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


-------- Original message --------
From: Thomas Beale <[email protected]>
Date: 23/10/18 9:50 pm (GMT+10:00)
To: [email protected]
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>.

- thomas


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. 😊

Regards,
Silje

_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to