What should AQL return in this case?
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 On 20/08/2012 9:10 PM, Thomas Beale wrote: > > 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* >> * > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/4bafaabd/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/4bafaabd/attachment-0001.png>
What should AQL return in this case?
Thanks, I think this is the best thing to do. On Mon, Aug 20, 2012 at 1:17 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 20/08/2012 05:47, Seref Arikan wrote: > >> 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? >> >> > in that case, whatever is matched is matched, which will include all your > combinations ;-) > > - thomas > > > __**_ > openEHR-technical mailing list > openEHR-technical at lists.**openehr.org lists.openehr.org> > http://lists.openehr.org/**mailman/listinfo/openehr-** > technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/b00bbd90/attachment.html>
What should AQL return in this case?
Ascii would take time iPad + Notability + a proper stylus I love it. On Mon, Aug 20, 2012 at 12:52 PM, Hugh Leslie < hugh.leslie at oceaninformatics.com> wrote: > You could have done the diagram in ascii... > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/3735b18a/attachment.html>
What should AQL return in this case?
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 On Mon, Aug 20, 2012 at 12:40 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > > 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 > > [image: 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* > * > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/04ef933e/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/04ef933e/attachment-0001.png>
What should AQL return in this case?
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 [image: 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/d32e102f/attachment-0001.html> -- next part -- A non-text attachment was scrubbed... Name: aql-result-set-question.png Type: image/png Size: 35089 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/d32e102f/attachment-0001.png>
What should AQL return in this case?
On 20/08/2012 05:47, Seref Arikan wrote: > 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? > in that case, whatever is matched is matched, which will include all your combinations ;-) - thomas
What should AQL return in this case?
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>
