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

Sebastian Garde sebastian.garde at oceaninformatics.com
Fri Oct 19 04:56:42 EDT 2018

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:

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


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20181019/19464442/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 41477 bytes
Desc: image002.png
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20181019/19464442/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 73143 bytes
Desc: image004.jpg
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20181019/19464442/attachment-0001.jpg>

More information about the openEHR-technical mailing list