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
