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.
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.
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.
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.
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.
Now, how do we proceed? I don’t know if there’s a formal way to do a Change Request to the RM. I don’t want to leave this issue to die on the lists.
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...
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.
My (clinician’s thinking) idea was to have ITEM_STRUCTURE inherit from Cluster (it is a fancy one anyway). This would make ITEM_TREE and ITEM_SINGLE redundant allow ITEM_LIST to be used as a constraint on Cluster to only allow ELEMENTS.
ITEM_TABLE could then have additional attributes .
The problem with this is that we currently use the RM inheritance to assist in these structure constraints, i.e. an ITEM_LIST only contains a CLUSTER containing only ELEMENTs. However, if you think about it, the semantics of CLUSTER and ITEM_TREE are equivalent. It is only the level in the model that is different. The question is, would it be helpful to have other ITEM_STRUCTURE subtypes within an ITEM_STRUCTURE, i.e. an ITEM_TREE containing an ITEM_LIST or ITEM_TABLE. This is certainly the case in CEN13606 with the mandatory CLUSTER.structure_type attribute.
I think we need to go back and ask, why are we trying to simplify ITEM_STRUCTURE? Are we doing it to simplify the RM, archetypes or data?
For me the data is of interest and it is about 10 years since I first questioned Thomas about the need for ITEM_STRUCTURE. Not only does it lengthen paths but it requires a whole level in data that is necessary and requires mandatory structural only attribute values such as node_id and name.
From a domain model perspective I see the value of supporting additional properties and methods on these sub-classes but in a persistence model they add no value, we just need to know which domain class to materialise. In XML this can be done using the built-in schema type attribute and this approach would support XML-class generator libraries, whereas using the CEN 13606 model defined attribute would require an additional adapter to materialise the domain model class. My point is, we probably need to separate the RM representation from the persistence ITS. Even with the current RM, we could probably simplify the XML schema to collapse this level of data, although we still need a way to represent the mandatory node_id and name attributes of the ITEM_STRCTURE. This would be easier if they were not mandatory, but that is topic for another day.
However, if we want a RM change with migration path, the minimal change that I can see is to make ITEM inherit from ITEM_STRUCTURE. We could make the ITEM_SINGLE, ITEM_TREE, ITEM_TABLE and ITEM_LIST sub type of CLUSTER but the only true sub type of CLUSTER is ITEM_TREE. In future we could merge CLUSTER and ITEM_TREE and remove ITEM_SINGLE.