Hi Sam some responses
> The first issue to note is the ANY class which contains a number of complex > attributes not shown in the package. nullFlavour is dealt with in CEN and > openEHR at the ELEMENT level which is far more appropriate in systems - ie > test > the datavalue, if it is Null then test the flavourOfNull on the element. As > HL7 > does not have the idea of container, this has to be here. All the other > attributes are dealt with at different levels (eg Template Id which may apply > to > an ELEMENT but never to a data value. Adding these to CEN would cause major > duplication, increase complexity without benefit and deteriorate performance. well, the concept of the ISO datatypes (also true for 11404) is that you can have direct and indirect conformance. If you are claiming indirect conformance (which will be true for HL7 and openEHR), then you must provide a mapping that explains how your implementation differs from the ISO datatypes as they stand. I have drafted an openEHR mapping - but it's just a series of notes at this time. But the openEHR mapping would explain all these things above and ANY would not have these properties. The same would apply to 13606. > The next issue is the inheritance hierarchy. In systems one would expect to > be > able to substitute on the basis of specialisation. While we can write > invariants > occasionally for good reason to prohibit this in some situations, generally > this > should apply. What strikes me about the inheritence model here is that it is > really a way of constraining the large class 'Term' for particular purposes. > Take for instance CV - it is a term that has translations added (CD), and > then > has qualifiers removed (CE) then has translations removed! While there may be > use cases when Term has all the attributes it does, this hierarchy cries out > for > remodelling! > Further, is it usable? How would clinicians know which one to use in an > archetype? yeah, I have some sympathy for this point. CE/CV are just constraints on CD, and defining them as separate types is rather inelegant. For mapping purposes, I'd simply drop CE and CV from openEHR & 13606. Since Term and Translation are private types, that simply leaves CD : coded value. That's not had for clinicians to pick between ;-) > Translations are the equivalent of the openEHR mapping. By including all the > text and qualifiers in translations one may find a good deal of difficulty > understanding the meaning. well, translations may require qualifiers. And the openEHR spec (rightly) allows this too. as for text on qualfiers and translations, this is an interesting point. To be really precise and pedantic, there are use cases for this. But if you aren't really concerned with being pedantic and precise, you should be able to ignore these things. I guess this is something I could usefully add to the spec - that the meaning of the text associated with qualifiers and translations can never have any independent contribution to the meaning of the whole term - I'll have to think about how to phrase that properly. > The issue of qualifiers is a large one and while the argument for the HL7 > approach is that this provides a syntax for coordination of terms, it is not > expressed in the model. CR is ambiguous from my point of view with two terms > that are both optional and the value may have translations and qualifiers. > Perhaps a computable set of rules will arise for how to control this space > but I > suspect some gnomes will be required. This approach was first published in > GEHR > in the early 90s and has been dropped in openEHR as it was deemed unworkable > from a semantic point of view. One can argue that the CODE_PHRASE in openEHR > is > as problematic potentially - but as it is provided by a terminology service, > it > is far less likely that enthusiastic implementers will start adding data > willy > nilly. So the HL7 qualifier thing is (mostly) simply a predefined expression syntax for post-coordination. It overlaps with terminologies that have their own expression syntax - such as SNOMED. The HL7 model does allow a richer expression of the details of the construction of the expression - such as which text led to which qualifier, but this is, as I said, for precision and pedantry. Not for normal everyday use. So the question is, is it better to squeeze things into the text of a CODE_PHRASE, or to squeeze things into xml? Either way, you need to have a terminology service to do anything useful with the data. So what's the difference? I don't have a strong feeling about that. Grahame _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
