Grahame Grieve wrote: > > 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. > > I think the main point here is that CODE_PHRASE and other similar parts of the openEHR model (and this applies to any model at all) that are modelled using an internal syntax string (which could itself be XML - who is to say it isn't?) implies quite strongly that the contents of the relevant attributes (CODE_PHRASE.code_string) are the business of some outside system, not openEHR itself. In purely technical terms, using a class modelling approach for such things may be the same as using the syntax approach - i.e. any code_string generated by a terminology server can most likely be modelled using a class model as well, something like HL7's classes. But.... * there is always the possibility that it can't - because the class model commits to one idea of terminology coordination, while the syntax approach leaves it open * the information model shouldn't dictate to the terminology environment how to represent its artefacts.
The key point about the openEHR approach in this area is that a CODE_PHRASE code_string is just a 'key' to a database that just happens to be a terminology service. The construction of the keys is the latter's business not the business of the client of the service. - thomas beale _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
