I am observing a strange behavior in the template designer and whated to check if this is the expected behavior and if not how to manage it.
In any template, when ever I rename any archetypes, their occurrence gets set to [0..1] automatically (single occurrence). The options for selecting multiple occurrences is no more available.
Have anybody else noticed this problem? Is there any way to work around this as some of these archetypes need to be multiple occurrences
Yes, this is expected. The behaviour was first noticed about 10 years ago, and initially it was reported as a bug. After some thought we realised that it’s the correct behaviour. I found it incredibly annoying too!
My memory of the exact reasoning is poor, after all of these years; but I think it’s something like this:
Initially, the name of the archetype node is unconstrained. As a consequence, any name would be valid for this node. Therefore, there’s an unlimited number of unique paths to the data that could be stored at this node’s path: for example, at1234[name = “a”], at1234[name = “b”], at1234[name = “c”], etc.
In the template, when you constrain the archetype node to a single specific name, there is only one possible path to the the node: for example, at1234[name=“whatever name you’ve constrained it to”]. There’s only one possible unique path to this. Therefore, the maximum occurrences possible is 1.
Essentially, this arises because there has to be one unique path to each node in the data. This is important so that each data node can be identified unambiguously within the EHR.
There is a workaround, however. (But again, my memory may be inaccurate, so please forgive me if this isn’t quite right or complete.) To allow multiple occurrences, you need to clone the node. Then you can rename the clone. Although the renamed clone will be single-occurrence, this will retain the original node as multiple occurrences. Or at least I think this is how it works — it’s been quite a few years!
I have an even vaguer recollection that ADL 2.0 may have resolved this in a more satisfactory way. Perhaps Thomas or someone can elucidate.
Thanks for your reply. However I am not sure I fully understand the logic of this.
OpenEHR has a way to represent multi occurrence nodes (by appending 0, 1 etc to the path) such that the paths will remain unique. This should work even when the mode is constrained with a name as well. May be I am missing something here.
I am not sure what you mean by cloning the node? Can this be done in Template designer? if yes how
In your particular example I would leave the archetype unchanged, but instead rename the Issue name to say ‘complaint description’. That way you can keep the multiple recurrence of the archetype, but have your preferred name in the data as the left hand side of the name/value pair. You may want to do the same with the Symptom/sign cluster too to allow multiple occurrences for that - unless you want to deliberately constrain it to a single occurrence.
I quite often use sections as a workaround, but that only works if the archetype you want to rename is an entry archetype - it wouldn’t work so well for clusters (unless you can safely rename the ‘container’ archetype e.g. Story/History or Physical examination finding).
So if I need multiple ‘named’ problems I add an ‘Adhoc’ section archetype for each, rename the ‘Adhoc’ with the appropriate problem name and leave the Problem/diagnosis archetype name as it is. It does mean that the section carries a degree of semantic meaning (which it isn’t really supposed to do), but it does help with - as Peter quite rightly says - very annoying problem.
Incidentally, the new web based ADL Designer tool developed by Marand doesn’t have this problem anymore. As far as I know it is very close to being released now.
It’s probably best to defer the exact answer to others, but my understanding is that the ‘unique path rule’ was interpreted too tightly in Template Designer, rather than this being a strict limitation in ADL 1.4. Certainly there is no need to migrate to ADL 2.0 with ADL Designer, it handles ADL 1.4 perfectly well.
But as I said - other people may want to pitch in and provide a more detailed explanation.
Okay, interesting! It would have made things easier for us 5 or 10 years ago to have had a looser interpretation of the ‘unique path rule’. Perhaps it was a case of erring on the side of caution, since it’s always easier to relax a rule that turns out to have been too strict rather than retrospectively tighten a rule that was too lax.
This would have implications for operational templates, as well as for existing downstream software that consumes the OPTs. Would OPTs generated by the new ADL Designer tool fail validation by existing software?
I’m looking forward to a more detailed explanation, if someone knows.
It’s AOM2.x inside, but deals with ADL 1.4 and .oet files externally. It’s now more or less BMM-driven I think. But also they made some compromises to make sure all the ADL 1.4 and .oet stuff works the way it did.
Archie is completely ADL/AOM2 of course. It may be that in the future they could use the Archie core, which I suspect is cleaner code, for the core of ADL-designer, but for now the main priority for that tool is to be a good replacement for the Archetype Editor + Template Designer, not to be mainly an ADL2 tool.