Chair: @ Julie
Scribe: @ Julie/Carol
H - HTA Member
O - observer
L - liaison
P - present
A - Apologies
|H||P||Julie James||Blue Wave Informatics LLP|
|H||P||Susan Matney||Intermountain Health|
|H||A||Sylvia Thun||HL7 Germany|
|H||P||Carol Macumber||Clinical Architecture|
|H||P||Davera Gabriel||Johns Hopkins University Institute for Clinical and Translational Research|
|L||A||Suzy Roy||SNOMED International|
|O||P||Andrea MacLean||Canada Health Infoway|
|O||P||Ted Klein||Klein Consulting / HL7 UTG / Vocabulary WG CoChair|
|O||P||Rob Hausam||Vocabulary WG CoChair|
|L||P||Rob McClure||US Realm Liason|
|O||P||Carmela Couderc||Vocab WG CoChair|
Minutes of Teleconference 2020-06-10
Motion to accept proposed and accepted.
Meeting Minutes from Discussion
Quorum is met
Motion to approve Minutes proposed
Susan M moves, Roel seconds: Motion 8-0-0
|Topic||External SDO Issues or additional topics||Continuous|
Carol and Suzy Roy
and Sara Armson
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
|Topic||Code system "stub" creation||New||Carol/Reuben|
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)
2) Code System "stub" is created as part of the IG publication process
3) Full blown code system resource
Ended discussion here, will be primary topic for next joint with Vocab
|Topic||Update to new PSS Process||New||Julie/Wayne|
Currently the process has this:
How should the question read? Should we create a pick list based on the external systems listed in vocabulary.hl7.org or the HTA page instead of asking people to list the terminologies?
All external terminologies should be registered with HTA
Picklist of known external terminologies is ideal. When the external terminology is no in the list, they pick other and use free text.
Group feels strongly that we should extend this data capture to NIB.
ENDED CALL HERE
|Topic||When a code system is not a code system||New||Julie|
Discussion of when a code system is not a code system but is a syntax….
|Topic||Discussion with FHIR - Managing change in code system identification||Report||Reuben|
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
- Reuben Daniels create the ISCO-08 Page
- Reuben Daniels to check with Joshua Procious to determine if we can transfer tickets from FHIR or UTG project to the HL7 JIRA project
Julie James will draft a note to co-chair list reintroducing the External Terminologies pages, pointing out LOINC update as an example, seeking feedback on changes and pointing out recent new additions (Dartmouth Health Atlas, ICD10PCS, ISOC-08 etc..)
Caroline Macumber to ping on HCPCS and ICD10CM
- Julie James to create agenda for next joint on 08 July 2020