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:





Discussion items


CVX and terminology source of truth in general

Work group update: 

Its one thing to remove CVX value sets/code system from THO, but it still lingers inother places. 

Reminder from last week:

Team, please consider that when communicating to people with questions about terminology source of truth - conference calls, work group meetings, Confluence, Zulip, etc. is not the HL7 official terminology repository for content, it is A repository to support publishing. Currently people can request that content be added to support their publishing requirements. 

The only official repository for content is FHIR build, and THO.

THO can only be the source of truth for internal HL7 code systems. THO is not the source of truth for any external content. THO may maintain a 'stub' for external content.  

R5 draft`status

The following 3 tickets did not make it into R5 draft, however they are in R5 post-draft. and and identified as high priority for completeness of ConceptMap tickets. Deadline March 30 extended to April 5

R5 Priorities

R5 dashboard showing applied tickets so far:  

R5 ConceptMap Dashboard:     (13 remaining tickets)

R5 NamingSystem Dashboard:    (5 remaining tickets)

R5 CodeSystem Dashboard:        (17 remaining tickets)

R5 ValueSet Dashboard:    (at least 58 remaining tickets) 

Vocab - no resource:    (85 remaining tickets)
Publish code system update schedule?

CodeSystem Identifier Task Force

Status:  diagram in a good state. Next steps to bring start communicating and putting decisions into action.

  1. Review requirements - FHIR-I? Work Group Meeting agenda - which quarter?
  2. Confirm documentation locations 
  3. Confirm/discuss communication plan
    1. Co-chair webinars
    2. BoF
    3. HL7 Blog Post
    4. HL7 Standards Update (from Wayne - more weight?)
  4. Value Sets and THO 

Recent decision related to Deprecated as a status
Next steps?

New JIRA project 

not covered on this call

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

O&O lab short term suggestions on how to exchange SOGI

Sexual Orientation, Gender Identity, Administrative Sex, Birth Sex etc

Scheduled for Q1 Tuesday at WGM - confirm

Request from Craig Newman to review this text related to exchanging SOGI in v2 ELR messages. Appropriate for Gender Harmony 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.

Project status? 

IdentifierSystem support tickets added as part of action items from 2 weeks ago.

HSCR-138 - Getting issue details... STATUS     Add support for Identifier Systems in THO 

HSCR-135 - Getting issue details... STATUS      Evaluate Identifier System support in THO - this ticket should be closed or deferred 

HSCR-139 - Getting issue details... STATUS      Add Identifier Systems to UTG in bulk

FHIR-31706 - Getting issue details... STATUS    Add NamingSystem extension to support Identifier System sub-type

Remaining action items:

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

  1. As part of prep work required for HSCR-139, Rob M. volunteers Marc D. to work with Rob H to create the artifact for bulk update into THO and to create the UTG ticket. 
  2. Remove the identifier systems from the FHIR page (GG)
  3. HTA stuff (Carol)
  4. 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. Vote on and apply FHIR-31706 added to address this: 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. ) 

Extensible Binding 

Rob M. report from the M&M meeting. 

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. 

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.  Ticket was applied for R5 draft. 

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, even though it has information for IG authors now. 
    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 

not covered on this call

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

not covered on this call

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

not covered on this call

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

not covered on this call

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

Action items