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.
1 Like
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.