Reviewing the ACTION.instruction_details<INSTRUCTION_DETAILS> structure, found that INSTRUCTION_DETAILS.instruction_id<LOCATABLE_REF> is not really an id of an INSTRUCTION instance, but a selector for many INSTRUCTIONs that can happen at a certain path in a COMPOSITION.
Case Archetype: COMPOSITION has 1..* INSTRUCTION with same nodeId (multiple occurrences of the same INSTRUCTION in a COMPO).
id: reference to the VERSION which VERSION.data (COMPOSITION), contains the INSTRUCTION that needs to be referenced from INSTRUCTION_DETAILS
path: path to the INSTRUCTION
The problem is that the path is not an identifier of an INSTRUCTION instance, it is a selector and will match all the INSTRUCTION occurrences in the COMPOSITION.
The solution is to use the INSTRUCTION.uid instead of the LOCATABLE_REF on INSTRUCTION_DETAILS, like there is an INSTRUCTION_DETAILS.activity_id to reference the ACTIVITY instance.
I guess activity_id has also that problem of being more a selector than an identifier since it's description on the specs:
Identifier of Activity within Instruction, in the form of its archetype path
And looking at the openEHR XSD, INSTRUCTION_DETAILS.activity_id is atNode (nodeId format).
So in 1.0.2 I'm not sure how a specific INSTRUCTION/ACTIVITY instance can be referenced from INSTRUCTION_DETAILS, because the reference is not to an instance. Maybe I'm missing something here...
Did anyone checked this issue?
I'm reviewing the latest specs (http://openehr.org/releases/RM/latest/docs/ehr/ehr.html#_instruction_details_class) and it seems there are no changes.
Maybe I'm missing something here, but if not, IMO this is a major issue.
1. Now INSTRUCTION_DETAILS.instruction_id and INSTRUCTION_DETAILS.activity_id are paths.
2. On the same path of the same VERSION instance, two or more items of the same class can be found (e.g. COMPOSITION.content can have two instances of an INSTRUCTION archetyped with the same archetype).
3. INSTRUCTION_DETAILS should clearly have a reference to a specific instance of an ACTIVITY.
4. Why not have a INSTRUCTION_DETAILS.activity_uid: UID?
I think implementers do is actually adding an extra field to reference the ACTIVITY, or maybe using instance paths with indexes, (that are not valid archetype paths like: /instruction[at0000]/activities[at0001]). If this is the case, I think it is better to provide a solution in the specs instead of doing custom solutions that might break interoperability.
How do implementer deal with this?
Erik: identify version + item number is safe
TB: old approach 'sibling_id'
Seref: use system implem profiles that establish sets of rules that can be adopted to guarantee that e.g. Locatables can have reliable runtime paths constructed to them, e.g to do so, you have to always populate Locatable.uid.
Could just require Locatable.uid be populated for targets of path locators in RM.
1. Double checked LOCATALBE_REF does have a uid: UID_BASED_ID, so INSTRUCTION_DETAILS.instruction_id: LOCATABLE_REF is capable of identifying an INSTRUCTION instance.
Not sure why I said that UID was for the VERSION. Please disregard the first part.
2. The problem persists considering that we need to identify a specific ACTIVITY inside the INSTRUCTION instance, and that is actually referenced by a path from INSTRUCTION_DETAILS.activity_id: String "Identifier of Activity within Instruction, in the form of its archetype path."
With a path only we can't identify a unique ACTIVITY inside a given INSTRUCTION instance. I think the description including "path" leads to wrong implementations, since when we mention "path" that should be a valid archetype path, or we need to mention that we can have different kinds of paths somewhere on the specs, so implementers are aware they need to implement them.
3. Orthogonal considerations: not sure why INSTRUCTION_DETAILS.instruction_id needs to be LOCATABLE_REF instead of UID_BASED_ID directly, IMO the LOCATABLE_REF.path field is not needed for instruction_id.
Similar goes to INSTRUCTION_DETAILS.activity_id, why not use UID_BASED_ID instead of String.
That will simplify things a lot, since LOCATABLE.uid is UID_BASED_ID.
4. Can you clarify the possible solutions a little bit?
Not sure what "item number", "sibling_id" or a "reliable runtime path" is.
Maybe the latest is related with my comment of clarifying which kinds of paths we can have in a system, what's the syntax, meaning, use, etc.