Re: AQL on specific list of compositions

[GF]

HI Ian,

Some definitions from Consys
These are taken from: https://contsys.org

problem: health condition  
considered by a healthcare actor  
to be a problem
health problemlist:health thread  
linking a set of health problems 
health issue: representation of an issue related to the health 
 of a subject of care 
 as identified by one or more 
healthcare actors 
episode of care: health related period 
 during which healthcare 
activities  are performed to 
address one health issue  as 
identified by one healthcare  
professional[



Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 20 Aug 2018, at 11:13, Ian McNicoll  wrote:
> 
> @Gerard - I have always assumed that Contsys 'Health Issue' equates to 
> problem.
> 
> https://github.com/openehr-clinical/shn-contsys 
> 
> 
> Ian
> 



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Birger Haarbrandt]

Hi Thomas,

Am 21.08.2018 um 20:38 schrieb Thomas Beale:


That would be the case if only the AQL spec were used for conformance 
testing. But conformance also relies on the RM, ADL and other specs, 
as you can see here 
. 
If you go to 6.2.2 and down to 'Directory Operations', you can see 
conformance tests for Folders. The first step is to make sure all 
systems implement just the basic structure the same way.


This is clear to me. However, if we are talking about vendor-neutral 
platform ecosystems with lots of client applications sharing an openEHR 
backend, you just need to have (just a stupid guess) ~98% conformance 
(and AQL is in practice just as important to devs as the more 
fundamental specs), otherwise it is getting too painful and expensive to 
change the vendor. Even with small variances in the implementation, you 
might just create a more friendly looking version of vendor lock-in. I 
think this is obvious and it is likely I have missed your point.


The worst case right now would be that a query that mentioned some 
FOLDER structure was run in Marand, DIPS, Code24, EtherCIS, EhrServer 
etc, with different results. This is partly because we have not agreed 
on how to use Folders (e.g. mark them in a certain way to represent an 
episode etc), and partly because some systems don't use them at all. 
Even systems that do have Folders may not use them in the same way (we 
know this is true). So Folder is a slight black hole in openEHR which 
we are actively working on in the SEC to tighten up, so that every 
implementation uses them in the same way.


The Querying conformance table 
 
also needs to be augmented to include Queries that reference Folders. 
A bit more work is needed to get all of this in place.


Jap, I agree that every AQL implementation that wants to meet the 
conformance criteria needs to support folders in a defined way. From my 
perspective, AQL queries on instances of EHR_ACCESS should also be 
considered for the conformance criteria, as consent information might 
also be relevant for querying in analytics scenarios (representation of 
consent information is something the community might also need to take a 
closer look at in the future).



- thomas



Birger



On 21/08/2018 18:28, Birger Haarbrandt wrote:

Hi Thomas,

from my perspective, this approach (by not being explicit about the 
RM classes (and semantics) that need to be supported by the Contains 
keyword) led to a situation in which two vendors (Marand and DIPS) 
can claim that they have a valid implementation of openEHR but are 
not compatible. I can't even tell if Marand (not support Folders at 
all) or DIPS (using questionable overloading of the semantics) is 
more right or wrong with their approaches on this matter...


Birger




--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
*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
birger.haarbra...@plri.de
www.plri.de
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Seref Arikan]

Ah I see. Well, in that case we agree :)

On Tue, Aug 21, 2018 at 5:30 PM, Birger Haarbrandt <
birger.haarbra...@plri.de> wrote:

> Hi Seref,
>
> I'm sorry, I interpreted the following quote
>
> "anybody using this function could figure out that it was introduced by a
> particular vendor"
>
> as a statement that the folder issue should be solved by particular
> vendors by introducing their own functions. I'm just saying that dealing
> with folders in AQL "somehow" should be part of the specification. However,
> I did not express any preferences regarding the solution.
>
> As you seem to agree on this point: sorry for the misunderstanding!
>
> Best,
>
> Birger
>
>
>
> Am 21.08.2018 um 17:10 schrieb Seref Arikan:
>
> You're missing my point. To express it in your terms: this is not about
> excluding Folders from AQL spec, I said nothing of that sort or implied it
> anyway. AQL does not include or exclude individual RM types, it addresses
> all of RM and it is either consistent or not consistent across all of RM,
> period.
>
> Contains statement works over folders but folders do not contain
> compositions, they contain references to compositions (and to other things
> if necessary) by design. Contains not returning compositions 'referenced'
> under folders is not excluding folders from aql: on the contrary, it is AQL
> working as intended on an RM type.
>
>
> What is suggested here would make it inconsistent due to special cases.
> I'm suggesting a way to preserve consistency and providing the
> functionality that is requested. That is a win-win. There may be better
> ways of doing it, but overloading the contains operator is not one of them
> due to reasons I explained.
>
> All the best
> Seref
>
>
>
>
> On Tue, Aug 21, 2018 at 3:52 PM, Birger Haarbrandt <
> birger.haarbra...@plri.de> wrote:
>
>> 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
>> birger.haarbra...@plri.de
>> 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 wa

Re: AQL on specific list of compositions

[Thomas Beale]

That would be the case if only the AQL spec were used for conformance 
testing. But conformance also relies on the RM, ADL and other specs, as 
you can see here 
. 
If you go to 6.2.2 and down to 'Directory Operations', you can see 
conformance tests for Folders. The first step is to make sure all 
systems implement just the basic structure the same way.


The worst case right now would be that a query that mentioned some 
FOLDER structure was run in Marand, DIPS, Code24, EtherCIS, EhrServer 
etc, with different results. This is partly because we have not agreed 
on how to use Folders (e.g. mark them in a certain way to represent an 
episode etc), and partly because some systems don't use them at all. 
Even systems that do have Folders may not use them in the same way (we 
know this is true). So Folder is a slight black hole in openEHR which we 
are actively working on in the SEC to tighten up, so that every 
implementation uses them in the same way.


The Querying conformance table 
 
also needs to be augmented to include Queries that reference Folders. A 
bit more work is needed to get all of this in place.


- thomas


On 21/08/2018 18:28, Birger Haarbrandt wrote:

Hi Thomas,

from my perspective, this approach (by not being explicit about the RM 
classes (and semantics) that need to be supported by the Contains 
keyword) led to a situation in which two vendors (Marand and DIPS) can 
claim that they have a valid implementation of openEHR but are not 
compatible. I can't even tell if Marand (not support Folders at all) 
or DIPS (using questionable overloading of the semantics) is more 
right or wrong with their approaches on this matter...


Birger




--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Pablo Pazos]

That is one of the issues with AQL, one thing is to support the syntax,
another thing is to have compatible query engine implementations, even if
the semantics are correctly interpreted for each operator, data results
might differ. But we are also having different interpretations of the
operators, and also different levels of support of the AQL syntax itself.

My interpretation of this situation is we are on a starting point of a
wider use of the query specs, we will have inconsistencies between
implementations and maybe in a couple of years we will have a clear spec
for the full AQL syntax (with extensions), the internal query engine
architecture, and the result sets.

On Tue, Aug 21, 2018 at 2:28 PM, Birger Haarbrandt <
birger.haarbra...@plri.de> wrote:

> Hi Thomas,
>
> from my perspective, this approach (by not being explicit about the RM
> classes (and semantics) that need to be supported by the Contains keyword)
> led to a situation in which two vendors (Marand and DIPS) can claim that
> they have a valid implementation of openEHR but are not compatible. I can't
> even tell if Marand (not support Folders at all) or DIPS (using
> questionable overloading of the semantics) is more right or wrong with
> their approaches on this matter...
>
> Birger
>
>
> Am 21.08.2018 um 17:04 schrieb Thomas Beale:
>
> Hi Birger,
>
> Note that no openEHR RM types (COMPOSITION etc) are part of the AQL spec -
> they are just used in examples. AQL doesn't actually know anytthing about
> particular types. Seref's intention is that it stays this way, and his
> proposed function, or some other equivalent resolver mechanism would be a
> generic addition to AQL that would, for openEHR structures be used for
> FOLDERs containing refs to COMPOSITIONs (actually VERSIONED_COMPOSITIONs),
> and also any other similar situation (e.g. in the demographic model).
>
> - thomas
>
>
> On 21/08/2018 15:52, Birger Haarbrandt wrote:
>
> 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,
>
> --
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
> --
>
>
>
> *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
> birger.haarbra...@plri.de
> www.plri.de
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter 

http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Birger Haarbrandt]

Hi Thomas,

from my perspective, this approach (by not being explicit about the RM 
classes (and semantics) that need to be supported by the Contains 
keyword) led to a situation in which two vendors (Marand and DIPS) can 
claim that they have a valid implementation of openEHR but are not 
compatible. I can't even tell if Marand (not support Folders at all) or 
DIPS (using questionable overloading of the semantics) is more right or 
wrong with their approaches on this matter...


Birger


Am 21.08.2018 um 17:04 schrieb Thomas Beale:

Hi Birger,

Note that no openEHR RM types (COMPOSITION etc) are part of the AQL 
spec - they are just used in examples. AQL doesn't actually know 
anytthing about particular types. Seref's intention is that it stays 
this way, and his proposed function, or some other equivalent resolver 
mechanism would be a generic addition to AQL that would, for openEHR 
structures be used for FOLDERs containing refs to COMPOSITIONs 
(actually VERSIONED_COMPOSITIONs), and also any other similar 
situation (e.g. in the demographic model).


- thomas


On 21/08/2018 15:52, Birger Haarbrandt wrote:

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,

--



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 




--
*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
birger.haarbra...@plri.de
www.plri.de
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Birger Haarbrandt]

Hi Seref,

I'm sorry, I interpreted the following quote

"anybody using this function could figure out that it was introduced by 
a particular vendor"


as a statement that the folder issue should be solved by particular 
vendors by introducing their own functions. I'm just saying that dealing 
with folders in AQL "somehow" should be part of the specification. 
However, I did not express any preferences regarding the solution.


As you seem to agree on this point: sorry for the misunderstanding!

Best,

Birger



Am 21.08.2018 um 17:10 schrieb Seref Arikan:
You're missing my point. To express it in your terms: this is not 
about excluding Folders from AQL spec, I said nothing of that sort or 
implied it anyway. AQL does not include or exclude individual RM 
types, it addresses all of RM and it is either consistent or not 
consistent across all of RM, period.


Contains statement works over folders but folders do not contain 
compositions, they contain references to compositions (and to other 
things if necessary) by design. Contains not returning compositions 
'referenced' under folders is not excluding folders from aql: on the 
contrary, it is AQL working as intended on an RM type.



What is suggested here would make it inconsistent due to special 
cases. I'm suggesting a way to preserve consistency and providing the 
functionality that is requested. That is a win-win. There may be 
better ways of doing it, but overloading the contains operator is not 
one of them due to reasons I explained.


All the best
Seref




On Tue, Aug 21, 2018 at 3:52 PM, Birger Haarbrandt 
mailto:birger.haarbra...@plri.de>> wrote:


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
birger.haarbra...@plri.de 
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 respo

AW: AQL on specific list of compositions

[Sebastian Garde]

I agree with Seref’s intention of keeping it clean and clear and most 
importantly of course consistent.
In this particular case, I think the REFERS idea is worth pursuing…to me this 
sounds pretty fundamental and should be supported without the need for defining 
an extension/function (in whatever way)

Regards,
Sebastian G.

Von: openEHR-technical  Im Auftrag 
von Seref Arikan
Gesendet: Dienstag, 21. August 2018 17:43
An: For openEHR technical discussions 
Betreff: Re: AQL on specific list of compositions

Hi Sebastian,

Sure, that is another way of dealing with the requirement of resolving object 
references. Every time we discuss new features like these for AQL, we're 
basically looking at a choice between small language with libraries vs large 
language with richer native semantics. (e.g.: Java is former and C# is latter)

My inclination is usually towards small language option or at least keeping 
functionality in libraries and later promoting them to language syntax if they 
become features used frequently. The REFERS option presents no semantic 
ambiguity so it is not subject to my previous criticism.

On Tue, Aug 21, 2018 at 4:25 PM, Sebastian Iancu 
mailto:sebast...@code24.nl>> wrote:

Hi Seref, Thomas,



On the last SEC meeting, another proposed idea (besides the one from Seref) was 
to use REFERS or REFERRED BY instead of CONTAINS - but it we did not explored 
further on. Could this still be considered in these discussions?



Sebastian I.

On 8/21/2018 5:10 PM, Seref Arikan wrote:
You're missing my point. To express it in your terms: this is not about 
excluding Folders from AQL spec, I said nothing of that sort or implied it 
anyway. AQL does not include or exclude individual RM types, it addresses all 
of RM and it is either consistent or not consistent across all of RM, period.

Contains statement works over folders but folders do not contain compositions, 
they contain references to compositions (and to other things if necessary) by 
design. Contains not returning compositions 'referenced' under folders is not 
excluding folders from aql: on the contrary, it is AQL working as intended on 
an RM type.


What is suggested here would make it inconsistent due to special cases. I'm 
suggesting a way to preserve consistency and providing the functionality that 
is requested. That is a win-win. There may be better ways of doing it, but 
overloading the contains operator is not one of them due to reasons I explained.

All the best
Seref




On Tue, Aug 21, 2018 at 3:52 PM, Birger Haarbrandt 
mailto:birger.haarbra...@plri.de>> wrote:
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
birger.haarbra...@plri.de
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 require

Re: AQL on specific list of compositions

[Pablo Pazos]

I agree with Seref,

So why not use conditions over the Folder.items instead of CONTAINS?

We might need a f.items INCLUDES c operator to resolve direct or indirect
references (?)

With indirect I mean via an OBJECT_REF, and direct via an object oriented
link in the IM.

That can be even used for CLUSTER.items or OBSERVATION.data.events, or any
other collection.

CONTAINS should be just for traversing the tree using ancestor-descendant
relationships, including direct references.

On Tue, Aug 21, 2018 at 9:37 AM, Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> @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  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: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>> 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  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 <+47%2093%2043%2029%2010>
>>>
>>>
>>>
>>> *From:* openEHR-technical  *On
>>> Behalf Of *Ian McNicoll
>>> *Sent:* mandag 20. august 2018 11:22
>>> *To:* For openEHR technical discussions >> hr.org>
>>> *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: i...@freshehr.com
>>> twitter: @ianmcnicoll
>>>
>>>
>>>

Re: AQL on specific list of compositions

[Bert Verhees]

On 21-08-18 17:25, Sebastian Iancu wrote:


Hi Seref, Thomas,


On the last SEC meeting, another proposed idea (besides the one from 
Seref) was to use REFERS or REFERRED BY instead of CONTAINS - but it 
we did not explored further on. Could this still be considered in 
these discussions?




Good idea from Sebastian, my three cents to this proposal:

Because the other way around would be:
A COMPOSITION is REFERRED BY a FOLDER

I think "FOLDER REFERS TO a COMPOSITION" would be better then "FOLDER 
CONTAINS a COMPOSITION"


For three reasons:

The keyword REFERS TO indicates that it is a referral, the keyword 
REFERS is the opposite form of REFERRED BY, and the keyword CONTAINS 
falsely indicates that a COMPOSITION would be inside the folder.


Bert



Sebastian I.


On 8/21/2018 5:10 PM, Seref Arikan wrote:
You're missing my point. To express it in your terms: this is not 
about excluding Folders from AQL spec, I said nothing of that sort or 
implied it anyway. AQL does not include or exclude individual RM 
types, it addresses all of RM and it is either consistent or not 
consistent across all of RM, period.


Contains statement works over folders but folders do not contain 
compositions, they contain references to compositions (and to other 
things if necessary) by design. Contains not returning compositions 
'referenced' under folders is not excluding folders from aql: on the 
contrary, it is AQL working as intended on an RM type.



What is suggested here would make it inconsistent due to special 
cases. I'm suggesting a way to preserve consistency and providing the 
functionality that is requested. That is a win-win. There may be 
better ways of doing it, but overloading the contains operator is not 
one of them due to reasons I explained.


All the best
Seref




On Tue, Aug 21, 2018 at 3:52 PM, Birger Haarbrandt 
mailto:birger.haarbra...@plri.de>> wrote:


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
birger.haarbra...@plri.de 
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 work

Re: AQL on specific list of compositions

[Thomas Beale]

Karsten,

Out of interest, is there a diagram or other GNUmed documentation / 
explanation of all this. It's pretty close to what I think openEHR is or 
should be doing; you have formalised more of this than we have so far, 
so it's good to have some reference points available.


- thomas


On 20/08/2018 10:28, Karsten Hilbert wrote:

On Mon, Aug 20, 2018 at 10:04:45AM +0100, Thomas Beale wrote:


Some of these Contsys definitions are problematic:

ENCOUNTER

But there is an encounter when the HcP interacts with the EHR without a
Patient (Virtually) present.

that would certainly be a subversion of the usual meaning of 'encounter'
(literally 'to meet') in English and all the latin languages at least... (in
Portuguese and Brazil health system, the word is 'atendimento', i.e.
attendance... - probably the same in Italian and Spanish).

It would be better ontologically to call such an event something else - in
openEHR it is a commit of a Contribution.

I agree. In GNUmed we tend to think of this as a "session",
in quite a technical sense, between the technical system and
_a_ ("one"-party, where one is by purpose, not by number) actor.

So, a tumor board meeting is a session, as long as the
patient (or a non-staff guarantor) is not present.

Perhaps it's the difference between ABOUT the patient as
opposed to WITH the patient.

A session is the frame within which the commit of a
Contribution occurs.

An encounter does need a session (implicit or explicit) in
order to technically manifest itself. But a session does not
need an encounter.

Waters get muddy when patient and system are involved only,
due to information asymmetry: What if the patient interacts
with the system and the system is programmed to reinforce
adherence. Patient types into a "Question: ___" GUI
field: "Should I continue this medication ?" And the system
answers:

Generally, you should continue as previously decided.
However, if you see fit to rethink that decision would you
like to:

- leave as is
- revisit the previously documented decision details
- decide something else now
- contact a HcP now
- book an appointment


I would suggest that most people think an episode of care is not limited to
one HCP, and is not always limited to one health issue, even if there is
usually one main 'problem' on admission. An episode of care is usually
thought of as care to resolve an issue for a patient by a team of HCPs
working in an integrated environment, e.g. a hospital. If the resolution of
the issue requires care that crosses institutions (usually the case), then a
different term is probably needed for that.

In GP land it feels more helpful to think of Episodes of Care
to relate to one "issue", "problem" each. Several episodes -
about currently-thought-to-be-different issues can overlap.

In GNUmed we over-arch episodes of care with "health issues".
Each health issue can have several (non-overlapping) episodes
over time. Each issue can be thought of to have several
episodes (technically) going on at different institutions
concurrently.

Each problem manifests as a thread, an episode of care for
that problem, running through one or several encounters. Each
encounter can interweave several threads. Each problem may
become identified to belong to a particular health issue, an
underlying "cause".

IOW, episodes and encounters are orthogonal in nature.
Problems are the labels of episodes. Health issues are the
containers for potentially several episodes.

At least in GNUmed.

Karsten


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Thomas Beale]

And I meant to say: can you check if it has a PR, and if not, add one? 
In either case, you or Seref might add the text from his proposal as well.


- thomas


On 21/08/2018 16:25, Sebastian Iancu wrote:


Hi Seref, Thomas,


On the last SEC meeting, another proposed idea (besides the one from 
Seref) was to use REFERS or REFERRED BY instead of CONTAINS - but it 
we did not explored further on. Could this still be considered in 
these discussions?



Sebastian I.




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Thomas Beale]

I had forgotten this, but I think it will turn out to be a syntax 
equivalent to Seref's proposal. It is probably the kind of syntax man 
people would like to use, so we should certainly consider it; it maybe 
that both mechanisms should be put in, and respective users can then 
argue over who is using 'syntactic sugar' ;)


- thomas

On 21/08/2018 16:25, Sebastian Iancu wrote:


Hi Seref, Thomas,


On the last SEC meeting, another proposed idea (besides the one from 
Seref) was to use REFERS or REFERRED BY instead of CONTAINS - but it 
we did not explored further on. Could this still be considered in 
these discussions?



Sebastian I.




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Seref Arikan]

Hi Sebastian,

Sure, that is another way of dealing with the requirement of resolving
object references. Every time we discuss new features like these for AQL,
we're basically looking at a choice between small language with libraries
vs large language with richer native semantics. (e.g.: Java is former and
C# is latter)

My inclination is usually towards small language option or at least keeping
functionality in libraries and later promoting them to language syntax if
they become features used frequently. The REFERS option presents no
semantic ambiguity so it is not subject to my previous criticism.

On Tue, Aug 21, 2018 at 4:25 PM, Sebastian Iancu 
wrote:

> Hi Seref, Thomas,
>
>
> On the last SEC meeting, another proposed idea (besides the one from
> Seref) was to use REFERS or REFERRED BY instead of CONTAINS - but it we did
> not explored further on. Could this still be considered in these
> discussions?
>
>
> Sebastian I.
>
> On 8/21/2018 5:10 PM, Seref Arikan wrote:
>
> You're missing my point. To express it in your terms: this is not about
> excluding Folders from AQL spec, I said nothing of that sort or implied it
> anyway. AQL does not include or exclude individual RM types, it addresses
> all of RM and it is either consistent or not consistent across all of RM,
> period.
>
> Contains statement works over folders but folders do not contain
> compositions, they contain references to compositions (and to other things
> if necessary) by design. Contains not returning compositions 'referenced'
> under folders is not excluding folders from aql: on the contrary, it is AQL
> working as intended on an RM type.
>
>
> What is suggested here would make it inconsistent due to special cases.
> I'm suggesting a way to preserve consistency and providing the
> functionality that is requested. That is a win-win. There may be better
> ways of doing it, but overloading the contains operator is not one of them
> due to reasons I explained.
>
> All the best
> Seref
>
>
>
>
> On Tue, Aug 21, 2018 at 3:52 PM, Birger Haarbrandt <
> birger.haarbra...@plri.de> wrote:
>
>> 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
>> birger.haarbra...@plri.de
>> 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 objectio

Re: AQL on specific list of compositions

[Sebastian Iancu]

Hi Seref, Thomas,


On the last SEC meeting, another proposed idea (besides the one from 
Seref) was to use REFERS or REFERRED BY instead of CONTAINS - but it we 
did not explored further on. Could this still be considered in these 
discussions?



Sebastian I.


On 8/21/2018 5:10 PM, Seref Arikan wrote:
You're missing my point. To express it in your terms: this is not 
about excluding Folders from AQL spec, I said nothing of that sort or 
implied it anyway. AQL does not include or exclude individual RM 
types, it addresses all of RM and it is either consistent or not 
consistent across all of RM, period.


Contains statement works over folders but folders do not contain 
compositions, they contain references to compositions (and to other 
things if necessary) by design. Contains not returning compositions 
'referenced' under folders is not excluding folders from aql: on the 
contrary, it is AQL working as intended on an RM type.



What is suggested here would make it inconsistent due to special 
cases. I'm suggesting a way to preserve consistency and providing the 
functionality that is requested. That is a win-win. There may be 
better ways of doing it, but overloading the contains operator is not 
one of them due to reasons I explained.


All the best
Seref




On Tue, Aug 21, 2018 at 3:52 PM, Birger Haarbrandt 
mailto:birger.haarbra...@plri.de>> wrote:


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
birger.haarbra...@plri.de 
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 mailto:i...@freshehr.com>> wrote:

Thanks Bjorn

That feels logical and the restriction to one layer of

Re: AQL on specific list of compositions

[Seref Arikan]

You're missing my point. To express it in your terms: this is not about
excluding Folders from AQL spec, I said nothing of that sort or implied it
anyway. AQL does not include or exclude individual RM types, it addresses
all of RM and it is either consistent or not consistent across all of RM,
period.

Contains statement works over folders but folders do not contain
compositions, they contain references to compositions (and to other things
if necessary) by design. Contains not returning compositions 'referenced'
under folders is not excluding folders from aql: on the contrary, it is AQL
working as intended on an RM type.


What is suggested here would make it inconsistent due to special cases. I'm
suggesting a way to preserve consistency and providing the functionality
that is requested. That is a win-win. There may be better ways of doing it,
but overloading the contains operator is not one of them due to reasons I
explained.

All the best
Seref




On Tue, Aug 21, 2018 at 3:52 PM, Birger Haarbrandt <
birger.haarbra...@plri.de> wrote:

> 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
> birger.haarbra...@plri.de
> 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  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: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>> On Tue, 21 Aug 2018 

Re: AQL on specific list of compositions

[Thomas Beale]

Hi Birger,

Note that no openEHR RM types (COMPOSITION etc) are part of the AQL spec 
- they are just used in examples. AQL doesn't actually know anytthing 
about particular types. Seref's intention is that it stays this way, and 
his proposed function, or some other equivalent resolver mechanism would 
be a generic addition to AQL that would, for openEHR structures be used 
for FOLDERs containing refs to COMPOSITIONs (actually 
VERSIONED_COMPOSITIONs), and also any other similar situation (e.g. in 
the demographic model).


- thomas


On 21/08/2018 15:52, Birger Haarbrandt wrote:

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,

--



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Birger Haarbrandt]

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
birger.haarbra...@plri.de
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 > 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: i...@freshehr.com 
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org

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 mailto:b...@dips.no>> 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 

*From:*openEHR-technical
mailto:openehr-technical-boun...@lists.openehr.org>> *On
Behalf Of *Ian McNicoll
*Sent:* mandag 20. august 2018 11:22
*To:* For openEHR technical discussions
mailto:openehr-technical@lists.openehr.org>>
*Subject:* Re: AQL on specific list of compositions

Yup but AQL is so cool for 

Re: AQL on specific list of compositions

[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  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: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> 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  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 <+47%2093%2043%2029%2010>
>>
>>
>>
>> *From:* openEHR-technical  *On
>> Behalf Of *Ian McNicoll
>> *Sent:* mandag 20. august 2018 11:22
>> *To:* For openEHR technical discussions > openehr.org>
>> *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: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>>
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>>
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>>
>>
>>
>> On Mon, 20 Aug 2018 at 10:14, Thomas Beale 
>> 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
>>

Re: AQL on specific list of compositions

[Ian McNicoll]

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: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
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  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 <+47%2093%2043%2029%2010>
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Ian McNicoll
> *Sent:* mandag 20. august 2018 11:22
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *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: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
>
>
>
> On Mon, 20 Aug 2018 at 10:14, Thomas Beale 
> 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
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[GF]

Hi,

There is ample reason to reconsider the use and need for folders.

There is a need for holding/collecting structures.
The RM has several places where data can be collected:
- Folder
- Composition
- Section
- Entry
- Cluster

For what purposes?
What contributes to the meaning, the semantics?
What is for aiding the author / reader managing the data?

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 20 Aug 2018, at 10:53, Thomas Beale  wrote:
> 
> 
> 
> On 18/08/2018 07:56, Bert Verhees wrote:
>> I cannot imagine how a folder structure can get lost except by data 
>> corruption. In that case anything is lost anyway and a rollback from a 
>> backup is needed.
> 
> It's a thought experiment, not a serious proposition about a real system. But 
> it partially answers the question: what is in an EHR? If Folders contain some 
> extra information that can't be reconstructed by running specific queries, 
> then probably the Folders are a first order part of the EHR rather than just 
> an optimising data structure.
> 
>> 
>> In fact there should not be a folderstructure in the database. There are 
>> folder objects which contain a list of references (data) to compositions. 
>> Not the compositions itself are in those lists. That would not be possible 
>> because a composition can be referenced in more then one folder.
> 
> There can be a Folder structure (= hierarchy of Folders), even though (as you 
> say) Folders only hold refs to Compositions, and more than one Folder can 
> point to the same Composition.
> 
> - thomas



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: AQL on specific list of compositions

[Bjørn Næss]

@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

From: openEHR-technical  On Behalf 
Of Ian McNicoll
Sent: mandag 20. august 2018 11:22
To: For openEHR technical discussions 
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: i...@freshehr.com
twitter: @ianmcnicoll

[https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Mon, 20 Aug 2018 at 10:14, Thomas Beale 
mailto:thomas.be...@openehr.org>> 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
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org