...
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
Use cases for terminology references in archetypes
We should try to collect and discuss use 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
- 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.
- [Hugh] Ocean has a dynamic terminology query language that has been implemented and proven in its tools. This language has recently been put forward to the IHTSDO as a possible candidate for such a query language or at least as an input to the development of the same.
- [Further comments please]
Term binding / 'semantic' tagging
- 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).