Re: constraining of laboratory_test_analyte Analyte result

[Georg Fette]

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

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: constraining of laboratory_test_analyte Analyte result

[Thomas Beale]

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[id0.17]
                }
                other_reference_ranges matches {
REFERENCE_RANGE[id0.18]     -- Quantity reference range
                }
            }
        }
    }

You can see a few others here in the ADL2 test archetype Git repo 
.


From my analysis, these subtypes are unavoidable in order to make 
querying work, but also to enable manual specialisations e.g. into 
particular analytes, which is something very useful for creating 
standardised analytes and panels.


- thomas

On 02/05/2019 09:57, Georg Fette wrote:


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


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: automatic demotion of lists in AQL ?

[Thomas Beale]

Unless I am missing something, the fragment items[at0001] cannot appear 
more than once /relative to any given archetype/. Here, it is relative 
to 'a', i.e. openEHR-EHR-CLUSTER.laboratory_test_analyte.v1. Within the 
same archetype, you cannot have other items[xxx] such that the xxx are 
not unique, even if there are multiple 'items' attributes down the 
containment graph. From different archetypes you can, but there is no 
difficulty for the AQL processor to disambiguate these.


On 26/04/2019 12:27, Georg Fette wrote:

Hello,
Is it allowed to use an element that is allowed to appear multiple 
times within a path ?

For example in the query

SELECT a/items[at0001]/value
    FROM EHR e
        CONTAINS CLUSTER 
a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]


the field items[at0001] may appear 0..* times. Thus the access to the 
value field is not properly defined from a type checking point of view.
Does the AQL specification allow such constructs and how is this 
situation interpreted ?

Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL query for blood pressure from the AQL documentation

[Thomas Beale]

Georg,

can you please raise a PR for this problem on the Jira PR tracker 
?


thanks

On 29/04/2019 22:49, Georg Fette wrote:

Hello,
I have a problem with the interpretation of an AQL query from the AQL 
documentation. In section 6.3 the path to the value of the systolic 
blood pressure is

/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
The first part until
/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
denotes a DV_QUANTITY.
Where is the additional field 'value' of the type DV_QUANTITY defined ?
The class itself defines the fields 'magnitude', 'precision', 'units', 
'normal_range' and 'other_reference_ranges'. Its parent class 
DV_AMOUNT defines 'accurany_is_percent' and 'accuracy'. The next 
parent DV_QUANTIFIED defines 'magnitude_status' and again 'accuracy'. 
The next parent DV_ORDERED defines 'normal_status', 'normal_range' and 
again 'other_reference_ranges'. The two parents of DV_ORDERED are 
DATA_VALUE and Ordered, both define no fields.
Has this field access to be 'magnitude' instead of 'value' or am I 
missing something ?

Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL query for blood pressure from the AQL documentation

[Ian McNicoll]

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

On Thu, 2 May 2019, 11:06 Thomas Beale,  wrote:

> Georg,
>
> can you please raise a PR for this problem on the Jira PR tracker
> ?
>
> thanks
> On 29/04/2019 22:49, Georg Fette wrote:
>
> Hello,
> I have a problem with the interpretation of an AQL query from the AQL
> documentation. In section 6.3 the path to the value of the systolic blood
> pressure is
> /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
> The first part until
> /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
> denotes a DV_QUANTITY.
> Where is the additional field 'value' of the type DV_QUANTITY defined ?
> The class itself defines the fields 'magnitude', 'precision', 'units',
> 'normal_range' and 'other_reference_ranges'. Its parent class DV_AMOUNT
> defines 'accurany_is_percent' and 'accuracy'. The next parent DV_QUANTIFIED
> defines 'magnitude_status' and again 'accuracy'. The next parent DV_ORDERED
> defines 'normal_status', 'normal_range' and again 'other_reference_ranges'.
> The two parents of DV_ORDERED are DATA_VALUE and Ordered, both define no
> fields.
> Has this field access to be 'magnitude' instead of 'value' or am I missing
> something ?
> Greetings
> Georg
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Project, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
>  | The Objective Stance
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL query for blood pressure from the AQL documentation

[Ian McNicoll]

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,  wrote:

> Thomas this is not a problem. The aql works as designed
>
> On Thu, 2 May 2019, 11:06 Thomas Beale,  wrote:
>
>> Georg,
>>
>> can you please raise a PR for this problem on the Jira PR tracker
>> ?
>>
>> thanks
>> On 29/04/2019 22:49, Georg Fette wrote:
>>
>> Hello,
>> I have a problem with the interpretation of an AQL query from the AQL
>> documentation. In section 6.3 the path to the value of the systolic blood
>> pressure is
>> /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
>> The first part until
>> /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
>> denotes a DV_QUANTITY.
>> Where is the additional field 'value' of the type DV_QUANTITY defined ?
>> The class itself defines the fields 'magnitude', 'precision', 'units',
>> 'normal_range' and 'other_reference_ranges'. Its parent class DV_AMOUNT
>> defines 'accurany_is_percent' and 'accuracy'. The next parent DV_QUANTIFIED
>> defines 'magnitude_status' and again 'accuracy'. The next parent DV_ORDERED
>> defines 'normal_status', 'normal_range' and again 'other_reference_ranges'.
>> The two parents of DV_ORDERED are DATA_VALUE and Ordered, both define no
>> fields.
>> Has this field access to be 'magnitude' instead of 'value' or am I
>> missing something ?
>> Greetings
>> Georg
>>
>> --
>> Thomas Beale
>> Principal, Ars Semantica 
>> Consultant, ABD Project, Intermountain Healthcare
>> 
>> Management Board, Specifications Program Lead, openEHR Foundation
>> 
>> Chartered IT Professional Fellow, BCS, British Computer Society
>> 
>> Health IT blog  | Culture blog
>>  | The Objective Stance
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL query for blood pressure from the AQL documentation

[Thomas Beale]

I'm confused... are you saying the value/value path is not a typo in the 
spec?


On 02/05/2019 12:01, Ian McNicoll wrote:

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

On Thu, 2 May 2019, 11:06 Thomas Beale, > wrote:


Georg,

can you please raise a PR for this problem on the Jira PR tracker
?

thanks

On 29/04/2019 22:49, Georg Fette wrote:

Hello,
I have a problem with the interpretation of an AQL query from the
AQL documentation. In section 6.3 the path to the value of the
systolic blood pressure is
/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
The first part until
/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
denotes a DV_QUANTITY.
Where is the additional field 'value' of the type DV_QUANTITY
defined ?
The class itself defines the fields 'magnitude', 'precision',
'units', 'normal_range' and 'other_reference_ranges'. Its parent
class DV_AMOUNT defines 'accurany_is_percent' and 'accuracy'. The
next parent DV_QUANTIFIED defines 'magnitude_status' and again
'accuracy'. The next parent DV_ORDERED defines 'normal_status',
'normal_range' and again 'other_reference_ranges'. The two
parents of DV_ORDERED are DATA_VALUE and Ordered, both define no
fields.
Has this field access to be 'magnitude' instead of 'value' or am
I missing something ?
Greetings
Georg



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: automatic demotion of lists in AQL ?

[Ian McNicoll]

Yes that at codes are always effectively namespaced by their parent
archetype.

Ian
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL query for blood pressure from the AQL documentation

[Ian McNicoll]

Ah sorry. Yes that is incorrect.

On Thu, 2 May 2019, 12:13 Thomas Beale,  wrote:

> I'm confused... are you saying the value/value path is not a typo in the
> spec?
> On 02/05/2019 12:01, Ian McNicoll wrote:
>
> Thomas this is not a problem. The aql works as designed
>
> On Thu, 2 May 2019, 11:06 Thomas Beale,  wrote:
>
>> Georg,
>>
>> can you please raise a PR for this problem on the Jira PR tracker
>> ?
>>
>> thanks
>> On 29/04/2019 22:49, Georg Fette wrote:
>>
>> Hello,
>> I have a problem with the interpretation of an AQL query from the AQL
>> documentation. In section 6.3 the path to the value of the systolic blood
>> pressure is
>> /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value
>> The first part until
>> /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value
>> denotes a DV_QUANTITY.
>> Where is the additional field 'value' of the type DV_QUANTITY defined ?
>> The class itself defines the fields 'magnitude', 'precision', 'units',
>> 'normal_range' and 'other_reference_ranges'. Its parent class DV_AMOUNT
>> defines 'accurany_is_percent' and 'accuracy'. The next parent DV_QUANTIFIED
>> defines 'magnitude_status' and again 'accuracy'. The next parent DV_ORDERED
>> defines 'normal_status', 'normal_range' and again 'other_reference_ranges'.
>> The two parents of DV_ORDERED are DATA_VALUE and Ordered, both define no
>> fields.
>> Has this field access to be 'magnitude' instead of 'value' or am I
>> missing something ?
>> Greetings
>> Georg
>>
>>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL query for blood pressure from the AQL documentation

[Thomas Beale]

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, > wrote:


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



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: AQL query for blood pressure from the AQL documentation

[Bjørn Næss]

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. 
/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

From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: torsdag 2. mai 2019 13:52
To: openehr-technical@lists.openehr.org
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, 
mailto:ian.mcnic...@gmail.com>> wrote:
Thomas this is not a problem. The aql works as designed

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL query for blood pressure from the AQL documentation

[Seref Arikan]

Hi Tom,
See comments inline please.

On Thu, May 2, 2019 at 12:52 PM Thomas Beale 
wrote:

> 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.
>
As I mentioned in my response earlier, the serialisation of Element.value
would have either xsi:type (xml) or "_type" (json) letting the consumer of
the query process this information during runtime. You're right about the
aql processor not having much capability here, though this particular case
is not necessarily problematic since you'll have the archetype node id and
all data instances with that arch. nd. id will be of the same type. A
situation in which you'd need the aql processor to be smarter, but it
cannot be is if you used this Element.value with an operator that is valid
for particular types, such as '<'. So if you were to attempt to filter the
data with aql and used Element.value to filter say based on dates such as:

"...WHERE c/bla/../item[at0022]/value/value < '2008-02-03'"

this would require the AQL processor to do what you said, i.e. check actual
data type at runtime to make sure that Element.value is of type to which
comparison operator can be applied. Heath and I just discussed this issue
based on a feedback/question we received. I am currently in favour of
allowing a cast at the aql level via use of a CAST function, as various SQL
variants do. After all, based on the model the author of the query knows
that the path will contain a date. Read on for why I would not do what
you're suggesting

> 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 ...
>
The downside is us, techies pushing our concern into modelling space. Very
much in the spirit of python seeing huge adoption over say Scala or Haskell
or even Java amongst scientists, I'd try to give clinical modellers some
space here. They would have to have a grasp of the type system arguments
above to see the justification for the (modelling) specialisation approach,
which I think is a weak argument here. My preferred compromise is to let
Aql engines know what to expect in advance using CAST (as a function, not
as a keyword) and let clinical modellers go on as things are a.t.m.

All the best
Seref

- 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,  wrote:
>
>> Thomas this is not a problem. The aql works as designed
>>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: automatic demotion of lists in AQL ?

[Georg Fette]

Hi Thomas,
I do not want to use the path element "items[at0001]" multiple times. 
What I mean is that in the query


SELECT a/items[at0001]/value
FROM EHR e CONTAINS CLUSTER 
a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]


the path "a/items[at0001]" denotes a list of ELEMENT (min: 0, max: *). 
Thus the access to the field "value" of this list seems odd. But from 
the specification it seems that if I want to receive all values of all 
values of all elements this query is the correct query to make what I want.
To access all path leafs of all elements of such a list is therefore 
implicitely done.

Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B009
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org