Simplify the ITEM_STRUCTURE package using a categorized ELEMENT container

http://www.openehr.org/mailarchives/openehr-clinical/msg02231.html

Pablo Pazos:
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().

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.

Rong Chen:
I agree with your analysis here especially the last one regarding evolution of archetypes.

Heather Leslie:
I model using ITEM_TREE as default in every archetype, except where we might need a table structure.
So I always aim to allow for maximal flexibility as the archetype evolves... and in almost every situation it does.

Sebastian Garde:
Yes - and if you want to go one further, ITEM_LIST is nothing more than
a special case of ITEM_TREE as well.
Modelling this explicitly hasn't been extremely useful I believe,
especially if weighed against your evolution argument.

David Moner:
I think Thomas has already mentioned that here there is a good possibility of harmonization with EN13606. At the end it seems that we only need single ELEMENTs and a container with list or table semantics.

Thomas Beale:
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.

Pablo Pazos:
Your comments are very interesting, and I think we all converge to the same point.

For the transition steps mentioned by Thomas, I think we could do quick change with backwards compatibility, adding things without removing the ITEM_STRUCTURE package.
We could do a fork also, and start to work in a new model without affecting current tools, and join the specs, tools and archetypes at some point on the future.