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, <ian.mcnic...@gmail.com <mailto:ian.mcnic...@gmail.com>> wrote:

    Thomas this is not a problem. The aql works as designed

openEHR-technical mailing list

Reply via email to