MLLP V2

The abbreviation of MLLP V2 is Minimal Lower Layer Protocol Release 2. MLLP V2 is a requirement for all Message Transport protocols used to transport HL7 Version 3 content.

MLLP V2 Content Exchange Model

MLLP Release 2 is a reliable Message Transport protocol. It guarantees In Order delivery and At Least Once delivery of HL7 Content. HL7 Content is framed in a Block and sent to the Destination system. The Destination system acknowledges the receipt of the message by returning a Commit Acknowledgement message. The MLLP V2 acknowledgement protocol is synchronous: the Source system shall not send new HL7 content until an acknowledgement for the previous HL7 Content has been received.

Figure 1–31 Interaction Diagram

All HL7 Content (of any kind or type) is framed in a Block and sent to the Destination system. The Destination system acknowledges the receipt of the Block by returning a Commit Acknowledgement message. If the HL7 Content (a query in the example below) triggers the sending of HL7 Content (a Response) by the Destination system, then this HL7 Content is framed in a Block and sent. MLLP has no knowledge of the HL7 Content, nor does it base any part of its behavior on HL7 Content.

In HL7 adapter, a database is used to persist the message.

In Inbound Mode, once the message is received by the HL7 adapter, it is persisted into the database and a commit acknowledgement is sent to the sender before the HL7 message is passed to the collaboration level. If the persistence fails, a negative acknowledgement is sent to the sender and the collaboration receives null as its message. Inside the collaboration, the message received is null, the collaboration returns without proceeding.

If the message received is a duplicate message, and if an ACK/NAK is already available in the persistence database, the same is retrieved from the database sent to the sender. The collaboration receives null as the received message.

In Outbound Mode, the message is sent to the sender and waits for the commit acknowledgement and/or negative acknowledgement from the receiver. If the adapter receives a negative acknowledgement, the message is sent again until the configured Maximum Number of Retries is made.

Standard Inbound HL7 V2 Collaboration Overview over MLLPV2

The Inbound HL7 V2 Collaboration, jcdHL7Inbound, contains OTDs for the HL7 Resource Adapter, JMSData, HL7 ACK, JMS Journal, and JMS Error, as well as the Generic HL7 Event. The Collaboration works with its own internal code and the Properties Configuration files.

HL7 V2 Standard Inbound Message Mode Data Flow over MLLPV2 — Part 1

Once the message is received, the Collaboration determines whether the message needs to be validated. The HL7 V2 message is then validated making sure that the message structure is correct. Various fields in the MSH segment of the message are also validated, such as Version ID and Sending Facility. If these fields do not match the configuration, a NAK is returned.

If sequence numbering is enabled the Collaboration checks to see if the messages sequence number is valid. If the sequence number is not valid, the adapter sends a NAK.

The validated HL7 V2 message moves on to processInitialHandshake() and the sequence numbers are synchronized. The sequence number within the message is checked against the expected sequence number. If the numbers match, the Collaboration sends an ACK, if not it sends a NAK. The ACK or NAK includes information from various fields of the incoming MSA segment. The ACKs level of acknowledgement is set to A (acknowledgement is sent when the message is successfully received), or C (acknowledgement is sent after the message is successfully processed).

Figure 1–32 HL7 V2 Standard Inbound Message Mode Data Flow over MLLPV2 — Part 1

HL7 V2 Standard Inbound Message Mode Data Flow over MLLPV2 — Part 2

The Collaboration receives the HL7 V2 message from the external using receiveHL7message(). If an exception occurs due to incomplete data, and the adapter fails to read the data within the configured number of retries, the associated recourse action is taken. If the exception is due to no response, the associated recourse action is taken.

Figure 1–33 HL7 V2 Standard Inbound Message Mode Data Flow over MLLPV2 — Part 2

HL7 V2 Standard Inbound Message Mode Data Flow over MLLPV2 — Part 3

If no exception occurs, validateHL7Message() is called, which validates the message to determine whether to ACK or NAK the message. Other helper methods are also called to validate the HL7 message.

If the HL7 message does not pass validation, the Collaboration calls makeNak() and sendHL7Nak() to create and send the NAK to the external. The HL7 message, with the NAK, is archived to the Error Queue. If the number of consecutive NAKs sent surpasses the maximum number of retries, the associated recourse action is taken.

If the HL7 message passes validation, the Collaboration calls makeAck() and sendHL7Ack() to create and send the ACK to the external.

The HL7 ACK/NAK are stored in the persistent database. This ACK/NAK is stored against the Inbound HL7 message received.

After the ACK is sent, the HL7 message and the ACK are journaled to the JMS Queue Journal destination. If the message fails to journal the associated recourse action is taken.

If Sequence Numbering is enabled, the processAckNakSequenceNumbering method calculates the next sequence number and stores the number in the sequence number file by calling the updateSequenceNumberFile method to persist the next sequence number.

Figure 1–34 HL7 V2 Standard Inbound Message Mode Data Flow over MLLPV2 — Part 3