Could you please take me off this distribution list Thank you
Norbert Lipszyc ======================================== Message du : 15/04/2013 08:45 De : "Erik Sundvall " <erik.sundvall at liu.se> A : "For openEHR technical discussions" <openehr-technical at lists.openehr.org> Copie ? : Sujet : Re: Trying to understand the openEHR Information Model Hi! Good questions! Many of the questions regarding versioning etc are explained in chapter 6 of http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf I'll briefly address some questions and hope others have time for the rest and more details. On Mon, Apr 15, 2013 at 5:07 AM, Randolph Neall <randy.neall at veriquant.com> wrote: >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. This is one of the parts that openEHR-learners often find tricky. Archetypes do _not_ "inherit" from the RM classes in the ordinary object-oriented sense of the word inherit. The archetypes can bee seen as a list of external validation rules, names etc describing how to pick, name and combine pieces from the RM for a specific clinical purpose. (To "name" a piece here refers to setting a value of a specific attribute of the object, not changing the RM class name.) The serialized EHR data for a patient only contains RM objects that in turn contain references to the archetypes that were used for naming and validating this particular combination of RM objects. I don't know if that simplified explanation helps. It might be a start. 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? I think most implementations work with pieces the level of VERSIONs of VERSIONED_OBJECTs (for example versioned compositions) or smaller when storing and querying data. See the previously linked common_im.pdf Or does it work something like source control systems like SVN, where different people can commit to a common project, merge differences, etc? Very much like a _distributed_ version control system, for example GIT. 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. Actually they are instantiations of the same COMPOSITION class, just with different values for one of the attributes. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130415/543cc85d/attachment-0001.html>
