Uploaded image for project: 'Specification PR tracker'
  1. SPECPR-279

No unique paths for slots if different slots are filled with same archetype

    Details

    • Type: Problem Report
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects versions: None
    • Fix versions: None
    • Components: ADL 1.4
    • Labels:
      None

      Description

      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:
      [openEHR-EHR-INSTRUCTION.service_request.v1]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1]

      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.
      openEHR-EHR-CLUSTER.service_request_information-at0141.v1
      - 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?)

        Attachments

          Issue links

            Activity

              People

              • Assignee:
                thomas.beale Thomas Beale
                Reporter:
                sebastian.garde Sebastian Garde
              • Votes:
                1 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated: