Skip to end of metadata
Go to start of metadata

Date: 2023-02-21  

Facilitator:  @Nick Radov

Note Taker: @Riki Merrick 


XAnthony JulianMayo Clinic
XUnited Healthcare

XVernetzt, LLC

XVassil PetchevEpic
XMichelle Barry Availity

Create Decision from template

ANSI Anti-Trust Policy:

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

Agenda Outline
Agenda Item
Meeting Minutes from Discussion
Decision Link(if not child)
ManagementQuorum Reached (co-chair + 2) Y/NYes
Management Minute Approval

MethodologyMessageHeader.identifier - do we need it?
    • Relationship between bundle and messageHeader
      • Minimum message is bundle with messageHeader – for a communications ACK
      • You have to make a bundle for each message
      • Batch bundle with entry for each bundle
      • So we should support the bundle.identifier, but no need for a messageHeader.identifier
      • If the snapshot that is the message cannot be maintained in restFUL representation, if you have a purely FHIR server where all resources are stored, so they can be updated – cannot keep the messageHeader resource AFTER the bundle was set
      • So MUST have RESTful persistence of the bundle = similar to V2 messages
    • For intermediaries, when you are forwarding to multiple recipients you should update the bundle.identifier
    • You don’t want to use the for the intermediary to change, because the can be reassigned by the receiving server – that’s why you need bundle.identifier
    • We only need bundle.identifier - left note on zulip
    • Proposal to suggest to remove FHIR messaging from the specification and write an IG in V2 on how to send a FHIR retrieval result message (ORU with RP in OBX-5 to the FHIR resource(s)) see if we get feedback
  • We only need bundle.identifier
MethodologyRequirement for response message in FHIR
MethodologyGender Harmony Block Vote
  • These are jiras that have been approved by Gender Harmony group and need the official vote for V2.9.1 ballot
  • will be sent later this week - for voting on March 7th

MethodologyOpen FHIR tickets
  • FHIR-40264
    • This affects the notifications IG
    • Changes to / sender / responsible
      • We need sender – for many reasons – at minimum for v2-FHIR Mapping from MSH-4
      • How would you reference the task for the purpose of identifying the sender/author/responsible?
      • If messageHeader.responsible and was intended to be used for workflow, then task should be used, but what if that was used for identifying the responsible levels (device / person / role / organization)
      • jira that discusses how to use author, sender and responsible = FHIR-32403
        • proposed disposition is to move messageHeader.responsible to extension
With the content deadline for R5 being 2/24 we need to resolve quickly, if we want to add in R5 - Tony will set up a zulip chat – Riki will review how notifications uses these elements – they are all MUST SUPPORT in the current version of the notifications IG – to know how much impact that would be =


Approve errata and publication request RE: V2.9, V2.9.1 

MSH-6 repeatability.


Management Next agenda

 Adjourned at

Supporting Documents

Outline Reference
Supporting Document
Minute Approval

Approve errata and publication request RE: V2.9, V2.9.1 

MSH-6 repeatability.

Draft errata letter


V2 unresolved issues filter

T Key Summary Assignee Reporter P Status Resolution Created Updated Due

InM unresolved FHIR issues

T Key Summary Assignee Reporter P Status Resolution Created Updated Due

Action items