Hi Horst, in writing my answer to you last night I have been thinking about some of these problems through the night so hopefully this answer helps. May I shift the metaphorical description or modelling of what we are trying to do away from your representation first. We think of the the "patient record" as being a "patient story" because "records" are for structured (typically relational) storage. For us each episode in the story is a form that is completed by someone (anyone, even the patient). The repository then has to collate the story from the episodes and re-present it to any enquirer when asked- that is the retreival aspect and we call those retrievals of "passive" episodes/forms. However there is another type of episode which we call "active" which is a derived or computed or analytical form and these can be either automatically generated (as needed in an ED) or manually created as needed by an analytical enquiry ( which importantly is not a retreival enquiry). What you are now proposing is that we need a variant of the analytical page which I will call a "compilated" page, that is a page that has defined in it information from passive pages that are a compilation of content from those pages. So the compilation page needs a function to refer to content on other passive pages but also to accept conditions to that content such as "most recent value" and even a floating cursor that would show you a list of the last x number of values. Thanks for pressing us on that issue.
In terms of entering data for the wrong patient I'm not sure what referential integrity you want to preserve. Clearly the data has to be taken out of one episode and possibly the whole episode removed as it was allocated to the wrong patient. Then the data placed in the correct episode if it exists otherwise a new episode has to be created. Conceptually that requires a function "transfer episode to another patient" - not a problem computationally. So what happens if there is a system crash in the hiatus between requesting the transfer and executing the correct storage - that has to managed by the rollback functionality in the repository store, and is the same issue for any management of data in a persistent store. cheers jon Quoting Horst Herb <[EMAIL PROTECTED]>: > 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. > > Horst > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
