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

Technical (archive)
1

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

2

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

(attachments)

image002.png
image004.jpg
image002.png

3

Thanks Diego,

Yes, I think Heath has suggested a path similar to your second suggestion, just with a comma as separator and in a different order:

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

I would probably prefer the mixture of your two suggestions, e.g.

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

But the exact syntax doesn’t matter a lot, as long as it is agreed upon.

Splitting node_id and archetype_id would probably work as well and may be the clearer solution, albeit maybe the one with more impact on existing implementations.

So, it sounds like it is a problem, and I think it is one that really needs to be solved generally for interoperability’s sake.

Sebastian

4

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@freshehr.com
twitter: @ianmcnicoll

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

5

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

6

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 :blush:. Renaming the root node of the slotted root node as you say is somewhat similar, easier, but mono-lingual.

Cheers,

Sebastian

7

I need to study this problem a bit more, but having read the posts here, I think the solution would potentially to allow the optional addition of a ‘::atNNNN’ appended to an archetype id at a root point. This means that all current systems and data remain valid. It is better if it is appended rather than prepended because it means the string id always starts with the archetype id (= the case today) and may have something on the end, and that would only be the case for this fairly rare use case. It would also be a fairly simple code upgrade to existing systems.

So I would agree with Diego’s syntax below, but say that it is optional, and only required when needed, which appears to be this one edge case. If we can convince ourselves of this, this is a pretty easy change to the relevant template tools and also ADL2.

thoughts?

  • thomas
8

So that we don’t forget, I have created https://openehr.atlassian.net/browse/SPECPR-279 for this.

I am not fussed whether it is prepended or appended, I can see tiny advantages for both.

The more interesting question to me is whether this is optional and only added when really needed or required.

There is this edge case, but I also wonder if a reasonable query on data would be to ask for anything inside a specific slot, no matter what it is filled with (as e.g. mandated by Template A vs Template B). This does not really seem to be (generally) possible - even if there are not two identical archetypes in different slots?

Sebastian

9

that would also require adding the slot node id, but I wonder how useful this particular query really could be… we never thought of it in 10 years of using AQL AFAIK… - thomas

10

Hi all! I hope the SEC will discuss and hopefully solve this issue in the upcoming meeting in Oslo. This is fairly serious from a modelling POV, as there are some archetypes that are based on the (in my opinion fair) assumption that it’s possible to tell two instances of the same CLUSTER in two parallel SLOTs apart. An example is “Communication capability” https://ckm.openehr.org/ckm/#showArchetype_1013.1.3155. We’d prefer not having to change the modelling to circumvent the technical issue, if possible. :blush:

11

I’m becoming convinced that we need to make a technical change to allow the slot id be stored in the data, as suggested on the discussion thread already.

So my suggestion for modellers is: assume it will get solved, and do your modelling in the natural / preferred way (i.e. don’t introduce hacks like extra CLUSTERs), and we’ll work out an ADL-level solution.

It would help if you can add any detailed info to the description of the PR that Sebastian just created.

  • thomas
12

Hi Tom
If we are using the same archetype for the sender info and receiver data then I can see only two sensible options from a design perspective:

  1. There are two slots…named receiver and sender.
  2. the designer did not know what might be in here so the person filling the slot in the template or the data named them differently.

In many situations it will be critical to differentiated sender and receiver unambiguously so a cluster could be a sensible solution. Otherwise transfering the name of a slot to the name of the archetype in the slot?

Cheers Sam

13

This could work in some cases, but if I recall correctly that name is language dependent (i.e. Only one of the archetype translations is used) , which would make this difficult to implement in archetypes that have several languages as you wouldn’t be able to easily tell what label is really there

14

I’ve just been thinking more about this problem. I agree we need to fix it, and it seems fairly likely adjusted rules for forming paths and storing archetype markers in data will be needed.

But… the archetype structure mentioned is a hack for getting around the lack of order-tracking attributes in the RM. We’ve had a look at this before (e.g. here) but I would suggest we need to think soon about additions to the ENTRY class or package to properly model requester and receiver meta-data.

  • thomas
15

Either it is solve using standardised basic Archetypes or via the RM.
The RM route is the preferred one.

When thinking about it, then…
Data in any Patient Record is either:

  • de novo data stored at a session
  • re-used pre-existing data (Reported data, used data in processes, etc.) This data is pre-existing data that is re-used. When querying for a concept it must be possible to restrict it to new data and/or re-used data.
    Again this can be solved via standardised basic Archetypes or the RM.
    The RM is the best option.

Gerard Freriks
+31 620347088
gfrer@luna.nl

Kattensingel 20
2801 CA Gouda
the Netherlands

16

Hi all!

The issue (and some possible solutions/workarounds) is now described at https://openehr.atlassian.net/browse/SPECPR-279

Feel free to add information, comments etc there.

//Erik Sundvall

3 nov. 2018 kl. 15:12 skrev GF <gfrer@luna.nl>: