Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-13 Thread Diego Boscá
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.

2018-07-13 13:37 GMT+02:00 Thomas Beale :

>
>
> On 13/07/2018 12:13, Diego Boscá wrote:
>
>> 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
>>
>
> 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
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-13 Thread Thomas Beale



On 13/07/2018 12:13, Diego Boscá wrote:
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


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


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-13 Thread Diego Boscá
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

2018-07-13 13:05 GMT+02:00 Thomas Beale :

>
>
> On 06/07/2018 18:03, Pablo Pazos wrote:
>
>> 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.
>>
>
> THis case disappears with the use of ADL2, which prevents alternatives not
> having node codes ('id-codes' in ADL2).
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-13 Thread Thomas Beale




On 06/07/2018 18:03, Pablo Pazos wrote:

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.


THis case disappears with the use of ADL2, which prevents alternatives 
not having node codes ('id-codes' in ADL2).


- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-06 Thread Pablo Pazos
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.

On Fri, Jul 6, 2018 at 6:07 AM, Dileep V S  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
>
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter 

http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-06 Thread Dileep V S
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  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  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.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  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. 

Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-06 Thread Ian McNicoll
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  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  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 

Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-06 Thread Dileep V S
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.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  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


RE: Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-06 Thread Bakke, Silje Ljosland
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 
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

[https://docs.google.com/uc?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
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 
mailto: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

[https://drive.google.com/uc?id=0BxQc41y9yqs6bkE5a1JQQVBjZG8]

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


Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-06 Thread Ian McNicoll
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  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


Unique paths for nodes in multiple instances of one archetype in the same OPT

2018-07-06 Thread Dileep V S
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