Unique paths for slots problem if slots are filled with same archetype

Diego Boscá yampeku at gmail.com
Fri Oct 19 07:21:56 EDT 2018


Discussing this with David we have another solution to this problem: one
thing you could do and would completely work without breaking anything is
to specify some kind of empty specializations of the include archetype, and
giving as the name of the specialization the node_id code. something like
this

[openEHR-EHR-INSTRUCTION.service_request-at0000.v1]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information-at0141.v1]

This won't break current systems and will probably solve the original
problem

Regards

El vie., 19 oct. 2018 a las 13:10, Ian McNicoll (<ian at freshehr.com>)
escribió:

> Hi Sebastian,
>
> This is 'known issue' but not one that we had really thought too carefully
> about. We 'solve' it right now by renaming the slotted in archetype root
> node at template level but others have already pointed out that this is
> less than ideal.
>
> Adding an intermediate cluster would solve things but feels clunky.
>
> I understand Thomas had some ideas about this re ADL2 but I like the ideas
> from Heath / Diego also.
>
> It is probably less of a practical issue than might seem the case as we
> tend not to have too many situations where the meaning needs to 'inherit'
> from the Slot name, and where those adjacent slot names differ for
> identical slot fills but agree it needs fixed.
>
> Ian
>
>
> @Diego - thanks for that input
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: ian at freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnicoll at openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Fri, 19 Oct 2018 at 10:44, Diego Boscá <yampeku at gmail.com> wrote:
>
>> While I believe we have reproduced this behavior in the OPT management to
>> be compatible with existing tooling, in our typical slot solving
>> methodology (non-template mode) the original archetype slot node_id ends in
>> the new object node_id. Information about which slot was solved in this
>> node ended in a new attribute in the term definitions (we called that
>> attribute 'DCM', but you get the idea). We modified the AOM model to have
>> references to both current archetype and solved archetype in order to avoid
>> node_id collisions in archetype definition time.
>>
>>
>> I think we have talked before about the need of splitting the
>> archetype_node_id attribute into node_id / archetype_id, which I think
>> would solve these problems. Another solution would be to include always the
>> node id in the node id, even if you are using it to store the archetype_id,
>> so paths would look like
>>
>> [openEHR-EHR-INSTRUCTION.service_request.v1::at0000]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1::at0141]
>>
>> Regards
>>
>> El vie., 19 oct. 2018 a las 10:57, Sebastian Garde (<
>> sebastian.garde at oceaninformatics.com>) escribió:
>>
>>> Hi all,
>>>
>>>
>>>
>>> We have encountered an interesting issue with how to construct unique
>>> paths for slots when there is more than one slot on the same level, and
>>> both slots are filled with the same archetype.
>>>
>>> In this case, the resulting paths for both seem to be the same in OPT
>>> and thus in the data. (The at/id code of the slot are not part of the path
>>> for a filled slot.)
>>>
>>> Likewise, you cannot apply an annotation to only one of them, because
>>> they share the same path.
>>>
>>>
>>>
>>> This seems to be a general problem, but let me explain it in more detail
>>> using a concrete example:
>>>
>>> The problem manifests itself for example when you start using the
>>> Service Request Archetype in CKM (
>>> https://ckm.openehr.org/ckm/#showArchetype_1013.1.614).
>>>
>>>
>>>
>>> In the archetype’s protocol (see screenshot below), there are various
>>> slots, most importantly let’s look at the *Requester* and the *Receiver*
>>> Slot.
>>>
>>> In a template (see 2nd screenshot), both slots can be filled with the
>>> same archetype, technically, and it also seems reasonable from a content
>>> point of view to use the same archetype for both slots.
>>>
>>>
>>>
>>> The problem is that this means that the paths are no longer unique –
>>> there is no way to differentiate between the Requester and Receiver
>>> information anymore as far as we can see in the OPT, and consequently in
>>> the data.
>>>
>>> Also, if annotations are used on a path like this, these annotations
>>> would automatically be applied to both Requester and Receiver.
>>>
>>>
>>>
>>> For example, the path for BOTH the Requester and Receiver, once filled
>>> with a service_request_information CLUSTER archetype is:
>>>
>>>
>>> [openEHR-EHR-INSTRUCTION.service_request.v1]/protocol[at0008]/items[openEHR-EHR-CLUSTER.service_request_information.v1]
>>>
>>>
>>>
>>> Is anybody already using this archetype (or a similar one) in their
>>> systems and is encountering this issue? Is anybody using workarounds for
>>> this?
>>>
>>> One way this issue could be avoided/dodged is if the archetype wraps
>>> these slots in additional clusters, so that the resulting path is unique
>>> even if the same archetype is used inside slots on the same level.
>>>
>>> It seems perfectly reasonable to me to construct archetypes the way this
>>> one has been constructed, but I am not sure if the implications are clear.
>>>
>>>
>>>
>>> Is this something the SEC needs to have a look at if this is something
>>> that needs to be addressed somehow…or are we simply missing something?
>>>
>>> Maybe at0141 for Requester / at0142 for Receiver need to be included in
>>> the path somehow (even if it is ugly)…
>>>
>>>
>>>
>>> Regards,
>>>
>>> Sebastian
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> openEHR-technical mailing list
>>> openEHR-technical at lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>
>>
>> --
>>
>> [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ>
>>
>> [image: Twitter]  <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn]
>> <https://htmlsig.com/t/000001C4DPJG> [image: Maps]
>> <https://htmlsig.com/t/000001BZTWS7>
>>
>> Diego Boscá Tomás / Senior developer
>> diebosto at veratech.es
>> yampeku at gmail.com
>>
>> VeraTech for Health SL
>> +34 654604676 <+34%20654604676>
>> www.veratech.es
>>
>> La información contenida en este mensaje y/o archivo(s) adjunto(s),
>> enviada desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
>> destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
>> recordamos que sus datos han sido incorporados en el sistema de tratamiento
>> de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
>> exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
>> rectificación, limitación de tratamiento, supresión, portabilidad y
>> oposición/revocación, en los términos que establece la normativa vigente en
>> materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
>> 1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
>> dpo at veratech.es
>>
>> Si usted lee este mensaje y no es el destinatario señalado, el empleado o
>> el agente responsable de entregar el mensaje al destinatario, o ha recibido
>> esta comunicación por error, le informamos que está totalmente prohibida, y
>> puede ser ilegal, cualquier divulgación, distribución o reproducción de
>> esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
>> devuelva el mensaje original a la dirección arriba mencionada. Gracias
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ>

[image: Twitter]  <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/000001C4DPJG> [image: Maps]
<https://htmlsig.com/t/000001BZTWS7>

Diego Boscá Tomás / Senior developer
diebosto at veratech.es
yampeku at gmail.com

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

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
dpo at veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20181019/6be0fc21/attachment-0001.html>


More information about the openEHR-technical mailing list