Coding archetype concepts and nodes using terminology

Clinical
4

@Dileep_V_S

As Diego has said, your question really relates to the ‘Node names’ that we apply to archetype nodes, not to their ‘Node values’

i.e to ‘Systolic’ not to ‘120 mmHg’ or to ‘Causative agent’ and not to ‘Penicillin’

For both Node names and node values, there are 2 different concepts to consider

  1. Node name bindings

These are suggestions for ‘binding’ the native ‘atCode’ node name to one or more external terminologies - this is what you are seeing in the Blood pressure example, and others in CKM etc. AFAIK all of the archetype tools support this, including the Ocean editor -> go to the Terminology tab.

However these are only design-time ‘suggestions’ - they are not automatically carried in any data instances.

  1. Node name mappings

If you want to carry the other external terminologies in the composition data instance, alongside the ‘atcode’ which remains the defining_code, you have to use the mappings attribute that is part of the Reference Model DV_TEXT (and DV_CODED_TEXT) datatype

Have a look at the LOCATABLE class and the name attribute, click through to DV_TEXT then the mappings attribute to to look at TERM_MAPPINGS - this is what is carried in the data and will be queryable via AQL

Something like this … (Not checked - might be wrong in detail!!)

select
    a_a/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude as systolic_magnitude,
    a_a/data[at0001]/events[at0006]/data[at0003]/items[at0004]/name/mappings[0]/target/code_string as systolic_name_defining_code
    
from EHR e
contains COMPOSITION a
contains OBSERVATION a_a[openEHR-EHR-OBSERVATION.blood_pressure.v1]

As @yampeku has said, at least for SNOMED-CT, this is where the fun starts :slight_smile: If you are looking for a specific code, you can do a simple lexical match but if you need the inferencing power of SNOMED-CT, you need to hook this up with a terminology server such as SNQuery, OntoServer etc, to do the hard work. We know this can work - several groups have done it in the past - the Highmed guys are currently working on a way to use FHIR Valuesets as a vendor-neutral approach, and there is related specifications work to standardise this for openEHR (and allow vendor-specific approaches as well).

So bindings are only in archetypes, mappings are what are carried in the data. We do not automatically force bindings to be carried as mappings as local requirements will vary, and as Silje says, the bindings are so far not really assured - this is actually quite hard work and I’m not convinced that it makes economic sense to do it at scale but here are probably key elements where it might be worthwhile.

3 Likes