This is very important, thinking about the strength of querying children’s of codes using e.g. a term server.
There is also the question how do this code appear in the composition ?
The binding from the archetypes should appear in the composition as term mapping.
Pulled from the archetype bindings.
1 Like
Do you use term bindings for that ?
Exactly, in theory AQL supports a function to query subsets (or even an ECL expression). But I don’t know if any provider implements this.
WHERE e/value/defining_code/code_string matches TERMINOLOGY('expand', 'hl7.org/fhir/4.0', 'http://snomed.info/sct?fhir_vs=isa/50697003')
In the data instance, the code goes into the name attribute of the RM class. I could be inside the mapping of the DV_TEXT, or a defining_code of a DV_CODED_TEXT.
<items xsi:type="ELEMENT" archetype_node_id="at0004">
<name xsi:type="DV_CODED_TEXT">
<value>Sistòlica</value>
<defining_code>
<terminology_id>
<value>SNOMED-CT</value>
</terminology_id>
<code_string>271649006</code_string>
</defining_code>
</name>
<value xsi:type="DV_QUANTITY">
<magnitude>111</magnitude>
<units>mm[Hg]</units>
</value>
</items>
1 Like
Yeah but what about e.g. DV_ORDINAL answers, the only real consistent solution here is using term_mapping tbh (if its not a DV_CODED per se).
Also DV_CODED allows only for one coding, what about LOINC?
Bind codings to them, render it into the composition using term mappings.
1 Like
The symbol of the DV_ORDINAL is a DV_CODED_TEXT, so you should be able to filter the values that you are looking for in the WHERE clause.
I thought I was brave enough by wanting to search ELEMENTs by its term mapping, since we should be careful with the context where those elements are used. I can’t imagine querying for a DV_ORDINAL value (i.e. select any DV_ORDINAL whose value is “sitting”) without selecting at least the appropriate ELEMENT first.
Regarding the multiple codings, the only solution is to use the mappings attribute of the DV_TEXT to put there the equivalent codes.
We provide the keys i.e. rubrics - which are either archetype text fields from archetype terms, or may be something adjusted from that - to LOINC.org and they give us provisional codes (which are proper LOINC codes, i.e. NNNNN-N numerics), and then they review later. So sometimes they may rescind a provisional code (or maybe its meaning).
We’re about to test this process with LOINC for the first time this week, so I’ll report on how it goes.
It might seem weird extending LOINC to ‘everything’ when most people are used to thinking of it as a lab coding system, but given the LOINC / SNOMED collaboration, it seems to make sense - Snomed enables subsumption between LOINC codes to be asserted.
We have also worked out a way of marking archetype fields with ‘canonical LOINC codes’. Example: the LOINC code for ‘body temperature’ would be used instead of any specialised variant such as ‘body temperature, tympanic method’ (a typical precoordinated LOINC code).
More soon.
1 Like
Can you share the compo?
It was in a previous message 
I speak of the DV_ORDINAL answers, why shouldn’t you not query on answers ?
There are other examples, also then you will have term mappings + a coding in the DV_CODED_TEXT name, also sometimes you have atcodes as answers you annotate term mappings.
I mean both are ok, but i rather like to have my codings all at one place 
I did not say that you cannot query them, I said that probably you first need to query the question (the container ELEMENT), and then filter the answers you need in the WHERE clause.
1 Like
Sure, but what do you do if the ELEMENT coded text uses a LOINC code as name instead the SNOMED code you expect, the SNOMED code on the otherhand is contained in the term mapping to the LOINC code.
Then you need to query for both on the name, i think just using the term mappings here makes things easier, covers all at once
All eggs in one basket, except for typical DV_CODED_TEXT which again often have at000* as local codes, which you also dont want to change or replace with snomed and rather annotate with term mappings.
Better just added a autogeneration to the compositions of termmappings using the Bindings of the archetype in the latest release, i think thats a very elegant solution and the way to go.
Can we maybe strip this out as a separate conversation on how to make mappings easier to query and to document? It is becoming an increasingly common issue as the use of LOINC and SNOMED becomes more universal.
2 Likes
Is this done automatically when storing a composition?
1 Like
Yes, as far as i understood it, you can export the composition then with/without it + its searchable via AQL.
The ability to ‘push’ term mappings has actually been in the Better Ehrscape /composition POST for some time but I think ti only works on LOCATABLEname/value and
It is applied at run-time per-composition, not in the template.
and generates somethinh like this
{
"@class": "ELEMENT",
"name": {
"@class": "DV_TEXT",
"value": "Systolic",
"mappings": [
{
"@class": "TERM_MAPPING",
"match": "=",
"target": {
"@class": "CODE_PHRASE",
"terminology_id": {
"@class": "TERMINOLOGY_ID",
"value": "SNOMED-CT"
},
"code_string": "271649006"
}
}
]
}
}
which was what I was suggesting in the other thread. I think it many only work on name/value.
What is new in Better CDR 4.0 is the ability to query an ELEMENT for one of these terms , regardless of the parent archetype context.
This uses a code predicate. Not how I might have done it but I guess it aligns with the FHIR approach.
SELECT
sys/value as Systolic,
dia/value as Diastolic
FROM COMPOSITION c
CONTAINS (ELEMENT sys[code='SNOMED-CT::271649006'] AND ELEMENT dia[code='SNOMED-CT::271650006'])
1 Like
What also new is that they can pull/generate Term mappings out of the Term bindings of the archetypes.
If it works only for LOCATABLE name/value idk have to try it.
Back to my initial question, I tested with the new EHRbase v2.0 as suggested by @birger.haarbrandt and now it works perfectly, an AQL like this returns the list of all ELEMENTS without any problem
SELECT ele FROM EHR e CONTAINS COMPOSITION c CONTAINS OBSERVATION o CONTAINS ELEMENT ele
5 Likes
For readability of this thread, I moved some AQL relevant posts to Improve AQL to simplifying the querying of terms to continue there on AQL specifics. Some other RM related posts are at How to make mappings easier to query and to document in openEHR topic.