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