Skip to end of metadata
Go to start of metadata


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

Date

Attendees


Regrets 

Goals

Discussion items

TimeItemWhoNotes

R5 Priorities

Progress made for NamingSystem tickets this past Thursday 

R5 dashboard showing applied tickets so far: https://jira.hl7.org/secure/Dashboard.jspa?selectPageId=12108#  

R5 ConceptMap Dashboard:  https://jira.hl7.org/secure/Dashboard.jspa?selectPageId=12101     (13 remaining tickets)

R5 NamingSystem Dashboard: https://jira.hl7.org/secure/Dashboard.jspa?selectPageId=11803    (2 remaining tickets)

R5 CodeSystem Dashboard:  https://jira.hl7.org/secure/Dashboard.jspa?selectPageId=11804        (17 remaining tickets)

R5 ValueSet Dashboard:  https://jira.hl7.org/secure/Dashboard.jspa?selectPageId=11510    (at least 58 remaining tickets) 

Vocab - no resource:  https://jira.hl7.org/secure/Dashboard.jspa?selectPageId=11806    (85 remaining tickets)



tx.fhir.org

Transparency of documentation


Publish code system update schedule?

 Marc D. obtained a list of all CodeSystems on tx.fhir.org. We need to be able to generate this list on demand and relate it to CodeSystem update schedules?  We have to be careful because there isn't much funding to keep CodeSystems up to date here. 

Rob H: we could publish general expectations about major CodeSystem updates. Others are updated on request - its not well known that this is the process. Rob H. will write this information. 

Reuben D: it comes down to transparency, and openness to the community. At some point HL7 will have to get a proper SLA to maintain this server. Ted notes there will be financial impacts. 

There is some question as to the source of the CodeSystem list. Rob H. will follow up with Marc.

Ted mentioned that the publisher gets terminology from 3 or so places to create an IG. tx.fhir.org is one source, but it is the last source. A patch has been put in to look in tx.fhir.org first for CVX (patch)


ConceptMap - normative track?

Recent FMG email listed ConceptMap as a potential for normative track in R5. 

Rob H.  GG doesn't think that the maturity level should have been decreased, and during the last meeting, people did not disagree with him. However the vote by Vocab was to reduce the the maturity level. FMG feels that Vocab misinterpreted the rules of assigning maturity levels.

ConceptMap is used in the FHIR Core spec, and in other implementations (e.g. Ontoserver). The argument for not lowering the maturity level is that people learned from the more immature resource, and are on track (or at least aware of the changes) to adopt the R5 version. 

ConceptMap is the only conformance resource that is not normative. RD noted that NamingSystem is not normative and it is a conformance resource. Note - NS is not one of the R5 normative candidates. http://build.fhir.org/conformance-module.html

Rob M: FMG is aligned with R5 ConceptMap definition, and it won't change going forward, must be behind the proposal to consider CM for normative. 

How should Vocab respond to Lloyd's email where CM was listed as a potential normative R5 resource.

RD: respond to the email with information that it will not be normative in R5, and if they would like to discuss, please contact Ted to join the agenda on one of the main WG calls. RH will do this. 



May 13 co-chair call

Conflict with Vocab Main WG call

We will meet for 30 minutes, attend the co-chair call for 60, and come back to the Vocab call.



CodeSystem Identifier Task Force

Status:  diagram in a good state. Next steps to bring start communicating and putting decisions into action.

  1. Team has suggested a separate, focused webinar
  2. See notes here:  2021-04-19 Vocab Special Topic Agenda/Minutes

WorkflowStatusDescription

Motion accepted for ValueSet - others?  NamingSystem identifier, CodeSystem, ConceptMap

Rob M: WorkflowStatusDescription is an extension defined for ValueSet, and it has been agreed that this will be used to reflect the "usability status" - reflects a sub-status. This would be a modifier. 

Rob H: this could be elevated to a Core extension. Rob M: suggests we just defined the extensions where we need them. Some key values: Deprecated, NotMaintained. 

  • ValueSet (versioned instance) possibly some implications for naked expansions
    • Would not be able to "deprecate" a ValueSet without deprecating all versions
  • CodeSystem
  • ConceptMap
  • Less likely
    • NamingSystem  
    • NamingSystem.identifier

THO is using a set of properties for concepts that might have some impact on the NamingSystem info. 

Proposes that we take that same extension and make it so we can use in all resources. 

Ted mentioned that he had been in discussions with GG previously, and there are issues with extensions being rendered in IGs (THO has encountered this and it is impacting usability)


New JIRA project 

Kind of covered on this call

Rob M.

Clarify how to set up the JIRA project for existing standards

We need to get this settled. We will continue to collect on Confluence (low volume). Rob M. has asked Marc to look into this. There is probably a series of tasks to do, and then we won't have to do them again. Gender Harmony and VSD. 


O&O lab short term suggestions on how to exchange SOGI



Sexual Orientation, Gender Identity, Administrative Sex, Birth Sex etc

Scheduled for Q1 Tuesday at WGM - confirm

We need to integrate Gender Harmony specifications into the product families - this has started due to California request to get SOGI data through labs. Integrating moderately detailed information into the spec to answer questions. By the end of the WGM there should be a publishable version. The existing Gender Harmony project will be adjusted. PC and O&O will meet with Vocab to move forward - V2 and FHIR. SD joint session might cover this as well.



Identifier Systems



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.

Project status? 

4/26/2021 status:

We have a recommendation that the NamingSystem.title is equal to CodeSystem.title when there is a CodeSystem. Same for NamingSystem.name and CodeSystem.name.

Ted is waiting for work underway by Reuben. Once this is ready, they will work together to make the changes in THO. 

IdentifierSystem support tickets added as part of action items from 2 weeks ago.

HSCR-138 - Getting issue details... STATUS     Add support for Identifier Systems in THO  - details on text for descriptions and tab names included here. 

HSCR-135 - Getting issue details... STATUS      Evaluate Identifier System support in THO - this ticket should be closed or deferred 

HSCR-139 - Getting issue details... STATUS      Add Identifier Systems to UTG in bulk

FHIR-31706 - Getting issue details... STATUS    Add NamingSystem extension to support Identifier System sub-type

Remaining action items:

Vocab will be responsible to nudge people to get this done.

  1. As part of prep work required for HSCR-139, Rob M. volunteers Marc D. to work with Rob H to create the artifact for bulk update into THO and to create the UTG ticket.  CC sent an email to co-chairs and Marc to remind them of this effort. 
  2. Remove the identifier systems from the FHIR page (GG)
  3. HTA stuff (Carol)
  4. Identify V2 and V3 identifier systems that have been defined as CodeSystems need to be addressed  
    1. Some of these exist  CodeSystem resources without a NamingSystem but some do have NamingSystems
    2. This is a mess, and someone will have to figure out 
    3. Vote on and apply FHIR-31706 added to address this: V2 identifier systems are sub-typed that will most likely require an extension https://www.hl7.org/fhir/v2/0203/index.html#SB
      1. This sub-type is important information for implementers (the FHIR identifier datatype has a system, value, and type. The type is the "subtype" mentioned above. ) 



Extensible Binding and upcoming recommendation to change CodeableConcept binding strength to preferred. 

not discussed on this call



Rob M. report from the M&M meeting. 

FHIR-29968 - Getting issue details... STATUS

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.


NHSN

not discussed on this call



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

not discussed on this call



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. 

Action plan? 

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. 






Using Codes / Selecting a Code System Identifier Text Review

did not discuss


Co-chair review of this text:

Updated text for Using Codes / Selecting a Code System Identifier

Confirm so ticket can be applied.  Ticket was applied for R5 draft. 

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.  

  1. implementers
    1. implementers should just use what is in the spec
    2. Rob H. contends that the FHIR spec should only have information for implementers, even though it has information for IG authors now. 
    3. If thats the case, then any information about how to obtain a code system URL might not belong in the spec
  2. IG authors
    1. responsible for making sure the spec has the right code system and value set identifiers


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 

not covered on this call


Discussion from 2/08.  3/15 note: this is now a "to do" item on the policy page

  1. Code System Identifier Deprecation  
    1. See notes here: 2021-01-18 Vocab Chair Agenda/Minutes
    2. See notes here where the group was reaching consensus:  Jan 2021 - HL7 WGM - Thursday Q3 Minutes
    3. FHIR-30319 - Getting issue details... STATUS  voted to move out of R4B to R5, define a policy related to deprecated 
    4. FHIR-31028 - Getting issue details... STATUS   create a new concept in Publication Status value set = Deprecated  
      1. https://www.hl7.org/fhir/valueset-publication-status.html 
      2. Add a new concept to the CodeSystem, change the existing definition to be the existing enumerated list. Make a new ValueSet that is enumerated list + deprecated 
      3. 4/5/2021 update: Rob M will bring this issue to a FHIR-I call
  2. Deprecation applies to
    1. CodeSystem Identifier
    2. CodeSystem resource
    3. ValueSet identifier
    4. ValueSet resource
    5. Concept Map resource
    6. Status:
      1. V3 and V2 ValueSets support deprecation in the work flow, FHIR does not as a status
      2. V3 and V2 ValueSets do not support Draft, whereas FHIR does 
        1.  Candidate for unification/harmonization
    7. FHIR inconsistently defines workflow status (e.g. review, approve) - sometimes in the Resource, other times depending on Provenance

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.  

FHIR-30319 - Getting issue details... STATUS

Discussion 2/22/2021:

Governance: (still need a policy)

Deprecated status takes precedence over the validity period.

How to detect deprecated identifiers 

  1. Deprecated = true
  2. Validity period end = past date

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

Extensible definition

not covered on this call



Rob M.

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.

Rob M:

  • Example value set expansion: Red, Blue, Green, Yellow
    • Someone wants to communicate Magenta. Is this a type of Red, or is it something different? In SNOMED, magenta would be a sub-type of red.
    • Extensible is intended to be guidance for implementers for what to support.
      • It is allowed to send a code that is in a more recent expansion/version of the bound value set.
      • See #4 in the comment of the JIRA.  This is problematic. 
      • It is acceptable to have a new value set version or a new value set that is claiming conformance to the original extensibly bound value, where an expansion has a concept that is a descendant of the original extensibly bound value set expansion
        • Want to explicitly add magenta to the expansion - either a new version of the original value set or a new value set and claim conformance. 
        • #4 as written doesn't allow this.
    • An implementer might decide to add magenta to their value set because their use case needs it. Conceptually, there is a new IG that has a new ValueSet.  
      • This is really obvious when a different CodeSystem is in play
  • Ted: Extensible could be viewed as ideally you would make the value set required, but you know there are use cases that you can't possibly know about, and want to allow implementers to send something not in the value set when necessary. 


.   FHIR-29968 - Getting issue details... STATUS

Policy on the use of extensible value set bindings

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?



CPT4 Syntax

not covered on this call



https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Combine.20CPT.20codes


This is encapsulated in one of the policy statements yet to be defined - in the lower priority section.


Vocabulary Work Group Policy Statements


Supporting C-CDA FHIR IG

not covered on this call



From WGM. How does C-CDA address terminology quality now that Term Info cannot be referenced?  

Action items

  •  
  •  
  •  
  •