Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date: 2023-02-21  



@Nick Radov

Note Taker:


@Riki Merrick 


XAnthony JulianMayo Clinic
XUnited Healthcare

XVernetzt, LLC

XVassil PetchevEpic
XMichelle Barry Availity

Create from template
title@currentDate InMDecision
buttonLabelCreate Decision from template


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