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
<https://openehr.atlassian.net/wiki/spaces/spec/pages/60358659/RM+additions+for+workflow+process>)
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
