Dear all, here is another important CR to consider in the next few weeks.
CR-000024 - Revert "meaning" to String. See <http://www.openehr.org/repositories/spec/latest/publishing/CM/CRs/CR-000024.txt>. This CR is about the meaning attribute defined on the class LOCATABLE (see Common Model, Archetype package, at <http://www.openehr.org/repositories/spec/latest/publishing/architecture/reference_model/common/im/REV_HIST.html>). This attribute is one of the most important in the whole reference model - it is effectively the node id of every node in an archetype, and it is what gets imprinted into data, so that the latter can be reconnected with its archetypes. It also has a second purpose: it is coded in the archetype, giving it a normalised meaning in multiple languages, e.g "systolic pressure", whereas as the node name might have been set by the user to "sys BP" or whatever. Currently, the attribute is of type DV_TEXT, meaning it could be a DV_CODED_TEXT as well (see the data types reference model for these types - <http://www.openehr.org/repositories/spec/latest/publishing/architecture/reference_model/data_types/im/REV_HIST.html>). Given that every single node in data will contain this item, it has been proposed by Sam, and now more recently by the DSTC that it should be reverted to just a String expressing the code (it must be an "at" code, of the kind you see in the archetypes), because to use a DV_CODED_TEXT means there is a DV_CODED_TEXT object, a CODE_PHRASE object, with the latter containing 2 Strings. The DSTC have shown that in the XML of the data, this causes quite a bit of bloat. Sam Heard has always contended that we should just used the code as a String; the pracical consequence of this is that you must have archetypes present to interpret the node id. Dipak Kalra has always contended that it should be present as the full coded term, so that the normalised meaning is available in the data (well, in one language at least), without referring to the archetype. It is also important to realise that the expression of the 'meaning' attribute as a simple string such as 'at0001', 'at0045.1' etc (codes derived from the archetypes) provides an easy way to support path based querying in XML data, using Xpath. A path of the form .../events[@id=at0014]/... can find the node marked with the arhceytpe node id (= meaning) 'at0014'; a concatenation of such patterns enables nodes to found anywhere in large trees of XML data. It has also been argued that the name of the attribute - 'meaning' should be changed to e.g. 'node_id', or even just 'id' - whcih would not harm the comprehension of archetypes, and would be more obvious in data. reactions? - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
