Replacing an archetyped value set - AD and CKM bug?

I was just made aware that AD allows a template modeller to replace an internal value set from an archetyped DV_CODED_TEXT data element:


The way I understand the whole concept of constraint modelling, this shouldn’t be allowed. When we constrain an archetyped DV_CODED_TEXT to a specific set of values, without the alternative of an unconstrained DV_TEXT, it’s because the included value set should always be used.

The values also follow when exporting an oet from the template, and the CKM gladly accepts them without sounding the validation alarm.

@borut.fabjan and @sebastian.garde, do you have any thoughts about this?

@siljelb This is definitely not allowed in 1.4 land, although I have heard that some find it useful regardless…

This is why we had the Binding strength / constraint strength discussion and have added the ability to mark a value set as

required, preferred, extensible, example

in 2.x.

In 1.4, it is always “required” and then this is not allowed - the only alternative I know is the DV_TEXT/DV_CODED_TEXT cludge you mentioned.

1 Like

When setting it as “required”, especially in an international context, I think, the author(s) should be very cautious.

For example, FHIR Patient.gender has a “required” binding to the AdministrativeGender ValueSet:


But, sometimes, it might be kinda annoying. For example, for a national implementation guide, it might be necessary to change its binding to a national ValueSet.

Similarly, in contrast, a good practice is to set the minimum cardinality to zero for most elements of FHIR resources.

I agree, and the pattern we mostly use nowadays reflects this. But when we do choose to require a specific value set, it shouldn’t be up to the template modeller to change it.

Understand. However, when releasing the archetype(s), it’s hard to think of all the use case scenarios, especially some edge cases.

2 Likes

@borut.fabjan, what are your thoughts about this? :blush: