National Institute of Standards and Technology (NIST)
M
Davera Gabriel
Johns Hopkins University Institute for Clinical and Translational Research
M (CSDO)
Dan Vreeman
HL7 International
O
Ted Klein
Klein Consulting
O
Marc Duteau
HL7 International
O
Joan Harper
Canada Health Infoway
O
John Snyder
National Library of Medicine
O
Rob Hausam
MITRE
O
Alex Kontur
ONC
O
Ravi Kafle
Washington State Department of Health
O
Abdullah Rafiqi
ICF
O
Hope Gray
UAB - Birmingham, HL7 Intern
O
Martha Jones
George Mason, HL7 Intern
Antitrust statement
Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).
Agenda Topics
Meeting was recorded
Agenda Outline
Time Allocation
Lead
Agenda Item
Administrative
5
RD
Rollcall & Proxies
Note that meetings are recorded
Agenda check
Status
10
RD
THO is frozen with release expected prior to 11/6
This release includes a good mix of change requests from the community, external code system updates, and the addition of the CC0 licensing page and link to it from Home page and footer of every page
TSMG voted to increment version to 5.0.0
One issue with the release.
Everything ready on MD's computer.
THO server has been migrated.
MD does not have all the permissions for the new HL7 web site server.
Josh P is looking into the issue. This will not be a barrier to getting the release out as there is enough time.
Note that discussions continue with regards to aligning V2 publication with THO
Great difficulty in understanding what some parties think needs to be done.
Task should be fairly straight forward.
Varying ideas about how code systems and value sets work.
Consensus still not reached and compromise required to move forward.
Taken the word version of Chapter 2C. Scraped content into computable format for comparison with UTG. Should be able to tell everyone the difference between Chapter 2C now and UTG and let people decide where to go from there.
Another aspect: difficult to understand why some parties have little confidence in what is coming from the V2 database.
The V2 database is used to create the source of truth.
The V2 database is complex.
2.9.1 is not published using the FHIR tooling. It uses the same tooling as previous versions of V2.
The source of truth for vocabulary for 2.9.1 is THO. There has been some pushback on this from V2 management group.
Beyond 2.9.1 (V2+), the idea is to maintain the standard as a computable standard.
Going forward V2+ will be produced by tooling and UTG/THO will be the source of truth and may need to be repackaged and re-rendered but will materially be the same.
Whether there is explicit adoption of the FHIR concepts of CodeSystem and ValueSet is hard to come up with a position on. No alignment on this from all members of the V2MG.
RD: Unless this is resolved before the January WGM, we may need a V2MG & TSMG joint session to resolve this.
Proposed wording on Terminology Expectations expected to be complete on next TSMG main call
A publication checklist exists and CMG needs to decide how this needs to change along with any specific feedback in the meeting within 24 hours of Wednesday.
New Business
30
RD
Handling THO anchored content in the FHIR spec FHIR-37440
-
Getting issue details...STATUS
Michael has completed an initial review
Assumption is that resources will share <id> (we know this isn't a rule but we need something to link the resources)
There are 42 code systems anchored in THO that are only in the FHIR core specification
Need to do same analysis for value sets
Assume they need to be moved but would like to finish analysis
There are 72 code systems and 190 value sets that are potential duplicates across THO/FHIR
Continue to discuss how to address changes across the following code system elements:
meta.lastUpdated (all) - not consequential
date (all) - not consequential
url - once moved, should all be anchored in tho
experimental (19) - we assume that all code systems may have been set to false upon moving to THO but this requires verification
title (23)
valueSet (70)
meta.profile (62) - not consequential
description (22)
publisher (18) - not consequential
name (8) - consequential, involve WGs if needed
contact (18)
status (17)
oid (25) - consequential and require cleanup, need to understand how this is happening from Grahame as there are duplicate OIDs across and within THO and FHIR (urn:oid:2.16.840.1.113883.4.642.1.0)
property (1)
hierarchyMeaning (1)
extensions
telecom
standards status
workgroup
fmm
concepts (18) - consequential, involve WGs if needed
Discuss how to address changes across the following value set system elements:
name (29)
oid (5)
status (19)
standards-status (10)
title (63)
description (25)
normative-version (1)
experimental (159)
immutable (123)
compose.include.system (19)
date (180)
extensions
fmm (25)
Goal is to get a list of resources we consider duplicates or easily categorizable fixes (only have non-consequential differences) and then a list of duplicate resources that need to be consolidated/resolved
Grahame can handle the duplicates and WGs will need to be involved in the resources that need consolidation
MF:
No new updates.
Things can be rearranged if more questions come up.
RD: Noting that the freeze for R5 is in February, at our next meeting we should take stock of where things are up to and what our next steps need to be.
Fix the "All HL7 Code Systems" tab to exclude external content
Tracked via
UP-320
-
Getting issue details...STATUS
Two options for approach (listed in comments of ticket)
Third option proposed: change to the IGPublisher manifest file format to support patterns based on the <id> value in the artefacts.
Support for supplement and fragments may already be supported. Need more detail on what specifically may be required to close this.
It would be helpful if the rendering of CodeSystem resources which are fragments, supplements or metadata only, or convenience copies explicitly state this in the yellow box at the top.
