Teleconference 2020-06-24 Joint with the Vocabulary WG

Quorum

Minutes Approval

Quorum is met

Motion to approve Minutes proposed

Susan M moves, Roel seconds: Motion 8-0-0

Apologies from Suzy

GPS will be updated against the June SNOMED International release, releasing in September. Volume is less than 200 new additional concepts. 

LOINC has updated their license, which triggered an update to the LOINC Ext Terminologies page managed by HTA

Support of implementer community process for creation of code system "stubs" and expected interaction with HTA"

Overarching question - Who has the official responsibility of governing the creation of these external codesystem stubs?

TK - Technical limitations of current tooling play a part here. Danger in establishing policy around these limitations...while there is also an issue with establishing policy that are not implementable. In the context of UTG, "Code System Stubs", we need a valid technical identifier from a codesystem to publish IGs. Whether or not we render the content from the codesystem is irrelevant. Both naming system and empty code systems ("stubs) were created in UTG to connect data field to idenity of a value set and then the code system. Right now we have both a naming system and coding system, but only until a firm decision is made. Paramaters that influence this - no capability in standard to have canonical URI of a namingsystem resource be in a valueset.compose statement. Personally agnostic in which we use. 

Historically this has differed by product, with vocab harmonization playing a role in fielding requests to create code system stubs (identifier to be used in HL7 publications, along with any known metadata). In V3, this was the OID. In FHIR, this is the URL.

RM - There is a large tasks to clean up stubs that were created in the past, that no longer meet the requirements/ bar for code system resources

TK - to get publishing working (siting a code system, or referencing one via a value set), the code system resource is required. There is a light way process that enables users at connectathons to create code system resources, when it moves to a higher maturity, there is a tight governance process. In fact, the processes are gradated from draft to normative. 

RH - FHIR specification vs IG publication requirements differ. Most don't need the actual code system resources, but rendering "nicely" does require them.

JJ - Does that mean instances of code system resource go through maturity model?

TK - Not exactly, internal HL7 code systems DO go through maturity level. For external code systems, no, they do not. When external code system identifiers are used today, the underlying terminology service must support the code system for the references to resolve. The TS utilized by the IG Publisher support most, but not all, of external code systems. 

In a context of IG publishing, external code sytsems can be used in three ways:

1) Known canonical URL for the code system, no other additional information provided. Codes may or may not be included in IG (X12 as an example)

• IG publisher meets this use case today
• Additional governance may be needed here - external entity that is FHIR enabled that is referenced

2) Code System "stub" is created as part of the IG publication process

• Additional metadata is provided when compared to #1
• Governance can guide the minimum requirements for these stubs

3) Full blown code system resource

• Governance can guide minimum requirements for the resource, better known boundaries exist

Ended discussion here, will be primary topic for next joint with Vocab

Discussion of when a code system is not a code system but is a syntax….

Also FHIR Vocabulary Binding for Authors

Agreement was reached that one central place must be designated for management of external code systems, and Austin, Wayne, Grahame and Reuben all agreed that UTG was the correct place. However, there are issues with external code system content in the first content relase of UTG, and those need to be addressed before additional content can be migrated (including existing FHIR non-ballot bound terminology).

Need to start here at next meeting

Call adjourned at zz.zz BST