Skip to end of metadata
Go to start of metadata

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

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





  • Review policy page

Discussion items


R5 draft`status

Deadline March 30 extended to April 5

Concept Map R5 dashboard:  

Marc working with Rob H to complete and and identified as high priority for completeness of ConceptMap tickets. 

Marc has made the structure changes, Rob is making build changes. 

Update 4/5/2021:

The build is still not working. There are 3 key ConceptMap related tickets we're looking for. Rob H has not given up.

CARIN IG for Digital Membership ID

Vocab signed on as an interested party. Mark Roberts would like to be on a WG call agenda to review. 10-20 minutes.

PSS for CARIN IG for Digital Insurance Card

Ted will create the page for April 15. CC will check with Mark on whether he prefers the beginning or end of the call. 

Identifier Systems

Zulip chat:  started specifically about transport addresses, more general discussion about how to support making identifier system identifiers available to the implementer community.

Vocab decided (at the main WG call 3/18/2021) that identifier systems will not be in THO. FHIR has a page for named identifier systems. This has been discussed at length since then, and it the decision has been reversed.

State of the union:

There are CodeSystems in THO that are really identifier systems (mostly from the CoreMIF where there was no such thing as a NamingSystem). There is no element in a CodeSystem resource that lets us know the CodeSystem resource represents an Identifier System.  

To support identifier systems, Vocab and FHIR-I have agreed that the following should occur:

  1. UTG tooling updates to properly and clearly render NamingSystems that are identifier systems vs: Codesystems
  2. Process for new identifier system requests
    1. HTA? 
    2. UTG process
  3. Import identifier systems currently defined in FHIR spec into THO
    1. THO as a kind of NS
  4. Clean up existing CS in THO that are really identifier systems(lower priority)
  5. FHIR Core spec updates to remove identifier systems and direct users to THO

Lloyd was invited to attend to help clear up any confusion in the community about identifier systems. A request was entered to add a NamingSystem for an identifier system. Vocab initially responded no due to resource constraints. Further discussions came back around that the current implementation of listing identifier systems on a page in the FHIR spec is not sustainable. 

There are around 100 existing identifier systems in FHIR. There has not been any (or very little) engagement with the owners of the identifier systems (e.g. the state of Maine who owns drivers' license number identifier system). 

HTA could develop something similar to what is done for external CodeSystems for identifier systems. Carol indicates there is not a resource issue.

Effort required to add this process to THO and to HTA, however this is in competition with the many other issues that need to be addressed to improve the quality of content. 

LM points out that when an error is found in THO, a ticket can be entered to address. There is a greater likelihood of new items being established in the right place. 

LM: would like to have a statement that identifier NamingSystems do fall into the scope of THO. Creating a tab is relatively simple. We should work with GG to transition the identifier systems that are defined in FHIR into THO - ideally before final version of R5. Longer term, having a specific UTG request type to separate a request for identifier systems from other types of requests.

HTA define a process (addition to HTA charter?) which may be much more light weight than what is required for CodeSystems. Carol proposes that any process is followed with new identifier systems. HTA will work with Vocab/FHIR-I to propose a url pattern and get agreement. This is not required for HL7 to move forward with incorporating identifier NamingSystems into THO.

Jessica Botais pretty far along with the specific request that started this discussion. 

In addition to the tasks listed above, we should ask the community if there are any identifier systems hiding in specifications.

Vocab will be responsible to nudge people to get this done.

  1. current, single request (Jess)
  2. THO updates to separate CodeSystem NamingSystems from identifier systems NamingSystems (Ted)
    1. One UTG ticket to add the tabs, how to name them, etc. 
    2. One UTG ticket for #3 to import the bulk mentioned in #3 
    3. One Vocab ticket to create the extension as described in 6.c
  3. Import existing identifier systems from the FHIR spec into THO as NamingSystems (they only exist on the html page, table row entries) (Rob M. volunteers Marc D. to work with Rob H for requirements to create the NamingSystem UTG proposal. Lloyd has volunteered to help)
  4. Remove the identifier systems from the FHIR page (GG)
  5. HTA stuff (Carol)
  6. Identify V2 and V3 identifier systems that have been defined as CodeSystems need to be addressed  
    1. Some of these exist  CodeSystem resources without a NamingSystem but some do have NamingSystems
    2. This is a mess, and someone will have to figure out 
    3. V2 identifier systems are sub-typed that will most likely require an extension
      1. This sub-type is important information for implementers (the FHIR identifier datatype has a system, value, and type. The type is the "subtype" mentioned above. ) 


This is a mini-project to coordinate the FHIR and UTG work. 

Extensible Binding 

MnM update? 

FHIR-29968 - Getting issue details... STATUS

In what circumstances should there be extensible binding strength in FHIR Core? What are the criteria that define when extensible binding strength is allowed in FHIR Core. More of these have been popping up. The M&M meeting is on Wednesday 3-4 EDT. Rob M. will attend the meeting.

This is not the same as the issue we've discussed in the past about implementer expectations in general with extensible binding strength.


UP-179 - Getting issue details... STATUS   Are we all set here? Notes from last week:

STU3 download package includes FHIR R4 info

We had stated early on that UTG would be a going forward from the old harmonization and way of doing things. Grahame had made up some URLs for v3 and v2 content that FHIR STU3 needed and he agreed that we would go with the new ones for UTG and FHIR F4 going forward.

Ted contends that the suggestion in the ticket is not valid. 

Rob M.: is it possible to have a STU3 "version" of THO?

Ted: no, we don't have the content

Rob M.: to support STU3 users, we would have to create versioned artifacts, etc. 

Ted: lots of dev work to support

Symptom: uri mismatch between THO and STU3. There are code system uris for existing code systems that only exist in R4, but they show up in the R3 build. 

Cause: UTG project scope creep not addressed, focused on R4 (as decided by CTO, TSC)

Ted: suggests removing the second bullet, and updating the text that Note that NPM packages are usually resolved via the FHIR NPM package system, so it's enough to reference these packages in your dependencies without downloading them should be changed to let people know that THO supports R4 and forward. 

Rob M: will this work?

Ted: there is no way to build an STU3 view including terminology. 

From the download page at 


Download the NPM Packages for this version of the HL7 terminology. Note that NPM packages are usually resolved via the FHIR NPM package system, so it's enough to reference these packages in your dependencies without downloading them

Action item: 

  1. Determine how and if people should be able to build STU3,
  2. STU3 builds should not use THO (question)
  3. STU3 folks have to do something different to pick up new terminology
  4. Need instructions on the downloads page (or somewhere) for people to build what they need 

Ted will update the ticket with our latest thoughts and follow up with GG. This ticket might not belong in UP. No change to the THO downloads page. 


Where do we represent the published code system version in THO? HSLOC.  Internal THO version, but not external code system version.

Provenance and AuditEvent

Problems related to the fact that Provenance and AuditEvent are a collaborative effort that has common lineage to DICOM, HL7, ISO and W3C. ValueSests exist with overlapping concepts - not helpful. 

Action plan? 

John M. started this Zulip thread - related to security. He is asking for Vocab's help to fix the problem. 

Ted: we use Provenance in THO - to track changes applied to THO content.

John is bringing up issues that are surfacing and causing problems with other implementation. Suggest that he prepare his material and get on a main WG call agenda. Rob M. sending this message. 

New JIRA project 

(did not get to this topic)

Rob M.Clarify how to set up the JIRA project for existing standards

R5 Priorities

Did not discuss

From LM email 

Must be clean and ready for QA by April 5 for R5 draft. See detail above. 

ConceptMap is priority #1. The FHIR tracker call on 3/11/2021 focused on ConceptMap as will the one on 3/25.     Consolidated information from Michael Lawley   Vocab dashboard (CC confirmed tickets in Michael's document are on dashboard)

  1. ConceptMap
  2. NamingSystem
  3. CodeSystem 
  4. ValueSet (addressed via VSD-P project, and incorporating 3 CPG profiles)
  5. Changes to FHIR spec to address THO  
    1. Remove FHIR pages that reference CodeSystems and ValueSets that are in THO, direct to THO
    2. IG IG updates 
  6. Difficult topics
    1. Extensible
    2. Deprecated identifiers
    3. Policy clarification

Using Codes / Selecting a Code System Identifier Text Review

did not discuss

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/15

Discussion from 2/08.  3/15 note: this is now a "to do" item on the policy page

  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 
      3. 4/5/2021 update: Rob M will bring this issue to a FHIR-I call
  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

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/8, 3/15 or 3/22

Rob M.

Discussion from 2/15: Note from 3/15 - this is now on the policy page as a "to do" 

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/15 or 3/22

This is encapsulated in one of the policy statements yet to be defined - in the lower priority section.

Vocabulary Work Group Policy Statements

Supporting C-CDA FHIR IG

Did not discuss on 3/15 or 3/22

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

Action items