So that we don’t forget, I have created https://openehr.atlassian.net/browse/SPECPR-279 for this. I am not fussed whether it is prepended or appended, I can see tiny advantages for both. The more interesting question to me is whether this is optional and only added when really needed or required. There is this edge case, but I also wonder if a reasonable query on data would be to ask for anything inside a specific slot, no matter what it is filled with (as e.g. mandated by Template A vs Template B). This does not really seem to be (generally) possible - even if there are not two identical archetypes in different slots?
Sebastian Von: openEHR-technical <openehr-technical-boun...@lists.openehr.org> Im Auftrag von Thomas Beale Gesendet: Montag, 22. Oktober 2018 19:00 An: openehr-technical@lists.openehr.org Betreff: Re: Unique paths for slots problem if slots are filled with same archetype 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
