Horst Herb wrote: > On Wednesday 20 September 2006 09:41, [EMAIL PROTECTED] wrote: >> The presupposition I read into your scenario is that all the data you >> describe is locked into a SINGLE document, like a database record locks up >> all patient info, where as under our model that would seem to be unlikely ( >> but not impossible). The matter is the granularity of the forms system you >> develop for your context. If each one of those users are recording >> different info on different forms then there is no concurrency issues >> whatsoever. Each form is stored in the database as a document linked by >> the patient identifier, and when you as the doctor retrieve the practice >> nurse's form of test results you see it EXACTLY as she recorded it, as if >> it were a piece of paper. > > I said I worry about concurrency *and* referential integrity. > > If you break up the document into multiple sub-documents (basically mapping a > document to a form in the simplest case?) you might run into situations where > you have to record the same parameter in multiple documents - e.g. blood > pressure in the context of an emergency visit, a diabetes visit, an antenatal > visit, a practice nurse encounter etc. - possibly represented via different > forms, possibly mapped onto several documents, but always the same entity - a > blood pressure reading. > > How to you handle it? If I refer in my own health record to the practice > nurse's record and she realizes she actually entered it for the wrong patient > the next day - how do you preserve referential integrity in such scenario > with your document centric paradigm? > > I am very interested in solutions for this problem - a more document centric > storage would make my work a lot easier if I could overcome these problems > myself.
We use a form/document-centric model for data collection in the open source public health data management system which we have been working on for a while now (and which approaches its V1.0 release). Our approach to concurrency issues is to use what could be called "hyper-optimistic locking". Basically, if user A starts to edit the data in a form for a patient at time t1, and then user B starts editing the same form for the same patient at time t2, and user B then saves the form at t3, and user A then saves the form at t4, which is later than t3, then our middleware layer detects this and merges the two sets of data on a data item-by-data item basis, and then informs user A when s/he saves that such merging has taken place and they might want to review the resulting record to check it is still OK. Nine times out of ten the automatic merging produces the correct result, at least for public health data collection. Might not be quite good enough for clinical settings - would need to be investigated further. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
