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 Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: [email protected] twitter: @ianmcnicoll Co-Chair, openEHR Foundation [email protected] Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On Fri, 6 Jul 2018 at 14:55, Dileep V S <[email protected]> wrote: > 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 > > Dileep V S > *Founder* > HealtheLife Ventures LLP > m: +91 9632888113 > a: 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100 > w: healthelife.in e: [email protected] > > On Fri, Jul 6, 2018 at 4:02 PM, Bakke, Silje Ljosland < > [email protected]> wrote: > >> As a side note, the “Service request” archetype has just (yesterday, in >> fact) been published as INSTRUCTION.service_request.v1. >> >> Regards, >> *Silje* >> >> >> >> *From:* openEHR-technical [mailto: >> [email protected]] *On Behalf Of *Ian McNicoll >> *Sent:* Friday, July 06, 2018 11:16 AM >> *To:* For openEHR technical discussions < >> [email protected]> >> *Subject:* Re: Unique paths for nodes in multiple instances of one >> archetype in the same OPT >> >> >> >> 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 >> >> Note that the AQL described was not working correctly on Ethercis in the >> past but that issue may have been fixed. >> >> >> >> Ian >> >> >> Dr Ian McNicoll >> mobile +44 (0)775 209 7859 >> office +44 (0)1536 414994 >> skype: ianmcnicoll >> email: [email protected] >> twitter: @ianmcnicoll >> >> >> >> Co-Chair, openEHR Foundation [email protected] >> >> Director, freshEHR Clinical Informatics Ltd. >> Director, HANDIHealth CIC >> Hon. Senior Research Associate, CHIME, UCL >> >> >> >> >> >> On Fri, 6 Jul 2018 at 10:07, Dileep V S <[email protected]> wrote: >> >> 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 >> >> >> >> Dileep V S >> >> *Founder* >> >> *HealtheLife Ventures LLP* >> >> m: >> >> +91 9632888113 >> >> a: >> >> 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100 >> >> w: >> >> healthelife.in e: [email protected] >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> > _______________________________________________ > openEHR-technical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
