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:



Regrets Rob McClure


  • Confirm R4B changes
  • R5 ticket approach - prioritize 
  • Address Zoom bombing

Discussion items


Conf call 


We addressed the co-chair webinar issue.

March 11 call collides with FHIR tracker. Attendees agreed to start the next tracker call at 5 pm ET, and extend to 2 hours to address Concept Map issues. Michael Lawley synthesized open issues and we will discuss as a collection.

Rob H has changed this call.

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

Zoom bombing

Zoom bombs are on the rise. Implement waiting room? 

Ted suggests we wait until the first bomb occurs. He suggests that there always be more than 1 host. A host can put someone in the waiting room even without setting up waiting room. The host can also bring someone back from the waiting room. 

R4B ticket status


Rob H

R4B Tickets Must be applied and QA'ed by March 3.  Vocab goal is Feb 22.

R4B Criteria:

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

29945  (Naming System maturity level),

29960 (Concept Map Dragon) and  *******StructureDefinition for comparison not available. 

  1. Apply change without map to StructureMap for comparison, or
  2. Complete StructureMap with link for MD to use and apply change
    1. Rob H is working on this. 
    2. The ticket specifically mentions including the StructureMap
    3. Rob H will contact MD today to apply the change without the structure map
    4. If Rob H is not able to complete this by noon ET on March 3, the ticket will need to be re-opened and updated to reflect that the structure map was not created. A new ticket. If he is able to complete this by noon ET, then he will apply the change.  
    5. Rob H will keep the co-chairs up to date on Skype.

29113 (Naming System ownership)

 THO releaseTed 

Notification sent to all co-chairs. Any issues? 

Release not yet started, delayed because of a build bug. If not able to successfully build this week, the release will be abandoned for R4B. 

R5 From LM email 

R5 draft deadline is in 29 days. Vocab needs to think about how to prioritize the work to be done. Will discuss on main WG call.

RD: Why is there an R5 draft? What is the different between R5 draft and R5? Doesn't the CI build process validate changes?

TK: The CI build doesn't check 100% of the updates. 

R5 draft will be everything in the CI build as of March 30. No lock that these would be the only changes allowed for R5. 

R5 draft will be balloted. RH reminded us that there was an R4 draft.  

ConceptMap should be #1. 

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

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. 

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. 


There is some thought in the community that R5 will be the last release of FHIR. People will be reluctant to move from R4.  He suggests that we should consider how to get all the vocab resources to normative for R5. Connectathons? ConceptMap and NamingSystem are the non-normative resources (TerminologyCapability?). Maturity level is not up to the owning work group. 

A resource doesn't have to be in its formal form to start the normative process.  The maturity level change might have hindered the ability to move ConceptMap to normative. 

Ted brought up the V2 experience - pre-adopting portions of a subsequent release. Its possible something similar will happen with FHIR.

OID related tickets 

Steps to resolve issue?

  1. Add OIDs to registry (or not?)
    1. Identified by people
    2. Sweep for missing ones
  2. Remove FHIR pages that reference CodeSystems and ValueSets that are in THO, direct to THO
  3. More?

Please review the tickets here:

These will be discussed on the main WG call this week.

*************From 2/22***********

project = fhir and "Work Group" = "Vocabulary [vocab]" and grouping = OIDs   

Must the OIDs be created via the OID registry, is there a technical requirement that the OIDs for a value set be in the OID registry.

TK: there is no V3 requirement that there is an OID in the OID registry for a value set. There is no OID registry API. 

RM: Is the OID registry the source of truth for all HL7 terminology - we can state that the OID registry is not the source of truth for OIDs for all HL7 terminology.

TK: at one time the OID registry was declared to be the source of truth (history - back to when V3 didn't participate in harmonization.....) 

RM: The OID registry as it exists does not contain every important OID, we shouldn't add OIDs to the registry simply because we have them. Personal opinion - we should create/generate OIDs for every terminology artifact. They don't have to be in the OID registry. The source of truth should be in THO (if appropriate) or in TOOLING UPDATE REQUIRED (possibly when the CodeSystem and/or ValueSet is created in UTG) (generate the OID, make it visible) HSCR project.  Category label = UTG  Vocab needs to define a policy 

RM: suggests adding this text to the tickets: Thank you for identifying these issues. Not all OIDs are in the OID registry. Vocab has identified that there is a deficiency in communication about OID assignments. It has been added to the list of items Vocab must address.  Please continue to bring these to our attention.  (Carmela will do this and prepare a block vote)  Some do not have OIDs, some do. 

TK: does this impact revenue? This is a complex issue that requires a systems level solution. 

Older policy: External CodeSystem OIDs must be registered in the OID registry - and there is a cost to this. Does HTA enforce this? This is not a policy that is enforced, known, etc. Its not clear that there was a formal policy, and if there is, this must change. 

Type 6 OID - are for external code systems if an external code system doesn't have their own OID. The owner can still be listed as the external organization.  

Bulk loading of OIDs would be helpful. 

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. 

Decided to talk about this at the 6 pm meeting. 

3/1/2021 update: The identifier meeting attendees clarified the target audience for the materials we are creating. 

Decided to focus first on getting the diagram up to date - which is for an IG author audience.  

  1. implementers
    1. implementers should just use what is in the spec
    2. Rob H. contends that the FHIR spec should only have information for implementers
    3. If thats the case, then any information about how to obtain a code system URL might not belong in the spec
  2. IG authors
    1. responsible for making sure the spec has the right code system and value set identifiers

Note: the Monday 6 pm ET discussions have been specific to the URL - for use in FHIR. There are other identifiers for the other HL7 product families. This should be managed through UTG. Not only identifiers, but different metadata across the product families. Example? 

Once the HTA material is in HTA, the problem will be less.  TOOLING REQUIREMENTS - create OIDs for every FHIR terminology 

Code System Identifier Deprecation 

Did not discuss on 3/1

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

Discussion 2/22/2021:

Governance: (still need a policy)

Deprecated status takes precedence over the validity period.

How to detect deprecated identifiers 

  1. Deprecated = true
  2. Validity period end = past date

Chance for mis-interpretation? Adding deprecated to the status value set does not help the NamingSystem identifier deprecated issue. 

Ran out of time. 

External code systems - Canada

Extensible definition

Did not discuss on 3/1

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 discuss on 3/1

Supporting C-CDA FHIR IG

Did not discuss on 3/1

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

Action items