Re: AQL on specific list of compositions

[Karsten Hilbert]

On Sun, Sep 02, 2018 at 10:25:23AM +0100, Ian McNicoll wrote:

> Very helpful. I'd suggest one other minor tweak to differentiate 'episode'
> which is one or more encounters associated with a particular problem or
> issue, and 'period of care' which is administrative idea that
> roughly equates to an admission or series of outpatient appointments. In
> hospital care the two are often conflated.

Agreed. Since GNUmed does not concern itself with documenting
in-patient care it never occurred to us that the time in
hospital most certainly does not necessarily equate to an
episode :-)

Particularly since GNUmed affords documenting hospital stays
(with admission and discharge dates), each stay linked to
episodes of care.

Thanks for pointing that out.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

___
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

[Ian McNicoll]

Thanks Karsten,

Very helpful. I'd suggest one other minor tweak to differentiate 'episode'
which is one or more encounters associated with a particular problem or
issue, and 'period of care' which is administrative idea that
roughly equates to an admission or series of outpatient appointments. In
hospital care the two are often conflated.

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 Sat, 1 Sep 2018 at 18:42, Karsten Hilbert 
wrote:

> Thomas,
>
> sorry for the late reply.
>
> > 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.
>
> Some details are in my head, but the big picture on the Wiki,
> say, in the User Guide:
>
> http://wiki.gnumed.de/bin/view/Gnumed/GmManualBasicEmrConcept
>
> The reason this aligns fairly well with the thinking
> in OpenEHR is that I've been following this list for
> far too long :-)
>
> Regards,
> Karsten
> --
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
>
> ___
> 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

Holistic view, was :AQL on specific list of compositions

[Bert Verhees]

Contsys will update some definitions. They are now the base of their thinking, 
but I am sure that will change soon. 

Thanks, Gérard, for giving me the opportunity to make my point again. :-) 

We don't call war a peace problem. So why do we call illness a health problem? 

Normally I would not mention such a small thing. But the positive naming could 
be standing in the way of a more holistic view. Healthcare is now about 
care-for illness. Medicine is not always about healing. It are medieval 
understandings in the way we still use them. 

Healthcare must also be for healthy people 

For example, food is important, not only for people with a disease, but also 
for healthy people so that they do not get a disease. 

According businessplans of tech giants, like Google, Amazon, etc,  a PHR will 
contain a holistic view of the consumer (not patient). The PHR will contain 
data from sport, leisure, diseases, yoga, food, everything related to health. 
Not only the negative aspects, but all aspects. This change in philosophy of 
healthcare is taking place quite some time now, but now reaching the upper 
levels of society. 

Preventing diseases will become a major way of spending healthcare money. If 
insurance companies can keep their members healthy, they are saving money. 

If companies do not start to change, they will lose their position on the 
billion dollar market. 
There will be a new business-competition. The patient will become a consumer 
and will give new meaning to the word healthcare. 

Change starts with using words in another way.

Now is the time to start with this. The world is changing fast, and we will 
change with it. 




Verzonden vanaf mijn Xperia™ van Sony-smartphone

 GF schreef 

>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
>> 
>
>
>___
>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

[Karsten Hilbert]

Thomas,

sorry for the late reply.

> 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.

Some details are in my head, but the big picture on the Wiki,
say, in the User Guide:

http://wiki.gnumed.de/bin/view/Gnumed/GmManualBasicEmrConcept

The reason this aligns fairly well with the thinking
in OpenEHR is that I've been following this list for
far too long :-)

Regards,
Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

___
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 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]

d, 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
>>>>
>>>>
>>>>
>>>> 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 

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]

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


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
<mailto: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 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 <mailto:i...@freshehr.com>
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
<mailto: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
<mailto:openEHR-technical@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>

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/o

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<mailto:birger.haarbra...@plri.de>
www.plri.de<http://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 

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%

Re: AQL on specific list of compositions

[Bert Verhees]

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


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
<mailto: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 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 <mailto:i...@freshehr.com>
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
<mailto: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
<mailto:openEHR-technical@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>

_

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]

r, 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
>>>>
>>>>
>>>>
>>>> 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 f

Re: AQL on specific list of compositions

[Sebastian Iancu]

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


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
<mailto: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 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 <mailto:i...@freshehr.com>
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
<mailto: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
<mailto:openEHR-technical@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>

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@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>


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

Re: AQL on specific list of compositions

[Seref Arikan]

coll
>> 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
>>>
>>>
>>>
>>> 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
>>
>>
>
>
> ___
> openEHR-technical mailing 
> listopenEHR-technical@lists.openehr.orghttp://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

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


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
<mailto: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>>
*Su

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
>>
&

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

[https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto: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<mailto: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

[Thomas Beale]

that would be possible if we modify the meaning of the CONTAINS operator 
to mean contains-by-value (like ENTRYs inside a COMPOSITION) /or 
/contains-by-reference, which is the FOLDERs case - as you have long 
argued ;)


Not hard technically as far as I can see - but it does mean a 
modification to all existing AQL implementations, and of course AQL itself.


- thomas

On 20/08/2018 10:21, Ian McNicoll wrote:

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


___
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

[Karsten Hilbert]

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
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

___
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]

You're (unintentionally) circling back to discussions re AQL in the last
SEC meeting in Slovenia (I was sitting in remotely)

What you're asking for can be accomplished in a number of ways at the AQL
level, all of which would require changes to AQL specs and implementations.
I'm always happy to discuss these but I suspect it deserves its own thread
:) Hint for subject: How to resolve object references with AQL?

All the best
Seref


On Mon, Aug 20, 2018 at 10:21 AM, Ian McNicoll  wrote:

> 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

[Ian McNicoll]

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

Re: AQL on specific list of compositions

[Ian McNicoll]

@Gerard - I have always assumed that Contsys 'Health Issue' equates to
problem.

https://github.com/openehr-clinical/shn-contsys

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:04, Thomas Beale  wrote:

> Some of these Contsys definitions are problematic:
>
> On 20/08/2018 09:13, GF wrote:
>
> Hi Karsten,
>
> ISO System of Concepts for Continuity of Care (ContSys) defines all kinds
> of concepts related to care and its documentation.
> It would be. a good thing to harmonise terms we use.
> More info via: https://contsys.org
>
> ContSys is *NOT* a Data model but a way to define concepts and there
> relations using UML.
> It can/must inform the production of shared archetypes.
>
> ENCOUNTER
> Most certainly this is the case when a Healthcare Provider meets the
> patient and documents the care given.
> Meeting can be real and virtual via telephone, e-mail, a third party
>
> 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.
>
> There are also other health system actions with the patient absent, e.g.
> doing lab work on tissue samples - also real 'work', but not an encounter.
>
>
> So ENCOUNTER, in my terms, is any interaction of an Author (HcP, Patient,
> third Party/Proxy) with the Patient Record.
>
> The ISO standard System of Concepts for Continuity of Care uses the term
> and definition:
> *contact  perio
> d- healthcare activity period
>  during which
> a contact  occurs*
>
> EPISODE
> ContSys defines this as:
> *episode of care- health related period
>  during which healthcare
> activities  are performed
> to address one health issue  as
> identified by one healthcare
> professional[*
>
>
> 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.
>
> - thomas
>
> --
> 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
>
___
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]

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

Re: AQL on specific list of compositions

[Ian McNicoll]

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.

How else might we meet Dileep's use-case with AQL?


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 Fri, 17 Aug 2018 at 17:00, Thomas Beale  wrote:

>
> The easiest way to think about this question is: if someone trashed the
> Folder structure, could we (some admin app) rebuild it? The answer is
> interesting. It should normally be possible to rebuild the Folder /
> Composition association structure (it's not containment, just referencing),
> but of course, if you stored other information in the Folders, for example
> in the recently SEC-approved other_details structure, then you would lose
> that.
>
> So the Folder approach does two things:
>
>- represents a pre-built query result (the Folder/Composition
>associations) - giving instant access, and avoiding having to construct the
>query, which is usually somewhat messy.
>- allows other information to be stored directly about the thing the
>Folder represents, e.g. admission / stay in a facility.
>
> - thomas
>
> On 17/08/2018 16:20, Seref Arikan wrote:
>
> Hi Ian,
>
> When the fact that the Composition is associated to an encounter or
> episode of care is recorded by including a reference to that composition in
> a folder, some clinical context/information related to that composition is
> now stored outside the composition, by means of a refence in a folder
>
> Unless I'm missing an Aql feature that can help, you can no longer select
> those compositions via Aql (since Aql does not support/specify how to
> resolve refs)
>
> If you follow the encounter id approach you mentioned, then you could use
> Aql.
>
> In fact, if Ethercis had support for Folder, Dileep would still not be
> able to get those compositions with a singl query: he'd need to fetchs uids
> from a folder with one query, then perform a second query to get
> compositions in the way I suggested.
>
> I'm probably being unnecessarily picky here, just pointing at the
> difference between approaches and trying to put my finger on any downstream
> issues. I'm not doing a great job of it though :)
>
> On Friday, August 17, 2018, Ian McNicoll  wrote:
>
>> Hi Seref,
>>
>> I'm not sure I understand your concerns here. I think the use case is
>> where there is a need to group compositions by some other higher level
>> construct which usually reflect something like an admission, episode of
>> outpatient care or perhaps a community plan of care.
>>
>> As Dileep has indicated he probably would use folders if Ethercis
>> supported them. Another alternative is to create an Encounter ID for each
>> new encounter (which in Dileep's example, I think I would call an episode
>> of care, and simply tag each composition with that Encounter ID e.g create
>> a cluster archetype to hold this in every Composition/ other_context. I
>> have done that on other projects. So it is a case of looking of all
>> composition with EncounterId = x
>> Now I would probably go down the Folder route, if I could.
>> 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 Fri, 17 Aug 2018 at 13:59, Seref Arikan <
>> serefari...@kurumsalteknoloji.com> wrote:
>>
>>> I'm used to thinking compositions as semantcally self contained units of
>>> information, at the very least using references to other means of
>>> expressing semantics (as in terminologies)
>>>
>>> What you're describing seems to take some clincal semantics out of the
>>> composion and if we have multiple ways of doing that, it may hurt
>>> reusability of queries and data.
>>>
>>> Do you think we can find a way of expressing this semantcs without
>>> losing its trace within the cmposition?
>>>
>>> (Sorry for the typos, on the phone..)
>>>
>>> On Friday, August 17, 2018, Thomas Beale 
>>> wrote:
>>>
 There is a bigger question of how best to model 'encounter' and
 'admission', which some implementers are doing with Folders, particularly
 DIPS in Norway. I suspect that some version of using Folders (or else some
 kind of tagging, which is semantically equivalent) will be the long term
 approach to doing this.

 - thomas

 On 17/08/2018 10:54, Dileep V S wrote:

 Hi,

 Can you write an AQL to query only on a list of specific compositions?
 Is there any sam

Re: AQL on specific list of compositions

[Thomas Beale]

Some of these Contsys definitions are problematic:


On 20/08/2018 09:13, GF wrote:

Hi Karsten,

ISO System of Concepts for Continuity of Care (ContSys) defines all 
kinds of concepts related to care and its documentation.

It would be. a good thing to harmonise terms we use.
More info via: https://contsys.org

ContSys is *_NOT_* a Data model but a way to define concepts and there 
relations using UML.

It can/must inform the production of shared archetypes.

ENCOUNTER
Most certainly this is the case when a Healthcare Provider meets the 
patient and documents the care given.

Meeting can be real and virtual via telephone, e-mail, a third party

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.


There are also other health system actions with the patient absent, e.g. 
doing lab work on tissue samples - also real 'work', but not an encounter.




So ENCOUNTER, in my terms, is any interaction of an Author (HcP, 
Patient, third Party/Proxy) with the Patient Record.


The ISO standard System of Concepts for Continuity of Care uses the 
term and definition:
/*contact *perio 
d-healthcare activity 
period during 
which acontact occurs/


EPISODE
ContSys defines this as:
/*episode of care-*health related period 
 during which 
healthcare activities 
 are performed to 
address one health issue  as 
identified by one healthcare 
professional[/


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.


- thomas

--
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]

This is how I understand it as well, just in the interests of avoiding 
confusion, so a Folder solution as described above is for episodes of 
care, within an institution, or something that functions like an 
institution, and where there is internal continuity of care, e.g. an 
integrated area or city health service.


- thomas


On 19/08/2018 12:20, Karsten Hilbert wrote:

On Fri, Aug 17, 2018 at 03:36:23PM +0100, Ian McNicoll wrote:


As Dileep has indicated he probably would use folders if Ethercis supported
them. Another alternative is to create an Encounter ID for each new
encounter (which in Dileep's example, I think I would call an episode of
care, and simply tag each composition with that Encounter ID

An Encounter (in community medicine) is very much different
from an Episode of Care.

An Encounter happens when patient and healthcare system
"meet" in some way, it is one-off. It can encompass a
multitude of Reasons for Encounter, about different care
targets.

An Episode of Care is a time range during which one
particular care target is handled. It manifests itself during
1..many Encounters, each of which is about 1..many care
targets (problems).

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]

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


___
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

[Karsten Hilbert]

Hello Gerard,

> ISO System of Concepts for Continuity of Care (ContSys) defines all kinds of 
> concepts related to care and its documentation.

I (GNUmed, that is) agree with the definitions you refer to.

I was answering to Ian's input:

> As Dileep has indicated he probably would use folders if Ethercis supported
> them. Another alternative is to create an Encounter ID for each new
> encounter (which in Dileep's example, I think I would call an episode of
> care, and simply tag each composition with that Encounter ID

which seemed to me to equate Encounter with Episode of Care.

But I may have misunderstood Dileep's example.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

___
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 Karsten,

ISO System of Concepts for Continuity of Care (ContSys) defines all kinds of 
concepts related to care and its documentation.
It would be. a good thing to harmonise terms we use.
More info via: https://contsys.org 

ContSys is NOT a Data model but a way to define concepts and there relations 
using UML.
It can/must inform the production of shared archetypes.

ENCOUNTER
Most certainly this is the case when a Healthcare Provider meets the patient 
and documents the care given.
Meeting can be real and virtual via telephone, e-mail, a third party

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

So ENCOUNTER, in my terms, is any interaction of an Author (HcP, Patient, third 
Party/Proxy) with the Patient Record.

The ISO standard System of Concepts for Continuity of Care uses the term and 
definition:
contact  perio 
d-   healthcare activity period 
 during which a contact 
 occurs

EPISODE
ContSys defines this as:
episode of care-health related period 
 during which healthcare 
activities  are performed to 
address one health issue  as 
identified by one healthcare 
professional[

PROBLEM
In addition the term PROBLEM is used in the context of EHR’s.
ContSys has NOT defines this term.
The closest concept in ContSys is:
reason for demand of Care-  subject of care 
 or a subject of care 
 proxy's perception of health 
needs  motivating a demand for car 
e



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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 19 Aug 2018, at 13:20, Karsten Hilbert  wrote:
> 
> An Encounter (in community medicine) is very much different
> from an Episode of Care.
> 
> An Encounter happens when patient and healthcare system
> "meet" in some way, it is one-off. It can encompass a
> multitude of Reasons for Encounter, about different care
> targets.
> 
> An Episode of Care is a time range during which one
> particular care target is handled. It manifests itself during
> 1..many Encounters, each of which is about 1..many care
> targets (problems).
> 
> Karsten



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

[Karsten Hilbert]

On Fri, Aug 17, 2018 at 03:36:23PM +0100, Ian McNicoll wrote:

> As Dileep has indicated he probably would use folders if Ethercis supported
> them. Another alternative is to create an Encounter ID for each new
> encounter (which in Dileep's example, I think I would call an episode of
> care, and simply tag each composition with that Encounter ID

An Encounter (in community medicine) is very much different
from an Episode of Care.

An Encounter happens when patient and healthcare system
"meet" in some way, it is one-off. It can encompass a
multitude of Reasons for Encounter, about different care
targets.

An Episode of Care is a time range during which one
particular care target is handled. It manifests itself during
1..many Encounters, each of which is about 1..many care
targets (problems).

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

___
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

[Bert Verhees]

As far as I understand, and I also implemented it like that, there should never 
be functionality to delete data. Accidental deletion can only occur when you 
pass the software and hack on the database directly. That should never occur 
and if it does, the database should be restored to a safe point in the backup 
routine. 

A folder is a versioned immutable object, that can never be changed or deleted, 
according the specs, or did I miss a change? 

Sorry in that case for my speaking while not being up to date. I don't read the 
specs every day. 

Bert 

Verzonden vanaf mijn Xperia™ van Sony-smartphone

 Seref Arikan schreef 

>My point was more about querying aspects. Tom emphasized data integrity
>aspects.
>
>I think we've survived just fine so far without any mechanisms similar to
>foreign keys in relational dbs that would stop a folder from being deleted,
>so I'd say go with folders as you intend to.
>
>My concerns can (probably) be handled by smarter Aql down the line.
>
>On Saturday, August 18, 2018, Dileep V S  wrote:
>
>> Very interesting discussion that has helped us get some of our thoughts
>> clarified. We have started building a virtual folder as a service outside
>> Ethercis to cover our requirements and are hoping to migrate the structure
>> into the EHR server at a later date.
>>
>> The plan is to cover both the things mentioned in Thomas's response. We
>> intend to get a list of compositions associated with a folder from this
>> service and pass it to the AQL to get what we want.
>>
>> However, I am not sure how to rebuild the folder structure if it is lost.
>> We do not have any folder related information inside Compositions and so
>> the query can only go from folder to the composition and not the other way.
>> Keeping folder details in Composition may not be a good idea as folder is
>> meant to be virtual grouping and can have some dynamism around it. Also
>> same composition can, in theory, be part of multiple folders. There is also
>> the concept of a folder hierarchy that exists only within the folder
>> service.
>>
>> regards
>>
>> Dileep V S
>> *Founder*
>> HealtheLife Ventures LLP
>> m: +91 9632888113
>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>> w: healthelife.in  e: dil...@healthelife.in
>>
>> On Fri, Aug 17, 2018 at 9:30 PM, Thomas Beale 
>> wrote:
>>
>>>
>>> The easiest way to think about this question is: if someone trashed the
>>> Folder structure, could we (some admin app) rebuild it? The answer is
>>> interesting. It should normally be possible to rebuild the Folder /
>>> Composition association structure (it's not containment, just referencing),
>>> but of course, if you stored other information in the Folders, for example
>>> in the recently SEC-approved other_details structure, then you would lose
>>> that.
>>>
>>> So the Folder approach does two things:
>>>
>>>- represents a pre-built query result (the Folder/Composition
>>>associations) - giving instant access, and avoiding having to construct 
>>> the
>>>query, which is usually somewhat messy.
>>>- allows other information to be stored directly about the thing the
>>>Folder represents, e.g. admission / stay in a facility.
>>>
>>> - thomas
>>>
>>> On 17/08/2018 16:20, Seref Arikan wrote:
>>>
>>> Hi Ian,
>>>
>>> When the fact that the Composition is associated to an encounter or
>>> episode of care is recorded by including a reference to that composition in
>>> a folder, some clinical context/information related to that composition is
>>> now stored outside the composition, by means of a refence in a folder
>>>
>>> Unless I'm missing an Aql feature that can help, you can no longer select
>>> those compositions via Aql (since Aql does not support/specify how to
>>> resolve refs)
>>>
>>> If you follow the encounter id approach you mentioned, then you could use
>>> Aql.
>>>
>>> In fact, if Ethercis had support for Folder, Dileep would still not be
>>> able to get those compositions with a singl query: he'd need to fetchs uids
>>> from a folder with one query, then perform a second query to get
>>> compositions in the way I suggested.
>>>
>>> I'm probably being unnecessarily picky here, just pointing at the
>>> difference between approaches and trying to put my finger on any downstream
>>> issues. I'm not doing a great job of it though :)
>>>
>>> On Friday, August 17, 2018, Ian McNicoll  wrote:
>>>
 Hi Seref,

 I'm not sure I understand your concerns here. I think the use case is
 where there is a need to group compositions by some other higher level
 construct which usually reflect something like an admission, episode of
 outpatient care or perhaps a community plan of care.

 As Dileep has indicated he probably would use folders if Ethercis
 supported them. Another alternative is to create an Encounter ID for each
 new encounter (which in Dileep's example, I think I would call an episode
 of care, and simply tag each compos

Re: AQL on specific list of compositions

[Seref Arikan]

My point was more about querying aspects. Tom emphasized data integrity
aspects.

I think we've survived just fine so far without any mechanisms similar to
foreign keys in relational dbs that would stop a folder from being deleted,
so I'd say go with folders as you intend to.

My concerns can (probably) be handled by smarter Aql down the line.

On Saturday, August 18, 2018, Dileep V S  wrote:

> Very interesting discussion that has helped us get some of our thoughts
> clarified. We have started building a virtual folder as a service outside
> Ethercis to cover our requirements and are hoping to migrate the structure
> into the EHR server at a later date.
>
> The plan is to cover both the things mentioned in Thomas's response. We
> intend to get a list of compositions associated with a folder from this
> service and pass it to the AQL to get what we want.
>
> However, I am not sure how to rebuild the folder structure if it is lost.
> We do not have any folder related information inside Compositions and so
> the query can only go from folder to the composition and not the other way.
> Keeping folder details in Composition may not be a good idea as folder is
> meant to be virtual grouping and can have some dynamism around it. Also
> same composition can, in theory, be part of multiple folders. There is also
> the concept of a folder hierarchy that exists only within the folder
> service.
>
> regards
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
> On Fri, Aug 17, 2018 at 9:30 PM, Thomas Beale 
> wrote:
>
>>
>> The easiest way to think about this question is: if someone trashed the
>> Folder structure, could we (some admin app) rebuild it? The answer is
>> interesting. It should normally be possible to rebuild the Folder /
>> Composition association structure (it's not containment, just referencing),
>> but of course, if you stored other information in the Folders, for example
>> in the recently SEC-approved other_details structure, then you would lose
>> that.
>>
>> So the Folder approach does two things:
>>
>>- represents a pre-built query result (the Folder/Composition
>>associations) - giving instant access, and avoiding having to construct 
>> the
>>query, which is usually somewhat messy.
>>- allows other information to be stored directly about the thing the
>>Folder represents, e.g. admission / stay in a facility.
>>
>> - thomas
>>
>> On 17/08/2018 16:20, Seref Arikan wrote:
>>
>> Hi Ian,
>>
>> When the fact that the Composition is associated to an encounter or
>> episode of care is recorded by including a reference to that composition in
>> a folder, some clinical context/information related to that composition is
>> now stored outside the composition, by means of a refence in a folder
>>
>> Unless I'm missing an Aql feature that can help, you can no longer select
>> those compositions via Aql (since Aql does not support/specify how to
>> resolve refs)
>>
>> If you follow the encounter id approach you mentioned, then you could use
>> Aql.
>>
>> In fact, if Ethercis had support for Folder, Dileep would still not be
>> able to get those compositions with a singl query: he'd need to fetchs uids
>> from a folder with one query, then perform a second query to get
>> compositions in the way I suggested.
>>
>> I'm probably being unnecessarily picky here, just pointing at the
>> difference between approaches and trying to put my finger on any downstream
>> issues. I'm not doing a great job of it though :)
>>
>> On Friday, August 17, 2018, Ian McNicoll  wrote:
>>
>>> Hi Seref,
>>>
>>> I'm not sure I understand your concerns here. I think the use case is
>>> where there is a need to group compositions by some other higher level
>>> construct which usually reflect something like an admission, episode of
>>> outpatient care or perhaps a community plan of care.
>>>
>>> As Dileep has indicated he probably would use folders if Ethercis
>>> supported them. Another alternative is to create an Encounter ID for each
>>> new encounter (which in Dileep's example, I think I would call an episode
>>> of care, and simply tag each composition with that Encounter ID e.g create
>>> a cluster archetype to hold this in every Composition/ other_context. I
>>> have done that on other projects. So it is a case of looking of all
>>> composition with EncounterId = x
>>> Now I would probably go down the Folder route, if I could.
>>> 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 Fri, 17 Aug 2018 at 13:59, Seref Arikan <
>>> serefari...@kurumsalteknoloji.com> 

Re: AQL on specific list of compositions

[Bert Verhees]

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.

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.

But maybe I am missing something

Bert

Op za 18 aug. 2018 05:40 schreef Dileep V S :

> Very interesting discussion that has helped us get some of our thoughts
> clarified. We have started building a virtual folder as a service outside
> Ethercis to cover our requirements and are hoping to migrate the structure
> into the EHR server at a later date.
>
> The plan is to cover both the things mentioned in Thomas's response. We
> intend to get a list of compositions associated with a folder from this
> service and pass it to the AQL to get what we want.
>
> However, I am not sure how to rebuild the folder structure if it is lost.
> We do not have any folder related information inside Compositions and so
> the query can only go from folder to the composition and not the other way.
> Keeping folder details in Composition may not be a good idea as folder is
> meant to be virtual grouping and can have some dynamism around it. Also
> same composition can, in theory, be part of multiple folders. There is also
> the concept of a folder hierarchy that exists only within the folder
> service.
>
> regards
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
> On Fri, Aug 17, 2018 at 9:30 PM, Thomas Beale 
> wrote:
>
>>
>> The easiest way to think about this question is: if someone trashed the
>> Folder structure, could we (some admin app) rebuild it? The answer is
>> interesting. It should normally be possible to rebuild the Folder /
>> Composition association structure (it's not containment, just referencing),
>> but of course, if you stored other information in the Folders, for example
>> in the recently SEC-approved other_details structure, then you would lose
>> that.
>>
>> So the Folder approach does two things:
>>
>>- represents a pre-built query result (the Folder/Composition
>>associations) - giving instant access, and avoiding having to construct 
>> the
>>query, which is usually somewhat messy.
>>- allows other information to be stored directly about the thing the
>>Folder represents, e.g. admission / stay in a facility.
>>
>> - thomas
>>
>> On 17/08/2018 16:20, Seref Arikan wrote:
>>
>> Hi Ian,
>>
>> When the fact that the Composition is associated to an encounter or
>> episode of care is recorded by including a reference to that composition in
>> a folder, some clinical context/information related to that composition is
>> now stored outside the composition, by means of a refence in a folder
>>
>> Unless I'm missing an Aql feature that can help, you can no longer select
>> those compositions via Aql (since Aql does not support/specify how to
>> resolve refs)
>>
>> If you follow the encounter id approach you mentioned, then you could use
>> Aql.
>>
>> In fact, if Ethercis had support for Folder, Dileep would still not be
>> able to get those compositions with a singl query: he'd need to fetchs uids
>> from a folder with one query, then perform a second query to get
>> compositions in the way I suggested.
>>
>> I'm probably being unnecessarily picky here, just pointing at the
>> difference between approaches and trying to put my finger on any downstream
>> issues. I'm not doing a great job of it though :)
>>
>> On Friday, August 17, 2018, Ian McNicoll  wrote:
>>
>>> Hi Seref,
>>>
>>> I'm not sure I understand your concerns here. I think the use case is
>>> where there is a need to group compositions by some other higher level
>>> construct which usually reflect something like an admission, episode of
>>> outpatient care or perhaps a community plan of care.
>>>
>>> As Dileep has indicated he probably would use folders if Ethercis
>>> supported them. Another alternative is to create an Encounter ID for each
>>> new encounter (which in Dileep's example, I think I would call an episode
>>> of care, and simply tag each composition with that Encounter ID e.g create
>>> a cluster archetype to hold this in every Composition/ other_context. I
>>> have done that on other projects. So it is a case of looking of all
>>> composition with EncounterId = x
>>> Now I would probably go down the Folder route, if I could.
>>> 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

Re: AQL on specific list of compositions

[Dileep V S]

Very interesting discussion that has helped us get some of our thoughts
clarified. We have started building a virtual folder as a service outside
Ethercis to cover our requirements and are hoping to migrate the structure
into the EHR server at a later date.

The plan is to cover both the things mentioned in Thomas's response. We
intend to get a list of compositions associated with a folder from this
service and pass it to the AQL to get what we want.

However, I am not sure how to rebuild the folder structure if it is lost.
We do not have any folder related information inside Compositions and so
the query can only go from folder to the composition and not the other way.
Keeping folder details in Composition may not be a good idea as folder is
meant to be virtual grouping and can have some dynamism around it. Also
same composition can, in theory, be part of multiple folders. There is also
the concept of a folder hierarchy that exists only within the folder
service.

regards

Dileep V S
*Founder*
HealtheLife Ventures LLP
m: +91 9632888113
a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
w: healthelife.in  e: dil...@healthelife.in

On Fri, Aug 17, 2018 at 9:30 PM, Thomas Beale 
wrote:

>
> The easiest way to think about this question is: if someone trashed the
> Folder structure, could we (some admin app) rebuild it? The answer is
> interesting. It should normally be possible to rebuild the Folder /
> Composition association structure (it's not containment, just referencing),
> but of course, if you stored other information in the Folders, for example
> in the recently SEC-approved other_details structure, then you would lose
> that.
>
> So the Folder approach does two things:
>
>- represents a pre-built query result (the Folder/Composition
>associations) - giving instant access, and avoiding having to construct the
>query, which is usually somewhat messy.
>- allows other information to be stored directly about the thing the
>Folder represents, e.g. admission / stay in a facility.
>
> - thomas
>
> On 17/08/2018 16:20, Seref Arikan wrote:
>
> Hi Ian,
>
> When the fact that the Composition is associated to an encounter or
> episode of care is recorded by including a reference to that composition in
> a folder, some clinical context/information related to that composition is
> now stored outside the composition, by means of a refence in a folder
>
> Unless I'm missing an Aql feature that can help, you can no longer select
> those compositions via Aql (since Aql does not support/specify how to
> resolve refs)
>
> If you follow the encounter id approach you mentioned, then you could use
> Aql.
>
> In fact, if Ethercis had support for Folder, Dileep would still not be
> able to get those compositions with a singl query: he'd need to fetchs uids
> from a folder with one query, then perform a second query to get
> compositions in the way I suggested.
>
> I'm probably being unnecessarily picky here, just pointing at the
> difference between approaches and trying to put my finger on any downstream
> issues. I'm not doing a great job of it though :)
>
> On Friday, August 17, 2018, Ian McNicoll  wrote:
>
>> Hi Seref,
>>
>> I'm not sure I understand your concerns here. I think the use case is
>> where there is a need to group compositions by some other higher level
>> construct which usually reflect something like an admission, episode of
>> outpatient care or perhaps a community plan of care.
>>
>> As Dileep has indicated he probably would use folders if Ethercis
>> supported them. Another alternative is to create an Encounter ID for each
>> new encounter (which in Dileep's example, I think I would call an episode
>> of care, and simply tag each composition with that Encounter ID e.g create
>> a cluster archetype to hold this in every Composition/ other_context. I
>> have done that on other projects. So it is a case of looking of all
>> composition with EncounterId = x
>> Now I would probably go down the Folder route, if I could.
>> 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 Fri, 17 Aug 2018 at 13:59, Seref Arikan > .com> wrote:
>>
>>> I'm used to thinking compositions as semantcally self contained units of
>>> information, at the very least using references to other means of
>>> expressing semantics (as in terminologies)
>>>
>>> What you're describing seems to take some clincal semantics out of the
>>> composion and if we have multiple ways of doing that, it may hurt
>>> reusability of queries and data.
>>>
>>> Do you think we can find a way of expressing this semantcs without
>>> losing its trace within the cmposition?
>>>
>>> (Sorry for the typos, on the phone..)
>>>
>>> On

Re: AQL on specific list of compositions

[Thomas Beale]

The easiest way to think about this question is: if someone trashed the 
Folder structure, could we (some admin app) rebuild it? The answer is 
interesting. It should normally be possible to rebuild the Folder / 
Composition association structure (it's not containment, just 
referencing), but of course, if you stored other information in the 
Folders, for example in the recently SEC-approved other_details 
structure, then you would lose that.


So the Folder approach does two things:

 * represents a pre-built query result (the Folder/Composition
   associations) - giving instant access, and avoiding having to
   construct the query, which is usually somewhat messy.
 * allows other information to be stored directly about the thing the
   Folder represents, e.g. admission / stay in a facility.

- thomas


On 17/08/2018 16:20, Seref Arikan wrote:

Hi Ian,

When the fact that the Composition is associated to an encounter or 
episode of care is recorded by including a reference to that 
composition in a folder, some clinical context/information related to 
that composition is now stored outside the composition, by means of a 
refence in a folder


Unless I'm missing an Aql feature that can help, you can no longer 
select those compositions via Aql (since Aql does not support/specify 
how to resolve refs)


If you follow the encounter id approach you mentioned, then you could 
use Aql.


In fact, if Ethercis had support for Folder, Dileep would still not be 
able to get those compositions with a singl query: he'd need to fetchs 
uids from a folder with one query, then perform a second query to get 
compositions in the way I suggested.


I'm probably being unnecessarily picky here, just pointing at the 
difference between approaches and trying to put my finger on any 
downstream issues. I'm not doing a great job of it though :)


On Friday, August 17, 2018, Ian McNicoll > wrote:


Hi Seref,

I'm not sure I understand your concerns here. I think the use case
is where there is a need to group compositions by some other
higher level construct which usually reflect something like an
admission, episode of outpatient care or perhaps a community plan
of care.

As Dileep has indicated he probably would use folders if Ethercis
supported them. Another alternative is to create an Encounter ID
for each new encounter (which in Dileep's example, I think I would
call an episode of care, and simply tag each composition with that
Encounter ID e.g create a cluster archetype to hold this in every
Composition/ other_context. I have done that on other projects. So
it is a case of looking of all composition with EncounterId = x
Now I would probably go down the Folder route, if I could.
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 Fri, 17 Aug 2018 at 13:59, Seref Arikan
mailto:serefari...@kurumsalteknoloji.com>> wrote:

I'm used to thinking compositions as semantcally self
contained units of information, at the very least using
references to other means of expressing semantics (as in
terminologies)

What you're describing seems to take some clincal semantics
out of the composion and if we have multiple ways of doing
that, it may hurt reusability of queries and data.

Do you think we can find a way of expressing this semantcs
without losing its trace within the cmposition?

(Sorry for the typos, on the phone..)

On Friday, August 17, 2018, Thomas Beale
mailto:thomas.be...@openehr.org>>
wrote:

There is a bigger question of how best to model
'encounter' and 'admission', which some implementers are
doing with Folders, particularly DIPS in Norway. I suspect
that some version of using Folders (or else some kind of
tagging, which is semantically equivalent) will be the
long term approach to doing this.

- thomas


On 17/08/2018 10:54, Dileep V S wrote:

Hi,

Can you write an AQL to query only on a list of specific
compositions? Is there any sample for reference?

I am trying to create the concept of clinical encounters
and maintain a collection of compositions per encounter.
I am using AQL to retrieve data per encounter and need to
pass the corresponding set of compositions.

Thanks in advance

regards



-- 
Thomas Beale

Principal, Ars Sema

Re: AQL on specific list of compositions

[Seref Arikan]

But folder does not contain COMPOSITIONS,  it contains object refs
https://www.openehr.org/releases/RM/latest/docs/common/common.html#_folder_class

You need some aql semantics to resolve those refs to whatever they're
pointing at, which does not exist as far as I know (q: what if object refs
are pointing at different types ? :) )

Contains is only applicable to parent/child/../descendant relationship of
object.property paths



On Friday, August 17, 2018, Ian McNicoll  wrote:

> Hi Seref,
>
> My understanding is that AQL can support FOLDER (assuming it is
> implemented) with something like
>
> Select c
> FROM EHR e CONTAINS FOLDER f CONTAINS COMPOSITION c
> Where folder f.name = "My lovely encounters"
>
> but I may be wrong (both in principle and practice)
>
> 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 Fri, 17 Aug 2018 at 16:20, Seref Arikan  kurumsalteknoloji.com> wrote:
>
>> Hi Ian,
>>
>> When the fact that the Composition is associated to an encounter or
>> episode of care is recorded by including a reference to that composition in
>> a folder, some clinical context/information related to that composition is
>> now stored outside the composition, by means of a refence in a folder
>>
>> Unless I'm missing an Aql feature that can help, you can no longer select
>> those compositions via Aql (since Aql does not support/specify how to
>> resolve refs)
>>
>> If you follow the encounter id approach you mentioned, then you could use
>> Aql.
>>
>> In fact, if Ethercis had support for Folder, Dileep would still not be
>> able to get those compositions with a singl query: he'd need to fetchs uids
>> from a folder with one query, then perform a second query to get
>> compositions in the way I suggested.
>>
>> I'm probably being unnecessarily picky here, just pointing at the
>> difference between approaches and trying to put my finger on any downstream
>> issues. I'm not doing a great job of it though :)
>>
>> On Friday, August 17, 2018, Ian McNicoll  wrote:
>>
>>> Hi Seref,
>>>
>>> I'm not sure I understand your concerns here. I think the use case is
>>> where there is a need to group compositions by some other higher level
>>> construct which usually reflect something like an admission, episode of
>>> outpatient care or perhaps a community plan of care.
>>>
>>> As Dileep has indicated he probably would use folders if Ethercis
>>> supported them. Another alternative is to create an Encounter ID for each
>>> new encounter (which in Dileep's example, I think I would call an episode
>>> of care, and simply tag each composition with that Encounter ID e.g create
>>> a cluster archetype to hold this in every Composition/ other_context. I
>>> have done that on other projects. So it is a case of looking of all
>>> composition with EncounterId = x
>>> Now I would probably go down the Folder route, if I could.
>>> 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 Fri, 17 Aug 2018 at 13:59, Seref Arikan >> kurumsalteknoloji.com> wrote:
>>>
 I'm used to thinking compositions as semantcally self contained units
 of information, at the very least using references to other means of
 expressing semantics (as in terminologies)

 What you're describing seems to take some clincal semantics out of the
 composion and if we have multiple ways of doing that, it may hurt
 reusability of queries and data.

 Do you think we can find a way of expressing this semantcs without
 losing its trace within the cmposition?

 (Sorry for the typos, on the phone..)

 On Friday, August 17, 2018, Thomas Beale 
 wrote:

> There is a bigger question of how best to model 'encounter' and
> 'admission', which some implementers are doing with Folders, particularly
> DIPS in Norway. I suspect that some version of using Folders (or else some
> kind of tagging, which is semantically equivalent) will be the long term
> approach to doing this.
>
> - thomas
>
> On 17/08/2018 10:54, Dileep V S wrote:
>
> Hi,
>
> Can you write an AQL to query only on a list of specific compositions?
> Is there any sample for reference?
>
> I am trying to create the concept of clinical encounters and maintain
> a collection of compositions per encounter. I am using AQL to retrieve 
> data
> per encounter and need to pass the corresponding s

Re: AQL on specific list of compositions

[Ian McNicoll]

Hi Seref,

My understanding is that AQL can support FOLDER (assuming it is
implemented) with something like

Select c
FROM EHR e CONTAINS FOLDER f CONTAINS COMPOSITION c
Where folder f.name = "My lovely encounters"

but I may be wrong (both in principle and practice)

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 Fri, 17 Aug 2018 at 16:20, Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> Hi Ian,
>
> When the fact that the Composition is associated to an encounter or
> episode of care is recorded by including a reference to that composition in
> a folder, some clinical context/information related to that composition is
> now stored outside the composition, by means of a refence in a folder
>
> Unless I'm missing an Aql feature that can help, you can no longer select
> those compositions via Aql (since Aql does not support/specify how to
> resolve refs)
>
> If you follow the encounter id approach you mentioned, then you could use
> Aql.
>
> In fact, if Ethercis had support for Folder, Dileep would still not be
> able to get those compositions with a singl query: he'd need to fetchs uids
> from a folder with one query, then perform a second query to get
> compositions in the way I suggested.
>
> I'm probably being unnecessarily picky here, just pointing at the
> difference between approaches and trying to put my finger on any downstream
> issues. I'm not doing a great job of it though :)
>
> On Friday, August 17, 2018, Ian McNicoll  wrote:
>
>> Hi Seref,
>>
>> I'm not sure I understand your concerns here. I think the use case is
>> where there is a need to group compositions by some other higher level
>> construct which usually reflect something like an admission, episode of
>> outpatient care or perhaps a community plan of care.
>>
>> As Dileep has indicated he probably would use folders if Ethercis
>> supported them. Another alternative is to create an Encounter ID for each
>> new encounter (which in Dileep's example, I think I would call an episode
>> of care, and simply tag each composition with that Encounter ID e.g create
>> a cluster archetype to hold this in every Composition/ other_context. I
>> have done that on other projects. So it is a case of looking of all
>> composition with EncounterId = x
>> Now I would probably go down the Folder route, if I could.
>> 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 Fri, 17 Aug 2018 at 13:59, Seref Arikan <
>> serefari...@kurumsalteknoloji.com> wrote:
>>
>>> I'm used to thinking compositions as semantcally self contained units of
>>> information, at the very least using references to other means of
>>> expressing semantics (as in terminologies)
>>>
>>> What you're describing seems to take some clincal semantics out of the
>>> composion and if we have multiple ways of doing that, it may hurt
>>> reusability of queries and data.
>>>
>>> Do you think we can find a way of expressing this semantcs without
>>> losing its trace within the cmposition?
>>>
>>> (Sorry for the typos, on the phone..)
>>>
>>> On Friday, August 17, 2018, Thomas Beale 
>>> wrote:
>>>
 There is a bigger question of how best to model 'encounter' and
 'admission', which some implementers are doing with Folders, particularly
 DIPS in Norway. I suspect that some version of using Folders (or else some
 kind of tagging, which is semantically equivalent) will be the long term
 approach to doing this.

 - thomas

 On 17/08/2018 10:54, Dileep V S wrote:

 Hi,

 Can you write an AQL to query only on a list of specific compositions?
 Is there any sample for reference?

 I am trying to create the concept of clinical encounters and maintain a
 collection of compositions per encounter. I am using AQL to retrieve data
 per encounter and need to pass the corresponding set of compositions.

 Thanks in advance

 regards


 --
 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
 

Re: AQL on specific list of compositions

[Seref Arikan]

Hi Ian,

When the fact that the Composition is associated to an encounter or episode
of care is recorded by including a reference to that composition in a
folder, some clinical context/information related to that composition is
now stored outside the composition, by means of a refence in a folder

Unless I'm missing an Aql feature that can help, you can no longer select
those compositions via Aql (since Aql does not support/specify how to
resolve refs)

If you follow the encounter id approach you mentioned, then you could use
Aql.

In fact, if Ethercis had support for Folder, Dileep would still not be able
to get those compositions with a singl query: he'd need to fetchs uids from
a folder with one query, then perform a second query to get compositions in
the way I suggested.

I'm probably being unnecessarily picky here, just pointing at the
difference between approaches and trying to put my finger on any downstream
issues. I'm not doing a great job of it though :)

On Friday, August 17, 2018, Ian McNicoll  wrote:

> Hi Seref,
>
> I'm not sure I understand your concerns here. I think the use case is
> where there is a need to group compositions by some other higher level
> construct which usually reflect something like an admission, episode of
> outpatient care or perhaps a community plan of care.
>
> As Dileep has indicated he probably would use folders if Ethercis
> supported them. Another alternative is to create an Encounter ID for each
> new encounter (which in Dileep's example, I think I would call an episode
> of care, and simply tag each composition with that Encounter ID e.g create
> a cluster archetype to hold this in every Composition/ other_context. I
> have done that on other projects. So it is a case of looking of all
> composition with EncounterId = x
> Now I would probably go down the Folder route, if I could.
> 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 Fri, 17 Aug 2018 at 13:59, Seref Arikan  kurumsalteknoloji.com> wrote:
>
>> I'm used to thinking compositions as semantcally self contained units of
>> information, at the very least using references to other means of
>> expressing semantics (as in terminologies)
>>
>> What you're describing seems to take some clincal semantics out of the
>> composion and if we have multiple ways of doing that, it may hurt
>> reusability of queries and data.
>>
>> Do you think we can find a way of expressing this semantcs without losing
>> its trace within the cmposition?
>>
>> (Sorry for the typos, on the phone..)
>>
>> On Friday, August 17, 2018, Thomas Beale 
>> wrote:
>>
>>> There is a bigger question of how best to model 'encounter' and
>>> 'admission', which some implementers are doing with Folders, particularly
>>> DIPS in Norway. I suspect that some version of using Folders (or else some
>>> kind of tagging, which is semantically equivalent) will be the long term
>>> approach to doing this.
>>>
>>> - thomas
>>>
>>> On 17/08/2018 10:54, Dileep V S wrote:
>>>
>>> Hi,
>>>
>>> Can you write an AQL to query only on a list of specific compositions?
>>> Is there any sample for reference?
>>>
>>> I am trying to create the concept of clinical encounters and maintain a
>>> collection of compositions per encounter. I am using AQL to retrieve data
>>> per encounter and need to pass the corresponding set of compositions.
>>>
>>> Thanks in advance
>>>
>>> regards
>>>
>>>
>>> --
>>> 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
>>
>
___
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

[Ian McNicoll]

Hi Seref,

I'm not sure I understand your concerns here. I think the use case is where
there is a need to group compositions by some other higher level construct
which usually reflect something like an admission, episode of outpatient
care or perhaps a community plan of care.

As Dileep has indicated he probably would use folders if Ethercis supported
them. Another alternative is to create an Encounter ID for each new
encounter (which in Dileep's example, I think I would call an episode of
care, and simply tag each composition with that Encounter ID e.g create a
cluster archetype to hold this in every Composition/ other_context. I have
done that on other projects. So it is a case of looking of all composition
with EncounterId = x
Now I would probably go down the Folder route, if I could.
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 Fri, 17 Aug 2018 at 13:59, Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> I'm used to thinking compositions as semantcally self contained units of
> information, at the very least using references to other means of
> expressing semantics (as in terminologies)
>
> What you're describing seems to take some clincal semantics out of the
> composion and if we have multiple ways of doing that, it may hurt
> reusability of queries and data.
>
> Do you think we can find a way of expressing this semantcs without losing
> its trace within the cmposition?
>
> (Sorry for the typos, on the phone..)
>
> On Friday, August 17, 2018, Thomas Beale  wrote:
>
>> There is a bigger question of how best to model 'encounter' and
>> 'admission', which some implementers are doing with Folders, particularly
>> DIPS in Norway. I suspect that some version of using Folders (or else some
>> kind of tagging, which is semantically equivalent) will be the long term
>> approach to doing this.
>>
>> - thomas
>>
>> On 17/08/2018 10:54, Dileep V S wrote:
>>
>> Hi,
>>
>> Can you write an AQL to query only on a list of specific compositions? Is
>> there any sample for reference?
>>
>> I am trying to create the concept of clinical encounters and maintain a
>> collection of compositions per encounter. I am using AQL to retrieve data
>> per encounter and need to pass the corresponding set of compositions.
>>
>> Thanks in advance
>>
>> regards
>>
>>
>> --
>> 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
>
___
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]

I'm used to thinking compositions as semantcally self contained units of
information, at the very least using references to other means of
expressing semantics (as in terminologies)

What you're describing seems to take some clincal semantics out of the
composion and if we have multiple ways of doing that, it may hurt
reusability of queries and data.

Do you think we can find a way of expressing this semantcs without losing
its trace within the cmposition?

(Sorry for the typos, on the phone..)

On Friday, August 17, 2018, Thomas Beale  wrote:

> There is a bigger question of how best to model 'encounter' and
> 'admission', which some implementers are doing with Folders, particularly
> DIPS in Norway. I suspect that some version of using Folders (or else some
> kind of tagging, which is semantically equivalent) will be the long term
> approach to doing this.
>
> - thomas
>
> On 17/08/2018 10:54, Dileep V S wrote:
>
> Hi,
>
> Can you write an AQL to query only on a list of specific compositions? Is
> there any sample for reference?
>
> I am trying to create the concept of clinical encounters and maintain a
> collection of compositions per encounter. I am using AQL to retrieve data
> per encounter and need to pass the corresponding set of compositions.
>
> Thanks in advance
>
> regards
>
>
> --
> 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

[Dileep V S]

We are working on the same lines. As Ethecis does not have folder concept
currently, we are doing this minimally outside as a different service.

 thanks for the pointer
Regards



On Fri 17 Aug, 2018, 5:28 PM Thomas Beale,  wrote:

> There is a bigger question of how best to model 'encounter' and
> 'admission', which some implementers are doing with Folders, particularly
> DIPS in Norway. I suspect that some version of using Folders (or else some
> kind of tagging, which is semantically equivalent) will be the long term
> approach to doing this.
>
> - thomas
>
> On 17/08/2018 10:54, Dileep V S wrote:
>
> Hi,
>
> Can you write an AQL to query only on a list of specific compositions? Is
> there any sample for reference?
>
> I am trying to create the concept of clinical encounters and maintain a
> collection of compositions per encounter. I am using AQL to retrieve data
> per encounter and need to pass the corresponding set of compositions.
>
> Thanks in advance
>
> regards
>
>
> --
> 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
>
___
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]

There is a bigger question of how best to model 'encounter' and 
'admission', which some implementers are doing with Folders, 
particularly DIPS in Norway. I suspect that some version of using 
Folders (or else some kind of tagging, which is semantically equivalent) 
will be the long term approach to doing this.


- thomas


On 17/08/2018 10:54, Dileep V S wrote:

Hi,

Can you write an AQL to query only on a list of specific compositions? 
Is there any sample for reference?


I am trying to create the concept of clinical encounters and maintain 
a collection of compositions per encounter. I am using AQL to retrieve 
data per encounter and need to pass the corresponding set of compositions.


Thanks in advance

regards



--
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

[Dileep V S]

thanks Ian, Seref

 regards

On Fri 17 Aug, 2018, 4:25 PM Ian McNicoll,  wrote:

> Beat me to it :(
>
> 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 Fri, 17 Aug 2018 at 11:52, Seref Arikan <
> serefari...@kurumsalteknoloji.com> wrote:
>
>> Modifying Ian's example for a/uid/value and using uid values instead of
>> names should do the trick
>>
>> On Friday, August 17, 2018, Dileep V S  wrote:
>>
>>> Thanks Ian,
>>>
>>> However my requirement is different. I seem to have confused you with
>>> the way my question was framed.
>>>
>>> What I meant by composition ID was in fact Composition UID. I want to
>>> query the same template (/name/value), but limited to specific commits
>>> (compositionUIDs).
>>>
>>> I hope that helps
>>>
>>> regards
>>>
>>> Dileep V S
>>> *Founder*
>>> HealtheLife Ventures LLP
>>> m: +91 9632888113
>>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>>> w: healthelife.in  e: dil...@healthelife.in
>>>
>>> On Fri, Aug 17, 2018 at 3:54 PM, Ian McNicoll  wrote:
>>>
 Hi Dileep,

 I do this by querying on the name attribute of the root composition
 archetype - see the examples in


 https://github.com/RippleOSI/Ripple-openEHR/blob/master/docs/bindings/Current%20Ripple%20Headings/Clinical%20notes/clinical_notes.md

 You can of course query on multiple names.

 where a/name/value matches {'Clinical Notes', 'Other Clinical Notes'}

 Going forward I would expect the list of allowable composition names to
 come from a controlled vocabulary or even a local terminology.

 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 Fri, 17 Aug 2018 at 10:54, Dileep V S  wrote:

> Hi,
>
> Can you write an AQL to query only on a list of specific compositions?
> Is there any sample for reference?
>
> I am trying to create the concept of clinical encounters and maintain
> a collection of compositions per encounter. I am using AQL to retrieve 
> data
> per encounter and need to pass the corresponding set of compositions.
>
> Thanks in advance
>
> regards
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
> ___
> 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
>>
> ___
> 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

[Ian McNicoll]

Beat me to it :(

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 Fri, 17 Aug 2018 at 11:52, Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> Modifying Ian's example for a/uid/value and using uid values instead of
> names should do the trick
>
> On Friday, August 17, 2018, Dileep V S  wrote:
>
>> Thanks Ian,
>>
>> However my requirement is different. I seem to have confused you with the
>> way my question was framed.
>>
>> What I meant by composition ID was in fact Composition UID. I want to
>> query the same template (/name/value), but limited to specific commits
>> (compositionUIDs).
>>
>> I hope that helps
>>
>> regards
>>
>> Dileep V S
>> *Founder*
>> HealtheLife Ventures LLP
>> m: +91 9632888113
>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>> w: healthelife.in  e: dil...@healthelife.in
>>
>> On Fri, Aug 17, 2018 at 3:54 PM, Ian McNicoll  wrote:
>>
>>> Hi Dileep,
>>>
>>> I do this by querying on the name attribute of the root composition
>>> archetype - see the examples in
>>>
>>>
>>> https://github.com/RippleOSI/Ripple-openEHR/blob/master/docs/bindings/Current%20Ripple%20Headings/Clinical%20notes/clinical_notes.md
>>>
>>> You can of course query on multiple names.
>>>
>>> where a/name/value matches {'Clinical Notes', 'Other Clinical Notes'}
>>>
>>> Going forward I would expect the list of allowable composition names to
>>> come from a controlled vocabulary or even a local terminology.
>>>
>>> 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 Fri, 17 Aug 2018 at 10:54, Dileep V S  wrote:
>>>
 Hi,

 Can you write an AQL to query only on a list of specific compositions?
 Is there any sample for reference?

 I am trying to create the concept of clinical encounters and maintain a
 collection of compositions per encounter. I am using AQL to retrieve data
 per encounter and need to pass the corresponding set of compositions.

 Thanks in advance

 regards

 Dileep V S
 *Founder*
 HealtheLife Ventures LLP
 m: +91 9632888113
 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
 w: healthelife.in  e: dil...@healthelife.in
 ___
 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
>
___
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]

Modifying Ian's example for a/uid/value and using uid values instead of
names should do the trick

On Friday, August 17, 2018, Dileep V S  wrote:

> Thanks Ian,
>
> However my requirement is different. I seem to have confused you with the
> way my question was framed.
>
> What I meant by composition ID was in fact Composition UID. I want to
> query the same template (/name/value), but limited to specific commits
> (compositionUIDs).
>
> I hope that helps
>
> regards
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
> On Fri, Aug 17, 2018 at 3:54 PM, Ian McNicoll  wrote:
>
>> Hi Dileep,
>>
>> I do this by querying on the name attribute of the root composition
>> archetype - see the examples in
>>
>> https://github.com/RippleOSI/Ripple-openEHR/blob/master/docs
>> /bindings/Current%20Ripple%20Headings/Clinical%20notes/clinical_notes.md
>>
>> You can of course query on multiple names.
>>
>> where a/name/value matches {'Clinical Notes', 'Other Clinical Notes'}
>>
>> Going forward I would expect the list of allowable composition names to
>> come from a controlled vocabulary or even a local terminology.
>>
>> 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 Fri, 17 Aug 2018 at 10:54, Dileep V S  wrote:
>>
>>> Hi,
>>>
>>> Can you write an AQL to query only on a list of specific compositions?
>>> Is there any sample for reference?
>>>
>>> I am trying to create the concept of clinical encounters and maintain a
>>> collection of compositions per encounter. I am using AQL to retrieve data
>>> per encounter and need to pass the corresponding set of compositions.
>>>
>>> Thanks in advance
>>>
>>> regards
>>>
>>> Dileep V S
>>> *Founder*
>>> HealtheLife Ventures LLP
>>> m: +91 9632888113
>>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>>> w: healthelife.in  e: dil...@healthelife.in
>>> ___
>>> 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

[Dileep V S]

Thanks Ian,

However my requirement is different. I seem to have confused you with the
way my question was framed.

What I meant by composition ID was in fact Composition UID. I want to query
the same template (/name/value), but limited to specific commits
(compositionUIDs).

I hope that helps

regards

Dileep V S
*Founder*
HealtheLife Ventures LLP
m: +91 9632888113
a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
w: healthelife.in  e: dil...@healthelife.in

On Fri, Aug 17, 2018 at 3:54 PM, Ian McNicoll  wrote:

> Hi Dileep,
>
> I do this by querying on the name attribute of the root composition
> archetype - see the examples in
>
> https://github.com/RippleOSI/Ripple-openEHR/blob/master/
> docs/bindings/Current%20Ripple%20Headings/Clinical%
> 20notes/clinical_notes.md
>
> You can of course query on multiple names.
>
> where a/name/value matches {'Clinical Notes', 'Other Clinical Notes'}
>
> Going forward I would expect the list of allowable composition names to
> come from a controlled vocabulary or even a local terminology.
>
> 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 Fri, 17 Aug 2018 at 10:54, Dileep V S  wrote:
>
>> Hi,
>>
>> Can you write an AQL to query only on a list of specific compositions? Is
>> there any sample for reference?
>>
>> I am trying to create the concept of clinical encounters and maintain a
>> collection of compositions per encounter. I am using AQL to retrieve data
>> per encounter and need to pass the corresponding set of compositions.
>>
>> Thanks in advance
>>
>> regards
>>
>> Dileep V S
>> *Founder*
>> HealtheLife Ventures LLP
>> m: +91 9632888113
>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>> w: healthelife.in  e: dil...@healthelife.in
>> ___
>> 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

[Ian McNicoll]

Hi Dileep,

I do this by querying on the name attribute of the root composition
archetype - see the examples in

https://github.com/RippleOSI/Ripple-openEHR/blob/master/docs/bindings/Current%20Ripple%20Headings/Clinical%20notes/clinical_notes.md

You can of course query on multiple names.

where a/name/value matches {'Clinical Notes', 'Other Clinical Notes'}

Going forward I would expect the list of allowable composition names to
come from a controlled vocabulary or even a local terminology.

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 Fri, 17 Aug 2018 at 10:54, Dileep V S  wrote:

> Hi,
>
> Can you write an AQL to query only on a list of specific compositions? Is
> there any sample for reference?
>
> I am trying to create the concept of clinical encounters and maintain a
> collection of compositions per encounter. I am using AQL to retrieve data
> per encounter and need to pass the corresponding set of compositions.
>
> Thanks in advance
>
> regards
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
> ___
> 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

AQL on specific list of compositions

[Dileep V S]

Hi,

Can you write an AQL to query only on a list of specific compositions? Is
there any sample for reference?

I am trying to create the concept of clinical encounters and maintain a
collection of compositions per encounter. I am using AQL to retrieve data
per encounter and need to pass the corresponding set of compositions.

Thanks in advance

regards

Dileep V S
*Founder*
HealtheLife Ventures LLP
m: +91 9632888113
a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
w: healthelife.in  e: dil...@healthelife.in
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org