Attendance can be found Here

Co-Chair and Key Participant information can be found on the Agenda found Here

Discussion items

6:00 Carol setting the stage CarolLots of agenda items. 

UTG General Updates (10):

  • CDA documentation updates to reference UTG. 
  • New content creation - moving from IG to UTG
  • CDA content needed (we thought we had until R2 later this Fall)
  • Ongoing issues that need attention 

UTG is functioning as if it were live and rolled out.

40 people are registered as submitters. 

Build issues are impeding progress.

Documentation updates in progresss.

New content creation - developers should start using UTG for non-core terminology (e.g. Code Systems or Value SEts that are IG specific)

CDA content being added as it is required for CDA builds.

Ongoing issues are being discussed on Zulip.

Go live to be announced at the next co-chair webinar

  • Implementation of both a CS stub and NS entry for all code systems
    • Need agreement on timing.
    • What about the FHIR update to indicate a CS stub has no CS information besides descriptive metadata?

UTG plans to implement CodeSystem & NamingSystem resource instances for all Code Systems. Note a Code System might be a "stub" for non-identifier information - descriptive information. All non-stub CodeSystem resources for external Code Systems at least the key information as documented by HTA.


Grahame Grieve (GG): For CodeSystems with just identifiers and descriptions - will we still have CodeSystem resources.  Yes

TK: we have one very old example of a CodeSystem that has an identifier only. 

Rob McClure (RM): we should move past this old example and not design around it.

GG: what is Vocab asking.

TK: if there are CodeSystems with only an identifier and descriptive metadata, 

Reuben Daniels (RD): we would simplify all of our lives if we have a motion to remove all the old, low quality, not used (see dross below) artifacts and not spend time trying to manage them.

TK: One example is Medispan Diagnostic Codes. He is concerned that this might cause problems with implementers.  

Julie James (JJ): Medispan is a US code system and is used - not used in Europe. She agrees with getting rid of the infamous dross.

TK: How do we know?

RD: we don't need an algorithm, we can create a list and publish it (between 100 and 200). Put a note on Zulip and the listserve.

Carol Macumber (CM): how did you identify them

RD: some CodeSystem do not have a human readable name, nor an identifier,e tc.

CM: please add the criteria to the communication.

TK: Moves that Reuben create and publish this list including a deadline. The communication will include the action to be taken with the CodeSystems in question and the criteria by which they were placed on the list.

JJ: HTA will review. 

RM: Define "remove" - 

Lloyd McKenzie (LM): he doesn't think that removing the CodeSystems

Moves that Reuben create and publish a list of CodeSystems and any referenced ValueSets to be removed from UTG, including a deadline for community review. The communication will include the action to be taken with the CodeSystems in question and the criteria by which they were placed on the list. The communication will include Zulip, FHIR-I, HTA and Vocab listservs.

Moved by:  Carmela Couderc, Seconded by Lloyd McKenzie

Vote:  Abstain:  0   Against:   0   For:   20


Some information will be in flux as HTA is gathering information. 

GG: Proposes that we create an extension to indicate whether the CodeSystem metadata is fully defined. Assumes we will still publish CodeSystem definition stubs for LOINC and SNOMED CT. He will create a new JIRA FHIR-28612 - Getting issue details... STATUS to define the proposed extension with similar semantics to the CodeSystem.content element but targeted at the Code System metadata .

RD: how would this extension be different than the content element. 

GG: content addresses the concepts; this extension would address metadata

TK: is the juice worth the squeeze? should we do something else 

RM: Should this also apply to ValueSets?

GG: lets try with CodeSystems and determine if we need it for ValueSets


  • Consider not including all of core MIF old content into UTG and just add that as an addendum to the content that is in UTG when creating the "current MIF build."

See section above - especially motion with regards to community and HTA review. 

  • Need decision regarding "retired" value sets that have invalid concepts. We should not require an update to the CLD to a retired value set in order to avoid errors or warning  See NUCC
Rob M.

The MIF has codes from NUCC defined in value sets and the codes are no longer valid. Most of the codes could be algorithmically replaced with newer codes. All the value sets were noted as deprecated in MIF, and some were also retired.

2 scenarios

  1. no longer to be used, it was valid for prior use
  2. no longer in active use

Should these value sets be dropped out of UTG?

The motion above should remove the NUCC value sets in question. However there are other artifacts where there is an issue.

  • Need to consider retired vs deprecated to handle if we want some previously useful value sets to continue to have an expansion, versus not expansions to be done. 

Retired != deprecated

Retired = do not create any new artifacts referencing this artifact, it is not maintained or intended to be used as the target of an expansion

Deprecated = 

GG: If the value set is no longer active, an expansion should not be attempted.

As a general rule, the validation could be updated so that a retired value set with references in the Compose to concepts no longer in the CodeSystem becomes a warning. 

RM: version level value set retirement must be addressed.

GG: agree

The IG publisher can only publish one version of a given resource because of how identifiers are managed. However making the changes proposed above will move the needle. 

CC: please confirm the definition of retired. 

GG: definition of retired = the resource has been withdrawn or superseded and is no longer to be used (from the FHIR spec) 

No longer to be used? What does this mean?

RM: what did deprecated mean in V3 MIF? 

LM: He thinks it meant withdrawn, you shouldn't use it but you can - its a warning that its currently active but on its way to being retired. 

RM: do we need deprecated?  based on the discussion it sounds like we don't transfer deprecated V3 items to FHIR.

LM/GG: there is an extension for noting a ValueSet as deprecated.  (any artifact can be noted as deprecated)

TK: this is good information to communicate to users. UTG will create  separate tabs for deprecated and retired. Those notions should carry forward. Deprecated is a kind of active. 

Vocab policy:  Policy on use of Retired or Legacy HL7 Code Systems


Summary of general issue - thanks Jessica Bota

Due to a timing issue, the FHIR resources for the R5 preview site were updated with their versions after the R4.0.1 versions were imported

We need a solution for the versioning issue with the imported FHIR code systems rooted at -they were all 4.2.0 when imported, the R5 preview set then to 4.4.0 whether or not they changed, and we have an adopted and approved Vocabulary WG policy on CS versioning which this also violates. We need to solve this and apply the solution for the 2.0.0 release


This ticket was entered by Bryn Rhodes. This is the first CodeSystem change for one that was imported from FHIR into UTG. The version needs to be confirmed/set. The only change was a clarification and a grammatical consistency update to a concept definition.  

GG: in general he would like to set the version for all Code Systems based on ballot status, etc. This would require a manual review. If the version numbers are reset, it could cause problems.  This is risky as it might overwrite changes that have been applied.

Difference between versions of artifacts in and 

All imported artifacts were set to 4.2.0 when imported. This is the only value set that was changed in UTG that was not done in the FHIR CI build.  

GG: will write a tool to determine how many instances of each value set has been published and then will reset the versions in UTG and will manage the one value set manually. 

7:00Discussion and review of the HTA/Vocab single repo for external CS info made yesterday
  • In the meantime...what to tell implementers creating new code systems under pressure for their IGs out in the community? (eg Mary Kay's issues; what to say in tomorrow's session)
Transition to Rob M chairing 

RD: The goal is that will be the source for all CodeSystem, Value Set, Naming System and Concept Map information. All other existing pages will redirect the user to

This will be a lot of work, but the work needs to start and be complete as soon as possible.

LM: this would not be all information? guidance for using terminology in FHIR?

RD: correct, some things would remain where they are - especially guidance

TK: does FHIR-I concur with this so planning can begin? V2 management group, V3 management group are also involved. 

GG: In the FHIR specification terminologies page, there is a long list of Code Systems.   (

The links to "Using xxxx with FHIR" would remain on this page. Users will be re-directed to UTG. 

Some discussion about what to leave on the current FHIR page.

TK: if we leave some code systems on the current FHIR page will be still have things in >1 place? 

GG: there is a challenge where the current page lists groups of code systems, not a single code system

TK: lets move forward and work out the 90%

RM: single repository, UTG process, clean up existing page, address the outliers

RH: will the "Using CodeSystemX" pages remain in the core spec? Why is that the direction? There is no reason they need to be tied to the FHIR spec. Why not just link to them and have them as part of UTG.

RD: those pages represent the effective collaboration of HL7 FHIR and the external terminology. He would like to see standalone IGs published by both organizations. He is leaning towards leaving them in the FHIR spec for now because they would be balloted.

GG: the details of what is in those pages are important for implementation and are outside of what was considered within the scope of UTG. The SNOMED page in particular has proven to be very valuable.

If UTG were to expand to include this information, lots to think about ....

RM: we can't resolve this now but it will be considered while moving forward.

Lenel James (LJ): representing folks who use this list. He supports GG in saying the uri should stay here. Having it in multiple places helps people find it somewhere. Need to transition - leave cookie crumbs.

RD: he is proposing a single authoritative source. part of the reason we have the problems we have is because we have not declared a source as authoritative

JJ: if people need guidance, then the cookie crumbs should be a link to the authoritative source rather than a copy of information

Mary Kay Daniels: (MKD) Amen. Please confirm which tabs we're talking about - it should be the existing External tab only. Why does "External" in FHIR is not external. Some day she would like to be enlightened.

CM: confirmed that all previous discussions have been constrained to the existing External tab only

LM: the urls are exposed in every value set that references a code system, and the expansions and renderings, including example instances. Once the publication happens they are locked. He claims implementers will look at the examples - they will not go to the web pages. It is too burdensome to implementers to follow a link to a web page. The publication process will access the urls from UTG so they should be correct. The publication process might not be checking the information on the existing page. 

RM: there is still a note on terminologies-systems.html about UMLS - there should be a ticket in to address this - 

GG: Moves that the ticket FHIR-27805 be approved and applied   FHIR-27805 - Getting issue details... STATUS  by following the suggested action.

RH: Seconds

Vote:  For:    17  Against:  0  Abstain:  0    

MD: will all this discussion and decisions fix her problem - what to tell implementers creating new CodeSystems under pressure. They are going to let the IGs go and then a project will redo all the terminology artifacts?

Vocab: harmonize the code systems for MD's project and follow the UTG process. 

(note - these were balloted, knowing the terminology wasn't there, tickets were entered, everyone has created their own code systems, each guide moved forward independently. 

GG: HTA has the authority to create urls for external code systems - for all HL7 IGs for affiliates. This might be a process issue. 

LM: what is the maturity level of the IG? the expectation is that you will move to the right external terminologies by level 2. Engaging HTA early in the process is key. It may make sense to publish with a code system that is clearly noted as planned to be replaced. 

RM: maturity level is the key

RM: MK do you have a sense of how many code systems there are and how mature the IGs are?

MK: NUBC revenue codes - they have gotten in hot water with AHA. We have an SOU. They have the spreadsheet in their hands, she has no idea how long it will take AHA to review the information. Carin, PDeX, CDeX are some examples. 

RM: a few code systems that are widely used

MK: yes - for example CPT4 modifiers. We cannot make the stewards move faster.

One guide is for legislation for Jan 1, 2021. It will be stuck.

RM: he senses that MK's situation, immediate need, perhaps needs some further discussion regarding managing the publication process that does not put HL7 at risk. Where do we find the time slot to further discuss? 

GG: MK's issues are complex - copyright, content, etc.

The attendees are trying to figure out how to help this project. We need a time slot.

Time slot discussion: Vocab is free between 1:30 and 3:30 EDT Friday. Or before 10:00 am. 1:30 works for financial management. Carol can attend for HTA.  

CM will add the session officially. Vocab will host FHIR-I and FM - focused on publishing changes to.

GG: requests that MD create a succinct issues list.  

RH: he is joining MD's  call tomorrow 

  • When and error is found in an R4 normative resource such as CodeSystem, how and when to address in both R4 and R5?   (e.g. FHIR-27762 syntax error in the FHIRpath expression in the csd-1 constraint on CodeSystem)

  • The required new code for designationUse have yet been added and cause continuing build errors.  See UTG ticket UP-107
Rob H.Add on to the call scheduled for 1:30 Friday September 25. 

  • Release 2.0.0 of UTG timing
Ted Ran out of time, this will move to a Zulip thread. 


FHIR-13493 - URL description clarification TRIAGED 

  • Remaining CS and VS on FHIR R5 site move - When? How?

Action items

  •  Reuben DanielsWGM 9/2020 Act on this motion: Moves that Reuben create and publish a list of CodeSystems and any referenced ValueSets to be removed from UTG, including a deadline for community review. The communication will include the action to be taken with the CodeSystems in question and the criteria by which they were placed on the list. The communication will include Zulip, FHIR-I, HTA and Vocag listservs.

  • No labels