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 <http://www.openehr.org/releases/1.0.2/architecture/rm/data_structures_im.pdf> (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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20111004/89b31518/attachment.html>
