I am not sure where this fits in, anyway.
Given an AQL for the latest systolic like this:
select
o/data[at0001]/events[at0006]/data[at0003]/items[at0004]
from
composition c
contains
OBSERVATION o[openEHR-EHR-OBSERVATION.blood_pressure.v1]
order by o/data[at0001]/origin desc
limit 1
I will return a representation of an ELEMENT where the value is a DV_QUANTITY.
For this value object you might navigate further into the attributes like i.e.
<path>/value/magnitude to get the number 160.0.
{
"_type": "ELEMENT",
"archetype_node_id": "at0004",
"name": {
"value": "Systolisk"
},
"value": {
"_type": "DV_QUANTITY",
"magnitude": 160.0,
"units": "mm[Hg]"
}
}
Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA
Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010>
From: openEHR-technical <[email protected]> On Behalf
Of Thomas Beale
Sent: torsdag 2. mai 2019 13:52
To: [email protected]
Subject: Re: AQL query for blood pressure from the AQL documentation
Ian,
If you were referring to the discussion about paths and data types, i.e. how do
you know if you can refer to some path inside a DvQuantity if the archetype
only knows about DataValue and LOINC codes, it's true that you can use such a
path, if the real data (Element.value) happen to be a DvQuantity, but you have
to be able to reliably figure this out at runtime, presumably by inferring it
from the LOINC or other code - every time? In this situation the AQL processor
cannot help you, because it doesn't have any information about what lies beyond
the Element.value point in the structure.
It seems to me that it would be preferable to convert data with DataValue
specific archetypes, since the general case is that data are written once, read
many times. In that case, you will have data that always has a typed analyte
Cluster archetype (e.g. to DvQuantity, DvOrdinal etc), and and the AQL service
will be able to do proper type / path checking. AQL authoring tools will also
be able to work in a more obvious way (e.g. with auto-complete on paths etc).
So far I am not seeing a downside to this. I realise others have thought about
it longer than I however ...
- thomas
On 02/05/2019 12:02, Ian McNicoll wrote:
The replies that seref and I gave address the issue. The vast majority of lab
imports will use the generic analyte cluster.
On Thu, 2 May 2019, 12:01 Ian McNicoll,
<[email protected]<mailto:[email protected]>> wrote:
Thomas this is not a problem. The aql works as designed
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
