# What should AQL return in this case? **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2012-08-20 11:19 UTC **Views:** 1 **Replies:** 7 **URL:** https://discourse.openehr.org/t/what-should-aql-return-in-this-case/15192 --- ## Post #1 by @Seref Greetings, Here is the setting in which AQL is being used: We are interested in outcomes of a particular clinical instruction in cases where a particular observation has been recorded. We want to get an attribute of both the observation and the and the instruction from patient EHR. The patient's EHR has multiple observations and instructions, as shown in the following diagram (the dual line connections are from the partial graph representation domain, meaning a child contained somewhere) The diagram also contains the query and other details, which I'll discuss below Inline image 1

The problem here is that the observation and instruction tuple can be represented in 4 ways. (I hope the diagram represents why it is so) Should AQL implementation return all 4? Then the consumer of the result set would have to sort things out. This is similar to RDMS behaviour when a select statement is issued on two tables without any joins. I'm inclined to accept this as the expected behaviour, but I'd like to hear what others think. (of course, adding some constraint that would enforce the instruction to have a creation time later than the observation would return only two tuples, but that is not the case I'm asking for) Best regards Seref --- ## Post #2 by @thomas.beale This is a good question\. I wold summarise it as: how do I ensure an AQL query picks up proximate rather than distant objects for a given object? It depends on the data\. If the only thing in the data that indicates that INSTR Y1 is related to OBS X1 is temporal proximity, then you would have to include something to do with time in the a WHERE clause\. Now, this might actually be ok \- if you know a priori that a certain pattern of Obs followed by Instr always corresponds to e\.g\. a situation of 'lab result' followed by a new order \(or whatever the pattern that you are looking for\), then this is safe to use\. Normally such inferences would not be safe\. So we need to think about how the proximate Obs/instr pairs could be explicitly linked\. In openEHR/13606, this is done with LINK objects, so your query WHERE clause could match Instructions that had a LINK pointing back to an Obs with some kind of causal relation specified\. Going one better means building some kind of active index in the record, where DV\_EHR\_URIs are used to refer to pairs / groups of Entries that are part of the same investigation, or whatever it might be\. Then to query, you would be querying that structure\. There are moves to standardise such structures in openEHR, but it's not there yet\. \- thomas --- ## Post #3 by @Seref Hi Tom, Your comments are quite helpful, but they do not belong to the context I'm asking about. I'm asking the default behaviour for returning results when no constraints are there. It may not be a meaningful use case for using AQL, but it is a technically valid one. My question is: how should the implementation behave when it faces this technically valid AQL, on this EHR? I'd like to discuss your suggestions seperately, since they'll be obviously relevant in population queries context :) Kind regards Seref --- ## Post #4 by @system Hi All The work_flow_id of an entry provides a way to link any ENTRY with an INSTRUCTION. There are more complex workflow parameters possible within the ENTRY class that can be used if more complex issues arise. Relating ENTRYs in a general way outside a particular application or repository is more difficult unless it follows the ACTION/INSTRUCTION model proposed in openEHR. Just some ideas. Cheers, Sam --- ## Post #5 by @Seref Ascii would take time iPad + Notability + a proper stylus I love it. --- ## Post #6 by @thomas.beale in that case, whatever is matched is matched, which will include all your combinations ;\-\) \- thomas --- ## Post #7 by @Seref Thanks, I think this is the best thing to do. --- ## Post #8 by @Heath_Frankel3 Hi Seref, It would return a cross join of the X.attr and Y.attr, but only from EHRs with both an X and Y. We have uses workflow ids because this is more efficient to evaluate than URIs (including links) due to string length and being bidirectional, but this only works for certain usecases. Heath. [details="(attachments)"] ![aql-result-set-question.png|640x682](upload://86GZKYgjDuLHTMAghXDWxeKBoYt.png) [/details] --- **Canonical:** https://discourse.openehr.org/t/what-should-aql-return-in-this-case/15192 **Original content:** https://discourse.openehr.org/t/what-should-aql-return-in-this-case/15192