Hello,
In AQL it is possible to constrain the value of a node to one of the codes that are allowed for that value (as specified in the respective archetype).
To find patients with gender (snomed-ct:248153007) male (snomed-ct:248153007) I could write something like this:
SELECT e FROM EHR e CONTAINS DEMOGRAPHICS d
WHERE d.items[at0017].value = ‘snomed-ct:248153007’
Is it possible to identify the node of an archetype instead of its path parts (e.g. d.gender or d.items[at0017]) also with a terminology code, so the query would rather look like something like that:
SELECT e FROM EHR e CONTAINS DEMOGRAPHICS d
WHERE d.items[‘snomed-ct:263495000’].value = ‘snomed-ct:248153007’
I am not very experienced with AQL so the queries are probably already syntactically wrong.
Greetings
Georg
currently, this is not possible directly using AQL. However, technically it is possible to make a look-up within all archetypes to automatically retrieve the elements (and their paths) that have a matching terminology-binding (for example to the snomed code for gender). This path could then be used within an AQL query which can use the code for "male". I actually was thinking about building such a tool within HiGHmed make analytics quers more convenient, though we are still searching for a developer.
In openEHR as it stands now, the answer would be no, because the snomed-ct:263495000 code is just one binding to at0017. What is reliable in the data is the at0017 internal code.
In future, it is not out of the question that different types of OPTs would be generated that would treat bound terminology codes as if they were the structural ones, but this is probably a long way off. Some further ideas about this in the ADL2 spec, and also the OPT2 spec.
It also might not be hard to preprocess AQL queries written like this into the standard form, but that would require that the code snomed-ct:263495000 be bound uniquely to at0017, and no other node code e.g. at0015. So doing this would require stricter binding rules than we currently have, and which I think are not semantically justifiable.
I’m about to slightly disagree with Birger (or at least clarify!!) but it is taking me longer and I need to be offline for a bit!! Watch this space!
It is definitely possible to search on SNOMED terms both on the name and value attributes of the Element. What is more tricky is using the subsumption capablities of a terminology like SNOMED *(which is what I think Birger was saying). - that requires coordination between AQL and the underlying terminology server. This has been done by individual implementers but not in a generic way to date.
Would it not at least in theory be possible to ignore the atCode? We can already do searches that ignore archetype node Ids at a higher level. It would be challenging to implement but I can certainly see some value.
it's likely I am just plainly wrong here (or just only a little bit), so let me elaborate and find out
My understanding is: there are some archetypes with terminology bindings on element level, for example the blood pressure archetype. When I am creating a composition based on the definition described in the archetype, I store the measured values, e.g. for the element systolic blood pressure. This systolic blood pressure Element has a terminology binding to SNOMED ([SNOMED-CT(2003)::163030003). However, I think in reality there is hardly an implementation that explicitly puts this SNOMED code into the name field of this element within a composition for every single measurement (what is the added information?). However, if you want to retrieve data, you might like to use SNOMED codes (or any other terminology) to _identify the paths_ that match your code (this is how I understood the question of Georg).
Even when you had all the codes put into your compositions, AQL would still not be able to find out to which path this belongs, you need to be explicit about the technical path.
To my knowledge, there is no way to use the terminology bindings defined on the archetype or template (say "metadata") level to retrieve data from compositions using AQL, if they are not explicitly stored in the particular instances of elements (e.g. the name attribute) within a composition (which I feel would be sort of a redundant information as the semantics of the element in the path should be invariant and are already defined in the archetype).
Hence, what I have in mind is a look-up of all elements with a matching terminology binding that provides the candiate paths which will then allow to build your AQL query.
under the covers, I don't see the point - the archetype codes are the only completely reliable codes in the system because they are definitional in their archetypes.
At the AQL level, as I say, I can imagine some sort of pre-processing, but it depends on unique binding as far as I can see.
So far I don't see the point, but you might have a good example which would help us think better about this question.
We do something similar to your proposal in LinkEHR, when working with transformations of data. we developed several functions to gain access to the archetype ontology and metadata while processing data instances, such as getText(atNNNN, LANG), getDescription( atNNNN, LANG), getTermBinding(atNNNN)… Sometimes they are useful while working with data instances. And the same is applied to AQL.
In my opinion, it would be interesting to study adding add a set of such functions to AQL, to be available in any implementation. They would help to interact with the archetype structure and metadata properly.
In SIAMM every node can have any name/label.
Its meaning is carried in attached one or mode codes. One code that is required at minimal is from the set of Reference Coding Systems.
In openEHR as it stands now, the answer would be no, because the snomed-ct:263495000 code is just one binding to at0017. What is reliable in the data is the at0017 internal code.
Exactly.
For the data inside an EHR system the at0017 code is essential, the key thing.
But in terms of what it means for interpretation by humans and ‘intelligent’ services the SNOMED code is the key thing.
In essence OpenEHR/13606 binds Codes from Reference Terminologies to archetype/template structures inside EHR systems and messages or documents.
