Re: AQL for multi-occurrence nodes

[Dileep V S]

Dear Thomas,

Can you point me to details of Java structures

regards

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

On Thu, Nov 2, 2017 at 8:12 PM, Thomas Beale 
wrote:

> Hi Dileep
>
> On 27/10/2017 04:15, Dileep V S wrote:
>
> Hi,
>
> What is the expected response to AQL on a node with multiple occurrences?
> Does it return all the occurrences or only the first one?
>
>
> querying is always about returning everything that matches - it's a
> declarative concept, not a procedural one.
>
>
> If it is expected to return all occurrences, what is the structure of the
> response? will the occurrences be returned as an array?
>
>
> In REST terms, see here
> . If you want
> other structures, e.g. C# / Java / other language etc, please respond here,
> there are answers for that as well.
>
> - thomas
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> 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: Scenarios for change type "deleted"

[Bert Verhees]

In a versioned system there is no status for "deleted" necessary *inside* a
composition. The system itself marks the composition deleted. With this in
mind it seems to me the semantical meaning of the inside "deleted" status
is meant for something else.

Bert

Op do 2 nov. 2017 20:01 schreef Pieter Bos :

> I meant data using the criteria you outlined.
>
> Regards,
>
> Pieter Bos
>
> Op 2 nov. 2017 om 18:25 heeft Pablo Pazos  > het volgende geschreven:
>
> Hi Pieter,
>
> What structure?
>
> On Thu, Nov 2, 2017 at 2:21 PM, Pieter Bos  pieter@nedap.com>> wrote:
> You would be able to import this structure into our implementation and it
> would work the same way.
>
> Pieter
>
> Op 2 nov. 2017 om 17:24 heeft Pablo Pazos  >> het volgende geschreven:
>
> Until we have a clear criteria for commits after delete, I'll use this:
>
> 1. lineal versioning (no branching)
> 2. "deleted" compositions can be "undeleted" using "modification" change
> type, since we don't have an "undelete" change type
> 3. if current latest version is "deleted" the composition won't appear on
> query results
>
>
>
> On Sun, Oct 15, 2017 at 11:49 AM, Pablo Pazos  >> wrote:
> Hi I'm trying to define a set of rules for a logical delete commit and
> have some gray areas that I'm not sure of.
>
> 1. commit after delete flow
>
> [creation v1] => [modification v2] => [deleted v3] => ?
>
> Can a modification/amendment v4 happen after a delete?
>
> This is one of those cases that forks in the version tree can happen,
> since v2 is deleted by v3, but v1 can be forked and a commit of
> modification or amendment can happen on that branch.
>
> I'm considering the delete only affects a VERSION, not the whole
> VERSIONED_OBJECT.
>
> Can a delete logically delete the whole VERSIONED_OBJECT?
>
> On a lineal versioning scheme, I'm not sure if an amendment can happen
> after the delete. because the semantics of lineal versioning is I'm
> versioning v3 not v1 if I do a commit after v3.
>
> I think if a delete happens, that is like killing that branch, so no new
> versions can be added.
>
> Is that correct? What do others think?
>
>
>
> 2. delete on persistent compos
>
> Looking at the specs, it is not clear to me how a delete would affect a
> persistent composition.
>
> This is an open question.
>
> This is also related with the previous case, since if a version is deleted
> on a persistent composition, there will be more commits for it after the
> delete, because it is persistent.
>
>
>
> 3. delete a non-trunk version
>
> [creation v1] => [modification v2] => [amendment v3] => ...
>
> Let's say there are many modifications/amendments for a compo, can be
> persistent or event.
>
> What happens if a version in the middle of the version tree/line is
> deleted?
>
> Can that even happen?
>
> What happens with the created versions after that?
>
> In my head those versions created on the branch of a deleted version
> should also be deleted if deletes are accepted in the middle of the tree.
> The other rule can be only accept deletes on the latest versions.
>
>
> What do you think?
>
>
> --
> Ing. Pablo Pazos Guti?rrez
> e: pablo.pa...@cabolabs.com pablo.pa...@cabolabs.com>
> p: +598 99 043 145
> skype: cabolabs
> [
> https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter
>
>
>
>
> --
> Ing. Pablo Pazos Guti?rrez
> e: pablo.pa...@cabolabs.com pablo.pa...@cabolabs.com>
> p: +598 99 043 145
> skype: cabolabs
> [
> https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org openEHR-technical@lists.openehr.org> openEHR-technical@lists.openehr.org 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 openEHR-technical@lists.openehr.org>
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> --
> Ing. Pablo Pazos Guti?rrez
> e: pablo.pa...@cabolab

Re: AQL for multi-occurrence nodes

[Dileep V S]

Thanks everybody for the clarification.

regards

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

On Thu, Nov 2, 2017 at 10:43 PM, Pablo Pazos 
wrote:

>
>
> On Fri, Oct 27, 2017 at 3:15 AM, Dileep V S  wrote:
>
>> Hi,
>>
>> What is the expected response to AQL on a node with multiple occurrences?
>> Does it return all the occurrences or only the first one?
>>
>>
> If the query matches multiple occurrences of data defined by the same
> archetype node, then all the matched occurrences should be returned. It
> doesn't make sense to return the first occurrence since each occurrence
> contains different clinical data.
>
>
>> If it is expected to return all occurrences, what is the structure of the
>> response? will the occurrences be returned as an array?
>>
>
> IMO the result will have the structure of the items in the SELECT, if the
> query projection is a COMPOSITION, then the result will be a list of
> compositions, and those might contain multiple occurrences of a node. On
> this context, the match in the WHERE might be that exists a node at certain
> path that contains certain value, that path might have multiple occurrences
> of a node, and the resulting compositions will be returned if any of those
> occurrences have that value.
>
> If the SELECT has a projection for the matched nodes that might have
> multiple occurrences, a list of those nodes will be returned, and those
> might be from many COMPOSITIONs. If the results are just a plain list, it
> will be difficult to know which occurrences have the same context
> (contained on the same composition), I prefer to return the composition uid
> alongside with the data and a timestamp.
>
>
>>
>> If only the first one is returned, how do we get all the occurrences?
>> Adding multiple select lines in aql may not be practical as the number of
>> occurrences can vary.
>>
>
> I don't think this is an issue of AQL, but an implementations issue on not
> supporting multiple occurrences of nodes on query results. Multiple
> occurrences is a basic part of the openEHR spec IMO and very common in
> clinical records, like having more than one diagnosis on the same document.
>
> As Thomas said, the query should return anything that matches, multiple
> occurrences included.
>
>
>>
>> Can nay body give a select statement syntax for this?
>>
>> regards
>>
>> Dileep V S
>> *Founder*
>> HealtheLife Ventures LLP
>> m: +91 9632888113 <+91%2096328%2088113>
>> a: 103, 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
>>
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> e: pablo.pa...@cabolabs.com
> p: +598 99 043 145
> skype: cabolabs
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
>
> ___
> 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: Scenarios for change type "deleted"

[Pieter Bos]

I meant data using the criteria you outlined.

Regards,

Pieter Bos

Op 2 nov. 2017 om 18:25 heeft Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>> het volgende 
geschreven:

Hi Pieter,

What structure?

On Thu, Nov 2, 2017 at 2:21 PM, Pieter Bos 
mailto:pieter@nedap.com>> wrote:
You would be able to import this structure into our implementation and it would 
work the same way.

Pieter

Op 2 nov. 2017 om 17:24 heeft Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>>>
 het volgende geschreven:

Until we have a clear criteria for commits after delete, I'll use this:

1. lineal versioning (no branching)
2. "deleted" compositions can be "undeleted" using "modification" change type, 
since we don't have an "undelete" change type
3. if current latest version is "deleted" the composition won't appear on query 
results



On Sun, Oct 15, 2017 at 11:49 AM, Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>>>
 wrote:
Hi I'm trying to define a set of rules for a logical delete commit and have 
some gray areas that I'm not sure of.

1. commit after delete flow

[creation v1] => [modification v2] => [deleted v3] => ?

Can a modification/amendment v4 happen after a delete?

This is one of those cases that forks in the version tree can happen, since v2 
is deleted by v3, but v1 can be forked and a commit of modification or 
amendment can happen on that branch.

I'm considering the delete only affects a VERSION, not the whole 
VERSIONED_OBJECT.

Can a delete logically delete the whole VERSIONED_OBJECT?

On a lineal versioning scheme, I'm not sure if an amendment can happen after 
the delete. because the semantics of lineal versioning is I'm versioning v3 not 
v1 if I do a commit after v3.

I think if a delete happens, that is like killing that branch, so no new 
versions can be added.

Is that correct? What do others think?



2. delete on persistent compos

Looking at the specs, it is not clear to me how a delete would affect a 
persistent composition.

This is an open question.

This is also related with the previous case, since if a version is deleted on a 
persistent composition, there will be more commits for it after the delete, 
because it is persistent.



3. delete a non-trunk version

[creation v1] => [modification v2] => [amendment v3] => ...

Let's say there are many modifications/amendments for a compo, can be 
persistent or event.

What happens if a version in the middle of the version tree/line is deleted?

Can that even happen?

What happens with the created versions after that?

In my head those versions created on the branch of a deleted version should 
also be deleted if deletes are accepted in the middle of the tree. The other 
rule can be only accept deletes on the latest versions.


What do you think?


--
Ing. Pablo Pazos Guti?rrez
e: 
pablo.pa...@cabolabs.com>
p: +598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter




--
Ing. Pablo Pazos Guti?rrez
e: 
pablo.pa...@cabolabs.com>
p: +598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter

___
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



--
Ing. Pablo Pazos Guti?rrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter

___
o

Re: Scenarios for change type "deleted"

[Thomas Beale]

On 15/10/2017 12:49, Pablo Pazos wrote:
Hi I'm trying to define a set of rules for a logical delete commit and 
have some gray areas that I'm not sure of.


*1. commit after delete flow*

[creation v1] => [modification v2] => [deleted v3] => ?

Can a modification/amendment v4 happen after a delete?


well, a deletion is a deletion, logically. In a non-versioned system, 
the data object would literally disappear. In a versioned system, such 
as we have, the top version records the fact of deletion, which 
logically applies to the whole versioned object.




This is one of those cases that forks in the version tree can happen, 
since v2 is deleted by v3, but v1 can be forked and a commit of 
modification or amendment can happen on that branch.


it could, if in system A (say in hospital A), the Composition is 
logically deleted but in system B (clinic B) a copy of that Composition 
(say medications list) is modified with a new version; then if this 
modified Versioned object is copied back to system A, system A will see 
a branched tree, which communicates the fact that hospital A thinks the 
information is no longer there, but clinic B does have a version of this 
information.


THis can only be resolved at the organisational level - i.e. by agreeing 
what is really going on with the medication list (or whatever the info 
object is) between the two HCFs.


But - is there any real scenario where this could actually happen? I 
can't imagine System A really wanting to delete the medication list 
Composition.




I'm considering the delete only affects a VERSION, not the whole 
VERSIONED_OBJECT.


Can a delete logically delete the whole VERSIONED_OBJECT?


that's what it logically means doing.



On a lineal versioning scheme, I'm not sure if an amendment can happen 
after the delete. because the semantics of lineal versioning is I'm 
versioning v3 not v1 if I do a commit after v3.


I think if a delete happens, that is like killing that branch, so no 
new versions can be added.


Is that correct? What do others think?


well as you point out, things might be ambiguous if two systems modify 
copies of the same versioned composition, and one of them does a logical 
deletion. We probably need to think about this more carefully and update 
the documentation. I at least would need to get a better understanding 
of the problem first i.e. real use cases.






*2. delete on persistent compos*

Looking at the specs, it is not clear to me how a delete would affect 
a persistent composition.


This is an open question.

This is also related with the previous case, since if a version is 
deleted on a persistent composition, there will be more commits for it 
after the delete, because it is persistent.


Well, deletion should really make the persistent composition act as if 
it wasn't there, except for queries in earlier time windows. So I would 
say a priori that further commits should be prevented, but - maybe 
someone is going to say: what if the deletion was an accident? Maybe 
there needs to be a lifecycle operation 'undelete' (or 'undo delete').






*3. delete a non-trunk version*

[creation v1] => [modification v2] => [amendment v3] => ...

Let's say there are many modifications/amendments for a compo, can be 
persistent or event.


What happens if a version in the middle of the version tree/line is 
deleted?


that can't happen - a deletion can only happen as the top version.

If we were talking about Git or some other typical system, deletion 
makes it look like a file is actually gone, and subsequent commits will 
create a new file of the same name, but whose version lineage is 
disconnected from the previous one. We could add something to the spec 
to force something like that behaviour.


- thomas

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

Re: Scenarios for change type "deleted"

[Pablo Pazos]

Hi Pieter,

What structure?

On Thu, Nov 2, 2017 at 2:21 PM, Pieter Bos  wrote:

> You would be able to import this structure into our implementation and it
> would work the same way.
>
> Pieter
>
> Op 2 nov. 2017 om 17:24 heeft Pablo Pazos  mailto:pablo.pa...@cabolabs.com>> het volgende geschreven:
>
> Until we have a clear criteria for commits after delete, I'll use this:
>
> 1. lineal versioning (no branching)
> 2. "deleted" compositions can be "undeleted" using "modification" change
> type, since we don't have an "undelete" change type
> 3. if current latest version is "deleted" the composition won't appear on
> query results
>
>
>
> On Sun, Oct 15, 2017 at 11:49 AM, Pablo Pazos  mailto:pablo.pa...@cabolabs.com>> wrote:
> Hi I'm trying to define a set of rules for a logical delete commit and
> have some gray areas that I'm not sure of.
>
> 1. commit after delete flow
>
> [creation v1] => [modification v2] => [deleted v3] => ?
>
> Can a modification/amendment v4 happen after a delete?
>
> This is one of those cases that forks in the version tree can happen,
> since v2 is deleted by v3, but v1 can be forked and a commit of
> modification or amendment can happen on that branch.
>
> I'm considering the delete only affects a VERSION, not the whole
> VERSIONED_OBJECT.
>
> Can a delete logically delete the whole VERSIONED_OBJECT?
>
> On a lineal versioning scheme, I'm not sure if an amendment can happen
> after the delete. because the semantics of lineal versioning is I'm
> versioning v3 not v1 if I do a commit after v3.
>
> I think if a delete happens, that is like killing that branch, so no new
> versions can be added.
>
> Is that correct? What do others think?
>
>
>
> 2. delete on persistent compos
>
> Looking at the specs, it is not clear to me how a delete would affect a
> persistent composition.
>
> This is an open question.
>
> This is also related with the previous case, since if a version is deleted
> on a persistent composition, there will be more commits for it after the
> delete, because it is persistent.
>
>
>
> 3. delete a non-trunk version
>
> [creation v1] => [modification v2] => [amendment v3] => ...
>
> Let's say there are many modifications/amendments for a compo, can be
> persistent or event.
>
> What happens if a version in the middle of the version tree/line is
> deleted?
>
> Can that even happen?
>
> What happens with the created versions after that?
>
> In my head those versions created on the branch of a deleted version
> should also be deleted if deletes are accepted in the middle of the tree.
> The other rule can be only accept deletes on the latest versions.
>
>
> What do you think?
>
>
> --
> Ing. Pablo Pazos Guti?rrez
> e: pablo.pa...@cabolabs.com
> p: +598 99 043 145
> skype: cabolabs
> [https://docs.google.com/uc?export=download&id=0B27lX-
> sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4
> VXBxWFZ6OXNnPQ] 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter
>
>
>
>
> --
> Ing. Pablo Pazos Guti?rrez
> e: pablo.pa...@cabolabs.com
> p: +598 99 043 145
> skype: cabolabs
> [https://docs.google.com/uc?export=download&id=0B27lX-
> sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4
> VXBxWFZ6OXNnPQ] 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org techni...@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
>



-- 
Ing. Pablo Pazos Gutiérrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs

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

Re: Scenarios for change type "deleted"

[Pieter Bos]

You would be able to import this structure into our implementation and it would 
work the same way.

Pieter

Op 2 nov. 2017 om 17:24 heeft Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>> het volgende 
geschreven:

Until we have a clear criteria for commits after delete, I'll use this:

1. lineal versioning (no branching)
2. "deleted" compositions can be "undeleted" using "modification" change type, 
since we don't have an "undelete" change type
3. if current latest version is "deleted" the composition won't appear on query 
results



On Sun, Oct 15, 2017 at 11:49 AM, Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>> wrote:
Hi I'm trying to define a set of rules for a logical delete commit and have 
some gray areas that I'm not sure of.

1. commit after delete flow

[creation v1] => [modification v2] => [deleted v3] => ?

Can a modification/amendment v4 happen after a delete?

This is one of those cases that forks in the version tree can happen, since v2 
is deleted by v3, but v1 can be forked and a commit of modification or 
amendment can happen on that branch.

I'm considering the delete only affects a VERSION, not the whole 
VERSIONED_OBJECT.

Can a delete logically delete the whole VERSIONED_OBJECT?

On a lineal versioning scheme, I'm not sure if an amendment can happen after 
the delete. because the semantics of lineal versioning is I'm versioning v3 not 
v1 if I do a commit after v3.

I think if a delete happens, that is like killing that branch, so no new 
versions can be added.

Is that correct? What do others think?



2. delete on persistent compos

Looking at the specs, it is not clear to me how a delete would affect a 
persistent composition.

This is an open question.

This is also related with the previous case, since if a version is deleted on a 
persistent composition, there will be more commits for it after the delete, 
because it is persistent.



3. delete a non-trunk version

[creation v1] => [modification v2] => [amendment v3] => ...

Let's say there are many modifications/amendments for a compo, can be 
persistent or event.

What happens if a version in the middle of the version tree/line is deleted?

Can that even happen?

What happens with the created versions after that?

In my head those versions created on the branch of a deleted version should 
also be deleted if deletes are accepted in the middle of the tree. The other 
rule can be only accept deletes on the latest versions.


What do you think?


--
Ing. Pablo Pazos Guti?rrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter




--
Ing. Pablo Pazos Guti?rrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter

___
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 for multi-occurrence nodes

[Pablo Pazos]

On Fri, Oct 27, 2017 at 3:15 AM, Dileep V S  wrote:

> Hi,
>
> What is the expected response to AQL on a node with multiple occurrences?
> Does it return all the occurrences or only the first one?
>
>
If the query matches multiple occurrences of data defined by the same
archetype node, then all the matched occurrences should be returned. It
doesn't make sense to return the first occurrence since each occurrence
contains different clinical data.


> If it is expected to return all occurrences, what is the structure of the
> response? will the occurrences be returned as an array?
>

IMO the result will have the structure of the items in the SELECT, if the
query projection is a COMPOSITION, then the result will be a list of
compositions, and those might contain multiple occurrences of a node. On
this context, the match in the WHERE might be that exists a node at certain
path that contains certain value, that path might have multiple occurrences
of a node, and the resulting compositions will be returned if any of those
occurrences have that value.

If the SELECT has a projection for the matched nodes that might have
multiple occurrences, a list of those nodes will be returned, and those
might be from many COMPOSITIONs. If the results are just a plain list, it
will be difficult to know which occurrences have the same context
(contained on the same composition), I prefer to return the composition uid
alongside with the data and a timestamp.


>
> If only the first one is returned, how do we get all the occurrences?
> Adding multiple select lines in aql may not be practical as the number of
> occurrences can vary.
>

I don't think this is an issue of AQL, but an implementations issue on not
supporting multiple occurrences of nodes on query results. Multiple
occurrences is a basic part of the openEHR spec IMO and very common in
clinical records, like having more than one diagnosis on the same document.

As Thomas said, the query should return anything that matches, multiple
occurrences included.


>
> Can nay body give a select statement syntax for this?
>
> regards
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113 <+91%2096328%2088113>
> a: 103, 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
>



-- 
Ing. Pablo Pazos Gutiérrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs

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

Re: Scenarios for change type "deleted"

[Pablo Pazos]

Until we have a clear criteria for commits after delete, I'll use this:

1. lineal versioning (no branching)
2. "deleted" compositions can be "undeleted" using "modification" change
type, since we don't have an "undelete" change type
3. if current latest version is "deleted" the composition won't appear on
query results



On Sun, Oct 15, 2017 at 11:49 AM, Pablo Pazos 
wrote:

> Hi I'm trying to define a set of rules for a logical delete commit and
> have some gray areas that I'm not sure of.
>
> *1. commit after delete flow*
>
> [creation v1] => [modification v2] => [deleted v3] => ?
>
> Can a modification/amendment v4 happen after a delete?
>
> This is one of those cases that forks in the version tree can happen,
> since v2 is deleted by v3, but v1 can be forked and a commit of
> modification or amendment can happen on that branch.
>
> I'm considering the delete only affects a VERSION, not the whole
> VERSIONED_OBJECT.
>
> Can a delete logically delete the whole VERSIONED_OBJECT?
>
> On a lineal versioning scheme, I'm not sure if an amendment can happen
> after the delete. because the semantics of lineal versioning is I'm
> versioning v3 not v1 if I do a commit after v3.
>
> I think if a delete happens, that is like killing that branch, so no new
> versions can be added.
>
> Is that correct? What do others think?
>
>
>
> *2. delete on persistent compos*
>
> Looking at the specs, it is not clear to me how a delete would affect a
> persistent composition.
>
> This is an open question.
>
> This is also related with the previous case, since if a version is deleted
> on a persistent composition, there will be more commits for it after the
> delete, because it is persistent.
>
>
>
> *3. delete a non-trunk version*
>
> [creation v1] => [modification v2] => [amendment v3] => ...
>
> Let's say there are many modifications/amendments for a compo, can be
> persistent or event.
>
> What happens if a version in the middle of the version tree/line is
> deleted?
>
> Can that even happen?
>
> What happens with the created versions after that?
>
> In my head those versions created on the branch of a deleted version
> should also be deleted if deletes are accepted in the middle of the tree.
> The other rule can be only accept deletes on the latest versions.
>
>
> What do you think?
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> e: pablo.pa...@cabolabs.com
> p: +598 99 043 145 <099%20043%20145>
> skype: cabolabs
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
>



-- 
Ing. Pablo Pazos Gutiérrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs

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

Re: AQL for multi-occurrence nodes

[Ian McNicoll]

Hi - agree with Thomas and more here

https://github.com/ethercis/ethercis/issues/69

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 2 November 2017 at 14:42, Thomas Beale  wrote:

> Hi Dileep
>
> On 27/10/2017 04:15, Dileep V S wrote:
>
> Hi,
>
> What is the expected response to AQL on a node with multiple occurrences?
> Does it return all the occurrences or only the first one?
>
>
> querying is always about returning everything that matches - it's a
> declarative concept, not a procedural one.
>
>
> If it is expected to return all occurrences, what is the structure of the
> response? will the occurrences be returned as an array?
>
>
> In REST terms, see here
> . If you want
> other structures, e.g. C# / Java / other language etc, please respond here,
> there are answers for that as well.
>
> - thomas
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> 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 for multi-occurrence nodes

[Thomas Beale]

Hi Dileep


On 27/10/2017 04:15, Dileep V S wrote:

Hi,

What is the expected response to AQL on a node with multiple 
occurrences? Does it return all the occurrences or only the first one?


querying is always about returning everything that matches - it's a 
declarative concept, not a procedural one.




If it is expected to return all occurrences, what is the structure of 
the response? will the occurrences be returned as an array?


In REST terms, see here 
. If you want 
other structures, e.g. C# / Java / other language etc, please respond 
here, there are answers for that as well.


- thomas

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

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

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