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 mailto:gf...@luna.nl>>:
Either it is solve using standardised
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
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
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
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
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
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
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
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 '::at' 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
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
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
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
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
13 matches
Mail list logo
