Inbound Functionality

The inbound TCP/IP HL7 Adapter Project, prjHL7Inbound, provides a sample implementation of an inbound flow using the Adapter. It can be configured for standard inbound mode or for forward message mode.

Inbound Adapter Data Flow

The inbound TCP/IP HL7 Adapter Project receives HL7 messages from an external system, sends an acknowledgement of the message to the external, provides sequence numbering, writes the HL7 message to a JMS data queue, and also writes the HL7 message and ACK to a JMS journal queue. Any error messages and NAKs are sent to a JMS error queue.

The HL7 data is processed so all the fields in the MSH segment of the message are stored in an internal structure to generate an HL7 response. Non-HL7 data, including HL7 acknowledgments, automatically generate warnings in the Adapter’s log file and send an HL7 NAK to the external system.

Standard Inbound Message Mode Data Flow and Architecture

The following steps describe the flow of data for an inbound Adapter:

1. The external system sends the HL7 message to the Adapter.

2. The Collaboration receives the HL7 message.

3. The Collaboration validates the message (if validate is enabled). If it fails, the Collaboration takes the configured recourse action. If the recourse action is stripped and the maximum number of retries has been exceeded, the message and error are written to the error queue.

4. The Collaboration writes the message to the data queue.

5. The Collaboration then creates the appropriate ACK and sends it to the RA.

6. The RA envelopes the ACK and sends it to the External System.

7. If journaling is enabled, the message and its ACK are written to the journal queue.

Inbound Receiver Message Mode

The Inbound Receiver Message mode is used when the Delayed ACK is configured to fulfill the role of the Receiver in the Delayed ACK scenario. It accepts the message and acknowledges the External and then forwards the message to the component fulfilling the Forwarder role. It then accepts the ACK from the Forwarder and passes it on to the External that sent the message.

The following steps describe the Inbound Forward Message Role:

1. The Sender External, sends an HL7 message to the Inbound Adapter, which is configured as a Receiver (Sends App Acks is enabled).

2. The Inbound Adapter receives the HL7 message and returns the first Acknowledgement to the External with an MSA - 5, value “D” for Delayed Acknowledgement. The External receives the ACK, validates the ACK (verifying that it is a Delayed ACK), and waits for another ACK.

3. The Inbound Adapter creates a JMS message with the HL7 message as the payload, creates a “reply to” destination, and forwards the HL7 message to the Outbound Forwarder (to a JMS destination).

4. The Outbound Forwarder gets the HL7 message and forwards the message to the External System.

5. The External System receives the HL7 message and returns the HL7 ACK message to the Outbound Forwarder.

6. The Outbound Forwarder gets the HL7 ACK message and sends it to the Inbound Receiver Adapter using the “reply to” destination.

7. The Receiver External reads the HL7 ACK message and forwards the second HL7 ACK message with an MSA - 5, value “F”to the Sender External. The Sender External then takes the appropriate action: for example, journaling the HL7 message and the HL7 ACK.

Message Verification

Message verification begins with reading the message from the external system. The message is expected to match the MLLP envelope, since both HLLP and MLLP envelopes have the Start of Block (SOB), End of Data (EOD), and a Carriage Return (CR) in common.

If a message fails the read verification, it is considered bad data. If read by an inbound Adapter, this failure causes the Adapter to generate a Canned HL7 NAK. An outbound Adapter ignores the message and logs a warning, reporting the nature of the problem to the log file.

An HLLP envelope needs further verification as to whether it is data or a NAK, as well as the Block Checksum and Block Size. The Adapter behaves as described above if the HLLP envelope verification fails.

After stripping the message envelope, the RA hands the de-enveloped message to the inbound Collaboration where it is parsed into the generic event Message Library. This ensures that the general form and MSH segment are valid. If the MSH property is set, the Collaboration verifies that the fields specified in the HL7 segment section are the same as those of the received MSH, otherwise, a NAK is returned.

Acknowledgment Processing

• Adapter Generates HL7 Acknowledgment

  In this scenario, the Adapter generates an HL7 ACK after receiving and successfully storing the message in a queue; otherwise, it generates an HL7 NAK. The HL7 ACK or NAK is placed in the proper envelope and sent to the external system.

• ESB Sends HL7 Acknowledgement

  In this scenario, the Adapter acts as a receiver in a Delayed ACK scenario, as described in Inbound Receiver Message Mode.

• Canned HL7 NAK

  A canned HL7 NAK is created when a read error occurs or when an message cannot be identified as an HL7 message. The initial test ensures that the message conforms to the lower-layer protocol. The Resource Adapter uses the MSH section parameters to create an appropriate NAK.

Recourse Actions

Recourse actions can be configured for an inbound Adapter for the following conditions. For more information, see Recourse Actions.

• The empty read limit is reached.

• The maximum number of NAKs are received by the Adapter.

• The maximum number of NAKs are sent by the Adapter.

• The maximum number of response timeouts is reached.

• A NAK response is received.

• No response is received after a message is sent the maximum number of times.