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:





  • Review policy page

Discussion items



Has everyone reviewed the 3 R4B changes?  

Who volunteered to add a page for ballot review?

Ballot Responsibilities    Update here!

Ted isn't planning on checking out R4B, nor is Reuben. 

R5 draft`

Deadline March 30

Good progress on Thursday 3/25. Marc applying updates - most seen here:  

3 VSDP related tickets, still in triage and   (adding extensions to ValueSet.compose) will be pre-applied.   FHIR-26069 - Getting issue details... STATUS  is a duplicate of FHIR-26550 which was already applied. How do we get rid of 26069? 

26069 taken care of. 

FHIR-26028 - Getting issue details... STATUS  we voted on this one but didn't provide enough detail to complete. Is this one Rob H could work with Marc on?  During the call, we clarified the intent, and added some text. Tagged Marc D. for the update. 

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. 

UTG Voting Process UpdateTed

Ted worked with Josh to add function for vote changes. The quorum process was adjusted. User gets a visual notification that quorum has been met and the ticket will move to the next step. A voter whose vote completes the vote tallies has until midnight the day after the user voted, to change their vote (to try and catch all timezone issues).  Any other voter may change their vote at any time prior to the voter who completes the vote tally. 

A nightly function runs that will detect when a ticket may be transitioned to the next step in the process. 

Testing: difficult to test due to the many variables. Ted's recommendation is that between now and Thursday (main WG call) they will test as best as possible, and either push to prod or announce that it has been pushed to prod. 

RD: confirming there is no deadline for consensus review (originally planned, but because of community concern, it was removed). 

Ted: the deadlines might be put back

RD: when the deadline is put back, will the vote withdrawal be impacted? 

Ted: proposals will transition when quorum and vote totals are met, and it is the transition time, but at any time in there, the ticket might expire. If the vote is completed and within the grace period the ticket normally would expire, it should not expire. 

RD: the deadline for final voter vote change seems unnecessary if the ticket has an expiration date.  He is concerned that people will be confused.

The idea of voting and deadlines is top of mind for people who vote on ballots. People might assume that if a ticket has an expiration of 30 days (for example), that they have 30 days to vote. But that's not the case because quorum might be reached and away it goes. RD suggests that we should just wait to the expiration date, and not automatically transition based on quorum. 

RH: will this make the process too long? RD: make it a short time period

TK: people were concerned about the last voter in the chain

TK: expiration ends up accomplishing the same thing as the grace period for the last voter to change their vote 

RD: we might be able to simplify the process if when we add the expiration date, we remove the grace period. 

Identifier Systems

(Decided this would be an April 5 topic)

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

Notes from last week (consolidated)

Transport Addresses

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. 

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 is one of those animals. 

  1. Clean up existing CS in THO that are really identifier systems(lower priority)
  2. Decide what to do with identifier systems (Peter had suggested EndPoint resource)
    1. THO as a kind of NS
    2. FHIR registry (rejected)
    3. EndPoint resource 

The simplest solution might be to have a page in the FHIR spec that lists the identifier systems.  

Rob M. suggests that this information should be in the FHIR spec. Dev work in THO required to support identifier systems. 

 A ticket has been added to the UTG tooling to evaluate THO for identifier systems.  HSCR-135 - Getting issue details... STATUS

3/29/2021 updates:

TK agrees with LM that identifier systems should be in THO, and that they should be represented with NamingSystem (not EndPoint). 

User interface work required to incorporate identifier systems in THO (not a great deal of programming) - lots of HTML pages. 

Does the UTG JIRA process support identifier system additions/changes? TK: yes 

  1. update UTG to make identifier systems part of the infrastructure
  2. add existing identifier systems, wherever they may be, to THO
    1. FHIR (must be removed from FHIR pages) 
    2. importing into UTG
    3. Core MIF generation - need an M&M decision to remove items identified in #3 
  3. Evaluate V2 and V3 identifier systems which were modeled as CodeSystems without any content (they are mis-represented as CodeSystems)


This is a mini-project to coordinate the FHIR and UTG work. Melva, Wayne, Carol have volunteered to find all the identifier systems. 

This will be prioritized along with the other UTG tickets. 

Will continue discussion at main WG call. 

VSD-P progress
Plan is to put the new profile in R5 draft without guidance text. Next week guidance text will be reviewed, and a plan developed to incorporate the CPG profiles into core. 

Monday Code System Identifier & UTG series ending


Workflow diagram in a good state. Next steps to draft best practices for IG authors and consider where to propose changes in text - plan for R5?    

  1. Best practices
  2. QA checklist
  3. Tooling opportunities
  4. Policy
  5. Edge case list

R5 Concept Map

Good progress made last week. 


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. 

Identifier Systems


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 

R5 draft deadline is in 16 days. Vocab needs to think about how to prioritize the work to be done. 

Must be clean and ready for QA by March 30.

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