Rob suggests that we start to use this page actively to record vocab policies in preparation for creation of a vocab management/governance group. We need to have crisp, concise statements to reference. Vocabulary Work Group Policy Statements
How to approach resolution? The R4B ticket for this was pushed to R5
Rob H: get the proposed text integrated into the FHIR specification (in the CI build), and review in context.
We reviewed FHIR-29968 and did not get to the point where we have a text block to propose for the R5 build.
Example value set expansion: Red, Blue, Green, Yellow
Someone wants to communicate Magenta. Is this a type of Red, or is it something different? In SNOMED, magenta would be a sub-type of red.
Extensible is intended to be guidance for implementers for what to support.
It is allowed to send a code that is in a more recent expansion/version of the bound value set.
See #4 in the comment of the JIRA. This is problematic.
It is acceptable to have a new value set version or a new value set that is claiming conformance to the original extensibly bound value, where an expansion has a concept that is a descendant of the original extensibly bound value set expansion
Want to explicitly add magenta to the expansion - either a new version of the original value set or a new value set and claim conformance.
#4 as written doesn't allow this.
An implementer might decide to add magenta to their value set because their use case needs it. Conceptually, there is a new IG that has a new ValueSet.
This is really obvious when a different CodeSystem is in play
Ted: Extensible could be viewed as ideally you would make the value set required, but you know there are use cases that you can't possibly know about, and want to allow implementers to send something not in the value set when necessary.