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