Hi! Perhaps the following image with UML redesign useful as input for a 2.0 development fork: http://www.imt.liu.se/~erisu/2010/openEHR/RM-pencil.jpg The accompanying mail describing it is at http://www.openehr.org/mailarchives/openehr-technical/msg05285.html
I have right now submitted parts of that mail as a formal change request at: http://www.openehr.org/issues/browse/SPECPR-73 Feel free to add all your own thoughts from this discussion to that issue. The argument that there are systems with 1.X data is of course valid for refreshing 1.X one more time, but a 2.X version of the RM should not wait too long since we'd like to have as much as possible of future patient data to be in 2.X form. Does anybody have an approximate number indicating how many patient records are now in 1.X systems? Do you believe those system owners with real patient data could be able to convert data to a 2.X based systems, I guess there aren't too many vendors involved... Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 P.s. There was no way of specifying in jira that it could relate to a 2.0 release On Tue, Oct 4, 2011 at 10:32, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > On 03/10/2011 15:23, pablo pazos wrote: > > Hi everyone, > > I've been studying how to simplify the ITEM_STRUCTURE model to enhance the > persistence performance of our Open EHR-Gen project > (http://code.google.com/p/open-ehr-gen-framework). > > Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE > in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some > arguments and hear your comments about it. > > Semantic argument: As I understand ITEM_SINGLE, the semantics of this class > are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean > that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1). > > Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as > an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the > interface of each class can be the same, like: getItems(), setItems(), the > ITEM_SINGLE breaks that with getItem() and setItem(). > > if you have a look at the RM specification for ITEM_STRUCTURE (p13-), you > will see that the interfaces are quite different across all the classes - > the ITEM_TABLE type has table-specific accessor functions, and the LIST type > has an interface specific to a list. But... see below... > > > Evolution argument: If I have an archetype with an ITEM_SINGLE, but the > concept modeled with this archetype needs to change adding more nodes to the > archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but > if the archetype is modeled with an ITEM_TREE, I can add any nodes without > changing the ITEM_STRUCTURE type. I think this way is more simple to create > new archetypes with backwards compatibility. > > > What do you think? > > this seems to be the conclusion of people creating archetypes as well. It > has turned out over the years that archetype modellers are far less able to > stick to any particular data structure than one might have thought. I don't > think the statically declared RM type is the main issue in archetype > authoring - it is the archetype paths that really matter... but if neither > were to change over time, that certainly makes things easier. The two data > types we thought would be used quite often were ITEM_LIST and ITEM_TABLE. It > appears that these types have been used pretty rarely, although that might > just reflect which parts of medicine have been modelled. > > Sam and no doubt others have proposed simplifications to the ITEM_STRUCTURE > part of the model, and I would have no problem with simplifying it. > However.... there are already openEHR operational systems in existence and a > lot of tools and archetypes, so we can't simply make breaking changes to the > release 1.x reference model - and - ITEM_STRUCTURE appears in a lot of > places in the model. I have not made a proper analysis, but a general > approach to simplifying things would probably involve adding an attribute to > ITEM_STRUCTURE to indicate which kind of logical structure it was meant to > be (as in the 13606 model ITEM.item_category attribute), and then always > using an ITEM_TREE in archetypes. This would still enable the types > ITEM_TABLE and ITEM_LIST to be implemented in software and to be able to > 'adopt' the data of an ITEM_TREE containing the appropriate logical marker. > > Other more radical approaches will probably break the current RM and would > need an alternative openEHR 2.x RM. > > - thomas > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical >
