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

Bakke, Silje Ljosland silje.ljosland.bakke at nasjonalikt.no
Tue Oct 23 06:29:25 EDT 2018


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

From: openEHR-technical <openehr-technical-bounces at lists.openehr.org> On Behalf Of Thomas Beale
Sent: Tuesday, October 23, 2018 11:21 AM
To: openehr-technical at lists.openehr.org
Subject: Re: AW: Unique paths for slots problem if slots are filled with same archetype




On 23/10/2018 10:09, Sebastian Garde wrote:
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?


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20181023/09db2bd4/attachment.html>


More information about the openEHR-technical mailing list