I just spent quite a few profitable hours today with ehr_im.pdf, which appears to be the main resource for understanding the "Information Model" or "Reference Model," available for download from the CKM web site.
Overall, it's a very well-written document that anyone trying design or implement any sort of EHR system should read. I'm left with a few questions about instantiation, isolation, persistence, querying and the impact of changes on stored content and querying. I hate to take valuable time for anyone to answer my questions, so maybe all I need are some more references. I'll first explain what I think I understand of how it all works. >From what I can see, the entire system consists of a hierarchy of classes, some, like the EHR, Composition, Instruction, Observation, Evaluation and Action are defined as part of the reference model while others, the archetypes, which are not part of the reference model, all inherit from one of these RM classes. There are other RM classes, like Entry, Navigation, Folder, Data_Structure, etc.) that are also part of the RM and are properties of the archetypes. EHR is the base class, containing, by reference, all the others. Navigational information inside the composition archetypes is apparently critical. The Composition type is the basic container for all other archetypes that might be used within a single "contribution." And templates specify which archetypes will exist in the composition types and in what arrangement. All of this seems quite clear. Several things would seem to follow from all this: To access even the smallest detail from the overall record, the software would need to request the entire record from the server, presumably in the form of a binary stream, deserialize it all, and then instantiate everything from the EHR class on down. It is somewhat analogous to loading a document of some sort, something you load into memory in its entirety before you can read anything from it. Am I mistaken here? Or is there a way to instantiate small pieces of it? That, it seems, would depend on the level at which serialization occurs, whether it is serialized in pieces or in one big blob (or XML document) or serializes it in smaller units. If it is all in one piece, how do you manage isolation? Can only one user "check out" the record at one time? Or does it work something like source control systems like SVN, where different people can commit to a common project, merge differences, etc? Once you obtain the binary stream from the server, you from then on know nothing of changes others might also be making. It would also seem to follow that when you want to save your work (say you added some composition) that you would serialize the entire record--which may contains years of information--and send it to the server as a fresh new document, completely replacing the old one, which, presumably, would be moved to some "past version" archive. Correct? If so, how do you cope with your storage requirements roughly doubling with every tiny addition to the record? I'm probably way off here; you've probably got an elegant answer to this, namely, some sort of segmented storage, with each composition persisted in its own little blob?? You have event classes and you have persistent classes, well described in the pdf. A persistent class would be something like a current drug list. Following on with my understanding, it would seem that any change to this list via a new composition submission, would effectively create an entirely new copy of the list, embracing any changes, however slight. Would the old one then be archived in the now-obsolete former EHR record? How, in all this, would querying work? Would the server itself have to deserialize and instantiate hundreds or thousands of complete EHR records in order to search within them? I understand that you do have some path information persisted outside the EHR blob, giving you some idea what is inside of what, but that would still not eliminate the need to do a server-side deserialization and instantiation in order to read specific information pointed to by the externally-stored paths. Or so I would think. If I'm right, how fast are your queries and what sort of hardware does it take to run them? Your documention is clear that navigation information within individual compositions is consulted in queries. That would seem to require server-side instantiation, and then, subsequent to that, probing the internal items piece by piece. Thank you very much for any help! Randy Neall With this as the structure, accessing the record would mean instantiating the whole mass of information, the complete record I suppose there would be nothing to stop some inventive engineers from persisting everything, down to the lowest-level element, in a regular relational database, but I suspect that would be a kluge. This is, after all, a system of classes -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130414/1142c3b8/attachment.html>
