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
P
Ted Klein
Klein Consulting
O
P
Marc Duteau
HL7 International
O
P
Joan Harper
Canada Health Infoway
O
John Snyder
National Library of Medicine
O
P
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
JB
Rollcall & Proxies
Note that meetings are recorded
Agenda check
Scheduling next call
Jess not available for next two Tuesdays to run call (SNOMED Expo travel)
I believe Reuben will also be attending
Get scheduling calls on main TSMG agenda
Status
10
JB
THO release v4.0.0
IG publisher update introduced errors and broken links
1.2.0 and 1.2.1 releases have a clean build
Marc is continuing the release process
Progress continues to be made on integrating automated IG publisher validation into UTG process
Context-sensitive help infrastructure is working
IG Publisher validation of proposed content is working
Working on parsing/comparing errors/warnings of branch to the CI build
Working on automations
New Business
30
JB/RD
Alignment of THO and V2 Publication
Initial import from Frank's database done by consultant
Did not have funding for validation check after import (was able to spot check)
Only took 2.9 release and created FHIR code system and value set resources from the databases
Tables and concept domains had different model mapping
Tables to single code system (V2 tables)
Concept domain mapped V2 concept domains into same model as V3 concept domains, which is also a code system
Legally we needed to remove some content supported in V2/V3 such as NUBC codes
This makes comparing the content more difficult
There have also been modifications after 2.9 publication via THO
We do not have previous versions of V2/V3 content in THO (and no current plan to do so), such as content prior to 2.9
TSMG/V2 need to determine if we want to take the work on to make everything explicit and deliberate so that we define the correct uri through the table property to also be linked in the code system
CodeSystem.valueSet is intended to be a pointer to the all codes Code System, including inactive codes
So there needs to be a different value set that the V2 tables links to
Table content has to include only active codes, so that implies that in every code system which there are inactive codes there will be different value sets
Issue is not isolated to V2
There are tables that include content for more than one code system
Value set connected to table inform codes for table, but if you follow value set to underlying code systems then the implicit value set will point to set of codes which are not the same as in the table because that implicit value set might have additional codes not in the table value set and won't include the codes from the other code system
Generally use naming conventions to make things clear, and the ones used are making it more confusing
Code systems/value sets named after table number
So when you have partial codes, from multiple code systems, or inactive codes, then the names lead you astray
Questions for TSMG:
Do we want to clean up the naming?
Do we want to declare modeling policies for unification?
What will V2 do right now?
Frank is moving forward with publishing entirety of Chapter 2c for 2.9.1 which he believes he has updated with THO changes since its initial publication
Michael may be able to pull it from the Word doc
Plan is to extract content from v2.9.1 and do third party verification of what is there and compare to what is in THO
Ted noted that each release the properties change, table metadata may have changed in addition to terminology content
Need to be able to document what is different in V2 content between db and THO
Ideally should have pointers to content in THO from V2 publication
Redirects are to latest release so changing code system in CI build, the V2 link will still point to published values
DID NOT DISCUSS BELOW
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
Education session for WGM (Monday lunch slot for FHIR committers)
Should be clear about where resources should live
For required bindings, the value set and associated code system should live in the FHIR spec
Subcommittee Work in Progress
15
JB/RD
THO cleanup
These tickets have approval from TSMG to proceed in UTG
Fix the "All HL7 Code Systems" tab to exclude external content
UP-320
-
Getting issue details...STATUS
Add tabs for deprecated content (based on deprecation task force)
UP-321
-
Getting issue details...STATUSDONE
Add subtabs to categorize identifier systems
Add profiles and extensions to THO
List resources by title (currently name) DONE
Execution of Deprecation representation and policy in UTG/THO
