I want to encode the RM locatable name with a terminology.
Archetype designer allows only DV_TEXT and no option to change it into DV_CODED… any idea how to do that except for editing the ADL everytime ?
1 Like
Actually you can:
The question is, why would you want to do that? Usually the name attribute in the RM will be filled with the same name of the correspondent node in the archetype. In the example of the image, the name of the observation instance would be “Blood pressure”, and this is filled automatically by most (all?) implementations generating data instances.
If you want to link that name to terminology codes, the way to go is by binding the archetype node to the codes you want, that is, a term binding.
2 Likes
Annotation via bindings is useless from a technical perspective, since its not queryable afaik.
Its a nice thing for modelers sure, but otherwise dust in the wind.
If you have a DV_CODED_TEXT then its obvious, otherwise its better to do it in the locatable because there its actually serializable and therefore queryable.
Well, you could also “copy” those bindings from the archetype to the data instances, but think of the implications: you are increasing the size of the instances with an information that, potentially, can evolve in the future (new codes appear that better describe the archetype node). Moreover, you will be repeating the same codes in every data instance.
I agree that in the WHERE clause of AQL probably some improvements could be made to better express a condition to be matched at the archetype level, not the instance level. The real power of AQL will arise when we learn to combine statements or filters over data values and filters over the semantics and terminologies that are bound to them.
1 Like
Well, the size argument is neglectable, since this adds semantic value.
Secondly, no one adds annotation nodes to an archetype all people do is bind annotation to them.
Just look at the example bloodpressure, so either there is a shift in the community or we add them to the locatable.
Adding new nodes like that would also just mean that you would require to rebuild the way we design and represent archetype to an DICOM/FHIResk way with system/codes as descriptors to each value.
About the AQL, i mean you could extend a AQL engine to pull that info from the bindings in the ADL, but that would also mean extending the AQL grammar, which may not be a bad idea.
I’d be inclined to add this as a name/value/mapping on DV_TEXT/CODED_TEXT rather than name/value/defining_code.
The only problem there is that it is not currently possible to constrain the mappings structure (in AD) , so that needs to be documented manually.
TBH I suspect it needs to be a little more complex than simple constraints.
1 Like
Hm not sure if i get your comment 100% right.
But in my case i need this for a Quantity lets say diastolic.
If you would add that as mapping to the DV_CODED_TEXT that wouldnt help me, except for doing it again in the locatable lol.
Also i think there should be maybe an option to encode different term codes to one node at once, except for term server query.
Sorry I confused you!!
I meant adding it to LOCATABLE.name.value.mapping. I think that is the approach that @bna took in DIPS.
See the Weight quantity element example below
<items xsi:type="OBSERVATION" archetype_node_id="openEHR-EHR-OBSERVATION.body_weight.v2">
<name>
<value>Weight</value>
</name>
<uid xsi:type="HIER_OBJECT_ID">
<value>9014f58f-47b1-4d06-a861-b0cce49711ee</value>
</uid>
<archetype_details>
<archetype_id>
<value>openEHR-EHR-OBSERVATION.body_weight.v2</value>
</archetype_id>
<rm_version>1.0.4</rm_version>
</archetype_details>
<language>
<terminology_id>
<value>ISO_639-1</value>
</terminology_id>
<code_string>en</code_string>
</language>
<encoding>
<terminology_id>
<value>IANA_character-sets</value>
</terminology_id>
<code_string>UTF-8</code_string>
</encoding>
<subject xsi:type="PARTY_SELF"/>
<data archetype_node_id="at0002">
<name>
<value>history</value>
</name>
<origin>
<value>2020-11-17T16:34:03.868Z</value>
</origin>
<events xsi:type="POINT_EVENT" archetype_node_id="at0003">
<name>
<value>Any event</value>
</name>
<time>
<value>2020-11-17T16:34:03.868Z</value>
</time>
<data xsi:type="ITEM_TREE" archetype_node_id="at0001">
<name>
<value>Simple</value>
</name>
<items xsi:type="ELEMENT" archetype_node_id="at0004">
<name>
<value>Weight</value>
<mappings>
<match>=</match>
<target>
<defining_code>
<terminology_id>
<value>LOINC</value>
</terminology_id>
<code_string>123456</code_string>
</defining_code>
<target/>
</mappings>
</name>
<value xsi:type="DV_QUANTITY">
<magnitude>630.52</magnitude>
<units>kg</units>
</value>
</items>
</data>
</events>
</data>
</items>
<name>
<value>Diastolic</value>
<defining_code>at003</defining_code>
<terminology_id>local
</name>
1 Like
The other factor re bindings is that these can only ever be advisory, since local SNOMED or LOINC use might be quite different.
We do need a better way to technically document how to populate mappings to be included in the data.
2 Likes
Another use case for this is to code the names of events, either in the archetype or in the template. I think we’ve discussed this before.
Edit:
Here’s the previous discussion: Coding element and event names - Clinical - openEHR
1 Like
It is technically possible to coerce the LOCATABLE/name to be a CODED_TEXT and therefore do something like
<name>
<value>Weight</value>
<defining_code>
<terminology_id>
<value>LOINC</value>
</terminology_id>
<code_string>123456</code_string>
</defining_code>
but @borut.fabjan persuaded me that this could get very messy.
1 Like
It would be interesting if you could elaborate what you mean here. (The same SNOMED CT concept has the same meaning independent of which edition is was included in.)
I just mean that the binding suggested by the archetype author might not equate to local use (rightly or wrongly)
And except for value sets I believe that this is something we need to work with in the future. 
2 Likes
Was there any further discussion about this in the SEC.
Since this problem will get more intense with the addition of more and more FHIR mappings made in the near future.
Otherwise, we should maybe define a guideline how to handle this in the meantime.
Thanks, that you were able to discuss this topic on openEHR.
Currently, I am modeling the medication order set in openEHR and I try to fulfill the following use case:
- The medication order set with 2…* independent medication orders includes a title.
- The user can configure a default order set and choose a title for this order set.
In the archetype medication order (openEHR-EHR-INSTRUCTION.medication_order.v3) the node “Order” in /content[openEHR-EHR-INSTRUCTION.medication_order.v3]/activities[at0001] provides the discussed attribute “name” inherited by the reference model. In order to fullfill these requirements, I would use this attribute.
My question: Would this violate any clinical modeling conventions in openEHR?
Hi Lucas,
First thing to say is that overriding the name/value as you are suggesting is perfectly legal.
However, if I am understanding your use-case correctly, we choose to approach this a little differently, in the case of needing to tag chemotherapy prescriptions/ administrations with the name of the chemotherapy protocol/regimen , which feels very similar.
We created a medication regimen cluster archetype, as we needed to capture other data beyond just the regimen/orderset name
1 Like
Well, well
something like AQL with support of ELEMENT class in the containment structure, which means that patient data can be retrieved based on common clinical concept codes (often encoded using SNOMED CT) without having to refer to openEHR archetypes.
1 Like
For sure, especially connected with a Termserver
Yet, the validation is still missing (which may not be important, since here we talk about “static” annotations).
Besides, i do have to annotate the mapping code for each composition, instead of e.g. defining that in the template.
At least using the LOCATABLE.