Attendance can be found Here

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

Discussion items


Call for additional items


No addtional items noted


Motion to establish HL7 Terminology as the single repository for external code system information.


Background - stakeholders are having a tough time determing what the HL7 recommended process is for using an external terminology in an HL7 prodct. Right now there are 4 different repositories with vary levels of information and accuracy

  • External FHIR tab
  • HTA External Terminologies Confluence Pages
  • OID registry

470+ code systems have been registered in these repositories, with conflicting information

Motion Basis - we can do better. it has been proposed that HL7 move towards a single repository located at Next step, given this joint groups approval would be to seek approval by TSC. If approved, this would require additional governance models within UTG.

Motion - Joint Vocab and HTA recommend the move towards a single repository of information including identifiers, at, about external code systems and their use in HL7 artifacts, . 

Motion by Reuben - Second by Ted, with understanding that details will need to be documented on how this will be implemented.

RM, CM, JS and RB: Friendly amendment accepted by RD and TK - "Vocab and HTA recommend that HL7 create a single maintained authoratative repository of information about external code systems and their use (e.g., copyright and identifiers) in HL7 artifacts at The authority for changes to the repository content rests solely with HTA. Only at the explicit request of a external terminology owner, will the external code system content be included in the respository."

Further discussion: RB - maintenance need to be mentioned, JS - should we add authoratative, BA - code systems and/or value sets?

Vote: 20-2-0 - motion carries

Next steps - Take to FHIR-I and then TSC

RM: The motion will likely require a that is owned by HTA

Related discussion below

Clarifying question - AM - does this mean from the single repositry users will be redirected to me (infoway) as the owner of, say, pCLOCD.

RD - Yes, exactly. HL7 has no interest in being the source of truth host for the code sytem content. It will explain rules and be single place of information for using the content within HL7 products. Thus, a simplification.

RB - HTA pages will be redirected?

RD - Yes, there will be for a time period. Eventually being replaced by the content. 

TK - Information about each external terminology exist in three classes. One of which is a revenue generating location (OID registry). 

  1. Metadata information
  2. Identifier information
  3. ?

RB - OID registry won't go away. There are alot more in the OID registry, not counted in the 470+ as they are completely independent of the HL7 publishing process. Proposed process will include determing what be moved over into the single repositry. The records in the OID registry will be authoratative on the OID only...and then include a link to the single repsositry 

10Code System and Naming Systems in UTGTed

TK: Separating identification from other CS metadata - For every code system in UTG (Contains technical information and maybe content), we must have a corresponding naming system (covers all known identifers and their provenance). The implementation of this must be considered as part of the next steps resulting from the motion passed to create a single maintained authoratative repository of information about external code systems. Ted plans to make a motion to implement the content in this manner. 

No further approval is required from Vocab or HTA (with FHIR-I notification)

10HTA directed changes to external URLsJulie, Carmela, Reuben

Vocab drafted a policy statement, which was discussed as part of Monday's 10 session and HTA's open meeting. As a result of the vocab meeting, agreement was made to seek legal counsel on the IP ownership of Code System identifiers.

As a policy statement, some members of vocab found it difficult to understand the level of pushback, on the best practice. As a workgroup, it is concerning that we back off and be willing to adapt against the wishes (via passed motions) of the community

It is HTA's wish that the relationship with external terminology owners be managed in a respectful, transparent and trustworthy way. 

Many have been contemplative since the monday meeting. SOmething that has not been stated thus far this week...there seems to be a perception that because HTA is declaring an authoritative identifier, via agreement with the external terminology owner...that we are implying that there is an expectation that change occurs in existing implementation immediately. Which is not true.

Many are not comfortable with the IP legality question being the critical point. Change is inevitable and must be planned for...

45 minutes

Switch to HTA Hosting

Policy text for reference:


Identifiers provided by the Code System owner are authoritative, are intellectual property and provide a stable identifier for use in HL7 artifacts.  The authoritative identifier MUST be used for any new use of the Code System - this includes draft specifications as well as renewed or updated balloted artifacts.  If a Code System Identifier is used in a balloted HL7 artifact, and it is discovered that the Code System identifier is not correct, it must be changed when the specification is updated. 

HL7 must provide the means by which updated Code System Identifiers, either declared by the Code System Owner, or as a result of HL7 internal processes, are published and supported.  

How to manage the discussion which has proven to be a challenge so far.

The Vocab policy has been approved and HTA has reviewed.  Policy on Maintenance of External Code System Identifiers (URIs)

Some background about a recent issue related to changing uris.

Swapna: UCUM was developed at Regenstrief by Clem M. and Gunther S. When Gunther left Regenstrief, he took UCUM with him. For the last 10-15 years he has been publishing the spec - it hasn't been updated and the site was sometimes not available. The content of the specification content has been acquired by LOINC however that did not include LOINC needs to create a url they own and control. 

TK: this is a great example of real-world-data impacting technical implementations.

Rob McClure (RM): technical desire to support identifiers in production; does there have to be a technical solution proposed to support the policy to sway folks?

Grahame Grieve (GG): Its reasonable for ucum to be hosted at it would also be good if redirects to The issue is the is in wide use - including references in regulation. Confusion about identifiers and where the content is hosted. Increasing maturity levels impact the ability to make a change. Changing the uri should not be considered lightly. 

Julie James (JJ): Is there any data to back up the cost claims? 

GG: metrics? difficult to put a dollar figure on this - don't have a methodology - 

JJ: there are no expectations that existing data is updated - the policy is moving forward 

GG: is this a useful distinction? Example: Argonaut community, US Core is updating the version, implementers would ideally have a single server that supports old/new implementations - (there is one example where implementers refused to change) - 

JJ: GG, are you saying we cannot separate new/old? 

GG: the cost is increased

JJ: If an implementation is moving from R4 to R4B, is that not a separation?

GG: it is and it isn't

JJ: like fertility?

GG: back to maturity level - later in the process changes will not be made. If we change the ucum url, there will be many ballot comments. 

Davera Gabriel (DG) - there are other examples of code systems where the uri that HL7 has been using is not correct. 

GG: some uris have been changed, others have not (scribe comment: seems subjective)

JJ; the assertion is that its not possible to separate urls - if there is a new Accelerator could they not start using the new uri?

GG: yes they could although this may cause considerable ramifications - socially and creation of non-interoperable content

JJ: mapping exists. 

GG: regulators might be very upset

JJ: might a regulator be concerned with referencing uris that are correct?

Reuben Daniels (RD): thanks GG for attending this call. Interesting points - one of the reasons we use uris is because they are somewhat "user friendly".  Uris can be problematic. Should there be a deprecation cycle introduced for uris? 

GG: its a good idea to have a documented process (note ucum uri is used directly in a datatype). 

CM: HTA can improve their communication to explain that the documented uris do not imply there needs to be an immediate change in implemented systems.

JJ: change management is part of life

Preston Lee (PL)  Uris, urns have clear semantics that have nothing to do with healthcare. Software vendors, content vendors, have these values hard coded  and its difficult to change. 

CM: we need to be clear about when a policy or value reference is to a uri or a  url.  

GG: early on in the process (of ?) there is a question of changing the url, HTA should do an impact assessment.  Some may be ok, others may be very unpopular with the community.

Swapna Abhyankar (SA): the working relationship with the owner of has impacted this specific example. 

TK: unitsofmeasure is a "one-off" and we shouldn't base any process off this case

TK: whatever is done (for will have an impact

Rob Hausam (RH): confirming content owner for ucum - its Regenstrief


JJ: We need a documented process for code system url changes. This will benefit the community. Acknowledges the unique issues with regards to ucum.

(reminds us of RD's comment about using urls to help the community - vs: using OIDs)

CM: Add an action item to outline the key points made in this session - detail specific assumptions and points agreed to in this session (not code system specific)

CM: the policy statement needs to be enhanced to include more detail SOON 

CM: the responsibility is on Vocab to do the work, HTA reviews (until this work is complete - HTA would refrain from publishing url changes/additions)

CC questioned the text in parentheses

TK: artifacts are moving along quickly - its important that new artifacts would benefit from having the most accurate, authoritative url

JJ: we are 7 minutes over

Action items: Vocab to act on CM's suggestions. 

HTA will work with Vocab to get this through as quickly as possible. 

3:54 PM EDTMeeting adjourned

Action items

  •  Caroline MacumberWGM 9/20 add the adjustment to the code system url change policy to a work group conf call agenda

  • No labels