...
Thilo Schuler: Value sets (fixed or dynamic) may be a useful name for terminology bindings.
[A worked example|Terminology and value sets] of binding SNOMED subset to an archetype and a template is now available.
Term binding
Term binding is an ADL construct used to associate a language-independent string-label (e.g. at0005) with a specific term from a specific terminology. This allows for the name of a data point or Archetype node (as distinct from the corresponding value) to be identified as being the same as a specific term in a terminology. This, in turn, has the potential attraction of allowing language translations through the terminology, where they have not been done explicitly in the Archetype.
...
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.
Addendum
Sam Heard, July 2008
One issue that we probably should address in this document is that the 'binding' to terminology addressed here (and called semantic tagging) is just that. It is at present a tag of a code from a terminology to aid in determination of the meaning if it is ambiguous. On further reflection in discussions with Eric Browne, I wonder if this relationship should always be "Records" as an archetype is a structure for recording information about things in the world. This archetype records that. This might help us with the ambiguity that arises when trying to semantically tag the blood pressure archetype. I have retrieved the terms that have an IS_A relationship with 'Blood pressure (observable entity)' as one would expect that we could say:
openEHR-EHR-OBSERVATION.blood_pressure.v1 _records_ "Blood pressure (observable entity)", SNOMED-CT, 75367002
In fact this is not so ,as the blood pressure archetype does not record all of the children of blood pressure:
Term | Recorded using blood pressure archetype | Note |
---|---|---|
24 hour blood pressure (observable entity) | Yes | The time series will allow this |
Arterial blood pressure (observable entity) | ? | It is really systemic arterial, local should use intravascular pressure |
Arterial pulse pressure (observable entity) | Yes | Core data element |
Arterial wedge pressure (observable entity) | No | I do not think this is ever used for systemic arterial |
Diastolic blood pressure (observable entity) | Yes | Core data element |
Invasive blood pressure (observable entity) | ? | Is this the site of measurement? Not when someone is invading? |
Lying blood pressure (observable entity) | Yes | Position at the time of measurement |
Mean blood pressure (observable entity) | Yes | Mean Arterial pressure (per cycle) and average blood pressure over a period of time |
Post-vasodilatation arterial pressure (observable entity) | Yes | Need a state model to cover this |
Segmental pressure (blood pressure) (observable entity) | No | To measure limb pressure and covered by intravascular pressure |
Sitting blood pressure (observable entity) | Yes | Position at the time of measurement |
Standing blood pressure (observable entity) | Yes | Position at the time of measurement |
Systemic blood pressure (observable entity) | Yes | This is what the archetype measures in the broadest sense |
Systolic blood pressure (observable entity) | Yes | Core data element |
Venous pressure (observable entity) | No | Covered by intravascular pressure measurement |
Comparison with the mindmap image of the archetype might be helpful:
In conclusion, there is much work to be done to maximise the benefit from a close association between the data structures to be shared, the terminology that provides the content for these structures (value sets) and the semantic links with the data points themselves (semantic tagging). Forging a strong working relationship between the IHTSDO and the openEHR Foundation will assist greatly in this process.
References
David Markwell's work for UK NHS CFH program
...
- 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.)
- 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.
- [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.
- 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.
- Combining archtyped and non-/pre-archetyped data for research
- [Sam, cited from list discussion] A final part of the equation is the area that David Markwell has been working on in the NHS in the UK. He is investigating how to generate computable terminology code phrases from an archetype: that is, how to post-coordinate information captured in an archetype for inferencing in the terminology space. This has benefit in linking with the pre-archetype data and may allow complex research to be undertaken in the future using ontological tools and engines (full source: see mailing list thread).