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 and R5

Discussion items


Co-chair webinar schedule


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. 

Possibly swap with co-chair call. 

Rob M. suggests that we have a main Vocab call every week. Not everyone agrees. 

R4B ticket status


Rob H

Dashboard with identified JIRAs

R4B Criteria:

Note here:  it mentions that datatypes can be added to R4B

29945  (Naming System maturity level),

29960 (Concept Map Dragon) and 

29113 (Naming System ownership)

are the R4B tickets as discussed on 2/11/2021 FHIR Tracker call.  They must be applied by March 3, 2021

RD: suggests RH reach out to Marc to see if this can be done by Feb 22. 

RH: he feels confident that this can be done by Feb 22. RD is plan B.

R5 CriteriaFrom LM email 
  • Priority criteria for a draft ballot in May 2021
    • have existing normative content they expect to update in R5
    • STU content moving to normative in R5
    • STU or net new content where they are seeking review to answer targeted questions to allow finalization of design in advance of the R5 ballots
  • Criteria for R5 have not been communicated (in terms of differences from any release)

FMG requesting exactly what content fits one of these criteria. Must be clean and ready for QA by March 30. 

Vocab has a lot of tickets to consider. Need to determine how tickets are prioritized.

CC gave a description of what happened at the FHIR tracker call related to R5. 

Some tickets have been taken care of, others might be transferred to UTG, some are OID related.

Any OID needed for an IG/specification reference can be added to the OID registry free of charge. 

RM: is there some requirement that OIDs created for a specification have to be in the OID registry? 

Ted: there is no requirement, no formal statement from SGB/TSC.

RM: is it possible that OIDs are assigned in the HL7 OID root that are not in the OID registry? 

TK: ANSI delegated responsibility for that root to HL7. For type .3, HL7 would delegate responsibility to the organization that registered the OID. Type 6 = CodeSystems. Type 5 = V3 Core MIF. Type 11 = Value Sets from harmonization. Type 13 = Value Sets referenced in specifications that didn't go through the harmonization process. Type 4 = identifier spaces (e.g internal HL7 organizations like FHIR which then have the responsibility for subsequent OIDs)

All value sets in the FHIR specs do not have an OID.

Going forward: we need to define a governance policy for OIDs.

How to prioritize 

  1. ones that look easy
  2. ones that are more involved (e.g. extensible)
  3. ones that are somewhere in-between

Please make sure you update tickets when you have a comment, or an idea about how to approach a ticket. Link to background information, or link to a Zulip chat. The ticket should be the main place to go to find info. 

Ted asked about the DesignationUse code system/value set.  Not critical for R4B, but must be in R5 draft.  UP-107 must be applied for R5 draft. Rob H and Ted will work off-line to resolve this issue. 

Rob H. could R5 draft be the milestone rather than R4B.

TK: suppressing warnings in build, 8 hard errors that cannot be suppressed are not documented in tickets. CodeSystem resource updated with an extension, but build not updated to support. Uncomfortable releasing new THO with the 8 hard errors. Related to external code systems. 

Using Codes / Selecting a Code System Identifier Text Review

Co-chair review of this text:

Updated text for Using Codes / Selecting a Code System Identifier

Confirm so ticket can be applied. 

Sent link in meeting chat - co-chairs please review.

Code System Identifier Deprecation 

Discussion from 2/08

  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, define a policy related to deprecated 
    4. FHIR-31028 - Getting issue details... STATUS   create a new concept in Publication Status value set = Deprecated  
      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 
  2. Deprecation applies to
    1. CodeSystem Identifier
    2. CodeSystem resource
    3. ValueSet identifier
    4. ValueSet resource
    5. Concept Map resource
    6. 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
    7. FHIR inconsistently defines workflow status (e.g. review, approve) - sometimes in the Resource, other times depending on Provenance

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. 

2/15/2021 Update: Vocab needs to define a deprecated identifier policy - the addition of a new publication status code is great, but doesn't solve everything. There is an immediate need to document how to work with the R4 definition before we get to R5. Based on last discussions, implementations can't distinguish between inactive and deprecated by looking at the effective period. TK will update the ticket with his thoughts on this issue. Unfortunately we are time limited. This was pushed to R5.  

FHIR-30319 - Getting issue details... STATUS

External code systems - Canada

Extensible definition

Did not discuss on this call.

Rob M.

Discussion from 2/15:

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?  

Action items