Skip to end of metadata
Go to start of metadata

Date: 20200507 

Facilitator:  Anthony Julian

Note Taker: Anthony Julian


XAnthony JulianMayo Clinic

United Healthcare

Kaiser Permanente
RVernetzt, LLC
X Altarum     
XJonathan WhitbyVital (Canon)

Christopher LindopGE Healthcare

Create Decision from template

Agenda Topics

Agenda Outline
Agenda Item
Meeting Minutes from Discussion
Decision Link(if not child)
Management Minute Approval

MethodologyDavinci Notifications block vote 5

MMS to accept block vote:  Craig Newman // Paul Knapp 

MethodologyUpdate FHIRcast PSS

MMS to change sponsoring workgroup to InM, II as co-sponsor, update objectives/deliverables to align with current calendar  Isaac Vetter // Jonathan Whitby


Craig Newman  will make recommendation  on removing original mode..  Tony will check out the trackers, and make recommendations.

MethodologyGuidance for data sharingThere is discussion in the FHIR spec. defining use cases of messages, rest, documents, etc. 
Management Next agenda

 Adjourned at

Supporting Documents

Outline Reference
Supporting Document
Minute Approval2020-04-23 InM WG Agenda/Minutes
Da Vinci Notifications Block Vote 5

Issue key Summary (Reporter) Resolution

  1. J#26909 Add transfers as a use case (ehaas) Persuasive
  2. J#26285 Provide guidance for error handling (seanmcilvenna) Persuasive
  3. J#26224 The text seems duplicated. Does it make sense to be in this section? (rquintano) Persuasive with Modification
  4. J#26220 "What consists a ""complex content""?" (rquintano) Persuasive with Modification
  5. J#26216 Follow FAST security guidelines (nradov) Considered for Future Use
  6. J#26212 New IG for messaging fundamentals (nradov) Considered for Future Use
  7. J#26211 Endpoint in message Bundle (nradov) Not Persuasive
  8. J#26208 Single Notification for fetal surgery patients (nradov) Considered - Question answered
  9. J#26195 Sensitive data should only be exchanged over secured channels (pknapp) Persuasive with Modification
  10. J#26192 Clarification required (pknapp) Considered - No action required
  11. J#26178 ValueSet Tree Holes (ginocanessa) Not Persuasive with Modification
  12. J#26164 Add Section on batch transactions and bulk data (ehaas) Considered for Future Use
  13. J#26156 make timestamp mandatory (craig.newman) Persuasive
  14. J#26147 fix labels (craig.newman) Persuasive
  15. J#26139 Security for sender sending endpoint (Isaac.Vetter) Persuasive with Modification
  16. J#26135 Flesh out the Security page. Use SMART Backend Services. (Isaac.Vetter) Considered for Future Use
  17. J#26134 Use SMART Backend Services. (Isaac.Vetter) Persuasive with Modification
  18. J#26106 immature resources (Brian_Pech) Persuasive with Modification
  19. J#26103 Why Messaging1? (Brian_Pech) Persuasive with Modification
  20. J#26098 Why Messaging? (vassil) Persuasive with Modification
Update FHIRcast PSS

(Original word doc version - may not be exactly the same as published PSS)

Does the Next Milestone need to be manually kept up-to-date?

Proposed modifications:



Deliver draft specification for connectathon testing - Target: December, 2017
Connectathon testing - Target: WGM: Jan, 2018
Submit for STU Ballot (First Ballot Cycle) - Target: May 2019 Ballot
Reconcile STU ballot - Target: May 2019 WGM
Publish STU - Target: Sept 2019
Submit for STU Ballot (Second, targeted Ballot Cycle) - Target: Feb 2020 Ballot
Reconcile STU ballot - Target: Feb 2020 WGM
Publish STU - Target: Jun 2020
STU Period - 18 months - Target: Jun 2020 – Jan 2022

Submit for Normative Ballot - Target: Feb 2022 BallotReconcile Normative Ballot - Target: Feb 2022 WGM
Publish Normative specification - Target: May 2022
Project End Date (all objectives have been met) - Target: Sept 2022 WGM

Application ACKing
  • ACKing query messages (see email from Craig on 4/17)
  • We were discussing a topic on the v2 Management Group call that we think we need InM input on.

    In original mode, is it valid to send an immediate Ack in response to the query response (which itself is the application Ack to the Query message)? Is there a difference between original mode for a query message and original mode for a non-query (like an ADT message where the application Ack is an ACK message type or an order message where the application Ack is a unique (non-ACK) message type)? Does the synchronous/asynchronous nature of an implementation make a difference?

    We saw a number of different patterns in different chapters:

    In Ch for the RDY^Znn^RDY_K15 where the Acknowledgement Choreography table doesn’t contain Application Ack message type.

    In Ch 4A.3.12 for the RRG^O16 where an immediate Ack is given (albeit with a typo) for the RRG^O16 response message (the RRG^O16 is the application Ack to the RGV^O15 message)

    In Ch 7.3.13 for the ORA^R41 where an application Ack is given for the ORA^R41 response message (the ORA^R41 is the application Ack to the ORU^R40 message)

    In Ch 3.3.1 for the ACK^A01 where there is neither Ack type even though the ACK^A01 can function as both an immediate Ack and an application Ack to the ADT^A01 message

    We are curious if this variation is intentional and driven by the message type and the nature of the exchange between systems or if there was just variability in how different WGs implemented the Ack Choreography tables.

Ralf-s response:

not Forwarding Ralf's response regarding the ACK Choreography. 

I will be out this week - I had an unfortunate encounter with a 2x6, courtesy of my horse :( and am nursing aome broken ribs and facial bones.

Hope to be back next week.


---------- Forwarded message ---------
From:  Ralf Herzog
Date: Tue, May 5, 2020, 2:37 AM
To: Ulrike Merrick

Hello Riki

I am not sure if I understood your question correctly, but I try to answer what I understand:

You want to know if there exists a use case for application level Acknowledge in response to an application level Acknowledge - do you mean an App Ack as answer to an App Ack which was the answer to a Request? 

In Chapter 13 yes - the question here is IMHO if this is a good and correct use case. 

I would argue that the correct way (based on how I understand the HL7 Ack idea) would be the following:

  • "Decoupled" mode (analog to the QBP^Q11 - RSP^K11 LAB-27 Request and the OML^O33 -  ORL^O34 LAB-28 Order Response):
    1. ESR Message with neither MSH-15 and MSH-16 set to NE
    2. ESR triggers an Immediate Ack
    3. ESR also triggers an Application Ack which would be the ESU message.
    4. ESU Message with (at least one of) MSH-15 and MSH-16 not set to NE  would trigger an ACK^U01 message.
  • "Coupled" mode (analog to the QBP^Q11 - RSP^K11 of LAB-22):
    1. ESR Message with MSH-15/-16 either empty or (MSH-15 == NE, MSH-16 == AL would trigger an ESU Message.
    2. ESU Message with MSH-15/-16 should only be MSH-15 == NE and MSH-16 == NE, else we would get either an Application Ack or an Immediate Ack (which both would be an ACK^U01^ACK Message).

BUT the the standard allows also an Application Acknowledge to an Application acknowledge. Here the message flow:

  1. You sent a request message (i.e. Equipment State Request, ESR^U02, with Application Ack enabled (either Original or enhanced mode)
  2. You might get an immediate Ack (ACK^U02) - (only in enhanced mode if MSH-15 is not NE.
  3. You get an ESU^U01 as answer (if MSH-16 is not NE - BTW: MSH-16 set to NE IMHO does not make sense)
  4. You might sent an application level Ack (ACK^U01, if  MSH-16 is not NE 
  5. You might sent an Immediate Ack (ACK^U01 if MSH-15 is one of (AL, SU, ER). 

All the best


  • Review of new gForge issues
Guidance for data sharing

Matrix: Data Sharing matrix

 Data Sharing Google document

Data Sharing Decision Tree

Action items