Join Zoom Meeting - https://zoom.us/j/7183806281?pwd=WHVnUUlkWWhhcnRaYk9sWWQyOEkvUT09 | Meeting ID: 718 380 6281 P: 370553
+1 646 558 8656 US (New York) | Find your local number: https://zoom.us/u/aciVC9RrJ6
- Review policy page
Deadline March 30 extended to April 5
Concept Map R5 dashboard: https://jira.hl7.org/secure/Dashboard.jspa?selectPageId=12108#
Marc working with Rob H to complete https://jira.hl7.org/browse/FHIR-28284 and https://jira.hl7.org/browse/FHIR-22129 and https://jira.hl7.org/browse/FHIR-31386 identified as high priority for completeness of ConceptMap tickets.
Marc has made the structure changes, Rob is making build changes.
The build is still not working. There are 3 key ConceptMap related tickets we're looking for. Rob H has not given up.
|CARIN IG for Digital Membership ID|
Vocab signed on as an interested party. Mark Roberts would like to be on a WG call agenda to review. 10-20 minutes.
Ted will create the page for April 15. CC will check with Mark on whether he prefers the beginning or end of the call.
Zulip chat: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/system.20values.20for.20transport.20addresses started specifically about transport addresses, more general discussion about how to support making identifier system identifiers available to the implementer community.
Vocab decided (at the main WG call 3/18/2021) that identifier systems will not be in THO. FHIR has a page for named identifier systems. This has been discussed at length since then, and it the decision has been reversed.
State of the union:
There are CodeSystems in THO that are really identifier systems (mostly from the CoreMIF where there was no such thing as a NamingSystem). There is no element in a CodeSystem resource that lets us know the CodeSystem resource represents an Identifier System.
To support identifier systems, Vocab and FHIR-I have agreed that the following should occur:
Lloyd was invited to attend to help clear up any confusion in the community about identifier systems. A request was entered to add a NamingSystem for an identifier system. Vocab initially responded no due to resource constraints. Further discussions came back around that the current implementation of listing identifier systems on a page in the FHIR spec is not sustainable.
There are around 100 existing identifier systems in FHIR. There has not been any (or very little) engagement with the owners of the identifier systems (e.g. the state of Maine who owns drivers' license number identifier system).
HTA could develop something similar to what is done for external CodeSystems for identifier systems. Carol indicates there is not a resource issue.
Effort required to add this process to THO and to HTA, however this is in competition with the many other issues that need to be addressed to improve the quality of content.
LM points out that when an error is found in THO, a ticket can be entered to address. There is a greater likelihood of new items being established in the right place.
LM: would like to have a statement that identifier NamingSystems do fall into the scope of THO. Creating a tab is relatively simple. We should work with GG to transition the identifier systems that are defined in FHIR into THO - ideally before final version of R5. Longer term, having a specific UTG request type to separate a request for identifier systems from other types of requests.
HTA define a process (addition to HTA charter?) which may be much more light weight than what is required for CodeSystems. Carol proposes that any process is followed with new identifier systems. HTA will work with Vocab/FHIR-I to propose a url pattern and get agreement. This is not required for HL7 to move forward with incorporating identifier NamingSystems into THO.
Jessica Botais pretty far along with the specific request that started this discussion.
In addition to the tasks listed above, we should ask the community if there are any identifier systems hiding in specifications.
Vocab will be responsible to nudge people to get this done.
This is a mini-project to coordinate the FHIR and UTG work.
In what circumstances should there be extensible binding strength in FHIR Core? What are the criteria that define when extensible binding strength is allowed in FHIR Core. More of these have been popping up. The M&M meeting is on Wednesday 3-4 EDT. Rob M. will attend the meeting.
This is not the same as the issue we've discussed in the past about implementer expectations in general with extensible binding strength.
STU3 download package includes FHIR R4 info
We had stated early on that UTG would be a going forward from the old harmonization and way of doing things. Grahame had made up some URLs for v3 and v2 content that FHIR STU3 needed and he agreed that we would go with the new ones for UTG and FHIR F4 going forward.
Ted contends that the suggestion in the ticket is not valid.
Rob M.: is it possible to have a STU3 "version" of THO?
Ted: no, we don't have the content
Rob M.: to support STU3 users, we would have to create versioned artifacts, etc.
Ted: lots of dev work to support
Symptom: uri mismatch between THO and STU3. There are code system uris for existing code systems that only exist in R4, but they show up in the R3 build.
Cause: UTG project scope creep not addressed, focused on R4 (as decided by CTO, TSC)
Ted: suggests removing the second bullet, and updating the text that Note that NPM packages are usually resolved via the FHIR NPM package system, so it's enough to reference these packages in your dependencies without downloading them should be changed to let people know that THO supports R4 and forward.
Rob M: will this work?
Ted: there is no way to build an STU3 view including terminology.
From the download page at terminology.hl7.org
Download the NPM Packages for this version of the HL7 terminology. Note that NPM packages are usually resolved via the FHIR NPM package system, so it's enough to reference these packages in your dependencies without downloading them
Ted will update the ticket with our latest thoughts and follow up with GG. This ticket might not belong in UP. No change to the THO downloads page.
Where do we represent the published code system version in THO? HSLOC. https://terminology.hl7.org/CodeSystem-hsloc.html Internal THO version, but not external code system version.
|Provenance and AuditEvent|
Problems related to the fact that Provenance and AuditEvent are a collaborative effort that has common lineage to DICOM, HL7, ISO and W3C. ValueSests exist with overlapping concepts - not helpful.
John M. started this Zulip thread - related to security. He is asking for Vocab's help to fix the problem.
Ted: we use Provenance in THO - to track changes applied to THO content.
John is bringing up issues that are surfacing and causing problems with other implementation. Suggest that he prepare his material and get on a main WG call agenda. Rob M. sending this message.
New JIRA project
(did not get to this topic)
|Rob M.||Clarify how to set up the JIRA project for existing standards|
Did not discuss
|From LM email|
Must be clean and ready for QA by April 5 for R5 draft. See detail above.
ConceptMap is priority #1. The FHIR tracker call on 3/11/2021 focused on ConceptMap as will the one on 3/25.
https://gist.github.com/lawley/3a59cf669d29a6d62e2948bc51e101a3 Consolidated information from Michael Lawley
https://jira.hl7.org/secure/Dashboard.jspa?selectPageId=12101 Vocab dashboard (CC confirmed tickets in Michael's document are on dashboard)
Using Codes / Selecting a Code System Identifier Text Review
did not discuss
Co-chair review of this text:
Confirm so ticket can be applied.
Decided to talk about this at the 6 pm meeting.
3/1/2021 update: The identifier meeting attendees clarified the target audience for the materials we are creating.
Decided to focus first on getting the diagram up to date - which is for an IG author audience.
Note: the Monday 6 pm ET discussions have been specific to the URL - for use in FHIR. There are other identifiers for the other HL7 product families. This should be managed through UTG. Not only identifiers, but different metadata across the product families. Example?
Once the HTA material is in HTA, the problem will be less. TOOLING REQUIREMENTS - create OIDs for every FHIR terminology
Code System Identifier Deprecation
Did not discuss on 3/15
Discussion from 2/08. 3/15 note: this is now a "to do" item on the policy page
2/15/2021 Update: Vocab needs to define a deprecated identifier policy - the addition of a new publication status code is great, but doesn't solve everything. There is an immediate need to document how to work with the R4 definition before we get to R5. Based on last discussions, implementations can't distinguish between inactive and deprecated by looking at the effective period. TK will update the ticket with his thoughts on this issue. Unfortunately we are time limited. This was pushed to R5.
Governance: (still need a policy)
Deprecated status takes precedence over the validity period.
How to detect deprecated identifiers
Chance for mis-interpretation? Adding deprecated to the status value set does not help the NamingSystem identifier deprecated issue.
Ran out of time.
|External code systems - Canada|
Did not discuss on 3/8, 3/15 or 3/22
Discussion from 2/15: Note from 3/15 - this is now on the policy page as a "to do"
Rob H: get the proposed text integrated into the FHIR specification (in the CI build), and review in context.
We reviewed FHIR-29968 and did not get to the point where we have a text block to propose for the R5 build.
This was discussed at length during Q5 Tuesday during the WGM. Jan 2021 - HL7 WGM - Tuesday Q5 Minutes
See discussion notes from previous co-chair call: 2021-01-18 Vocab Chair Agenda/Minutes
Should we also review the definition of preferred binding strength?
How to distinguish between extensible and preferred?
Did not discuss on 3/15 or 3/22
This is encapsulated in one of the policy statements yet to be defined - in the lower priority section.
Supporting C-CDA FHIR IG
Did not discuss on 3/15 or 3/22
|From WGM. How does C-CDA address terminology quality now that Term Info cannot be referenced?|