Coding archetype concepts and nodes using terminology

Many of the archetypes in CKM (for example Blood pressure - have their concepts and nodes coded using SNOMED CT. I have the following queries regarding this

  1. What tools can be used to do this? Can we use archetype editor and template designer for this? BTW, I am also not able to view these coding in template designer and archetype editor.
  2. Once such coding is done, do the do they become part of every instance of the template?
  3. Can we retrieve such codes suing aql?


1 Like

In archetypes there are both “label” and “value” terminology bindings. Label/term bindings tell the meaning of a node, a given node, and value/constraint bindings show you the valid codes a node can take. Depending on what you are interested in, different tools can be used. In general, all tools make you accept a license that you are indeed in a country part of IHTSDO.

If you are interested in the label/term bindings (in your example, at0013 is binded to [SNOMED-CT(2003)::246153002 | Type of cuff (attribute)]) then you can use SNOMED CT browser to define these mappings.
If you are interested in value/constraint bindings, these are defined by stating the valid codes (extensional) or by providing a expression that gives those values (intensional). e.g. “all viral diseases caused by coronavirus”. For these “value sets” you can use tools that let you query the SNOMED hierarchy, such as SNQuery

The answer for 2 again depends on which kind: label bindings only live on the archetype, you can easily get them by the at-code from the data instance. For value bindings, you will find one code of the valid ones in the data instance. It should be part of the defined value set, or else the data instance is not valid.

For 3, I’m not sure all servers allow querying data by the label bindings yet, but it is intended to define a standard way of connecting AQL queries to FHIR-like terminology services


Thanks to @yampeku for good answers!

I’d also like to add that none of the current bindings in have been through any kind of review, and should not be counted on to be correct.

(Reviews for archetypes in CKM are done separately for content, translations and terminology bindings. Thus, even archetypes whose content is in the published state, may have completely wrong translations or terminology bindings.)



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!!)

    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.



Thanks Diego, Silje & Ian. That was helpful

As Ian points out, I was talking about ‘Node names’ and not ‘Node values’.

I think the ‘node value’ part is quite intuitive and clear. We already use it in actual practice and use a SNOMEDCT server to code data into a composition and also query them using AQL. This is done at the application where a type ahead search brings up matching values and the user chooses the most appropriate one. (BTW, India is a member of IHTSDO and so have a license to use SNOMED CT freely.)

However the coding of ‘Node names’ into composition was not something that I was not very clear about. Ian’s reply has made things a lot more clearer. So the ‘bindings’ are put there during design for reference and may be used to create ‘mappings’ on the node names at instance creation. And if this is done, they become queryable. However this coding may not be a run-time user decision, but a decision to be taken during application development.

Will test this out

Yes that’s it - there was some discussion about automatically generating mappings where bindings are found but this could get really messy, and given issues are around ‘correct’ use of codes, potentially risky, though it would be nice, in templates to be able to force a mapping to be created at an individual node level.

1 Like