I need to study this problem a bit more, but having read the posts here,
I think the solution would potentially to allow the /optional addition/
of a '::atNNNN' appended to an archetype id at a root point. This means
that all current systems and data remain valid. It is better if it is
appended rather than prepended because it means the string id always
starts with the archetype id (= the case today) and may have something
on the end, and that would only be the case for this fairly rare use
case. It would also be a fairly simple code upgrade to existing systems.
So I would agree with Diego's syntax below, but say that it is optional,
and only required when needed, which appears to be this one edge case.
If we can convince ourselves of this, this is a pretty easy change to
the relevant template tools and also ADL2.
thoughts?
- thomas
On 19/10/2018 10:44, Diego Boscá wrote:
While I believe we have reproduced this behavior in the OPT management
to be compatible with existing tooling, in our typical slot solving
methodology (non-template mode) the original archetype slot node_id
ends in the new object node_id. Information about which slot was
solved in this node ended in a new attribute in the term definitions
(we called that attribute 'DCM', but you get the idea). We modified
the AOM model to have references to both current archetype and solved
archetype in order to avoid node_id collisions in archetype definition
time.
I think we have talked before about the need of splitting the
archetype_node_id attribute into node_id / archetype_id, which I think
would solve these problems. Another solution would be to include
always the node id in the node id, even if you are using it to store
the archetype_id, so paths would look like
[openEHR-EHR-INSTRUCTION.service_request.v1::at0000]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1::at0141]
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
