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 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
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.
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.
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...
