Hello,
How do I constrain the Analyte result of a laboratory_test_analyte.v1 ?
The Analyte result are defined as an ELEMENT that is only constrained by a node predicate (i.e. ELEMENT[at0001]). Therefore the results cannot be bound with a specialized type and an alias within the FROM part, as in the FROM part only archetypeID-predicates are allowed and no node predicates. As the result is defined with the abstract ELEMENT type, which has an abstract DATA_VALUE as its content, no paths can be defined that constrain specific aspects of subclasses of DATA_VALUE that are actually stored in the ELEMENT[at0001] field of the test_analyte.
How can this problem be resolved ?
Greetings
Georg
Hi Georg,
Just to be clear, are you trying to specialise the openEHR-EHR-CLUSTER.laboratory_test_analyte.v1 archetype for specific analytes, e.g. serum sodium, TSH etc?
- thomas
Hi Georg
The instance data will actually have been subclassed to have a specific datatype and therefore the relevant attributes.
Therefore if you know that a particular analyte is a quantity, you can use aql to access the data just as if it had originally been modelled specifically as a quantity.
If you do not know the datatype you should still be able to pull back the whole element as an object and process it further after figuring out the datatype.
I’ll try to an example when I get to my laptop. Too hard on the phone.
Ian
Hi Georg,
Please note that you can always define your FROM clause with a high level node such as an OBSERVATION o[archetype_id] and access the particular path you’re interested in using a path starting from o as in o/data[..]/…
Regarding your assumptions re FROM clause, technically there is nothing stopping you from writing a query such as SELECT x FROM EHR e CONTAINS DV_CODED_TEXT x. As useless as it may be, this is valid AQL and it asks for all the DV_CODED_TEXT instances in all compositions under all EHRs
However, it is likely that most AQL implementations won’t let you run this query simply because implementers don’t want to pay the multi-dimensional price for supporting a theoretically possible but useless-in-real-life use-case. I’m telling this only because your comments sounds like you’re assuming archetype node ids are mandatory in the FROM clause. They’re not, from a syntax standpoint and maybe we should close that gap in the specs.
So use the SELECT clause to define a path from the Observation and the aql implementation should give you the element you’re interested in based on its archetype node id. Whatever serialisation format the back end uses (json/xml), you should always get an attribute or a json field telling you the actual instance type of DATA_VALUE, which you can use to process data. It is really no different than any subtype based polymorphism implementation where you’re given a base (sometimes abstract) type and you need to figure out the actual type during runtime.
All the best.
S.
Hi Thomas,
It depends on what you mean with "specialise". I do not wish to create a new archetype but I rather would like to query existing instances of the openEHR-EHR-CLUSTER.laboratory_test_analyte.v1 archetype. From those instances I would like to query only this with specific attributes. One constraint I am able to define is to constrain the analyte name:
SELECT e
FROM EHR e CONTAINS CLUSTER a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]
WHERE a/items[at0024]/value/value = 'Calcium'
But how can I manage to as well constrain the value ? The path openEHR-EHR-CLUSTER.laboratory_test_analyte.v1/items[at0001] is of the type ELEMENT, which has a DATA_VALUE for its field "value". The concrete instances of the analytes do have decendents of the DATA_VALUE type in the place for ELEMENT[at0001]/value, e.g. DV_QUANTITY. Is it possible to use paths to those concrete value types in the WHERE-paths, such like:
SELECT e
FROM EHR e CONTAINS CLUSTER a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]
WHERE a/items[at0024]/value/value = 'Calcium' AND a/items[at0001]/value/magnitude > 100
From a type checking point of view, this is not allowed, because the data type at the path a/items[at0001]/value (which is DATA_VALUE) does not contain a field "magnitude". To make this work I would have to bind the value to the concrete type, with something like:
SELECT e
FROM EHR e CONTAINS CLUSTER a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]
CONTAINS DV_QUANTITY b
WHERE a/items[at0024]/value/value = 'Calcium' AND a/items[at0001]/value = b and b/magnitude > 100
but I don't think this is allowed in AQL. I am not yet that fluent in AQL, so I could need a little help in this.
Greetings
Georg
Well, at the risk of stepping on Ian’s toes (he has spent a lot more time on these particular archetypes and also AQL in general than me), I would say that what we need to do is to create a data-type specific version of this archetype for each DATA_VALUE descendant, e.g. openEHR-EHR-CLUSTER.laboratory_test_analyte_quantity.v1 etc. For example, I did these test archetypes some time ago to illustrate just this:
openEHR-EHR-CLUSTER.laboratory_test_analyte_quantity.v1
The definition of this is:
definition
CLUSTER[id1.1] matches { -- -
/items[id2]/value matches {
DV_QUANTITY[id0.16] matches {
normal_range matches {
DV_INTERVAL<DV_QUANTITY>[id0.17]
}
other_reference_ranges matches {
REFERENCE_RANGE<DV_QUANTITY>[id0.18] -- Quantity reference range
}
}
}
}
You can see a few others here in the ADL2 test archetype Git repo.
- thomas