AW: Unique paths for slots problem if slots are filled with same archetype
sam.heard at oceaninformatics.com
Tue Oct 23 09:24:37 EDT 2018
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?
-------- Original message --------
From: Thomas Beale <thomas.beale at openehr.org>
Date: 23/10/18 9:50 pm (GMT+10:00)
To: openehr-technical at lists.openehr.org
Subject: Re: AW: Unique paths for slots problem if slots are filled with same archetype
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<https://openehr.atlassian.net/browse/SPECPR-279>.
On 23/10/2018 11:29, Bakke, Silje Ljosland wrote:
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. 😊
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-technical