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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130415/f08631fb/attachment.html>
