GenericHL7Input node

The GenericHL7Input node listens on a port and when a client socket connects to the port, the server socket creates a connection for the client. When a connection is open a record of data is received and the end of record is detected by the presence of a configurable delimiter. If an error occurs when reading data, for example a timeout waiting for data or the closure of a connection while waiting for the full record, the data is sent to the Failure terminal. If the Failure terminal is not connected an exception is thrown. If the Retry mechanism property for the node is not set to Failure, the node retries until the data is successfully retrieved or until the number of retry attempts defined by the Retry threshold property is exceeded.

The GenericHL7Input node requires messages that use the MLLP protocol over TCP/IP. If the MLLP leading bytes are not present the message is sent to the Failure terminal.

The GenericHL7Input node handles messages that are defined in the MRM domain. The HL7 message format in the HL7v25P message set message set is used to parse the messages. If a parsing error occurs, or if mandatory MSH fields are not present, the message is passed to the Failure terminal. For information about message sets, see Message sets overview in the IBM Integration Bus product documentation.

You can configure the GenericHL7Input node to check for duplicates. Each incoming HL7 message has a MessageControlID field in the MSH header segment, which identifies the record. If the Check duplicates property is selected, all identifiers are stored on the duplicate queue with the acknowledgment (ACK) that was returned to the sender. The identifier of an incoming message is checked against the saved identifiers to determine if it is a duplicate. When a duplicate is detected, it is not processed, but the same acknowledgment that was sent with the first message is returned to the sender. The duplicate queue is specified as a node property.

Identifiers are stored on the duplicate queue for the duration defined by the Duplicate time period property. After this duration has elapsed, the identifiers are deleted and messages with the same identifier are no longer treated as duplicates. You must size the duplicate queue to contain the peak number of message identifiers expected in the set time period.

If an incoming message is not a duplicate, the message is passed to the Out terminal of the GenericHL7Input node for further processing. If a duplicate is detected, the GenericHL7Input node returns the ACK to the requester. If duplicate reporting is selected and a duplicate is detected the message is passed to the Failure terminal.

Messages are processed under transactional control. If the message flow is rolled back then duplicate identifiers that were added to the duplicate identifier queue are removed. This ensures that if the message is resubmitted it is not identified as a duplicate and is processed as a new message.

If an error occurs in reading data, including a timeout waiting for data or the closure of a connection while waiting for the full record, the data is sent to the Failure terminal. If the Failure terminal is not connected an exception is thrown. If the Retry mechanism property for the node is not set to Failure, the node retries until the data is successfully retrieved or until the number of retry attempts defined by the Retry threshold property is exceeded.

For information about HL7, see Health Level Seven International.

The GenericHL7Input node is contained in the Healthcare drawer of the message flow node palette, and is represented in the IBM Integration Toolkit by the following icon:

When a GenericHL7Input node is used in a message flow, messages passed to the Out terminal contain parsed HL7 messages with leading and trailing MLLP bytes removed. The message tree contains MQMD and MQRFH2 headers so that the message can be written directly to a queue if required. The body of the message contains an HL7 message in the MRM domain. The message flow is responsible for returning an acknowledgment (ACK) to the requester.

The GenericHL7Input node is transactional. When the message flow in which it is used ends successfully, all messages written under the transaction are committed, including the message to the queue that saves IDs for duplicate detection.

If there is a failure in the GenericHL7Input node, the message is passed to the Failure terminal. LocalEnvironment.HL7 contains the fields shown in the following Environment table. These fields give information that is used to build a negative acknowledgment (NACK) or create an error message.

If the EndConnection is set to YES, the connection must be closed. This action occurs when the incoming message did not contain the correct MLLP delimiters and it is therefore assumed that the MLLP protocol is not supported.

The HL7RC (HL7 Return code) and ErrorCondition fields are available to provide information in the NACK that is returned to the requester.

The GenericHL7Input node is transactional. When the message flow in which it is used ends successfully, all messages written under the transaction are committed. If the message ends with an exception that is not caught, all messages written under the transaction are rolled back, including the message. This action includes the message to the queue that saves IDs for duplicate detection. You must determine which messages you want to be rolled back in these circumstances and ensure that other messages, for example error messages, are not written under the transaction.

When you have added an instance of a GenericHL7Input node into a message flow, you can configure it.

All mandatory properties for which you must enter a value (properties that do not have a default value defined) are marked with an asterisk.

The following tables describe the node properties. The column headed M indicates whether the property is mandatory (marked with an asterisk if you must enter a value when no default is defined); the column headed C indicates whether the property is configurable (you can change the value when you add the message flow to the BAR file to deploy it).