Thanks Ian, I will also test with Ethercis and update
regards Dileep V S *Founder* HealtheLife Ventures LLP m: +91 9632888113 a: 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: healthelife.in e: dil...@healthelife.in On Fri, Jul 6, 2018 at 8:12 PM, Ian McNicoll <i...@freshehr.com> wrote: > 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: i...@freshehr.com > twitter: @ianmcnicoll > > > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > 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 <dil...@healthelife.in> 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: dil...@healthelife.in >> >> On Fri, Jul 6, 2018 at 4:02 PM, Bakke, Silje Ljosland < >> silje.ljosland.ba...@nasjonalikt.no> 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:openehr-technical- >>> boun...@lists.openehr.org] *On Behalf Of *Ian McNicoll >>> *Sent:* Friday, July 06, 2018 11:16 AM >>> *To:* For openEHR technical discussions <openehr-technical@lists. >>> openehr.org> >>> *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: i...@freshehr.com >>> twitter: @ianmcnicoll >>> >>> >>> >>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org >>> >>> 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 <dil...@healthelife.in> 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: dil...@healthelife.in >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical@lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr- >>> technical_lists.openehr.org >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical@lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr- >>> technical_lists.openehr.org >>> >>> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr- >> technical_lists.openehr.org >> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
