There is an established use of the DV_TEXT/DV_CODED_TEXT choice pattern to allow
extension/replacement of internal code lists (better solved by the proposed changes to allow for ‘extensible’ etc.
To allow a free text to be used in place of a coded text, where none is available.
As an example, the Adverse reaction archetype is intended to be used in the UK with a very strict SNOMED valueset, so that it can power decision support across systems . So in this case the valueset is ‘required’ and not ‘extensible’, However we do recognise that very occasional allergies need to be recorded against drugs that currently have no coded terms e.g new medications, trial drugs, foreign products.
in FHIR the ‘extensible’ valueset binding allows for a free text extension (against their CodableText datatype) but that would not work for us technically , and also is, for me, not quite right semantically. In the UK use-case I want ot strictly control the coded valueset so it should be ‘required’ and not ‘extensible’.
The good news is that with the changes to valueset binding strength, we can make the DV_TEXT/CODED_TEXT option work for this.
The bad news is that it leaves open a problem that Fabio highlighted in Braunschweig – If we leave DV_TEXT as an alternate through to run-time (or a template-level) it can always potentially be sub-classed to a DV_CODED_TEXT, and therefore subvert any existing constraints on the existing DV_CODED_TEXT valueset bindings. i.e I could then use any coced valueset I wished.
This is one of the issues that is blocking full adoption of ADL2 in AD.
Add an attribute to DV_TEXT this signifies it as ‘final’ ie. not able to be sub-classed to DV_CODED_TEXT
Add new sub-class to DV_TEXT alongside DV_CODED_TEXT as DV_PLAIN_TEXT.
In practical terms when, as modellers we want to use the Choice option, we would use DV_PLAIN_TEXT/DV_CODED_TEXT as the normal choice.
I think this solves Fabio’s issue.