Dear all,
after quite a few months of experimentation and reflection, Sam Heard
and I have come to the conclusion that a modification is needed in the
semantics of the ontology section of ADL archetypes, to do with term
bindings.
The current situation is shown in the example archetype:
---------------------------------------------------------------
archetype
adl-test-OBSERVATION.apgar.draft
concept
[at0000] -- apgar observation
definition
OBSERVATION[at0000] matches {
-- apgar observation
data matches {
HISTORY[at0001] occurrences matches {1} matches {
-- history
events cardinality matches {1..*} matches {
EVENT[at0002] occurrences matches {0..1} matches {
-- 1 min event
data matches {
LIST[at0003] matches {
-- list
items cardinality matches {1..*;
unordered} matches {
ELEMENT[at0004] occurrences matches
{0..1} matches { -- cardiac score **************
...
}
}
}
}
}
}
}
}
}
}
}
ontology
primary_language = <"en">
languages_available = <"en", ...>
terminologies_available = <"openehr", ...>
term_definitions("en") = <
items("at0004") = <text = <"cardiac score">;
description = <"cardiac score in Apgar observation of neonate">>
>
-------------------------------------------------------
Now the question here is what does the 'term_binding' section of the
archetype look like? Currently, we simply list bindings from internal
"at" codes to external terms, such as snomed terms, as follows:
term_binding("snomed") = <
items("at0004") = <[snomed::123456789]> -- snomed term
for Apgar cardiac score
>
But what we should in fact be doing is binding external terms to
_paths_, e.g. the path:
[at0000]/data[at0001]/events[at0002]/data[at0003]/items[at0004], which
refers to 'cardiac score' in the context of an Apgar observation, and
not something else. There are undoubtedly other 'cardiac scores'
elsewhere in cardiology, and we don't want to mix them up. So the new
proposal would allow us to bind to paths, not just to terms regardless
of where they appear in an archetype. However, the latter _is_ something
we still want to do quite often - e.g. bind a snomed term to the "at"
code for "systolic blood pressure" regardless of where it appears in the
archetype. We can represent this as a path expression using the Xpath
approach, e..g "//[@meaning=at0004]" matches any node with the "meaning"
attribute set to "at0004". (We have not yet determined a complete
proposal for improving archetype paths to be completely Xpath -
compatible, but this work is also underway)
The result would be something like the following term_binding section in
an archetype:
term_binding("snomed") = <
items("[at0000]/data[at0001]/events[at0002]/data[at0003]/items[at0004]")
= <[snomed::123456789]> -- snomed term for Apgar cardiac score
items("//[xxxx]") = <[snomed::12313412414]> -- a context
- independent mapping
>
Where each string in the items() expression is an Xpath compatible
expression, rather than just a single internal "at" code.
Making this change will make the binding capabilities of archetypes more
general, while retaining the current capabilities, but does require
changes to a number of things, including the ADL specification, the path
syntax, the existing software, and all the existing ADL examples.
reactions?
- thomas beale
--
___________________________________________________________________________________
CTO Ocean Informatics (http://www.OceanInformatics.biz)
Hon. Research Fellow, University College London
openEHR (http://www.openEHR.org)
Archetypes (http://www.oceaninformatics.biz/adl.html)
Community Informatics (http://www.deepthought.com.au/ci/rii/Output/mainTOC.html)
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
