Page Comparison

...

The relationship between SNOMED and Archetypes is important in building semantic interoperability in health care. However it is critical that we do not bind terms inappropriately to nodes in archetypes that have unambiguous meanings which are not yet represented in the correct part of the SNOMED hierarchy. This will be tempting in the name of expediency. But to do so will do more harm than good.

Use cases for terminology references in archetypes

We should try to collect and discuss sse cases for terminology references in archetypes. I divided them into two lists for "terminology binding / value sets" and "term binding / 'semantic' tagging". Please amend the lists and discuss.

Here my definition of terminology binding vs term binding (in par with Eric's above):
Terminology binding - Stating the allowed value for an archetype leaf-node. Can be query based (dynamic, in ADL via constraint-binding) or predefined concept sets (static, in ADL via term-binding)
Term binding - 'Semantic' tagging of intra- and leaf-archetype-nodes with single terminology concepts (in ADL always via term-binding)

 Terminology binding / value sets

1. Definition of value sets (for value containing archetype leaf-nodes)
   • [Thilo] IMO there is no question that SNOMED concepts  (or concepts from other terminologies) are important to define value sets. This can be a predefined enumeration (static) or more preferably a query-based statement (dynamic). The advantage of a dynamic statement is that it adapts as the terminology is further developed. Unfortunately there is no standard way to express such queries yet.
   • [Further comments please]

Term binding /  'semantic' tagging

1.  Automatic translation
   • [Thilo] I agree with Eric that term binding is (currently!) very questionable for the purpose of automatic translation. But IMO there are other use cases for term binding (see 2. and 3.)
2. Export into non-openEHR formats
   • [Thilo] An archetype is self contained model and the meaning of its nodes is defined within the context that the archetype provides. I don't think an external multipurpose terminology can be more accurate. Thus, decision support should be developed based on archetypes and/or templates.
     But many non-openEHR formats are less semantically rich e.g. vanilla CDA (i.e. without a constraining template). In order to provide the best possible (most semantically rich) exports into the non-openEHR world the meaning that can be derived from the terminology could be helpful.
3. Terminology-enriched archetype-based decision support
   • [Thilo] Although most decision support will be based on the information in the archetype and/or template I think sometimes addional information (e.g. 'calf' is part of 'lower extremity' via ISA relation) can be gained from the terminology.