Message Tracking Schemes

An integration engine is responsible for sending messages to a variety of different systems using a number of different message systems. Some of these messaging standards, most notably HL7, define a means of acknowledging that these messages have been received by the remote system and if the message was processed correctly. These responses allow the integration engine to resend messages, if necessary, or to notify the system administrator that one of the systems is not processing correctly or is not responding at all.

Message tracking in Rhapsody involves matching messages sent to a remote system with an acknowledgment message received from that system and taking a configurable action depending on the response (or lack of response) received.

Why Use Message Tracking?

Message tracking is used to verify that a remote system has correctly received a message sent to it, and allows appropriate action to be taken if this is not the case. It provides verification that the remote system actually processed the message, and did not crash after receiving it. Message tracking is an application layer acknowledgment system that operates at a higher level than the acknowledgment systems built into the lower layers (such as TCP).

For example, the Transmission Control Protocol (TCP) verifies that some data (in this case a message) has been correctly received by the remote system, but it does not verify that the remote application has correctly processed that message. It is possible for an application to correctly receive a message via TCP, but then stop responding (due to a crash, power cut, or other reason) before it completes processing that message. The acknowledgment system in TCP is of no help in this case, as the message was correctly received over TCP. So a higher level acknowledgment system is required to ensure the message is resent so the application can process it correctly.

HL7 Message Tracking

HL7 message tracking is one of the most common forms of message tracking in use. It is defined in detail in the relevant HL7 specifications, but is summarized and simplified here. Although message tracking in Rhapsody may be used with other messaging standards as well, the most common use is for HL7.

In HL7 version 2, all HL7 messages begin with an MSH segment (Message Header). The segment contains basic information about the message, including the following:

• The message separators to be used when processing the message.
• Information about the sender of the message.
• Information about the intended receiver of the message.
• The date/time the message was sent.
• The message type.
• The message control ID.
• The HL7 version.

Of greatest interest here is the message control ID (normally referred to as MSH/MessageControlID or MSH.10) which is used to identify the message. When receiving messages from multiple systems, this value, in conjunction with the information about the sender, is used to uniquely identify the message (or at least relatively uniquely over a short period of time).

An example of an HL7 MSH segment is as follows:

MSH|^~&|ABC|001|DEF|001|20020502145546||ADT^A01| *69549* |P|2.2|||AL|NE[0D]

HL7 defines a large number of acknowledgment messages. Some of them are general acknowledgments, whereas others, particularly query responses, are specifically for acknowledging/responding to particular message types. The most commonly used acknowledgment message is the ACK, although most acknowledgment messages follow the same format.

The HL7 ACK message contains three segments (in HL7 2.5 the third segment may repeat):

• MSH - the message header containing basic information about the message.
• MSA - the message acknowledgment segment which is used to determine what message is being acknowledged.
• ERR - the error segment, which contains errors found in the original message.

The first two fields in the MSA segment are the fields normally used for processing acknowledgments. These are the acknowledgment code and the message control ID.