There is an 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:
It seems perfectly reasonable to construct archetypes the way this one has been constructed, but I am not sure if the implications are clear.
Suggested Workrounds so far:
Wrap 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.
Renaming the concepts of the slot archetypes in the template
Specialise the slot archetypes into two different ones using the at-code, e.g.
Specialise the slot archetypes into two different ones using reusable specialisation, e.g.
openEHR-EHR-CLUSTER.service_request_information-requester.v1 and openEHR-EHR-CLUSTER.service_request_information-receiver.v1, even if they are nearly identical. Could also enforce these slots in the main archetype.
Suggested Solutions so far:
Probably at0141 for Requester / at0142 for Receiver need to be included in the path somehow, exact syntax to be discussed.
Optional addition of a '::atNNNN' appended to an archetype id at a root point, only added when really needed (TB)
Always append ::atNNNN to the path (DB)
Formally split the archetype_node_id attribute into node_id / archetype_id (DB)
use atNNNN, archetype-id in the path when required (HF)
use atNNNN::archetype in the path when required (SG)
So, it's manly a question of a) syntax and b) whether this is optional or always required. (I wonder if a reasonable query on data would be to ask for anything inside a specific slot, no matter what it is filled with. This does not really seem to be generally possible - even if there are not two identical archetypes in different slots?)
I had not thought about how this could be done in the XSD level but that's smart. We finished the conversation yesterday by saying that implementers should look in their systems and assess the cost / risks of modifying what goes in the archetype_id field in their DBs. But maybe the way is to add a new DB field, and then use an XML attribute in the XML, as you have done. I'll get people to look at this suggestion.
@Tom which msg you're responding to? I cannot see any mention of XSD/XML in the above messages?
see Heath's comment above.
Heath's suggestion backed by the ADL2 solution sounds to me the way to go - I support this.
Funny though, that when I suggested yesterday a quite similar solution (not being aware of ADL2 info), it was considered to be 'nuclear', but I had actually the same thing in mind with archetype_details, regarding query aspects and path aspects...
It is anyway something for release 1.1.0 (or 1.2.0).
I don't know if changes to the archetype_details field in everyone's implementations are nuclear or not, but they could be dangerous - I'd certainly recommend that everyone do a careful impact assessment of storing strings like id0.2, openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-1.v1 instead of just openEHR-EHR-EVALUATION.t_clinical_info_ds_sf-1.v1, which is the current scheme. But people might want to store the 'id0.2' (or it would be some 'at-code' in current systems) in another DB field and then generate the XML that Heath suggests on output through REST (also a JSON equivalent would be easy), that could work.
Again, it's up to you implementers to determine the impact - I am not close to any code bases these days.