Message Sequencing in HL7V2.x

Maintaining message sequencing when clinical systems are integrated with in an enterprise using middleware approach and HL7V2.x message specifications is crucial from two perspectives

• Delivering messages in the order is crucial for HL7 messaging; for example an A03-Discharge message cannot arrive before an A04-register a patient or A01- Admit notification. In case of orders a Modify Order cannot reach before a Create New Order is sent
• If a sender needs to send an extremely large message to a receiver, typically containing multiple OBX segments it is impractical to send all the segments into a single message as it will not fit into a single message. The breaking the message into parts and sending each of the parts as a separate message requires that each message needs to indicate its position in the sequence and indicate the total number of messages to expect.

The obvious solution to maintain the messages in sequence in the order they are received and to keep them in sequence as they travel through the middleware-Integration Engine. The solution may be as simple as sending all HL7 ADT messages from the HIS/PAS system to departmental systems in the hospital in the order that they were generated. This can be done by allowing a single-threaded route from the originating application usually the HIS/PAS to the middleware-integration engine. This usually means implementation of a behavior where messages are sent to a single point (Fixed IP address and Port number) and a receipt of acknowledgement message for the previously sent message before the next message is sent.

However for large organizations with huge volumes of messages it is not feasable to maintain a single thread and implementation of multi-threading might disrupt the delivery of messages in the order which they arrive.


One way to solve the problem associated with message sequencing for multi-threaded solutions is to keep messages in sequence that contain information related to the same entity which can be the patient identifier and allow the middleware to route all the messages related to a particular patient or a rane of patinets based on the patient identifier range over the same thread.

Approach – A – Single Threaded Solution

Messages must be delivered by the sending system in sequence using a single communication channel with the integration engine. Messages are received from HIS/PAS through TCP/IP Socket Listener and are allocated a sequence number. The sequence number, and message control id (MSH-10) are persisted either onto the disk or to the database associated with the integration engine. Each of the message that is sent are checked against the stored sequence number and message control id to verify if messages are sent in sequence.

Approach – B – Multi Threaded Solution

When a message is received by the middleware it is allocated a sequence number and the number along with the patient id taken from message are persisted to the disk or database. In case of multi-threaded solution the messages can be processed in parallel by any of the thread which subscribes to the publisher of the message. The thread which picked up the message for processing checks to see if a message has been is delivered through that thread for the patient in the message by looking at the patient id. If it is established messages for that patient in fact have been sent through that thread then a check is made to see if the sequence number of the current message is greater or lower than previously sent stored message. On confirmation of the value of sequence number value the message is delivered to the destination system. The delivery status of the message can be stored in the system so that in case of non-delivery suitable rehydration mechanism can be established before delivering the next message with the same patient id.