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 On 20/08/2012 05:19, Seref Arikan wrote: > 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* > * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/7dd56009/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 35089 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/7dd56009/attachment-0001.png>
