Often you see on mailinglists a notice how to unsubscribe. Maybe a good idea.
Bert On 04/15/2013 08:47 AM, irl at club-internet.fr wrote: > > 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 <mailto: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 <mailto:erik.sundvall at liu.se> > http://www.imt.liu.se/~erisu/ <http://www.imt.liu.se/%7Eerisu/> 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 > > > _______________________________________________ > 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/e64d520f/attachment.html>
