I was reviewing some archetypes and on the “term_bindings” section there are always one-to-one bindings.
I think we can have many codes in one terminology corresponding to one at code in the archetype, e.g. in the blood pressure archetype we have:
I would strongly recommend against having multiple targets of "term
bindings", at least for the use case presented here. Multiple targets
should not be allowed unless the targets can be securely assumed to have
identical meaning. Binding nodes in the archetype to external
terminologies through the "term binding" mechanism has, possibly among
other things, the purpose of fixing/stabilizing the meaning of the node
by reference to some external source. I realize this is not easy, but
guidelines should be developed for selecting targets of term bindings,
e.g. like what is currently (kind-of) happening in CIMI, to minimize
variability and maximize reproducibility across archetypes and archetype
usage.
there are multiple, equally correct/useful/etc. perspectives on reality
and that is not a situation SNOMED CT or any other terminology/ontology
can ever resolve. No terminology will ever be perfect since 1. "perfect"
is not unequivocally defined, 2. human effort is error prone, 3.
computational complexity limits use of technology. Imperfections are
probably easier to agree on and SNOMED CT has its fair share of
those. However, quality programs have continuously improved the
situation.
Then, within those boundaries terminologies can be used, through term
binding [ADL2, 8.11.4], to add external references to the meaning of
archetype nodes. If the meaning of the archetype node is not clear,
neither will any term binding be. Term binding is not only useful when
comparing data to other IM frameworks, e.g. Act.code is often used
corresponding to an ELEMENT term binding, but also to maintain a larger
set of archetypes by allowing e.g. terminology-based queries.
In the example presented, there are at least three alternatives for term
binding OBSERVATION archetypes to SNOMED CT: a procedure, a finding, and
an observable entity. We would just have to agree on a set of patterns
for how (and if) to bind to ENTRY-ies, ELEMENTs etc. based on our
understanding of the meaning of the archetype nodes. A very tentative
such pattern for OBSERVATIONs could be:
OBSERVATION --> term-bind to <<386053000 | evaluation procedure
(procedure) |
ELEMENT --> term-bind to <<363787002 | observable entity (observable
entity) |
I think it makes sense to have just one term_binding per terminology, and if more than one concept on the terminology represents the same concept, the terminology has some problems and the archetype editor/reviewer has to make a decision on which code to use.
In the other hand, for one nodeID, different term_bindings can be created for different terminologies, that’s supported by ADL1.4 I think.
From the last example by Daniel, I don’t think it is correct to link abstract Information Model classes to concepts using term bindings, since, as you remark, those are abstract classes that are very generic, so they match several concepts. But, when those classes are on an archetype, as in my example, they represent very specific concepts (the recording of the BP in my example).
For me is clear that the desicion is on the archetype editor and he/she should choose just one concept code that matches that specific archetype node.
I’d also suggest one and only one term_binding to a particular (version of) terminology for each archetype node. I think this is essential to get the semantics right in the world of Semantic Web / Linked Open Data worlds as well. I think we’ll also see it is going to be used to link to unique identifiers (as in identifiers.org) to non-ambiguously define it which can then be used to link to other resources) – so I think essentially a URI could also do it. Something to consider in Specifications program. Another aspect to think about is a terminology query – it is not at the top of my head at the moment but I remember reading current specs there is room for improvement in terminology section. So the question is can we define the semantics of a node in real world not just by referring to a single term but a terminology query. One example comes to my mind from a current practical example I’m working on is to limit the problem/diagnosis to a list of conditions called Acute Coronary Syndrome, there are a few individual diagnoses in it. In SNOMED because of relationships it is possible to find a single concept but for other terminologies this may not be possible. We may also want to refer to a custom set of SNOMED CT concepts as well. Thoughts?
When it comes to terminology queries and SNOMED CT I would like to promote IHTSDO:s “SNOMED CT Expression Constraint Syntax Specification for Terminology Binding”. The specifications is currently in the “Public draft” status and can be accessed from http://ihtsdo.org/fileadmin/user_upload/doc/ .
this is an important point. I suspect that the meaning of archetype nodes (as defined by the internal coded terms) is ‘pretty clear’ in the sense that it assumes the encapsulation that the archetype provides. For example, the Apgar archetype has the following: [“at0009”] = < text = <“Respiratory effort”> description = <“Observation of the infant’s respiratory effort.”> > Here the meaning of ‘respiratory effort’ (id10 in the ADL2 converted form) is clear within the encapsulating context of ‘Apgar score’, but wouldn’t be on its own. One of the major differences between codes in archetypes is that they are (as far as I know) always defined on this relative basis, whereas SNOMED codes have to be defined on a fully qualified basis. I don’t claim that this makes archetype node meanings 100% clear, but it must go close in many cases, since one test is being able to classify real world data elements as matching (or not) the various elements, and I would suggest that by this extensional method, the ‘definition’ of nearly every archetype node is indeed accurate. I’m not sure if we should be doing this (maybe we should…), but the suggestion for OBSERVATION could be right, if ‘evaluation’ means something like ‘measuring’ or ‘observing’. If it means something like ‘assessing’ or ‘diagnosing’ then I would say not (but I assume the former, if it is a ‘procedure’). ELEMENT is used ubiquitously in openEHR (and 13606) models and would only correspond to an ‘observable entity’ in some. For example, it wouldn’t where it turns up in demographic structures like addresses etc, nor inside Instructions where it represents elements of orders, drugs etc. - thomas
I think Daniel used the << operator in the example without explaining it.
Page 16 in the document that Mikael recommended says:
"<< A” Either the compositional grammar expression A or an expression that is a valid subtype of it SHALL be used.
OBSERVATION → term-bind to <<386053000 | evaluation procedure(procedure) |
ELEMENT → term-bind to <<363787002 | observable entity (observable entity) |
oops - he did - but I missed in the formatting that he was being properly precise (and I can't even claim ignorance, I know the syntax well, I've been one of the reviewers of the drafts over the years).
So this puts a different cast on the question.
One of the things I believe we most urgently need to do in the ontology / terminology area is to actually establish an ontology whose concepts correspond to each archetype as a whole, and whose english-language mnemonic names are understood to be the short names we use in the archetype identifiers (i.e. things like 'apgar_score'). As mentioned in the Knowledge Artefact Identification <http://www.openehr.org/releases/trunk/architecture/am/knowledge_id_system.pdf>document, this ontology could potentially be situated under a new version of IAO <http://www.ontobee.org/browser/rdf.php?o=IAO&iri=http://purl.obolibrary.org/obo/IAO_0000027>\. Note that all archetypes in openEHR (and I would argue in health) are information objects _about_ some X, where X is some ontological entity. I.e. the general epistemic X IS-ABOUT ontological X relation.
In this sense, 'blood_pressure' doesn't mean blood pressure in the real world, it means 'result of observation of blood pressure'.
Things like Apgar are tricky because they are a first order information item, even in the real world. So the Apgar_result archetype isn't really 'about' Apgar result in the same sense. It's 'about' the health status of a newborn. I'm not sure what the ontologist's view of this is...
ENTRIES define the meta-data about one of five possible processes (ResultCollection/Observation, Inference/Assessment, Planning, Ordering, Execution
They express that as the result of one of these processes one or more statements about the patient system are documented.
Statements have the format:
topic T has as result R, where T is an entity and R can be many things: number, code, multi media, etc.
plus the context data dealing with: localisations in space, time and patient system, plus the particiapations, plys the reasons why, the method and confounding factors.
The Blood pressure that is documented is a named ‘panel’ consisting of two statements (systolic and diastolic) documented as the result of the ResultCollection/Observation process.
And Apgar is the same. It is a named ‘panel’ consisting of multiple statements that have the nature of a questionnaire for documenting and processing observations. It can be seen as a complex semantic ordinal.
Hi, we had quite a few papers recently about ontological aspects of clinical information models.
I’d be quite interested to hear from these authors – it’d be a great contribution. I really think we need to merry Semantic Web / Linked Open Data and openEHR approaches.
and SNOMED CT has its fair share of