Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

 

8.1 Purpose

The importance of acknowledgements (ACKs) in HL7 should not be understated. The only messages that should not be acknowledged are ACKs themselves (Acknowledging ACKs results in an infinite loop). Assuming delivery is not enough when clinical safety is at risk. A sending system user wants to know that their message has been successfully delivered and imported into the recipient system. An extension of this is human read acknowledgements indicating that the message content has been viewed.

ACKs also have other benefits such as highlighting how far in a delivery chain a message was transmitted before it failed, and thus which system to investigate the fault in. This implies that a sending system may receive multiple ACKs for a single message. Determining who the ACK originates from requires inspection of the sending facility and sending application. All actors in the chain of delivery have the potential to provide ACKs.

The ACK that indicates delivery to the target system is the application ACK and should be the defined ACK for the message type. E.g. REF^I12^REF_I12 results in a RRI^I12^RRI_I12, ORU^R01^ORU_R01 results in a ACK^R01^ACK_R01.

Systems upstream or users downstream from the target system, or the target system itself, may produce generic ACKs (|ACK|). This is because other segments in the message may be unreadable because of errors or they are unavailable to the processing system. This type of ACK is informational, the confirmation of delivery to the target system relies on the application ACK. These additional ACKs are accept ACKs as defined by the international standard.



Should delivery fail, faults that can be remedied are highlighted. These would have otherwise been unknown to the sender as the receiver would be unaware they should have received a message. This also allows systems to provide notification of human read acknowledgements of messages, mapping the sending application to the provider viewing the message contents.

The international HL7 standard describes 2 modes of acknowledgement in chapter 2: "original mode" and "enhanced mode". For Australian purposes enhanced mode acknowledgement is required.

“The HL7 Standard makes no assumptions about the ownership of data. It also makes no requirements of its own on the subsequent action of the recipient of data, nor does it make any assumption about the design or architecture of the receiving application system. The scope of HL7 is restricted to the specification of messages between application systems, and the events triggering them. HL7 does not explicitly support, but can be used with, systems that support store and forward and data broadcast facilities (see the HL7 Implementation Support Guide).
The HL7 Standard makes no functional interpretation of the requirement that a system commit the data in a message to its database before acknowledging it. All that is required is that the receiving system accept responsibility for the data, providing the same integrity test that it would apply to data from any source.”[1]

Each message in a batch should be acknowledged individually. There is no requirement to ACK the batch as such.

8.2 MSA Usage

To generate an ACK message:

  1. Enter Original Message MSH-3(Sending Application) into ACK MSH-5(Receiving Application). (Blue)
  2. Enter Original Message MSH-4(Sending Facility) into ACK MSH-6(Receiving Facility). (Red)
  3. Fill with software generating ACK into ACK MSH-3(Sending Application). (Green)
  4. Enter Original Message MSH-6(Receiving Facility) into ACK MSH-4(Sending Facility). (Orange)
  5. Enter Original Message MSH-11(Processing ID) into ACK MSH-11(Processing ID). (Purple)
  6. Enter Original Message MSH-10(Message control ID) into ACK MSA-2(Message control ID). (Gold)
  7. ACK MSH-10(Message control ID) should be unique and unrelated to Original Message MSH-10(Message control ID). (Maroon)


MSA segment details can be found here.

8.3 Accept vs Application Acknowledgements

The HL7 acknowledgment paradigm distinguishes both accept and application acknowledgments, as well the conditions under which each is required. With a positive accept acknowledgment, the receiving system commits the message to safe storage in a manner that releases the sending system from the need to resend the message. After the message has been processed by the receiving system, an application acknowledgment may be used to return the resultant status to the sending system.

Example Scenarios

  1. Sender to Receiver with application ACK.

    1. REF Examples 1.7 Level 1.zip Level 1 Example 1 in Appendix 6 Example Messages - 6.2 Patient Referral Examples.
      “MSH|^~\&|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID||JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|20170608223629+1000||REF^I12^REF_I12|MOE06082236987-957.1.4|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-REF-SIMPLIFIED-201706-L1&&L|||AL|AL|AUS<cr>
      RF1…”
    2. MSH|^~\&|SomeSoftware^SomeSoftware V1.2^L|JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID|20170608223642+1000||ACK|945375|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-ACK-201701&&L|||NE|AL|AUS<cr>
      MSA|CA|MOE06082236987-957.1.4
    3. MSH|^~\&|SomeSoftware^SomeSoftware V1.2^L|JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID|20170608224009+1000||RRI^I12^RRI _I12|AB19274|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-REF-SIMPLIFIED-201706/RRI&&L|||NE|AL|AUS<cr>
      MSA|AA|MOE06082236987-957.1.4<cr>
      RF1|…<cr>
      PRD|…<cr>
      PID|…<cr>
  2. Sender to Intermediary with accept ACKs and later application ACK.

    1. REF Examples 1.7 Level 1.zip Level 1 Example 1 in Appendix 6 Example Messages - 6.2 Patient Referral Examples.
      “MSH|^~\&|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID||JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|20170608223629+1000||REF^I12^REF_I12|MOE06082236987-957.1.4|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-REF-SIMPLIFIED-201706-L1&&L|||AL|AL|AUS<cr>
      RF1…”
    2. MSH|^~\&|MiddleWare^MiddleWare V2^L|JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID|20170608223849+1000||ACK|945376|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-ACK-201701&&L|||NE|AL|AUS<cr>
      MSA|CA|MOE06082236987-957.1.4
    3. MSH|^~\&|SecondHopSoftware^ SecondHopSoftware Build 5.2^L|JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID|20170608223701+1000||ACK|8ajojeaha2|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-ACK-201701&&L|||NE|AL|AUS<cr>
      MSA|CA|MOE06082236987-957.1.4
    4. MSH|^~\&|SomeSoftware^SomeSoftware V1.2^L|JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID|20170608223629+1000||RRI^I12^RRI _I12|AB19275|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-REF-SIMPLIFIED-201706/RRI&&L|||NE|AL|AUS<cr>
      MSA|AA|MOE06082236987-957.1.4<cr>
      RF1|…<cr>
      PRD|…<cr>
      PID|…<cr>
  3. Sender to Intermediary with multiple ACKs. Includes positive and negative user read ACK examples.

    1. REF Examples 1.7 Level 1.zip Level 1 Example 1 in Appendix 6 Example Messages - 6.2 Patient Referral Examples.
      “MSH|^~\&|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID||JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|20170608223629+1000||REF^I12^REF_I12|MOE06082236987-957.1.4|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-REF-SIMPLIFIED-201706-L1&&L|||AL|AL|AUS<cr>
      RF1…”
    2. MSH|^~\&|MiddleWare^MiddleWare V2^L|JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID|20170608223849+1000||ACK|945376|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-ACK-201701&&L|||NE|AL|AUS<cr>
      MSA|CA|MOE06082236987-957.1.4
    3. MSH|^~\&|SomeSoftware^SomeSoftware V1.2^L|JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID|20170608223852+1000||RRI^I12^ RRI _I12|AB19275|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-REF-SIMPLIFIED-201706/RRI&&L|||NE|AL|AUS<cr>
      MSA|AA|MOE06082236987-957.1.4<cr>
      RF1|…<cr>
      PRD|…<cr>
      PID|…<cr>
    4. Positive read ACK:
      MSH|^~\&|DrJohnSmith^889119NF^AUSHICPR|JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID|20170609123701+1000||ACK|8ajojeaha2|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-ACK-READ-2020006&&L|||NE|AL|AUS<cr>
      MSA|AA|MOE06082236987-957.1.4

      Negative read ACK:
      MSH|^~\&|DrJohnSmith^889119NF^AUSHICPR|JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID|20170609123701+1000||ACK|8ajojeaha2|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-ACK-READ-2020006&&L|||NE|AL|AUS<cr>
      MSA|AR|MOE06082236987-957.1.4|Report is unreadable.
      ERR|^^^EUserError&Report is unreadable&L

  4. Sender to Intermediary with Error/Reject ack from application/intermediary.

    1. REF Examples 1.7 Level 1.zip Level 1 Example 1 in Appendix 6 Example Messages - 6.2 Patient Referral Examples.
      “MSH|^~\&|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID||JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|20170608223629+1000||REF^I12^REF_I12|MOE06082236987-957.1.4|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-REF-SIMPLIFIED-201706-L1&&L|||AL|AL|AUS<cr>
      RF1…”
    2. MSH|^~\&|MiddleWare^MiddleWare V2^L|JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID|20170608223650+1000||ACK|945379|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-ACK-201701&&L|||NE|AL|AUS<cr>
      MSA|CA|MOE06082236987-957.1.4
    3. See point 1.
    4. MSH|^~\&|SomeSoftware^SomeSoftware V1.2^L|JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID|20170608224201+1000||ACK|8ajojeaha2|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-ACK-201701&&L|||NE|AL|AUS<cr>
      MSA|AE|MOE06082236987-957.1.4||||EHL7RelayAccessException^"Your user is not authorised to relay messages on this server. Access Denied"^L^EHL7RelayAccessException^^L
      ERR|^^^EHL7RelayAccessException&"Your user is not authorised is not authorised to relay messages on this server. Access Denied"
    5. MSH|^~\&|SomeSoftware^SomeSoftware V1.2^L|JD Medical^F144C1B5-56C7-43C1-80A4-83AD87D4FE5E^GUID|MERIDIAN^MERIDIAN:3.1.4 [win32-i386]^L|Buderim GE Centre Demo^0AE5C60C-A510-43B3-A509-C57F29B2D368^GUID|20170608224201+1000||ACK|8ajojeaha2|P|2.4^AUS&Australia&ISO3166_1^HL7AU-OO-ACK-201701&&L|||NE|AL|AUS<cr>
      MSA|AE|MOE06082236987-957.1.4||||EHL7RelayAccessException^"Your user is not authorised to relay messages on this server. Access Denied"^L^EHL7RelayAccessException^^L
      ERR|^^^EHL7RelayAccessException&Your user is not authorised is not authorised to relay messages on this server. Access Denied&L

8.4 User Read Acknowledgements

User read acknowledgements serve the purpose of notifying the sender that a specific recipient has viewed the message and confirmed they have read the content. The user performing the read confirmation is therefore provided in the return acknowledgement. The Internal version ID component of MSH-12 is used to confirm an acknowledgement specifically is a user read. MSH-3 is the field is used for the purpose of reporting the read confirmation user details.

MSH-12-3 must be valued “HL7AU-OO-ACK-READ-2020006”

Valid formats for the user details in MSH-3(Sending Application) are:

  • Username^<Medicare Australia provider number>^AUSHICPR
  • Username^<HPI-I>@<HPI-O>^NPIO

8.5 ACK - general acknowledgment

The simple general acknowledgment (ACK) can be used where the application does not define a special application level acknowledgment message or where there has been an error that precludes application processing. It is also used for accept level acknowledgments. General acknowledgments are well suited to the scenario where a system confirms receipt of message transport to halt retransmission attempts. It allows a system to generate an acknowledgment, for this type of scenario, without needing to fully process all the segments in the message which may have major faults that stop the responding system from generating an acknowledgement at all.

MSH-12-3 must be valued “HL7AU-OO-ACK-201701”

ACK^^ACK

General Acknowledgment

Chapter

MSH

Message Header

2

MSA

Message Acknowledgment

2

[ ERR ]

Error

2

Note: For the general acknowledgment (ACK) message, the value of MSH-9-2-Trigger event is equal to the value of MSH-9-2-Trigger event in the query message being acknowledged. The value of MSH-9-3-Message structure for the general acknowledgment message is always ACK.


[1]HL7 Messaging Standard Version 2.4, 2.3.2 Acknowledgments: original mode, 2000

  • No labels