Re: Unique paths for slots problem if slots are filled with same archetype

[Erik Sundvall]

Hi all!

The issue (and some possible solutions/workarounds) is now described at 
https://openehr.atlassian.net/browse/SPECPR-279

Feel free to add information, comments etc there.

//Erik Sundvall


3 nov. 2018 kl. 15:12 skrev GF mailto:gf...@luna.nl>>:

Either it is solve using standardised basic Archetypes or via the RM.
The RM route is the preferred one.

When thinking about it, then…
Data in any Patient Record is either:
- de novo data stored at a session
- re-used pre-existing data (Reported data, used data in processes, etc.) This 
data is pre-existing data that is re-used. When querying for a concept it must 
be possible to restrict it to new data and/or re-used data.
Again this can be solved via standardised basic Archetypes or the RM.
The RM is the best option.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

On 3 Nov 2018, at 12:23, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:


I've just been thinking more about this problem. I agree we need to fix it, and 
it seems fairly likely adjusted rules for forming paths and storing archetype 
markers in data will be needed.

But... the archetype structure mentioned is a hack for getting around the lack 
of order-tracking attributes in the RM. We've had a look at this before (e.g. 
here)
 but I would suggest we need to think soon about additions to the ENTRY class 
or package to properly model requester and receiver meta-data.

- thomas

___
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: Unique paths for slots problem if slots are filled with same archetype

[GF]

Either it is solve using standardised basic Archetypes or via the RM.
The RM route is the preferred one.

When thinking about it, then…
Data in any Patient Record is either:
- de novo data stored at a session
- re-used pre-existing data (Reported data, used data in processes, etc.) This 
data is pre-existing data that is re-used. When querying for a concept it must 
be possible to restrict it to new data and/or re-used data.
Again this can be solved via standardised basic Archetypes or the RM.
The RM is the best option.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 3 Nov 2018, at 12:23, Thomas Beale  wrote:
> 
> I've just been thinking more about this problem. I agree we need to fix it, 
> and it seems fairly likely adjusted rules for forming paths and storing 
> archetype markers in data will be needed.
> 
> But... the archetype structure mentioned is a hack for getting around the 
> lack of order-tracking attributes in the RM. We've had a look at this before 
> (e.g. here 
> )
>  but I would suggest we need to think soon about additions to the ENTRY class 
> or package to properly model requester and receiver meta-data.
> 
> - thomas

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

Re: Unique paths for slots problem if slots are filled with same archetype

[Thomas Beale]

I've just been thinking more about this problem. I agree we need to fix 
it, and it seems fairly likely adjusted rules for forming paths and 
storing archetype markers in data will be needed.


But... the archetype structure mentioned is a hack for getting around 
the lack of order-tracking attributes in the RM. We've had a look at 
this before (e.g. here 
) 
but I would suggest we need to think soon about additions to the ENTRY 
class or package to properly model requester and receiver meta-data.


- thomas

On 19/10/2018 09:56, Sebastian Garde wrote:


Hi all,

We have encountered an interesting issue with how to construct unique 
paths for slots when there is more than one slot on the same level, 
and both slots are filled with the same archetype.


In this case, the resulting paths for both seem to be the same in OPT 
and thus in the data. (The at/id code of the slot are not part of the 
path for a filled slot.)


Likewise, you cannot apply an annotation to only one of them, because 
they share the same path.


This seems to be a general problem, but let me explain it in more 
detail using a concrete example:


The problem manifests itself for example when you start using the 
Service Request Archetype in CKM 
(https://ckm.openehr.org/ckm/#showArchetype_1013.1.614).


In the archetype’s protocol (see screenshot below), there are various 
slots, most importantly let’s look at the _Requester_ and the 
_Receiver_ Slot.


In a template (see 2^nd screenshot), both slots can be filled with the 
same archetype, technically, and it also seems reasonable from a 
content point of view to use the same archetype for both slots.


The problem is that this means that the paths are no longer unique – 
there is no way to differentiate between the Requester and Receiver 
information anymore as far as we can see in the OPT, and consequently 
in the data.


Also, if annotations are used on a path like this, these annotations 
would automatically be applied to both Requester and Receiver.


For example, the path for BOTH the Requester and Receiver, once filled 
with a service_request_information CLUSTER archetype is:


[openEHR-EHR-INSTRUCTION.service_request.v1]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1]

Is anybody already using this archetype (or a similar one) in their 
systems and is encountering this issue? Is anybody using workarounds 
for this?


One way this issue could be avoided/dodged is if the archetype wraps 
these slots in additional clusters, so that the resulting path is 
unique even if the same archetype is used inside slots on the same level.


It seems perfectly reasonable to me to construct archetypes the way 
this one has been constructed, but I am not sure if the implications 
are clear.


Is this something the SEC needs to have a look at if this is something 
that needs to be addressed somehow…or are we simply missing something?


Maybe at0141 for Requester / at0142 for Receiver need to be included 
in the path somehow (even if it is ugly)…




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

Re: AW: Unique paths for slots problem if slots are filled with same archetype

[Diego Boscá]

This could work in some cases, but if I recall correctly that name is
language dependent (i.e. Only one of the archetype translations is used) ,
which would make this difficult to implement in archetypes that have
several languages as you wouldn't be able to easily tell what label is
really there

El mar., 23 oct. 2018 15:25, Sam Heard 
escribió:

> Hi Tom
> If we are using the same archetype for the sender info and receiver data
> then I can see only two sensible options from a design perspective:
> 1) There are two slots...named receiver and sender.
> 2) the designer did not know what might be in here so the person filling
> the slot in the template or the data named them differently.
>
> In many situations it will be critical to differentiated sender and
> receiver unambiguously so a cluster could be a sensible solution. Otherwise
> transfering the name of a slot to the name of the archetype in the slot?
>
> Cheers Sam
>
>
>  Original message 
> From: Thomas Beale 
> Date: 23/10/18 9:50 pm (GMT+10:00)
> To: openehr-technical@lists.openehr.org
> Subject: Re: AW: Unique paths for slots problem if slots are filled with
> same archetype
>
> I'm becoming convinced that we need to make a technical change to allow
> the slot id be stored in the data, as suggested on the discussion thread
> already.
>
> So my suggestion for modellers is: assume it will get solved, and do your
> modelling in the natural / preferred way (i.e. don't introduce hacks like
> extra CLUSTERs), and we'll work out an ADL-level solution.
>
> It would help if you can add any detailed info to the description of the PR
> that Sebastian just created
> .
>
> - thomas
>
>
>
> On 23/10/2018 11:29, Bakke, Silje Ljosland wrote:
>
> Hi all! I hope the SEC will discuss and hopefully solve this issue in the
> upcoming meeting in Oslo. This is fairly serious from a modelling POV, as
> there are some archetypes that are based on the (in my opinion fair)
> assumption that it’s possible to tell two instances of the same CLUSTER in
> two parallel SLOTs apart. An example is “Communication capability”
> https://ckm.openehr.org/ckm/#showArchetype_1013.1.3155. We’d prefer not
> having to change the modelling to circumvent the technical issue, if
> possible. 
>
>
>
> Regards,
>
> *Silje*
>
>
> ___
> 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: AW: Unique paths for slots problem if slots are filled with same archetype

[Thomas Beale]

I'm becoming convinced that we need to make a technical change to allow 
the slot id be stored in the data, as suggested on the discussion thread 
already.


So my suggestion for modellers is: assume it will get solved, and do 
your modelling in the natural / preferred way (i.e. don't introduce 
hacks like extra CLUSTERs), and we'll work out an ADL-level solution.


It would help if you can add any detailed info to the description of the 
PR that Sebastian just created 
.


- thomas



On 23/10/2018 11:29, Bakke, Silje Ljosland wrote:


Hi all! I hope the SEC will discuss and hopefully solve this issue in 
the upcoming meeting in Oslo. This is fairly serious from a modelling 
POV, as there are some archetypes that are based on the (in my opinion 
fair) assumption that it’s possible to tell two instances of the same 
CLUSTER in two parallel SLOTs apart. An example is “Communication 
capability” https://ckm.openehr.org/ckm/#showArchetype_1013.1.3155. 
We’d prefer not having to change the modelling to circumvent the 
technical issue, if possible. 


Regards,

*Silje*



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

RE: AW: Unique paths for slots problem if slots are filled with same archetype

[Bakke, Silje Ljosland]

Hi all! I hope the SEC will discuss and hopefully solve this issue in the 
upcoming meeting in Oslo. This is fairly serious from a modelling POV, as there 
are some archetypes that are based on the (in my opinion fair) assumption that 
it’s possible to tell two instances of the same CLUSTER in two parallel SLOTs 
apart. An example is “Communication capability” 
https://ckm.openehr.org/ckm/#showArchetype_1013.1.3155. We’d prefer not having 
to change the modelling to circumvent the technical issue, if possible. 

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Tuesday, October 23, 2018 11:21 AM
To: openehr-technical@lists.openehr.org
Subject: Re: AW: Unique paths for slots problem if slots are filled with same 
archetype




On 23/10/2018 10:09, Sebastian Garde wrote:
So that we don’t forget, I have created 
https://openehr.atlassian.net/browse/SPECPR-279 for this.
I am not fussed whether it is prepended or appended, I can see tiny advantages 
for both.
The more interesting question to me is whether this is optional and only added 
when really needed or required.
There is this edge case, but I also wonder if a reasonable query on data would 
be to ask for anything inside a specific slot, no matter what it is filled with 
(as e.g. mandated by Template A vs Template B). This does not really seem to be 
(generally) possible - even if there are not two identical archetypes in 
different slots?


that would also require adding the slot node id, but I wonder how useful this 
particular query really could be... we never thought of it in 10 years of using 
AQL AFAIK...

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

Re: AW: Unique paths for slots problem if slots are filled with same archetype

[Thomas Beale]

On 23/10/2018 10:09, Sebastian Garde wrote:


So that we don’t forget, I have created 
https://openehr.atlassian.net/browse/SPECPR-279 for this.


I am not fussed whether it is prepended or appended, I can see tiny 
advantages for both.


The more interesting question to me is whether this is optional and 
only added when really needed or required.


There is this edge case, but I also wonder if a reasonable query on 
data would be to ask for anything inside a specific slot, no matter 
what it is filled with (as e.g. mandated by Template A vs Template B). 
This does not really seem to be (generally) possible - even if there 
are not two identical archetypes in different slots?




that would also require adding the slot node id, but I wonder how useful 
this particular query really could be... we never thought of it in 10 
years of using AQL AFAIK...


- thomas

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

AW: Unique paths for slots problem if slots are filled with same archetype

[Sebastian Garde]

So that we don’t forget, I have created 
https://openehr.atlassian.net/browse/SPECPR-279 for this.
I am not fussed whether it is prepended or appended, I can see tiny advantages 
for both.
The more interesting question to me is whether this is optional and only added 
when really needed or required.
There is this edge case, but I also wonder if a reasonable query on data would 
be to ask for anything inside a specific slot, no matter what it is filled with 
(as e.g. mandated by Template A vs Template B). This does not really seem to be 
(generally) possible - even if there are not two identical archetypes in 
different slots?

Sebastian

Von: openEHR-technical  Im Auftrag 
von Thomas Beale
Gesendet: Montag, 22. Oktober 2018 19:00
An: openehr-technical@lists.openehr.org
Betreff: Re: Unique paths for slots problem if slots are filled with same 
archetype


I need to study this problem a bit more, but having read the posts here, I 
think the solution would potentially to allow the optional addition of a 
'::at' appended to an archetype id at a root point. This means that all 
current systems and data remain valid. It is better if it is appended rather 
than prepended because it means the string id always starts with the archetype 
id (= the case today) and may have something on the end, and that would only be 
the case for this fairly rare use case. It would also be a fairly simple code 
upgrade to existing systems.

So I would agree with Diego's syntax below, but say that it is optional, and 
only required when needed, which appears to be this one edge case. If we can 
convince ourselves of this, this is a pretty easy change to the relevant 
template tools and also ADL2.

thoughts?

- thomas

On 19/10/2018 10:44, Diego Boscá wrote:
While I believe we have reproduced this behavior in the OPT management to be 
compatible with existing tooling, in our typical slot solving methodology 
(non-template mode) the original archetype slot node_id ends in the new object 
node_id. Information about which slot was solved in this node ended in a new 
attribute in the term definitions (we called that attribute 'DCM', but you get 
the idea). We modified the AOM model to have references to both current 
archetype and solved archetype in order to avoid node_id collisions in 
archetype definition time.


I think we have talked before about the need of splitting the archetype_node_id 
attribute into node_id / archetype_id, which I think would solve these 
problems. Another solution would be to include always the node id in the node 
id, even if you are using it to store the archetype_id, so paths would look like
[openEHR-EHR-INSTRUCTION.service_request.v1::at]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1::at0141]


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

Re: Unique paths for slots problem if slots are filled with same archetype

[Thomas Beale]

I need to study this problem a bit more, but having read the posts here, 
I think the solution would potentially to allow the /optional addition/ 
of a '::at' appended to an archetype id at a root point. This means 
that all current systems and data remain valid. It is better if it is 
appended rather than prepended because it means the string id always 
starts with the archetype id (= the case today) and may have something 
on the end, and that would only be the case for this fairly rare use 
case. It would also be a fairly simple code upgrade to existing systems.


So I would agree with Diego's syntax below, but say that it is optional, 
and only required when needed, which appears to be this one edge case. 
If we can convince ourselves of this, this is a pretty easy change to 
the relevant template tools and also ADL2.


thoughts?

- thomas


On 19/10/2018 10:44, Diego Boscá wrote:
While I believe we have reproduced this behavior in the OPT management 
to be compatible with existing tooling, in our typical slot solving 
methodology (non-template mode) the original archetype slot node_id 
ends in the new object node_id. Information about which slot was 
solved in this node ended in a new attribute in the term definitions 
(we called that attribute 'DCM', but you get the idea). We modified 
the AOM model to have references to both current archetype and solved 
archetype in order to avoid node_id collisions in archetype definition 
time.



I think we have talked before about the need of splitting the 
archetype_node_id attribute into node_id / archetype_id, which I think 
would solve these problems. Another solution would be to include 
always the node id in the node id, even if you are using it to store 
the archetype_id, so paths would look like

[openEHR-EHR-INSTRUCTION.service_request.v1::at]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1::at0141]



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

AW: Unique paths for slots problem if slots are filled with same archetype

[Sebastian Garde]

Hi Ian,

Yes, it is not many cases where this is really required, but in the Service 
Request archetype, it is fairly likely to happen and anybody creating a 
template without your, Diego’s, David’s, Heath’s etc. cutting edge top-level 
expert knowledge around this will quite likely run into a trap…so, yes, it 
should be fixed somehow.

The various workarounds (including David’s/Diego’s latest idea) ‘work’ and have 
slightly different advantages but all dodge the issue (of course).
Extra Clusters in the core archetype are clunky but avoid the need for doing 
anything in the template; Specialising the CLUSTER without changes for a new 
archetype id is probably more elegant and you can use it with the current 
published archetype...but on the other hand you need to know this and not 
forget . Renaming the root node of the slotted root node as you say is 
somewhat similar, easier, but mono-lingual.

Cheers,
Sebastian


Von: openEHR-technical  Im Auftrag 
von Ian McNicoll
Gesendet: Freitag, 19. Oktober 2018 13:09
An: For openEHR technical discussions 
Cc: Sarmad Al-Kufiash 
Betreff: Re: Unique paths for slots problem if slots are filled with same 
archetype

Hi Sebastian,

This is 'known issue' but not one that we had really thought too carefully 
about. We 'solve' it right now by renaming the slotted in archetype root node 
at template level but others have already pointed out that this is less than 
ideal.

Adding an intermediate cluster would solve things but feels clunky.

I understand Thomas had some ideas about this re ADL2 but I like the ideas from 
Heath / Diego also.

It is probably less of a practical issue than might seem the case as we tend 
not to have too many situations where the meaning needs to 'inherit' from the 
Slot name, and where those adjacent slot names differ for identical slot fills 
but agree it needs fixed.

Ian


@Diego - thanks for that input
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

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


On Fri, 19 Oct 2018 at 10:44, Diego Boscá 
mailto:yamp...@gmail.com>> wrote:
While I believe we have reproduced this behavior in the OPT management to be 
compatible with existing tooling, in our typical slot solving methodology 
(non-template mode) the original archetype slot node_id ends in the new object 
node_id. Information about which slot was solved in this node ended in a new 
attribute in the term definitions (we called that attribute 'DCM', but you get 
the idea). We modified the AOM model to have references to both current 
archetype and solved archetype in order to avoid node_id collisions in 
archetype definition time.


I think we have talked before about the need of splitting the archetype_node_id 
attribute into node_id / archetype_id, which I think would solve these 
problems. Another solution would be to include always the node id in the node 
id, even if you are using it to store the archetype_id, so paths would look like
[openEHR-EHR-INSTRUCTION.service_request.v1::at]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1::at0141]

Regards

El vie., 19 oct. 2018 a las 10:57, Sebastian Garde 
(mailto:sebastian.ga...@oceaninformatics.com>>)
 escribió:
Hi all,

We have encountered an interesting issue with how to construct unique paths for 
slots when there is more than one slot on the same level, and both slots are 
filled with the same archetype.
In this case, the resulting paths for both seem to be the same in OPT and thus 
in the data. (The at/id code of the slot are not part of the path for a filled 
slot.)
Likewise, you cannot apply an annotation to only one of them, because they 
share the same path.

This seems to be a general problem, but let me explain it in more detail using 
a concrete example:
The problem manifests itself for example when you start using the Service 
Request Archetype in CKM 
(https://ckm.openehr.org/ckm/#showArchetype_1013.1.614).

In the archetype’s protocol (see screenshot below), there are various slots, 
most importantly let’s look at the Requester and the Receiver Slot.
In a template (see 2nd screenshot), both slots can be filled with the same 
archetype, technically, and it also seems reasonable from a content point of 
view to use the same archetype for both slots.

The problem is that this means that the paths are no longer unique – there is 
no way to differentiate between the Requester and Receiver information anymore 
as far as we can see in the OPT, and consequently in the data.
Also, if annotations are used on a path like this, these annotations would 
automatically be 

Re: Unique paths for slots problem if slots are filled with same archetype

[Diego Boscá]

Discussing this with David we have another solution to this problem: one
thing you could do and would completely work without breaking anything is
to specify some kind of empty specializations of the include archetype, and
giving as the name of the specialization the node_id code. something like
this

[openEHR-EHR-INSTRUCTION.service_request-at.v1]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information-at0141.v1]

This won't break current systems and will probably solve the original
problem

Regards

El vie., 19 oct. 2018 a las 13:10, Ian McNicoll ()
escribió:

> Hi Sebastian,
>
> This is 'known issue' but not one that we had really thought too carefully
> about. We 'solve' it right now by renaming the slotted in archetype root
> node at template level but others have already pointed out that this is
> less than ideal.
>
> Adding an intermediate cluster would solve things but feels clunky.
>
> I understand Thomas had some ideas about this re ADL2 but I like the ideas
> from Heath / Diego also.
>
> It is probably less of a practical issue than might seem the case as we
> tend not to have too many situations where the meaning needs to 'inherit'
> from the Slot name, and where those adjacent slot names differ for
> identical slot fills but agree it needs fixed.
>
> Ian
>
>
> @Diego - thanks for that input
> 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, 19 Oct 2018 at 10:44, Diego Boscá  wrote:
>
>> While I believe we have reproduced this behavior in the OPT management to
>> be compatible with existing tooling, in our typical slot solving
>> methodology (non-template mode) the original archetype slot node_id ends in
>> the new object node_id. Information about which slot was solved in this
>> node ended in a new attribute in the term definitions (we called that
>> attribute 'DCM', but you get the idea). We modified the AOM model to have
>> references to both current archetype and solved archetype in order to avoid
>> node_id collisions in archetype definition time.
>>
>>
>> I think we have talked before about the need of splitting the
>> archetype_node_id attribute into node_id / archetype_id, which I think
>> would solve these problems. Another solution would be to include always the
>> node id in the node id, even if you are using it to store the archetype_id,
>> so paths would look like
>>
>> [openEHR-EHR-INSTRUCTION.service_request.v1::at]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1::at0141]
>>
>> Regards
>>
>> El vie., 19 oct. 2018 a las 10:57, Sebastian Garde (<
>> sebastian.ga...@oceaninformatics.com>) escribió:
>>
>>> Hi all,
>>>
>>>
>>>
>>> We have encountered an interesting issue with how to construct unique
>>> paths for slots when there is more than one slot on the same level, and
>>> both slots are filled with the same archetype.
>>>
>>> In this case, the resulting paths for both seem to be the same in OPT
>>> and thus in the data. (The at/id code of the slot are not part of the path
>>> for a filled slot.)
>>>
>>> Likewise, you cannot apply an annotation to only one of them, because
>>> they share the same path.
>>>
>>>
>>>
>>> This seems to be a general problem, but let me explain it in more detail
>>> using a concrete example:
>>>
>>> The problem manifests itself for example when you start using the
>>> Service Request Archetype in CKM (
>>> https://ckm.openehr.org/ckm/#showArchetype_1013.1.614).
>>>
>>>
>>>
>>> In the archetype’s protocol (see screenshot below), there are various
>>> slots, most importantly let’s look at the *Requester* and the *Receiver*
>>> Slot.
>>>
>>> In a template (see 2nd screenshot), both slots can be filled with the
>>> same archetype, technically, and it also seems reasonable from a content
>>> point of view to use the same archetype for both slots.
>>>
>>>
>>>
>>> The problem is that this means that the paths are no longer unique –
>>> there is no way to differentiate between the Requester and Receiver
>>> information anymore as far as we can see in the OPT, and consequently in
>>> the data.
>>>
>>> Also, if annotations are used on a path like this, these annotations
>>> would automatically be applied to both Requester and Receiver.
>>>
>>>
>>>
>>> For example, the path for BOTH the Requester and Receiver, once filled
>>> with a service_request_information CLUSTER archetype is:
>>>
>>>
>>> [openEHR-EHR-INSTRUCTION.service_request.v1]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1]
>>>
>>>
>>>
>>> Is anybody already using this archetype (or a similar one) in their
>>> systems and is encountering this issue? Is anybody using workarounds for
>>> this?
>>>
>>> One way this issue could be avoided/dodged 

Re: Unique paths for slots problem if slots are filled with same archetype

[Ian McNicoll]

Hi Sebastian,

This is 'known issue' but not one that we had really thought too carefully
about. We 'solve' it right now by renaming the slotted in archetype root
node at template level but others have already pointed out that this is
less than ideal.

Adding an intermediate cluster would solve things but feels clunky.

I understand Thomas had some ideas about this re ADL2 but I like the ideas
from Heath / Diego also.

It is probably less of a practical issue than might seem the case as we
tend not to have too many situations where the meaning needs to 'inherit'
from the Slot name, and where those adjacent slot names differ for
identical slot fills but agree it needs fixed.

Ian


@Diego - thanks for that input
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, 19 Oct 2018 at 10:44, Diego Boscá  wrote:

> While I believe we have reproduced this behavior in the OPT management to
> be compatible with existing tooling, in our typical slot solving
> methodology (non-template mode) the original archetype slot node_id ends in
> the new object node_id. Information about which slot was solved in this
> node ended in a new attribute in the term definitions (we called that
> attribute 'DCM', but you get the idea). We modified the AOM model to have
> references to both current archetype and solved archetype in order to avoid
> node_id collisions in archetype definition time.
>
>
> I think we have talked before about the need of splitting the
> archetype_node_id attribute into node_id / archetype_id, which I think
> would solve these problems. Another solution would be to include always the
> node id in the node id, even if you are using it to store the archetype_id,
> so paths would look like
>
> [openEHR-EHR-INSTRUCTION.service_request.v1::at]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1::at0141]
>
> Regards
>
> El vie., 19 oct. 2018 a las 10:57, Sebastian Garde (<
> sebastian.ga...@oceaninformatics.com>) escribió:
>
>> Hi all,
>>
>>
>>
>> We have encountered an interesting issue with how to construct unique
>> paths for slots when there is more than one slot on the same level, and
>> both slots are filled with the same archetype.
>>
>> In this case, the resulting paths for both seem to be the same in OPT and
>> thus in the data. (The at/id code of the slot are not part of the path for
>> a filled slot.)
>>
>> Likewise, you cannot apply an annotation to only one of them, because
>> they share the same path.
>>
>>
>>
>> This seems to be a general problem, but let me explain it in more detail
>> using a concrete example:
>>
>> The problem manifests itself for example when you start using the Service
>> Request Archetype in CKM (
>> https://ckm.openehr.org/ckm/#showArchetype_1013.1.614).
>>
>>
>>
>> In the archetype’s protocol (see screenshot below), there are various
>> slots, most importantly let’s look at the *Requester* and the *Receiver*
>> Slot.
>>
>> In a template (see 2nd screenshot), both slots can be filled with the
>> same archetype, technically, and it also seems reasonable from a content
>> point of view to use the same archetype for both slots.
>>
>>
>>
>> The problem is that this means that the paths are no longer unique –
>> there is no way to differentiate between the Requester and Receiver
>> information anymore as far as we can see in the OPT, and consequently in
>> the data.
>>
>> Also, if annotations are used on a path like this, these annotations
>> would automatically be applied to both Requester and Receiver.
>>
>>
>>
>> For example, the path for BOTH the Requester and Receiver, once filled
>> with a service_request_information CLUSTER archetype is:
>>
>>
>> [openEHR-EHR-INSTRUCTION.service_request.v1]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1]
>>
>>
>>
>> Is anybody already using this archetype (or a similar one) in their
>> systems and is encountering this issue? Is anybody using workarounds for
>> this?
>>
>> One way this issue could be avoided/dodged is if the archetype wraps
>> these slots in additional clusters, so that the resulting path is unique
>> even if the same archetype is used inside slots on the same level.
>>
>> It seems perfectly reasonable to me to construct archetypes the way this
>> one has been constructed, but I am not sure if the implications are clear.
>>
>>
>>
>> Is this something the SEC needs to have a look at if this is something
>> that needs to be addressed somehow…or are we simply missing something?
>>
>> Maybe at0141 for Requester / at0142 for Receiver need to be included in
>> the path somehow (even if it is ugly)…
>>
>>
>>
>> Regards,
>>
>> Sebastian
>>
>>
>>
>>
>>
>>
>> ___
>> 

AW: Unique paths for slots problem if slots are filled with same archetype

[Sebastian Garde]

Thanks Diego,

Yes, I think Heath has suggested a path similar to your second suggestion, just 
with a comma as separator and in a different order:
[at0008,openEHR-EHR-INSTRUCTION.service_request.v1]/protocol[at0008]/items[at0141,openEHR-EHR-CLUSTER.service_request_information.v1]

I would probably prefer the mixture of your two suggestions, e.g.
[at0008::openEHR-EHR-INSTRUCTION.service_request.v1]/protocol[at0008]/items[at0141::openEHR-EHR-CLUSTER.service_request_information.v1]

But the exact syntax doesn’t matter a lot, as long as it is agreed upon.
Splitting node_id and archetype_id would probably work as well and may be the 
clearer solution, albeit maybe the one with more impact on existing 
implementations.

So, it sounds like it is a problem, and I think it is one that really needs to 
be solved generally for interoperability’s sake.
Sebastian


Von: openEHR-technical  Im Auftrag 
von Diego Boscá
Gesendet: Freitag, 19. Oktober 2018 11:45
An: For openEHR technical discussions 
Cc: Sarmad Al-Kufiash 
Betreff: Re: Unique paths for slots problem if slots are filled with same 
archetype

While I believe we have reproduced this behavior in the OPT management to be 
compatible with existing tooling, in our typical slot solving methodology 
(non-template mode) the original archetype slot node_id ends in the new object 
node_id. Information about which slot was solved in this node ended in a new 
attribute in the term definitions (we called that attribute 'DCM', but you get 
the idea). We modified the AOM model to have references to both current 
archetype and solved archetype in order to avoid node_id collisions in 
archetype definition time.


I think we have talked before about the need of splitting the archetype_node_id 
attribute into node_id / archetype_id, which I think would solve these 
problems. Another solution would be to include always the node id in the node 
id, even if you are using it to store the archetype_id, so paths would look like
[openEHR-EHR-INSTRUCTION.service_request.v1::at]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1::at0141]

Regards

El vie., 19 oct. 2018 a las 10:57, Sebastian Garde 
(mailto:sebastian.ga...@oceaninformatics.com>>)
 escribió:
Hi all,

We have encountered an interesting issue with how to construct unique paths for 
slots when there is more than one slot on the same level, and both slots are 
filled with the same archetype.
In this case, the resulting paths for both seem to be the same in OPT and thus 
in the data. (The at/id code of the slot are not part of the path for a filled 
slot.)
Likewise, you cannot apply an annotation to only one of them, because they 
share the same path.

This seems to be a general problem, but let me explain it in more detail using 
a concrete example:
The problem manifests itself for example when you start using the Service 
Request Archetype in CKM 
(https://ckm.openehr.org/ckm/#showArchetype_1013.1.614).

In the archetype’s protocol (see screenshot below), there are various slots, 
most importantly let’s look at the Requester and the Receiver Slot.
In a template (see 2nd screenshot), both slots can be filled with the same 
archetype, technically, and it also seems reasonable from a content point of 
view to use the same archetype for both slots.

The problem is that this means that the paths are no longer unique – there is 
no way to differentiate between the Requester and Receiver information anymore 
as far as we can see in the OPT, and consequently in the data.
Also, if annotations are used on a path like this, these annotations would 
automatically be applied to both Requester and Receiver.

For example, the path for BOTH the Requester and Receiver, once filled with a 
service_request_information CLUSTER archetype is:
[openEHR-EHR-INSTRUCTION.service_request.v1]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1]

Is anybody already using this archetype (or a similar one) in their systems and 
is encountering this issue? Is anybody using workarounds for this?
One way this issue could be avoided/dodged is if the archetype wraps these 
slots in additional clusters, so that the resulting path is unique even if the 
same archetype is used inside slots on the same level.
It seems perfectly reasonable to me to construct archetypes the way this one 
has been constructed, but I am not sure if the implications are clear.

Is this something the SEC needs to have a look at if this is something that 
needs to be addressed somehow…or are we simply missing something?
Maybe at0141 for Requester / at0142 for Receiver need to be included in the 
path somehow (even if it is ugly)…

Regards,
Sebastian

[cid:image002.png@01D46798.DB3D8900]
[cid:image004.jpg@01D4679A.67A3F590]


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