Hi Seref,
while I understand your argument regarding overloading of definitions
(and I agree with your reasoning), I see a clear need to not treat
folders as second class citizens in openEHR. Not including Folders in
the official AQL spec and leaving this to vendor-dependent functions
will not be helpful to allow portability. Especially, as the use of
folders (especially when it can contain data in an ITEM_STRUCTURE) is
becoming a common pattern to represent episodes of care.
Cheers,
--
*Birger Haarbrandt, M. Sc.
Peter L. Reichertz Institut for Medical Informatics (PLRI)
Technical University Braunschweig and Hannover Medical School
Software Architect HiGHmed Project *
Tel: +49 176 640 94 640, Fax: +49 531/391-9502
[email protected]
www.plri.de
Am 21.08.2018 um 14:37 schrieb Seref Arikan:
@Bjorn and @Ian both: I don't think this is a good idea. This example
overloads the semantics of CONTAINS operator of AQL for a very
specific scenario: when the object reference is a reference to a
composition and the reference sits under folder F, which btw should
not be a folder contained in another folder. Based on the second
Example from Bjorn, It looks like CONTAINS also (silently?) resolves
the reference of its parent's parent (f) which is another overload of
its very core definition.
This is not standard AQL, even though AQL is probably the most
variable spec in openEHR in terms of its implementation across
vendors. I know different vendors come across different requirements
at different times and our individual solutions to those slowly make
it into the standard so there is always a window during which a
feature is available from a vendor but still not in the spec but this
can be problematic at times.
As I said in the past in numerous occasions: I think the robust way to
deal with these type of edge cases is to leave the core semantics of
AQL alone as much as possible and use extensions such as functions.
Something like
SELECT resolve_folder_comps(f/items) as compositions_under_folder FROM
EHR e[$ehrId] CONTAINS FOLDER f[..]
would encapsulate the specific case into resolve_folder_comp
function's definition and semantics. Anybody using this function could
figure out that it was introduced by a particular vendor, see its
documentation, read its limitations such as the root folder
requirement for f etc etc.
Pretty soon, we'll have a REST spec which the vendors will have
implemented, with API calls to run AQL queries. If those queries do
not work across REST deployments of Ocean, DIPS, Marand, Code24 etc
how on earth we can claim we have a unified way of retrieving data
that works consistently across systems?
My suggestion above my be faulty and I'd be delighted to hear
objections and suggestions for alternatives but let's please try to
not to lose the big picture when working on AQL: it is going to be a
huge value added of openEHR in near future and its portability matters
a lot. I tried to make this point in a more subtle way in my previous
messages but I seem to have failed, hence: this rather blunt response
I'm sending with good intentions only.
All the best
Seref
On Tue, Aug 21, 2018 at 12:44 PM, Ian McNicoll <[email protected]
<mailto:[email protected]>> wrote:
Thanks Bjorn
That feels logical and the restriction to one layer of folders
make sense. I appreciate that under the hood 'CONTAINS' is
implemented differently but it feels natural to think in terms of
logical containment.
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: [email protected] <mailto:[email protected]>
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation [email protected]
<mailto:[email protected]>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
On Tue, 21 Aug 2018 at 08:54, Bjørn Næss <[email protected]
<mailto:[email protected]>> wrote:
@ian – we have implemented the query you wrote:
“select c from EHR e contains FOLDER f contains COMPOSITION c
where c…..”
You might even write:
“select c from EHR e contains FOLDER f contains FOLDER
child_folder contains COMPOSITION c where c…..”
We made a restriction such that the COMPOSITION c MUST be
referenced in FOLDER f and not any sub-folder. This was needed
to avoid circular references and explosion in the result set.
Vennlig hilsen
Bjørn Næss
Product owner
DIPS ASA
Mobil +47 93 43 29 10 <tel:+47%2093%2043%2029%2010>
*From:*openEHR-technical
<[email protected]
<mailto:[email protected]>> *On
Behalf Of *Ian McNicoll
*Sent:* mandag 20. august 2018 11:22
*To:* For openEHR technical discussions
<[email protected]
<mailto:[email protected]>>
*Subject:* Re: AQL on specific list of compositions
Yup but AQL is so cool for this kind of thing :)
I still want to do
Select c FROM EHR Contains folder x contains composition c
since logically folder x contains compositions.
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: [email protected] <mailto:[email protected]>
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation [email protected]
<mailto:[email protected]>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
On Mon, 20 Aug 2018 at 10:14, Thomas Beale
<[email protected] <mailto:[email protected]>>
wrote:
Well if you have access to a Folder, you don't need to do
an AQL query,
you can just retrieve the Folder structure and recurse
through it,
picking up direct refs to VERSIONED_COMPOSITIONs.
Creating Folders from the data on the other hand requires
writing some
queries that look for admissions and discharges, matching
them up, and
generating a Folder for each pair, named after the
institution and/or
dates of the stay. A bit messy, but not hard to do, if
one wants to
post hoc add Folders to 'old' EHRs that never had them.
- thomas
On 20/08/2018 10:07, Ian McNicoll wrote:
> Thanks Thomas,
>
> What are your thoughts on the AQL example I
foolishly guessed at :(
> and that Seref quite correctly rejected!!
>
> How would/should we do...
>
> Select all compositions referenced by Folder x.
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
