CR-000024 - Revert meaning to String in LOCATABLE nodes in openEHR data

Technical (archive)
1

Dear all,

this CR has been processed, but since it involves probably the most crucial piece of meta-data in the data - the archetype node ids which are imprinted into their corresponding data nodes - I want to ensure that we are doing the right thing, particularly by implementors. (original CR text - http://www.openehr.org/repositories/spec-dev/latest/publishing/CM/CRs/CR-000024.txt)

To refresh your memories:

  • archetypes have an id for the whole archetype, like “openehr-ehr-entry.blood_pressure.v1”, and node-level ids throughout the archetype, usually of the form “at0002” etc.

  • these ids are included in data generated from archetypes. The node ids are recorded in every node of the data; this is achieved by an attribute in the LOCATABLE class (Common IM, http://www.openehr.org/repositories/spec-dev/latest/publishing/architecture/reference_model/common/im/REV_HIST.html - note this version is the current release, without the CR-000024 changes)

  • this attribute used to be named “meaning”, and was of type DV_TEXT (allowing it to be a DV_CODED_TEXT as well), but CR-000024 proposed to alter that to an attribute called “node_id” of type String. The idea behind this change is that all you need in the data is the archetype node_id to be able to match data nodes to archetype nodes and process them. It also simplifies the XML considerably. Further work has shown that a function called “meaning” is useful - this function does retrieve the whole term from the archetype, in the language of the locale. Doing this means that the archetype must be available, and/or that in EHR Extracts, at least a copy of the ontology section of the archetype, where these terms are defined, is included.
    This CR has passed, and the changes been made and tested in software but not released. However, during ARB discussions it was suggested that the attribute name in LOCATABLE be changed to “archetype_node_id” rather than just “node_id”. Remembering that this is the name of an attribute in the data, the idea was that “archetype_node_id” makes it crystal clear that the value is a node id from the archetype, not some other node id being used in the data. In XML data, this one attribute, along with the archetype_id attribute (the one that appears at archetype root points in teh data) are the only two which will be expressed as XML “attributes”, i.e. appear inside the tag. This a) clearly separates these special attributes from the “real” data attributes and b) significantly facilitates XPath/XQuery processing (work so far suggests that we will be able to have very powerful Xpath-based data querying in openEHR systems that use XML).

The question to the implementors is: which name is preferable - “node_id” or “archetype_node_id”?

My recommendation would be that, if it doesn’t cause terrible problems to current implementations, “archetype_node_id” is better - it really is unambiguous, and doesn’t get in the way if at some future time we want some other attribute called “node_id” in the EHR information model. However, I know that we have said in teh past, and documented as such, the name “node_id”. So - what do implementers/would-be implementers think?

  • thomas beale

  • If you have any questions about using this list, please send a message to d.lloyd@openehr.org

2

Zit idd heel veel in ja..

Ik ga gelijk refactoren :wink:

Arthur

3

The question to the implementors is: which name is preferable -

> "node_id" or "archetype_node_id"?

I prefer "archetype_node_id" for the same reasons mentioned by Thomas. And I don't see any big problem caused by this change in our current implementation.

Rong

Thomas Beale wrote:

4

For us it doesn't matter. It will have some pretty big consequences for our implmentation, since we currently assume a DVText everywhere in the code. Since we are behind on the specs anyway (meaning not really keeping up), this won't yet be integrated, untill we have a go at catching up with the changes made to the specificion.

We would like to see some kind of deprecation however for changes to the openehr model, since it currently is already a very big puzzle for us to be able to use the new specs. Maybe it will somewhat clutter the specs, but currently we have to start downloading/tracking older revisions of the spec to get to what we implemented.
Example is the table_s which was renamed to item_table (with a whole new inheritence tree) in the specs, finding the right spec gave us a hard time (we didn't have the time to refactor everything to use the new structure).

You say :
This CR has passed, and the changes been made and tested in software but not released.

Which software and how was it tested ?

Mvgr,
Martin

Thomas Beale wrote:

5

Martin van den Bemt wrote:

For us it doesn't matter. It will have some pretty big consequences for our implmentation, since we currently assume a DVText everywhere in the code. Since we are behind on the specs anyway (meaning not really keeping up), this won't yet be integrated, untill we have a go at catching up with the changes made to the specificion.

Martin,

presumably your implementation is locked at an earlier baseline of openEHR around 0.9?

We would like to see some kind of deprecation however for changes to the openehr model, since it currently is already a very big puzzle for us to be able to use the new specs. Maybe it will somewhat clutter the specs, but currently we have to start downloading/tracking older revisions of the spec to get to what we implemented.

Do you mean you want to keep all previous details intact in the specification documents? I think we have a reponsibility to publish the latest version of any specification in a "clean" form for new implementors - after all the latest version is "the specification". If you look at the changes that have been made, there are currently 125 or so change requests - some of which have changed the way we present the material, some of which change the structure of the model. Now, the intention is that such changes will diminish over time, with the forthcoming release 1.0 being a stable release. And of course, there cannot be ongoing chopping of changing of the basic models. However I think we are still in a phase where we are getting feedback from implementors about what works and what doesn't.

I think it would be resonable to do what you say after the release of 1.0, and we will look into how this should be done. At the moment, we have tried to a) supply detailed CRs online and b) be careful to document all changes in the revision histories of the specifications and c) make sure that all the specifications compile in our modelling environment, before publishing them. It does mean that implementors have a certain responsibility to read the CRs (particularly the page http://www.openehr.org/repositories/spec-dev/latest/publishing/CM/CRs/CR_by_release.html) and the revision histories of documents. A new CR/PR system will make CRs more accessible, and the CM plan has been rewritten.

What would help us is better feedback from implementors - it has been hard to determine how many developers are at what stage in implementation, and therefore what impact any change will have. Hopefully the new "implementers" list will help that; other suggestions are welcome.

Another thing we will release in the next couple of months is a textual rendition of the entire RM and Archetype Model in XML form, using a UML 2.0 tagset. This expression of the model will be lossless from the specifications, and can be used to generate or validate other deliverables, such as XML-schemas, programming language interfaces, relational database schemata and so on.

Example is the table_s which was renamed to item_table (with a whole new inheritence tree) in the specs, finding the right spec gave us a hard time (we didn't have the time to refactor everything to use the new structure).

This change happened quite a while ago now - I would have thought nearly 2 years ago, but I would have to check that. Do you mean that it wasn't easy to work out what had changed? Suggestions on how to better provide such information are welcome.

You say :
This CR has passed, and the changes been made and tested in software but not released.

Which software and how was it tested ?

all modelling changes are made to the openEHR Eiffel model environment, compiled and tested in a basic way. This environment is used because it is the closest to UML that actually implements all UML semantics, particularly class invariants and pre- and post-conditions (otherwise known as "contracts"). I don't mean to imply that whole systems have been built with each change by openEHR - of course it doesn't have the resources for that. But most other specifications - standards - in the world are not even validated before being published, and so there is not even a minimum guarantee of implementability or coherence. In the future, with reference software implmentations in existence, we would use those to test changes before releasing them. This will include the emerging Java reference model implementation, XML-schemas and so on.

hope this helps.

- thomas beale