Skip to end of metadata
Go to start of metadata

Chair:  Craig Newman

Scribe:  Riki Merrick

NOTE: This attendance applies if you are present at the related meeting/call, regardless if you have signed a different attendance for your WG. 






Craig Newman


Frank Oemigv2MG

Tony Julianv2MG
XRiki Merrickv2MG

Elizabeth Newtonv2MG

Amit Popat

XNick Radovv2MG
XRob Snelickv2MG
XLynn LaaksoHL7

This is a Friday morning call

Agenda Topics

Agenda Item

Meeting Minutes from Discussion

UDI publication request
  • Reviewing the comments we had from last review
    • In appendix they changed “mappings” to “definitions”
    • Line 312 – corrected 5 to 6 – this is a technical correction (do we worry about the correct name of those elements? – no that is just narrative, so should be ok like this
    • Introduction: would like to reference DAM, but that is not yet published, so will do that once DAM comes out in next version
  • Motion to approve the publication request Riki Merrick, Nick Radov, no further discussions, abstain: 0, against: 0, in favor: 3
  • Craig will let Marti know
v2.5.1 ADT in CMS Final Rule
  • 5.1 ADT in CMS final rule
    • Mentioned
    • Patient admit notices to other providers, but the actual mechanism is not named, so not sure what that means
    • didn't see much else that affects V2 Management
ACK Choreography issue email review

These changes don’t seem to be the same as the typos we have been dealing with, but we will review them (email text in bold italic):

  • 4.6.2 - QBP^Z73^QBP_Z73 - There is an application ack specified in a column where MSH-16 is 'NE'


      • This needs review as to why there is NO column for MSH-16 in enhanced mode, that allows use of application ACK
      • Ch. 4.16.4 - This one is due to the omission of a caret: ACK^O41ACK to ACK^O41^ACK
        • Lynn will fix that

  • 16.3.12 table for QBP^E22^QBP_E22 -- different message type (RSP^E22^RSP_E03) when MSH-16 is 'AL, ER, SU'


    • Send this to the chapter author, we think it is most likely a copy/paste error

  • Ch.2.5.6 indicates that the example is in section 2.12.3.  It is Ch.2.12.2.


      • There is NO section 2.12.3, so that looks like a typo – Lynn will fix to point to 2.12.2 (update field)

  • Error - Ch.2.12.2The first sentence of the second bullet point is 100% wrong. The table is correct and shows that the opposite is the case.

Citation form v2.9:

  • When MSH-15 is AL(Always)and MSH-16 is NE(Never) no immediate ack is returned. When MSH-15 is Never, and MSH-16 is AL, the receiver is expected to only return an WRP application acknowledgment on a separate communication channel. See section
  • When MSH-15 is Always, and MSH-15 is Always, the receiver is expected to return both the transport ACK as well as the WRP application ack. The immediate ACK will return on the current channel, and the application acknowledgment on a separate communication channel. See


      • MSH-15 is AL and MSH-16 is NE, immediate ACK is always returned – remove the “no”
      • Need some spaces around the () elements – Lynn already fixed that
      • Add the word section before the reference (and does section need to be capitalized?) – keep for v2+
      • Re-organize these 2 bullets in V2+
      • Updated section to use: “Section 2.12.2
        • When MSH-15 is AL (Always) and MSH-16 is NE (Never) an immediate ack is always returned. When MSH-15 is NE (Never), and MSH-16 is AL (Always), the receiver is expected to only return an WRP application acknowledgment on a separate communication channel. See section
        • When MSH-15 is AL (Always), and MSH-16 is AL (Always), the receiver is expected to return both the immediate ACK as well as the WRP application ack. The immediate ACK will return on the current channel, and the application acknowledgment on a separate communication channel. See section

  • In general, the example's coupling of the MSH-15 and MSH-16 values perpetuates the notion that there is some interaction between those values that dictates what acknowledgement messages are sent.  In actuality, they are completely independent.  The sending of immediate ack messages is determined solely by the value of MSH-15 and the sending of application ack messages is determined solely by the value of MSH-16.


      • Re-organize these 2 bullets in V2+, Craig entered gForge#25234

  • Error - When I look at Ch.3, I see that there is an Acknowledgment Choreography (AC) table after each message definition. The message definitions are paired as message:ack-message, where each one is followed by an AC.  When I look at the AC for ADT^A01^ADT_A01, I see that the application ack in original mode is ACK^A01^ACK.  This makes sense to me.  When I look at the AC for ADT^A02^ADT_A02, I see that the application ack for original mode is ADT^A02^ADT_A02.  This does not make sense to me.  We are ack'ing with a message that isn't an ACK message and, it would seem, we would end up with a never-ending loop of ADT^A02^ADT_A02 messages.  Browsing through Ch.3, it appears that all of the messages except for ADT^A01^ADT_A01 list the same message type as the application ack in original mode. Franks has indicated that this is an error.


      • Agree this is an error – refer to chapter authors – needs to be handled by errata
      • gForge ticket 25239 created


  • Error? - Ch. 14.3.2, the first AC table includes a column where the values for MSH-15 and MSH-16 are 'N/A'.  No other table includes this.  'N/A' is not a valid value for those fields.  The 'N/A' column just makes no sense within the context of all other AC tables.



  • Error - In Ch. 14.3.2, the second AC table looks odd. The only column for enhanced mode lists 'AL, SU, ER, NE' for the value of both MSH-15 and MSH-16 and no ack messages are specified.  If the intention is that an ack is never sent in response to an ACK^N02^ACK message then it follows that the only valid value for MSH-15 and MSH-16 is 'NE'.


      • We should state that more clearly in section and
        • Found some typos there – double period after “empty” in both and missing a period after “message” in section – Lynn will fix the Typos
        • Will defer to V2+


  • Possible Errors - There are a number of AC tables where, for MSH-16, the only value that appears is 'AL'.  This implies that, in all cases, an ACK must be sent and that 'NE' is never a valid value for MSH-16.  A number of the AC tables in the following list have the additional characteristic (i.e. error) that despite the MSH-16 value always being specified as 'AL', no application ack is ever specified.  These tables are noted with a red asterisk (*).These messages are:
    • Ch. - QBP^Z99^QBP_Q13
    • Ch. - QBP^Znn^QBP_Qnn
    • *Ch. - RTB^Znn^RTB_Knn
    • Note the row for Application Ack is missing in this table.
    • *Ch. - RDY^Znn^RDY_K15
    • Note that this AC table (as well as the message definition) are defined again in Ch., which seems quite odd.
    • *Ch - RTB^Znn^RTB_K13
    • Ch - QBP^Znn^QBP_Q11
    • *Ch - RSP^Znn^RSP_Znn
    • Ch. 5.4.1 - QBP^Q11^QBP_Q11
    • *Ch. 5.4.1 - RSP^K11^RSP_K11
    • *Ch. 5.4.2 - RTB^K13^RTB_K13
    • Ch. 5.4.3 - QBP^Q15^QBP_Q15
    • *Ch. 5.4.3 - RDY^K15^RDY_K15
    • Ch. 5.4.4 - QSB^Q16^QSB_Q16
    • *Ch. 5.4.4 - ACK^Q16^ACK
    • Ch. 5.4.5 - QVR^Q17^QVR_Q17
    • *Ch. 5.4.5 - ACK^Q17^ACK
    • Ch. 5.4.6 - QCN^J01^QCN_J01
    • *Ch. 5.4.6 - ACK^J01^ACK
    • Ch. 5.4.7 - QSX^J02^QCN_J01
    • Ch. 11.3.1 - RQI^I01^RQI_I01
    • Ch. 11.3.2 - RQI^I02^RQI_I01
    • Ch. 11.3.3 - RQI^I03^RQI_I01
    • Ch. 11.3.4 - RQP^I04^RQP_I04
    • Ch. 11.4.1 - RQA^I08-I11^RQA_I08
    • Ch. 11.5.1 - REF^I12-I15^REF_I12
    • Ch. 11.7.1 - CCQ^I19^CCQ_I19
    • Ch. 11.7.2 - CCF^I22^CCF_I22


  • From a query shouldn’t you ALWAYS get some kind of application ACK – since that is the whole point of a query, to get a response?
  • Is the query response considered an application ACK?
  • If so, then yes, else what is in the application ACK? – defer to INM
  • What is the difference between a query and a request message? – defer to INM


  • Error? - Ch. 11.3.7 has an usual AC table.  It is the only place where a value of only 'AL' is found for MSH-15.  In all other cases, the values for MSH-15 are either 'NE' or 'AL, ER, SU'.  If this is not an error, this table implies that only 'NE' or 'AL' are valid values for 'MSH-16'.  The table also implies that the only valid value for MSH-16 is 'NE', i.e. that there are no conditions for which an application ack is sent.


      • Looks like you cannot send an Application ACK – defer to FM / chapter editor

Next steps:

    • Continue this level of review to find the typos and delay the publication of the technical corrections – below not discussed today – for next call:
  • An observation -- In Ch.3, the AC tables following ACK message definitions indicate that, in enhanced mode, an ACK should be sent in response to an ACK if the first ACK had a value other than NE for MSH-15.  This leaves open the possibility of an ACK loop.  I'm assuming that the V2 standard assumes that implementers are smart enough to not do that.  Is that correct?
  • Observation and question -- When I look at Ch.4, there is not an ACK message defined in each event (so, different than Ch.3).  The AC tables indicate responses with other types of messages, which seems perfectly OK.  However, whenever I see an ACK message specified in an AC table in Ch.4, that message appears to not be defined anywhere, in any chapter.  That happens for all messages named ACK^Onn^ACK.  I assume that this implies that these messages are the same as any of the other identical ACK messages?
  • Observation - There are a lot of AC tables where the only value for MSH-15 is 'NE'.  This implies that there are a lot of cases in enhanced mode where an immediate ack would never be sent.  No problem, just interesting.
  • Question -- In figure, System B includes the text, "FAILURE SEND NACK".  What is "NACK"?  It isn't defined anywhere in Ch.2.
  • Question -- That leads me to the repeated definition of the same ACK message with different names.  See below for a list of 101 differently named messages that appear to be otherwise identical ACK messages.  Is there any reason to maintain separate definitions of all of these different ACK messages?  I understand why there may be a need to maintain all of the names of the otherwise identical ACK messages, but perhaps we can accomplish that by using aliases or adding an attribute to FHIR EventDefinition that specifies the context specific name of the ACK message?
  • 3
    • 3.37 - AC table for ADT^A37^ADT_A37 lists an undefined message as application ack in original mode: ADT^A37^ADT_A15
    • 3.38 - The random characters 'st' appear between the message definition table and the AC table.
    • 3.59 - AC table for QBP^Q24^QBP_Q21 lists an undefined message as application ack for enhanced mode: RSP^K24^RSP_K24
      • Also, one cell has a typo: RSP^K2^4^RSP_K24
    • 4A
      • 3.16 - AC table for RDE^O25^RDE_O11 lists an undefined message as application ack for enhanced mode: RRE^O26^RRE_O26
    • 5 - many messages with no AC table
    • 7
      • 3.13 AC table has blank cells where it should have cells containing '-'.
    • 10
      • 3 - AC table immediate acks are listed as ACK^S10-S11^ACK , which appear to be incorrect and should probably be ACK^S01- S11^ACK
      • 3 - AC table application acks are listed as ACK^S10-S11^SRR_S01, which appear to be incorrect and should probably be SRR^S01-S11^SRR_S01
    • 11
      • 5.1 - AC table for REF^I12-I15^REF_I12 specifies RPI^I12-I15^RPI_I12 as the application ack message.  This message is undefined.  I am assuming that this is a typo and should be RRI^I12-I15^RRI_I12 since that message definition appears immediately after
    • There is a stylistic inconsistency for AC tables that correspond to a MessageDefinition table that defines multiple messages.  In some cases, the title message in the second row of the AC table corresponds to the first message that the message definition table defines and in other cases it corresponds to a collection of message definitions.  An example of the first case is the message definition for CRM^C01-C08^CRM_C01 in Ch. 7.7.1 where the AC table lists the message as CRM^C01^CRM_C01.  An example of the second case is the message definition for SIU^S12-S24,S26,S27^SIU_S12 in Ch. 10.4 where the AC table lists the message as SIU^S12-S24,S26,S27^SIU_S12.  In this case, the AC table would list SIU^S12^SIU_S12 if it were following the pattern of the first case.
      • Where message definition tables exist that cover multiple message definitions (as is the case here), I have been splitting these into individual message definitions for V2+.  When this happens, I am replacing the
        AC table values for any ack messages that also corresponding to a span of message definitions with values that correspond to a single message definition. For example, in an AC table for the XYZ^X05^XYZ_X05 message, I would replace ACK^X01-X09^ACK with ACK^X05^ACK.

Identical ACK Messages

ACK^A01^ACK: General Acknowledgment
ACK^A02^ACK: General Acknowledgment
ACK^A03^ACK: General Acknowledgment
ACK^A04^ACK: General Acknowledgment
ACK^A05^ACK: General Acknowledgment
ACK^A06^ACK: General Acknowledgment
ACK^A07^ACK: General Acknowledgment
ACK^A08^ACK: General Acknowledgment
ACK^A09^ACK: General Acknowledgment
ACK^A10^ACK: General Acknowledgment
ACK^A11^ACK: General Acknowledgment
ACK^A12^ACK: General Acknowledgment
ACK^A13^ACK: General Acknowledgment
ACK^A14^ACK: General Acknowledgment
ACK^A15^ACK: General Acknowledgment
ACK^A16^ACK: General Acknowledgment
ACK^A17^ACK: General Acknowledgment
ACK^A20^ACK: General Acknowledgment
ACK^A21^ACK: General Acknowledgment
ACK^A22^ACK: General Acknowledgment
ACK^A23^ACK: General Acknowledgment
ACK^A24^ACK: General Acknowledgment
ACK^A25^ACK: General Acknowledgment
ACK^A26^ACK: General Acknowledgment
ACK^A27^ACK: General Acknowledgment
ACK^A28^ACK: General Acknowledgment
ACK^A29^ACK: General Acknowledgment
ACK^A31^ACK: General Acknowledgment
ACK^A32^ACK: General Acknowledgment
ACK^A33^ACK: General Acknowledgment
ACK^A37^ACK: General Acknowledgment
ACK^A38^ACK: General Acknowledgment
ACK^A40^ACK: General Acknowledgment
ACK^A41^ACK: General Acknowledgment
ACK^A42^ACK: General Acknowledgment
ACK^A43^ACK: General Acknowledgment
ACK^A44^ACK: General Acknowledgment
ACK^A45^ACK: General Acknowledgment
ACK^A47^ACK: General Acknowledgment
ACK^A49^ACK: General Acknowledgment
ACK^A50^ACK: General Acknowledgment
ACK^A51^ACK: General Acknowledgment
ACK^A52^ACK: General Acknowledgment
ACK^A53^ACK: General Acknowledgment
ACK^A54^ACK: General Acknowledgment
ACK^A55^ACK: General Acknowledgment
ACK^A60^ACK: General Acknowledgment
ACK^A61^ACK: General Acknowledgment
ACK^A62^ACK: General Acknowledgment
ACK^Q05^ACK: General Acknowledgment
ACK^P01^ACK: General Acknowledgment
ACK^P02^ACK: General Acknowledgment
ACK^P03^ACK: General Acknowledgment
ACK^P05^ACK: General Acknowledgment
ACK^P06^ACK: General Acknowledgment
ACK^P10^ACK: General Acknowledgment
ACK^P11^ACK: General Acknowledgment
ACK^P12^ACK: General Acknowledgment
ACK^R01^ACK: Observation Message
ACK^R30^ACK: Observation Message
ACK^R31^ACK: Acknowledgment
ACK^R32^ACK: Observation Message
ORA^R33^ORA_R33: Observation Report Acknowledgement
ACK^T07^ACK: General Acknowledgment
ACK^I07^ACK: General Acknowledgment
ACK^PC6-PC8^ACK: General Acknowledgment
ACK^PC1-PC3^ACK: General Acknowledgment
ACK^PCB-PCD^ACK: General Acknowledgment
ACK^PCG,PCH,PCJ^ACK: General Acknowledgment
ACK^U01^ACK: General Acknowledgement
ACK^U02^ACK: General Acknowledgment
ACK^U03^ACK: General Acknowledgment
ACK^U04^ACK: General Acknowledgment
ACK^U05^ACK: General Acknowledgment
ACK^U06^ACK: General Acknowledgment
ACK^U07^ACK: General Acknowledgment
ACK^U08^ACK: General Acknowledgment
ACK^U09^ACK: General Acknowledgment
ACK^U10^ACK: General Acknowledgment
ACK^U11^ACK: General Acknowledgment
ACK^U12^ACK: General Acknowledgment
ACK^U13^ACK: General Acknowledgment
ACK^U14^ACK: General Acknowledgment
ACK^B01^ACK: General Acknowledgment
ACK^B02^ACK: General Acknowledgment
ACK^B03^ACK: General Acknowledgment
ACK^B04^ACK: General Acknowledgment
ACK^B05^ACK: General Acknowledgment
ACK^B06^ACK: General Acknowledgment
ACK^B07^ACK: General Acknowledgment
ACK^B08^ACK: General Acknowledgment
ACK^S28^ACK: General Acknowledgment
ACK^S29^ACK: General Acknowledgment
ACK^S30^ACK: General Acknowledgment
ACK^S31^ACK: Anti-Microbial Device Data Request Response
ACK^S32^ACK: Anti-Microbial Device Cycle Data Request Response
ACK^S33^ACK: General Acknowledgment
ACK^S34^ACK: General Acknowledgment
ACK^S35^ACK: General Acknowledgment
ACK^S36^ACK: General Acknowledgment
ACK^S37^ACK: General Acknowledgment

Call adjourned 9:59 AM EDT

Supporting Documents

Outline Reference

Supporting Document

Minute Approval