Skip to end of metadata
Go to start of metadata

Web Meeting Info:

Join Zoom Meeting - | Meeting ID: 718 380 6281  P: 370553 

+1 646 558 8656 US (New York) | Find your local number:




  • R4B, Extensible

Discussion items



Rob H

Dashboard with identified JIRAs


Marc and Rob have set a 2 week time window (as of last week), Marc doesn't have any blockers. 1 week left of the 2. 

Marc and Rob will coordinate. There is no official date yet communicated for R4B however we need to be prepared. 

Co-chair review of this text:

Updated text for Using Codes / Selecting a Code System Identifier

Co-chairs will review this text and decide next Monday Feb 15. 

Code System Identifier Deprecation 

  1. Code System Identifier Deprecation  
    1. See notes here: 2021-01-18 Vocab Chair Agenda/Minutes
    2. See notes here where the group was reaching consensus:  Jan 2021 - HL7 WGM - Thursday Q3 Minutes
    3. FHIR-30319 - Getting issue details... STATUS  voted to move out of R4B to R5
    4. Summary:
      1. Deprecation does not require an additional element - use the combination of period and preferred indicator
        1. Use date greater than end-date - identifier is deprecated
        2. Not:
          1. Using Provenance
      2. Blank on purpose
  2. Deprecation applies to
    1. CodeSystem
    2. ValueSet
    3. Identifiers for each
    4. Concept Map
    5. Status:
      1. V3 and V2 ValueSets support deprecation in the work flow, FHIR does not as a status
      2. V3 and V2 ValueSets do not support Draft, whereas FHIR does 
        1.  Candidate for unification/harmonization
    6. FHIR inconsistently defines workflow status (e.g. review, approve) - sometimes in the Resource, other times depending on Provenance
    7. Rob M. suggests that we request a new value in the FHIR status value set 
      1. The FHIR status value set is bound to status, with code data type, and is normative
      2. Opportunity in R5 to request an update
        1.   (this shows everywhere the value set is used - see 2.a.ii)
        2. To change this a ticket should be entered in the FHIR project (not UTG since this is core) Rob McClurevolunteers to do some more research, and then possibly enter a ticket.
          1. 2 approaches:
            1. Add a boolean extension to ValueSet to represent deprecated (deprecated definition needs to be clear - active but......)
              1. This might provide more control over the use of this concept
              2. Ted notes that this implementation might be problematic - extensions are only exposed/rendered in the FHIR spec if they are core extensions. 
            2. Add a new concept to the CodeSystem, change the existing definition to be the existing enumerated list. Make a new ValueSet that is enumerated list + deprecated 
              1. Deprecated might not make sense for all uses of this ValueSet - the CLD for this ValueSet might be problematic for other use cases.

Action item from 2/1: compare/merge material from WGM Policy for terminology in FHIR IGs and the Vocab material during the Task Force call today.  Done. 

External code systems - Canada

Vocab policy pageRob M.

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

Extensible definition

Rob M.


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.

Rob M:

  • 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. 

.   FHIR-29968 - Getting issue details... STATUS

Policy on the use of extensible value set bindings

This was discussed at length during Q5 Tuesday during the WGM. Jan 2021 - HL7 WGM - Tuesday Q5 Minutes

See discussion notes from previous co-chair call: 2021-01-18 Vocab Chair Agenda/Minutes

Should we also review the definition of preferred binding strength? 

How to distinguish between extensible and preferred?

CPT4 Syntax

Did not get to this topic

Supporting C-CDA FHIR IG

Did not get to this topic

From WGM. How does C-CDA address terminology quality now that Term Info cannot be referenced?  

Co-chair webinar schedule

Did not get to this topic


Co-chair webinars collide with main WG call once a month. Do we want to try and change the day/time.

Ted asked Sadhana about this schedule. She has not yet answered. 

Ticket prioritization

Did not get to this topic

R5 upcomingR5 and moving forward.

Action items