Brett, > I know what you are saying about RIM semantics but aren't the > openEHR RM classes, OBSERVATION, INSTRUCTION, EVALUATION, > etc. implying a general weak clinical semantic as a framework > for hanging stronger semantic archetyping. I can imply > certain things about a stored openEHR OBSERVATION based on > the openEHR RM definition without knowledge of the archetype > applied to it, for a start it is considered an observation > not an instruction for instance.
As you say, they are very generic concepts and effectively only represent the class of the concept and the pattern for its data compared with a instance of the concept. This is analogous to the RIM classes on the UML diagram, but this is not where the semantics are carried, the semantics are in the RIM vocabulary. The equivalent of this RIM vocabulary are archetypes without the more clinically intuitive and extensible data definition capability. > > As for terminology binding for consistency we would need to > ensure that the use of terminology binding in leaf nodes of > archetypes was controlled enough to ensure that the > granularity of the concept matched the allowed data > constraints at the node and also that concept either did not > appear in other archetypes or matched exactly in terms of > constraints to data. It is what it is...there are no choices here. Exactly what is done in templates. You can also have Cluster and Data Element Archetypes to support the reuse of lower-level concepts such as Body Site etc. > We could also ensure that terminology bound child nodes in an > archetype definition can be related to the parent terminology > binding in a known way; this might be made explicit as a > SNOMED-CT hierarchy. Parents and child nodes are related > through a relationship this is not explicitly stated in > archetype definitions at this point. Not explicitly, but there is a reference to a pre-defined code set that might be a result of applying a complex query of relationships on a hierarchical terminology such as SNOMED-CT. For example, all the Herpes related viruses. This result set is stored in a Terminology Server such as the Ocean Terminology Server and can be accessed by a system using the archetype using the code set reference. This a bit like the HL7 V3 Vocabulary domains to external vocabularies but more fine grained and less pre-coordinated. For example, the Australian code set of Herpes related viruses may be different to the UK. Heath _______________________________________________ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
