References from original 2.4 international standard.

• 2.3.2 Acknowledgments: original mode
• 2.3.3 Acknowledgments: enhanced mode
• 2.13 APPLICATION (LEVEL 7) PROCESSING RULES
• 2.13.1 Original and enhanced processing rules
•  
• 2.13.1.1 Initiation
• 2.13.1.2 Response
• 2.13.1.2.1 When the original acknowledgment rules apply
• 2.13.1.2.2 When enhanced acknowledgment rules apply
• 2.13.2 Application (level 7) processing rules, deferred processing two phase reply (original acknowledgment mode only)
•  
• 2.13.2.1 Initiation
• 2.13.2.2 Response
• 2.14 ACKNOWLEDGMENT MESSAGES
• 2.14.1 ACK - general acknowledgment
• 2.14.2 MCF - delayed acknowledgment

2.15.3.3 Acknowledging batches

2.18 SAMPLE CONTROL MESSAGES

• 2.18.1 General acknowledgment

Several sections contain “REMOVE?” Or “CHANGE?” for consideration.

8 Acknowledgements

8.1.1 Purpose

The importance of acknowledgements in HL7 should not be understated. The only messages that should not be acknowledged are acknowledgments themselves (Acknowledging acknowledgments 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.

Acknowledgements 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. Should delivery fail, faults that can be remedied are highlighted that would have otherwise been unknown to the sender, without feedback from a receiver unaware they should have received a message.8.2.1 Acknowledgments: original mode

When an unsolicited update is sent from one system to another, this acknowledgment mode specifies that it be acknowledged at the application level. The reasoning is that it is not sufficient to know that the underlying communications system guaranteed delivery of the message. It is also necessary to know that the receiving application processed the data successfully at a logical application level.
The acknowledgment may contain data of interest to the system that initiated the exchange. For example, if a patient care system has processed the trigger event a lab test is ordered for a patient, it may send an unsolicited update to a lab application identifying the patient, the test ordered, and various other information about the order. The ancillary system will acknowledge the order when it has processed it successfully. For some pairings of patient care and ancillary department systems the acknowledgment may also include the ancillary identification number that was assigned. (HL7 does not require Order Entry and Results Reporting applications to interface in this manner, but it supports those that do.)
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. To continue the prior example, the ancillary system may acknowledge the order after placing it in an input queue, expecting to fully process the order into its database at a future time. The only assumption is that the input queue is maintained at the same level of integrity as the database.

8.2.2 Acknowledgments: enhanced mode

The HL7 acknowledgment paradigm has been extended to distinguish 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.

8.2.3 Acknowledging batches

In general, the utility of sending batches of data is that the data is accepted all at once, with errors processed on an exception basis. However, it is a permissible application of HL7 to acknowledge all messages. Several options for acknowledgment are given and will be chosen on an application basis. In these cases, the sequence numbering protocol can be useful to the applications processing the batch.
The options are:
a) all messages are acknowledged in the response batch.
REMOVE? b) the receiving system prints some form of batch control report, which is then dealt with manually by personnel at the sending system. No acknowledgments are performed by the protocol software.
REMOVE? c) an automated acknowledgment batch is created containing acknowledgment messages only for those messages containing errors. In this mode an empty acknowledgment batch may be created (i.e., an HL7 batch file without any HL7 acknowledgment messages).
In each case where there is a response batch, its format is a batch of individual messages. Each individual message is in the format defined for an online response in the chapters. Consider, for example, a batch that might be constructed to respond to a batch of Detailed Financial Transactions (Chapter 6). The messages in the response batch would consist entirely of ACK messages, since ACK is the response shown in Chapter 6.
When batches are retransmitted after the correction of errors, BHS-12-reference batch control ID should contain the batch control ID of the original batch.

8.3.1 APPLICATION (LEVEL 7) PROCESSING RULES

8.3.1.1 Original and enhanced processing rules

The processing rules described here apply to all exchanges of messages, whether or not the HL7 encoding rules or Lower Layer Protocols are used. They represent the primary message processing mode. Certain variants are documented in Section 8.3.1.2, "Application (level 7) processing rules, deferred processing two phase reply (original acknowledgment mode only)." These include:
a) the application processing rules for a special processing mode, deferred processing. This mode remains in the specification only for backward compatibility.
b) an optional sequence number protocol
c) an optional protocol for continuing a very long message
The processing rules were extended in Version 2.2 of the Standard. The extensions provide a greater degree of flexibility in the way that messages can be acknowledged, as specified by several new fields in the Message Header segment. To provide backward compatibility with prior versions, the absence of these fields implies that the extended processing rules are not used. In the remainder of this section the extended mode is called the enhanced acknowledgment mode; the prior version is called the original acknowledgment mode.
Because the protocol describes an exchange of messages, it is described in terms of two entities, the initiating and responding systems. Each is both a sender and receiver of messages. The initiating system sends first and then receives, while the responding system receives and then sends.
In overview this exchange proceeds as follows:
Step 1 the initiating system constructs an HL7 message from application data and sends it to the responding system
Step 2 responder receives message and
2.1 when the original acknowledgment rules apply:
a) validates the message syntactically and against the detailed rules described in Section 8.3.1.1.2.1, If it fails, a reject message is constructed by the protocol software and returned to the initiator; if it does not fail, continue to the next step (2.1,b)
b) passes the message to the application, which:
1) creates a response message, or
2) creates an error message, or
3) creates a reject message
c) sends the response, error, or reject message
Initiator passes the message to the initiating application.
2.2 when enhanced acknowledgment rules apply:
See section 8.3.1.1.2.2
a) the responding system receives the message and commits it to safe storage. This means that the responding system accepts the responsibility for the message in a manner that releases the sending system from any obligation to resend the message. The responding system now checks the message header record to determine whether or not the initiating system requires an accept acknowledgment message indicating successful receipt and secure storage of the message. If it does, the accept acknowledgment message is constructed and returned to the initiator.
b) at this point, the requirements of the applications involved in the interface determine whether or not more information needs to be exchanged. This exchange is referred to as an application acknowledgment and includes information ranging from simple validation to a complex application-dependent response. If the receiving system is expected to return application-dependent information, it initiates another exchange when this information is available. This time, the roles of initiator and responder are reversed.
The details follow.

8.3.1.1.1 Initiation

The initiating application creates a message with data values as defined in the appropriate chapter of this Standard. The fields shown below should be valued in the MSH segment (as defined under the MSH segment definition of this chapter). The message is encoded according to the applicable rules and sent to the lower level protocols, which will attempt to deliver it to the responding application

Certain other fields in the MSH segment are required for the operation of the HL7 encoding rules; they will not be relevant if other encoding rules are employed.
The event code in the second component of MSH-9-message type is redundantly shown elsewhere in some messages. For example, the same information is in the EVN segment of the ADT message. This is for compatibility with prior versions of the HL7 protocol. Newly-defined messages should only show the event code in MSH-9-message type.

8.3.1.1.2 Response

The protocol software in the responding system does one of the following:

8.3.1.1.2.1 When the original acknowledgment rules apply

Note: Both MSH-15-accept acknowledgment type and MSH-16-application acknowledgment type are null or not present.
a) accepts the message
b) validates it against at least the following criteria:
1) the value in MSH-9-message type is one that is acceptable to the receiver
2) the value in MSH-12-version ID is acceptable to the receiver
3) the value in MSH-11-processing ID is appropriate for the application process handling the message
If any of these edits fail, the protocol software rejects the message. That is, it creates an ACK message with AR in MSA-1-acknowledgment code.
c) if the message passes the edits, the message is passed to the receiving application, which performs one of these functions:
1) process the message successfully, generating the functional response message with a value of AA in MSA-1-acknowledgment code.
-OR-
2) send an error response, providing error information in functional segments to be included in the response message with a value of AE in MSA-1-acknowledgment code.
-OR-
3) fail to process (reject) the message for reasons unrelated to its content or format (system down, internal error, etc.). For most such problems it is likely that the responding system will be able to accept the same message at a later time. The implementers must decide on an application-specific basis whether the message should be automatically sent again. The response message contains a value of AR in MSA-1-acknowledgment code.
d) passes the message to the initiating system
e) the protocol software in the initiating system passes the response message to the initiating application
In all the responses described above the following values are put in the MSA segment.

The MSH segment in the response is constructed anew following the rules used to create the initial message described above. In particular, MSH-7-date/time of message and MSH-10-message control ID refer to the response message; they are not echoes of the fields in the initial message. MSH-5-receiving application, MSH-6-receiving facility, and MSH-11-processing ID contain codes that are copied from MSH-3-sending application, MSH-4-sending facility and MSH-11-processing ID in the initiating message.

8.3.1.1.2.2 When enhanced acknowledgment rules apply

Note: At least one of MSH-15-accept acknowledgment type or MSH-16-application acknowledgment type is not null.
a) accepts the message
b) makes an initial determination as to whether or not the message can be accepted, based on factors such as:
1) the status of the interface
2) the availability of safe storage onto which the message can be saved
3) the syntactical correctness of the message, if the design of the receiving system includes this type of validation at this phase
4) the values of MSH-9-message type, MSH-12-version ID, and MSH-11-processing ID, if the design of the receiving system includes this type of validation at this phase
c) examines the Message Header segment (MSH) to determine whether or not the initiating system requires an accept acknowledgment.

If it does, the responding system returns a general acknowledgment message (ACK) with:
1) a commit accept (CA) in MSA-1-acknowledgment code if the message can be accepted for processing
2) a commit reject (CR) in MSA-1-acknowledgment code if the one of the values of MSH-9-message type, MSH-12-version ID or MSH-11-processing ID is not acceptable to the receiving application
3) a commit error (CE) in MSA-1-acknowledgment code if the message cannot be accepted for any other reason (e.g., sequence number error)

For this response, the following values are put in the MSA segment.

The MSH segment in the response is constructed anew following the rules used to create the initial message described above. In particular, MSH-7-date/time of message and MSH-10-message control ID refer to the response message; they are not echoes of the fields in the initial message. MSH-5-receiving application, MSH-6-receiving facility, and MSH-11-processing ID contain codes that are copied from MSH-3-sending application, MSH-4-sending facility and MSH-11-processing ID in the initiating message.
Note: MSH-15-accept acknowledgment type and MSH-16-application acknowledgment type are not valued (not present or null). At this point, the accept portion of this message exchange is considered complete.
d) If the message header segment indicates that the initiating system also requires an application acknowledgment, this will be returned as the initial message of a later exchange.
For this response, the following values are put in the MSA segment.

For this message, the receiving system acts as the initiator. Since the message it sends is application-specific, the layouts of these application-level response messages are defined in the relevant application-specific chapter. If needed, this application acknowledgment message can itself require (in MSH-15-accept acknowledgment type) an accept acknowledgment message (MSA). MSH-16-application acknowledgment type, however, is always null, since the protocol does not allow the application acknowledgment message to have an application acknowledgment.
At this point, the application acknowledgment portion of this message exchange is considered complete.
If the processing on the receiving system goes through multiple stages, chapter-defined messages may be used to relay status or informational changes to other systems (including the original initiating system). Such messages are not part of the acknowledgment scheme for the original message, but are considered to be independent messages triggered by events on the (original) responding system.
Note: The original acknowledgment protocol is equivalent to the enhanced acknowledgment protocol with MSH-15-accept acknowledgment type = NE and MSH-16-application acknowledgment type = AL, and with the application acknowledgment message defined so that it never requires an accept acknowledgment (MSH-15-accept acknowledgment type = NE).

REMOVE?8.3.1.2 Application (level 7) processing rules, deferred processing two phase reply (original acknowledgment mode only)

(This section remains in the specification only for reasons of providing backward compatibility: it is to be used only with the original acknowledgment protocol. For the original acknowledgment protocol, it creates a generic form of an asynchronous application level acknowledgment, the MCF message.)
The application processing rules for deferred processing are described here. In this mode the responding system sends an acknowledgment to the initiating system that means the message has been placed in some type of secure environment (e.g., disk storage), and the receiving system commits to processing it within a reasonable amount of time, if a) the message contains the necessary information, and b) nothing causes the message's request for action to be cancelled before the responding system processes the request.
Note: Neither of these two conditions is completely checked at the time of the first acknowledgment. They are both checked at the time of processing.
The receipt of the first delayed acknowledgment by the initiating system means that the responding system has taken responsibility for the subsequent processing of the message. This also implies that the initiating system no longer needs to keep the particular message in its current form to send out later. For example, if the sending system were maintaining a queue of outgoing messages, the particular message could be deleted from the output queue at this point.
The receipt of the second delayed acknowledgment message informs the initiating application of either: a) the application's successful processing of the initial message, or b) an error that prevented its processing. If the receiving application needs to return detailed change of status information, an application-specific message will be used. An example of the latter is the General Order message (ORM) described in Chapter 4.
The general delayed acknowledgment protocol is implemented on a site-specific and application-specific basis as needed. At a particular site, for a given transaction type the choices are:
a) do not allow deferred acknowledgments
b) all messages will have a deferred acknowledgment
c) only exceptional cases (errors) will receive the deferred acknowledgment
In overview the processing for options b) and c) proceeds as follows:
Initiator receives message from sending application and sends it to the responding system.
The responding system receives the message from the initiating system and
a) partially validates it syntactically and against the detailed rules described in Section 2.13.1, "Original and enhanced processing rules." This validation need not be complete but should be sufficient to determine the application that will ultimately respond to the message. If this validation fails, a reject message is constructed by the protocol software and returned to the initiator.
b) (if the message passes this validation) stores it and constructs a response message that simply acknowledges receipt. MSA-5-delayed acknowledgment type then has a value of D.
c) subsequently passes the message to the application, which:
1) creates a response message, or
2) creates an error message, or
3) creates a reject message
d) The protocol software sends the response, error, or reject message to the initiating system as an unsolicited update with no value present in MSA-5-delayed acknowledgment type.
The protocol software of the initiating system responds to the response, error, or reject message with simple acknowledgment and passes it to the initiating application.
The details follow.

REMOVE?8.3.1.2.1 Initiation

The rules for creating the initial message are exactly as defined in Section 2.13.1, "Original and enhanced processing rules," for the original acknowledgment rules.

REMOVE?8.3.1.2.2 Response

The processing in the responding system follows this pattern:
a) the protocol software accepts the message and validates it against at least the following criteria:
1) the value in MSH-9-message type is one that is acceptable to the receiver
2) the value in MSH-12-version ID is acceptable to the receiver
3) the value in MSH-11-processing ID is appropriate for the application process handling the message
If any of these edits fail, the protocol software rejects the message. That is, it creates an ACK message with AR in MSA-1-acknowledgment code.
b) If the message passes the edits, the protocol software stores it and generates a response message of type ACK with a value of AA in MSA-1-acknowledgment code and D in MSA-5-delayed acknowledgment type.
c) Subsequently the protocol software passes the message to the application, which performs one of these functions:
1) processes the message successfully, generating the functional response message (message type MCF) with a value of AA in MSA-1-acknowledgment code.
- OR -
2) creates an error response, providing error information in functional segments to be included in the response message, which has a value of AE in MSA-1-acknowledgment code.
- OR -
3) fails to process (rejects) the message for reasons unrelated to its content or format (system down, internal error, etc.) For most such problems it is likely that the responding system will be able to accept the same message at a later time. The implementors must decide on an application-specific basis whether the message should be automatically sent again. The MSA segment of the response message contains a value of AR in MSA-1-acknowledgment code.
d) the application passes the message to the protocol software, which constructs a message of type MCF with F in MSA-5-delayed acknowledgment type.
e) the protocol software passes the message to the initiating system as an unsolicited update.
f) the protocol software in the initiating system passes the response message to the initiating application and generates a simple ACK message. No value is present in MSA-5-delayed acknowledgment type.
All other values are put in the MSA segment as described in Section 2.13.1, "Original and enhanced processing rules."

8.4.1 ACKNOWLEDGMENT MESSAGES

Acknowledgment messages may be defined on an application basis. However the simple general acknowledgment message (ACK) may be used as a response for all messages (of any message type except acknowledgements) where the application does not define a special message (application level acknowledgment). It is also valid  in other cases as described in the international 2.4 standard Section 2.13.1, "Original and enhanced processing rules." 

Multiple acknowledgements may be returned for the same originating message.

8.4.1.1 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. The details are described in Section 2.13.1, "Original and enhanced processing rules.". This is not a quick and dirty way to acknowledge messages. It is best suited to enhanced mode acknowledgements 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.

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.

8.5.1 SAMPLE CONTROL MESSAGES

CHANGE? |ACK^^ACK_ACK|  to |ACK| in the examples? 8.5.1.1 General acknowledgment

LXB acknowledges the message that AXT sent identified as ZZ9380. (LXB and AXT, the sending and receiving system IDs, are site-defined.) Both systems are associated with the same FACILITY, 767543. The AA code in the MSA segment indicates that the message was accepted by the application.
MSH|^~\&|LXB|767543|AXT|767543|19900314130405||ACK^^ACK_ACK|XX3657|P|2.4<cr>
MSA|AA|ZZ9380<cr>

8.5.1.2 Error return

The AR code in MSA indicates that the application rejected the message for functional reasons. The optional ERR segment includes here that the 16th field of the PID segment with the SET ID value of 1 had an error which was defined by the locally-established code X3L. The optional text message UNKNOWN COUNTY CODE in the link is designed to help programmers and support personnel while reviewing message logs.
MSH|^~\&|LXB|767543|AXT|767543|199003141304-0500||ACK^^ACK_ACK|XX3657|P|2.4<cr>
MSA|AR|ZZ9380|UNKNOWN COUNTY CODE<cr>
ERR|PID^1^16^X3L<cr>

REMOVE? 8.5.1.3 Sequence number: initial message

The sender initiates the link with a message that has no functional content. The sequence number is 0. The message type and event code are not used.
MSH|^~\&|AXT|767543|LXB|767543|199003141304-0500||^|XX3657|P|2.4|0<cr>
The responder uses a general acknowledgment. The expected sequence number is 1.
MSH|^~\&|LAB|767543|ADT|767543|199003141304-0500||ACK^^ACK_ACK|ZZ9380|P|2.4<cr>
MSA|AA|XX3657||1<cr>

8.5.1.4 Single message full delivery chain

The sender transmits a REF^I12 message to the recipient via a message carriage service. The message carriage service acknowledges delivery. The receiving middleware, as part of a practice software package, also supplies initial acceptance. The software the recipient user interfaces with returns a completed processing acknowledgement. Note the mixture of general acknowledgments and RRI^12 acknowledgements.

1. Message carriage service acknowledgement of delivery to site instance.
   MSH|^~\&| CAPRICORN^CAPRICORN:3.1.8 (Build 10) [win32-i386]^L|767543|AXT|767543|199003141304-0500||ACK|XX3657|P|2.4<cr>
   MSA|AA|ZZ9380 <cr>
2. Receiving software accepts transmission of message. Note the software may be middleware and not the final software the recipient interfaces with. This acknowledgement would be returned to the message carriage server which in turn can return it to the sender.
   MSH|^~\&|LXB Middleware|767543|AXT|767543|199003141304-0500||ACK|PP7643|P|2.4<cr>
   MSA|CA|ZZ9380 <cr>
3. Receiving software performs complete parsing and storage of message
   MSH|^~\&|LXB |767543|AXT|767543|199003141304-0500||RRI^I12|8746KA|P|2.4<cr>
   MSA|AA|ZZ9380 <cr>

RF1| segment must echo what was received in the referral message

PRD| segment must echo what was received in the referral message

PID| segment must echo what was received in the referral message