The outbound TCP/IP HL7 Adapter Project, prjHL7Outbound, can be implemented in standard outbound mode or in two forward message modes: outbound delayed ACK or outbound forwarder.
In outbound mode, the Adapter receives HL7 messages from a JMS queue. Each message is verified to ensure it contains HL7 data only. Legitimate HL7 data is enveloped into its configured format and sent to the external system.
A message in the JMS queue triggers the outbound Collaboration. The outbound Collaboration is provided with an HL7 message to send to the external system
The Adapter waits for a configurable number of milliseconds for an incoming HL7 ACK or NAK from the external system. After receiving an HL7 response from the external system, the Adapter strips the message from its envelope and verifies its integrity.
Any non-HL7 acknowledgment received from the external system causes the Adapter to resend the same message. If the incoming response is an HL7 ACK or NAK, the Adapter might do either of the following, as dictated by its configuration:
Recourse action on NAK received.
Recourse action on Max NAK received.
If journaling is set, these messages and their ACKs are placed in the journal file.
The following steps describe the process for the Outbound Standard Message Mode:
An HL7 message triggers the Collaboration. The outbound Collaboration is designed to accept the HL7 messages.
The Collaboration maps the received message into the Generic Event Message Library and validates the MSH segment. If validation is enabled, the Collaboration checks the MSH segment of the outbound messages against MSH values configured in the Adapter properties file. If the validation fails or the message cannot be parsed, the message and its error are written to the error queue. Note that the HL7 message is always checked for structural correctness.
The Collaboration sends the message to the RA.
The RA envelopes the message and sends it to the External System and waits for an ACK.
The Collaboration receives and validates the ACK, and then journals the ACK and the HL7 message (if journaling is enabled). If the Collaboration receives a NAK, the NAK and the HL7 message are sent to the error queue.
Finally, the Collaboration commits the JMS receive.
The outbound Adapter can fulfill two roles in a delayed ACK scenario. The outbound delayed acknowledgement mode is used to communicate with an external system that is configured to receive messages in a delayed ACK way; that is, it receives two ACKs. One confirms the message was received, and the other is from the application that accepts the message. For delayed ACK mode, the process is similar to that of the standard outbound mode, except that it receives two ACKs. The initial ACK comes from the receiving system.
The following steps describe the outbound delayed acknowledgement role process displayed:
The outbound Adapter, which is configured as Delayed Acknowledgement role, receives a message from JMS, and sends the message to the External System.
The External System receives the message and returns the first Acknowledgement to the outbound Adapter with an MSA - 5, value “D” for Delayed Acknowledgement. The outbound Adapter receives the ACK, validates the ACK (verifying that it is a Delayed ACK), and waits for another ACK.
The outbound Adapter receives another HL7 ACK message (the second) and validates that the second HL7 ACK message is an MSA - 5, with a value of “F.” If the second ACK is valid, the Adapter commits the message, otherwise it resends the message.
The Outbound Forward Message role is used in conjunction with the with the inbound Adapter, which is also configured to handle delayed ACKs. No validation is preformed: the Adapter acts as a “pass-through.”
The following steps describe the Outbound Forwarder Role processing:
Data is received by the Collaboration, from the JMS queue.
The Collaboration extracts the JMS property “reply to” destination from the message, but does no validation, and sends the message to the External System.
The Adapter receives the ACK from the External System.
The Collaboration sends the ACK to the temporary topic that was contained in the “reply to.”
For Delayed ACK, the Receiver and Forwarder must be on the same integration server.
The only verification that the outbound Adapter does is to ensure that the message parses into the generic Event Message Library, and that the MSH uses the correct fields. The acknowledge is verified to ensure that the sent message is valid.
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 sender in a Delayed ACK scenario, as described in Delayed ACK 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 can be configured for the outbound Adapter for the following conditions:
The Adapter sends the maximum number of canned negative acknowledgments.
The Adapter attempts to read data the maximum number of times from the external system after a read or receive operation returns nothing.
The Adapter receives the maximum number of negative acknowledgments.
HL7 message validation fails prior to the sending of the HL7 message to the external system.
The Adapter reaches the maximum number of response timeouts while waiting for data from the external system.
The Adapter receives an HL7 Application NAK from the external system.
The Adapter waits for a response from the external system for the configured amount of time (in milliseconds).
For more information on the available recourse actions, see Recourse Actions.
The TCP/IP HL7 Adapter includes internal counters that keep track of all error conditions.