Hi Eric, The serialisation in XML Schema should provide the basis for transformation I would have thought. If there is a standard transformation then we can share data based on a previous reference model.
Is that sensible? Cheers, Sam > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Erik Sundvall > Sent: Wednesday, 5 October 2011 6:58 PM > To: For openEHR clinical discussions; For openEHR technical discussions > Subject: Re: Questions about the necessity of ITEM_SINGLE > > 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 > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
