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 2.12.2, "APPLICATION (LEVEL 7) PROCESSING RULES". 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 2.12.1.1, "Initiation" 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:
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.
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. (For definitions of the MSH fields see Section 2.24.1, "MSH message header segment.")
Field |
Notes |
MSH-3-sending application | |
MSH-4-sending facility | |
MSH-5-receiving application | |
MSH-6-receiving facility | |
MSH-7-date/time of message |
This field is not used in the processing logic of the HL7 protocol. It is optional. |
MSH-9-message type | |
MSH-10-message control ID |
Unique identifier used to relate the response to the initial message. |
MSH-11-processing ID | |
MSH-12-version ID | |
MSH-13-sequence number | |
MSH-14-continuation pointer |
Used in implementation of message continuation protocol. See Sections 2.23.2, "Continuation messages and segments," 2.14.3, "Continuation of unsolicited display update message," and 2.15.4, "Interactive continuation or cancellation of response messages: original mode (display and record oriented) and enhanced mode (display, tabular, and event replay)." |
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.
The protocol software in the responding system does one of the following:
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 implementors 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. Note that the field definitions for the MSA segment fields are in Section 2.24.2, "MSA message acknowledgment segment":
Field |
Notes |
MSA-1-acknowledgment code |
As described above. |
MSA-2-message control ID |
MSH-10-message control ID from MSH segment of incoming message. |
MSA-3-text message |
Text description of error. |
MSA-4-expected sequence number |
As described in Section 2.23.1, "Sequence number protocol," (if the sequence number protocol is being used). |
MSA-5-delayed acknowledgment type |
For use only as described in Section 2.12.2, "Application (level 7) processing rules, deferred processing xe "Processing rules: application" xe "Processing rules: deferred" two phase reply (original acknowledgment mode only)." |
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: 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. Note that the field definitions for the MSA segment fields are in Section 2.24.2, "MSA message acknowledgment segment"):
Field |
Notes |
MSA-2-message control ID |
MSH-10-message control ID from the incoming message. |
MSA-1-acknowledgment code |
As described above. |
MSA-3-text message |
Text description of error. |
MSA-4-expected sequence number |
As described in Section 2.23.1, "Sequence Number Number Protocol" (if the sequence number protocol is being used). |
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. Note that the field definitions for the MSA segment fields are in Section 2.24.2, "MSA message acknowledgment segment):
Field |
Notes |
MSA-2-message control ID |
Identifies the initial message from the original initiating system as defined in Section 2.12.1.1, "Initiation." |
MSA-1-acknowledgment code |
Uses the application (processing) acknowledgment codes as described in Section 2.12.1.2.1, "When the original acknowledgment rules apply." |
MSA-3-text message |
Text description of error. |
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). |