# Unique paths for nodes in multiple instances of one archetype in the same OPT **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2018-07-06 09:07 UTC **Views:** 1 **Replies:** 10 **URL:** https://discourse.openehr.org/t/unique-paths-for-nodes-in-multiple-instances-of-one-archetype-in-the-same-opt/15526 --- ## Post #1 by @system Hi, We are trying to create a service request template using the following structure [openEHR-EHR-COMPOSITION.request.v1] [openEHR-EHR-INSTRUCTION.request.v0] [openEHR-EHR-CLUSTER.organisation.v0] [openEHR-EHR-CLUSTER.person_name.v1] [openEHR-EHR-CLUSTER.organisation.v0] [openEHR-EHR-CLUSTER.person_name.v1] The first set of organization & person name archetypes are for the requester and the second set for the receiver. However in the template editor, the paths for the nodes of both these instances are the same(Eg. Orgaization name, Identifier, unstructured name etc). This, we feel, will create problems in the AQL as we cannot uniquely identify the nodes. How do we solve this problem. Is there any better way to model the template I m attaching the template file set for reference Regards [details="(attachments)"] [EHRN Service request.zip|attachment](upload://gvokEaX9ZMNoyofcJpVQSgPG5ox.zip) (17.1 KB) [/details] --- ## Post #2 by @system Hi Dileep, The usual approach I take here is to rename the clustered archetype to reflect local use, which works out as [openEHR-EHR-COMPOSITION.request.v1] [openEHR-EHR-INSTRUCTION.request.v0] [openEHR-EHR-CLUSTER.organisation.v0, 'Requesting organisation'] [openEHR-EHR-CLUSTER.person_name.v1] [openEHR-EHR-CLUSTER.organisation.v0, ' Receiving organisation'] [openEHR-EHR-CLUSTER.person_name.v1] and is queryable on AQL. see [https://github.com/RippleOSI/Ripple-openEHR/tree/master/docs/bindings/Current%20Ripple%20Headings/Referrals](https://github.com/RippleOSI/Ripple-openEHR/tree/master/docs/bindings/Current%20Ripple%20Headings/Referrals) Note that the AQL described was not working correctly on Ethercis in the past but that issue may have been fixed. Ian --- ## Post #3 by @siljelb As a side note, the “Service request” archetype has just (yesterday, in fact) been published as INSTRUCTION.service_request.v1. Regards, **Silje** --- ## Post #4 by @system Thanks Ian/Silje, I will take a look at what Ian has suggested. But if Ethercis dos not support it, I will be back to square one. In that case would specializing the person_name and organisation archetypes for requester and receiver make sense? On further thought, I feel that what Ian has suggested is a work around and not part of the standard specs. Has there been any thoughts on a more elegant solution to be included in the standards? A more robust solution may be to include the slot id in the path and also in AQL so that same archetype in 2 different slots will have different paths. But then again this does not cover the situation where one slot is required to contain multiple instances of the same archetype. Silje, Thanks for the pointer to the new version of service request archetype. Will use that regards --- ## Post #5 by @system Hi Dileep, I'll check the AQL against Ethercis ASAP - Chrisitian has done a lot of work in this area recently. The issue of how best to distinguish different nodes on the same path is an old and long conversation. There are quite a few different requirements/ use-cases. What I suggested is perfectly legitimate, the AQL for each path will be different as you can use a qualified name predicate in the AQL but I agree it would be helpful to be able to carry the slot meaning (optionally) in the patient data not just in the design-time definition. I know Thomas has talked about this in the past. It would need a somewhat significant change to the RM, I think. Ian --- ## Post #6 by @system Thanks Ian, I will also test with Ethercis and update regards --- ## Post #7 by @system Hi Dileep, In the EHRServer we use the template path as an absolute path for each node in the template, that allows to identify each node in the OPT even if different nodes hang from the same archetype root (have the same archetype path). This allows querying for the right node. Also there is another case when nodes with the same path but different data type are in a composition instance. We use the path + type to identify those node alternatives. Best, Pablo. --- ## Post #8 by @system THis case disappears with the use of ADL2, which prevents alternatives not having node codes \('id\-codes' in ADL2\)\. \- thomas --- ## Post #9 by @yampeku Technically in ADL1.4 it is completely legal that alternatives have their own node codes. Other thing is that OPT or current software supports it --- ## Post #10 by @system it is legal, but not always implemented\. Your group \(UPV\) did the right thing with LinkEHR early on, and I should have fixed it in ADL 1\.4\.\.\. the beauty of hindsight\.\.\. \- thomas --- ## Post #11 by @yampeku We had to wrestle with data transformation in our early days, which made us learn things in the hard way :) As you said ADL2 addresses most of these issues so I think it is definitely the way to go. --- **Canonical:** https://discourse.openehr.org/t/unique-paths-for-nodes-in-multiple-instances-of-one-archetype-in-the-same-opt/15526 **Original content:** https://discourse.openehr.org/t/unique-paths-for-nodes-in-multiple-instances-of-one-archetype-in-the-same-opt/15526