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: > > 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 at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
