Hi John I am not sure that this has gone further.... > Hello. I am currently investigating AQL and would like to know how the > following queries would be answered by a conformant AQL query engine. I > understand that the structure of AQL query results are not standardized > yet in the AQL specifications, so if the spec cannot give a definitive > answer what would Ocean's AQL query engine implementation do? > > 1. SELECT > o/data[at0001]/events[at0031]/data[at0003]/items[at0004]/value AS > PosturalChangeSystolic, > o/data[at0001]/events[at1004]/data[at0003]/items[at0004]/value AS > ParadoxSystolic > FROM > EHR > CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.encounter.v1] > CONTAINS OBSERVATION o [openEHR-EHR- > OBSERVATION.blood_pressure.v1] > WHERE > > o/data[at0001]/events[at0031]/data[at0003]/items[at0004]/value/value >= > 140 OR > > o/data[at0001]/events[at1004]/data[at0003]/items[at0004]/value/value >= > 140 > > This query attempts to find all Systolic readings for Paradox and > Postural Change blood pressure events where the Systolic reading for > either is >= 140.
[Sam Heard] These would usually be 0-30 or so but.... As there is a one-to-many relationship between a > blood pressure observation and both Paradox and Postural Change events, > how should the query be processed? If an observation has three Postural > Change events where Systolic >= 140, and four such Paradox events, > would the query return twelve rows (using my relational database > thinking). Or would one row be returned, having two "lists" (with three > and four members respectively) of Systolic readings? [Sam Heard] In the Ocean environment we flatten the response (ie one row). > > > 2. SELECT o > FROM > EHR > CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.encounter.v1] > CONTAINS OBSERVATION o [openEHR-EHR- > OBSERVATION.blood_pressure.v1] > WHERE > > o/data[at0001]/events[at0031]/data[at0003]/items[at0004]/value/value >= > 140 OR > > o/data[at0001]/events[at1004]/data[at0003]/items[at0004]/value/value >= > 140 > > This query is the same as the previous one, except that it returns the > whole observation. It seems to me that all readings should be returned, > regardless of their systolic values? [Sam Heard] Yes, you are selecting all observations that include a paradox or postural change of > 140 (very rare!) > > > 3. SELECT o > FROM > EHR > CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.encounter.v1] > CONTAINS OBSERVATION o [openEHR-EHR- > OBSERVATION.blood_pressure.v1] > WHERE > > o/data[at0001]/events[at0031]/data[at0003]/items[at0004]/value/value >= > 140 AND > > o/data[at0001]/events[at1004]/data[at0003]/items[at0004]/value/value >= > 140 > > This query is the same as the previous one, except that the OR has been > changed to an AND. It could be argued that only the Paradox and > Postural Change events with a Systolic reading >= 140 should be > returned, but it could also be argued that all readings should be > returned, as the whole observation has been selected. > [Sam Heard] Again - the whole observation that meets both criteria should be returned. > > The problem I have is how to treat queries which have in the WHERE > clause a path expression that traverses through a 1:n relationship. In > trying to think through the semantics of such queries, I come up with > ambiguities. In a relational query (i.e. SQL) the "equivalent" path > expression would have to be expressed as a join between tables in the > FROM clause, thus removing the ambiguities. > > Am I missing something or are my concerns relevant? If so, how does the > spec/Ocean implementation address them? [Sam Heard] Hope that helps. Sam > > Thanks, > > John Ryan-Brown > The Australian e-Health Research Centre > CSIRO ICT Centre > Brisbane > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
