Following Koray’s finding of this problem, I have created the issue http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/233
This problem is about handling occurrences on ‘use_nodes’ i.e. ARCHETYPE_INTERNAL_REF instances; see for example the use_node lines in the Apgar archetype - http://svn.openehr.org/knowledge/archetypes/dev/adl/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.apgar.v1.html
I have cc:d Dipak, since one of the choices would create a small change in the Archetype Object Model, which is used by CEN EN13606, and would require an update.
I have partly implemented the change. There is a choice:
if no occurrences is found on a use_node (i.e. ARCHETYPE_INTERNAL_REF node) then either:
- the occurrences of the target node should be used, and a new flag needs to be added to the ARCHETYPE_INTERNAL_REF to indicate that this will be the case (since ARCHETYPE_INTERNAL_REF has its own local occurrences - unavoidable since it inherits from C_OBJECT)
- or…the occurrences of the target node should be used (i..e same semantics), but the target’s occurrences object is copied into the source node ARCHETYPE_INTERNAL_REF object.
In the second case, no flag is needed in ARCHETYPE_INTERNAL_REF, since the AOM semantics will be that local occurrences on all C_OBJECT types (including ARCHETYPE_INTERNAL_REF) will always be used (which will be correct, due to the copying). This case is a bit harder to implement in parsing, since it means that a special pass is needed to go an get the occurrences off target nodes of use_node refs, and copy them into the use_node source node.
In the first case, parsing is easier, and I don’t think it makes any difference at runtime. However, a new flag (called something like use_target_occurrences) needs to be added to ARCHETYPE_INTERNAL_REF.
I would prefer to add the flag. Thoughts from others?
- thomas