Hi Ian,

Yes, it is not many cases where this is really required, but in the Service 
Request archetype, it is fairly likely to happen and anybody creating a 
template without your, Diego’s, David’s, Heath’s etc. cutting edge top-level 
expert knowledge around this will quite likely run into a trap…so, yes, it 
should be fixed somehow.

The various workarounds (including David’s/Diego’s latest idea) ‘work’ and have 
slightly different advantages but all dodge the issue (of course).
Extra Clusters in the core archetype are clunky but avoid the need for doing 
anything in the template; Specialising the CLUSTER without changes for a new 
archetype id is probably more elegant and you can use it with the current 
published archetype...but on the other hand you need to know this and not 
forget 😊. Renaming the root node of the slotted root node as you say is 
somewhat similar, easier, but mono-lingual.


Von: openEHR-technical <openehr-technical-boun...@lists.openehr.org> Im Auftrag 
von Ian McNicoll
Gesendet: Freitag, 19. Oktober 2018 13:09
An: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Cc: Sarmad Al-Kufiash <sarmad.alkufi...@oceanhealthsystems.com>
Betreff: Re: Unique paths for slots problem if slots are filled with same 

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 

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.


@Diego - thanks for that input
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation 
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On Fri, 19 Oct 2018 at 10:44, Diego Boscá 
<yamp...@gmail.com<mailto:yamp...@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


El vie., 19 oct. 2018 a las 10:57, Sebastian Garde 
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 
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 

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:

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)…


openEHR-technical mailing list


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

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

Diego Boscá Tomás / Senior developer

VeraTech for Health SL
+34 654604676<tel:+34%20654604676>

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 d...@veratech.es<mailto:d...@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 mailing list

Reply via email to