Simplify modelling of 'CodedWithExtensions' CWE pattern of DV_CODED_TEXT by addition of an 'unbounded' qualifier to defining_code constraint
Description
Activity
Sebastian Garde March 6, 2020 at 10:04 AMEdited
For reference, also see the related discussion at https://openehr.atlassian.net/wiki/spaces/ADL/pages/386007225/Local+Value-set+Replacement
An important use case I would like to add here is where a DV_TEXT is modelled without restrictions in a - say internationally governed - archetype and then specialised/templated for local use to “use codes x,y,z from terminology A where possible, but otherwise revert to other codes or freetext if you really have to”.
From my point of view, best candidate solutions for this are:
In 1.4: adding a C_CODE_PHRASE.code_list_open flag akin to the C_STRING.list_open would do the trick as far as I can see.
For 2.0, I think either a “required” flag on C_TERMINOLOGY_CODE or a usage recommendation: required | preferred | example as discussed in https://openehr.atlassian.net/wiki/spaces/ADL/pages/386007225/Local+Value-set+Replacement is a reasonable approach. This is similar to what FHIR is doing with their Binding Strength (required,extensible,preferred,example): see https://www.hl7.org/fhir/terminologies.html#strength
Thomas Beale May 12, 2015 at 8:52 AM
That's an ADL 2 change. The AOM 2 model is more systematic, and we've tried to remove as many ad hoc flags and special case constraints as possible.
Heath Frankel May 11, 2015 at 11:27 PM
Are you saying that the list_open attribute has been removed from the C_STRING class? When?
Thomas Beale May 11, 2015 at 10:48 AM
The C_STRING flag has now been replaced with a proper model that allows Regexes, which clearly can say anything. See http://www.openehr.org/releases/trunk/UML/#Diagrams___18_1_83e026d_1428951213353_780349_6504 .
So there is no special 'or anything else' flag on Strings now.
The problem with this idea is that it means that the constraint is no longer really a constraint, just a suggestion or preference. It means that implementations have to treat it like it isn't there, or at best, provide some suggestions on the screen but allow anything. For validation, it's the same as no constraint. I am not sure why we would want to do this in ADL.
Heath Frankel May 10, 2015 at 11:19 PM
From my understanding of Ian's requirement it is simply an open-list attribute on C-CODE-PHRASE as per C-STRING so that additional codes can be used other than those specified in the archetype.
I think it is now pretty clear that it would be helpful to have the
equivalent of a CNE/CWE attribute applied to a DV_CODED text
constraint. This is a very common clinical modelling pattern, where we
want to define an internal valueset or referenced termset, but wish to
allow other terms to be used if required. We will, of course often
wish to tighten this constraint at template level.
Although we can simulate this requirement by the use of a
DV_TEXT/DV_CODED_TEXT element, this is pretty messy and unintuitive to
model and I think we should strongly consider in ADL1.5, the addition
of an 'unbounded' attribute to DV_CODED_TEXT, defaulting to
False. I think it would have to be this rather than LimitToList to
provide backwards compatibility but it may make sense to default to
true for new DV_CODED_TEXT elements in archetype tooling.
After discussion with Thomas Beale, one option might be to allow a simple qualifier to be appended to the coded text constraint.
e.g.
ELEMENT[at0005] occurrences matches {0..1} matches { – Rhythm
value matches {
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0006, – Regular
at0007, – Irregular
*] – Any other coded_text
}
}
}
}
This is considerably simpler to model and understand than a DV_TEXT/DV_CODED_TEXT pair, is aligned closely to the HL7 CNE/CWE vocabulary strength and is also explicit that only another coded_text is allowed, not free text. It could also be applied to a term-binding constraint, where the binding offered is not mandatory and any other coded_text is allowed. This would allow 'open' access to a terminology without this having to be explicitly modelled in every termset.