Design of the Healthcare: HL7 to HL7 pattern

The Healthcare: HL7 to HL7 pattern pattern uses the GenericHL7Input node to read incoming HL7 messages completely; no restrictions exist on the segments that you can include in a message, provided that the segments are present in the HL7v25P message set that is used by the pattern. The pattern uses the HL7v25P message set that is included with IBM Integration Bus Healthcare Pack. The HL7v25P message set includes definitions of all segments that are valid and standard at HL7 version 2.5. You can add additional Z-segments to this HL7v25P message set. Z-segments are used by applications to send or receive data that is defined outside the HL7 specification.

Sequence numbering, duplicate checking, and HL7 acknowledgment are carried out once, by the Receiver flow, on the source message.

The pattern defines the number of destinations to which an incoming message is distributed. For each destination, the message is processed and filtering is applied. This filtering determines whether the message is required for the destination, and which of the segments in the source message to include in the output message.

The Sender flow for each destination ensures that messages are sent in the correct sequence to the destination application.

Processing the source message by using the GenericHL7Input node

An input message is initially read by the GenericHL7Input node in the Receiver flow as a BLOB message. Before parsing, the leading MLLP bytes are removed. If the leading byte is not found, the message is rejected because the sender is not following MLLP protocol, the connection is closed, and a negative acknowledgment (NACK) response message is sent.

The GenericHL7Input node parses the message according to the HL7 message definition in the HL7v25P message set; see Resources for the Healthcare: HL7 to HL7 pattern. All segments are read, and if any segment has additional fields, these fields are placed in a Remainder field for that segment.

Message validation

No standard validation of message data is used in the Receiver flow. However, the presence of the following specific HL7 data fields in the MSH segment is confirmed, because these fields are required for processing to continue:

• MSH.1.FieldSeparator
• MSH.2.SeviceString
• MSH.3.SendingApplication
• MSH4.SendingFacility
• MSH.10.MessageControlID
• MSH.11.ProcessingID
• MSH.12.VersionID

Duplicate processing option

Each incoming HL7 message has a MessageControlID field in the MSH header segment that identifies the record.

The pattern parameters that control duplicate checking are used to set the equivalent properties on the GenericHL7Input node.

If the Check duplicates check box in the IBM Integration Bus Toolkit is selected, all identifiers are stored on the duplicate queue together 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.

Identifiers are stored on the duplicate queue for a given time, after which they are deleted and messages with the same identifier are no longer treated as duplicates. The default time period for storing message identifiers is 24 hours, but you can change the time by using a pattern parameter. The duplicate queue must be sized 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 through 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, or if any other error occurs in the GenericHL7Input node, the message is passed to the Failure terminal and the environment contains a description of the error.

Transformation and routing

The TransformAndRoute flow reads an HL7 message from the queue.

Remainder fields

If the Report remainders parameter is selected, a check is made for Remainder fields, which are additional fields that are found within a segment but are not modeled in the HL7 message that is used to parse incoming messages. If Remainder fields are found, these are either written to a queue or published. This option is used during development to identify the additional fields and determine how they are processed.

XML canonical form

The HL7 message is transformed into its XML canonical form and passed to the SubCustomize subflow. By default this subflow does nothing except pass on the message. However, the subflow provides a place where you can introduce customization for a particular pattern instance without changing the structure of the flow.

If the Canonical feed parameter is selected, the canonical form is output at this time, see Output from a pattern instance. You can use the canonical form of the input message as a feed to other applications that do not accept basic HL7 messages.

Distribution to destinations

The pattern provides for up to six destinations for each part of the pattern. You can configure each destination separately. If you select fewer than six destinations, only the selected destinations are configured. For each destination, the TransformAndRoute flow sends a copy of the message to the filtering subflow for the TransformAndRoute flow. For each destination, a filter is applied to determine whether an incoming message is sent to the destination. A filtering subflow for each destination, DestnFilter, where n is the number of the destination, is configured by pattern parameters to generate a list of permitted pairs for message code and message event. Only messages that match are passed to the destination application.

A dummy message is passed to the sender DestnSender subflow, where n is the number of the destination, whenever a message is filtered out, except when the Sequencing action parameter for a destination is set to No sequencing . This dummy message is required so that correct sequencing of messages from the source is maintained.

Segment filtering

After message filtering, each required message is transformed back into HL7 format. If the Segment filtering parameter is selected, any segments that are listed in the Segment filters table for the destination are removed as part of the transformation.

Customization

The message is then passed through a customization subflow. By default, this subflow does nothing except pass on the message. However, the subflow provides a place where you can introduce customization for a particular pattern instance. Finally, the message is written to the queue for the Sender flow.

Sender flows

A separate message flow, DestnSender subflow, where n is the number of the destination, is created for each destination.

Resequencing

Sequencing for a destination can be either strict or lax, which is determined by the Sequencing action pattern parameter. If Strict sequencing is selected, a Resequence node is included in the Sender flow with an indefinite timeout. If messages arrive out of sequence, they are held on the sequencing queue until the missing messages arrive. If this option is chosen, the system queue that holds pending messages must be monitored and action taken to supply missing messages.

For each message that is successfully delivered to a destination, the sequence numbers from source, and any resequencing in the Sender flow, are written to the queue QueuePrefix.SEQNOS, where QueuePrefix is defined by the Queue prefix parameter, together with a time stamp and the sequence group that corresponds to the destination specified as Destn, where n is the number of the destination.

Even with strict sequencing, some messages are not passed to a destination if the Message filtering option is selected. In this case the dummy messages, which represent those message that are not for delivery, are removed after resequencing and new sequence numbers are applied to the following messages before they are passed to the destination.

If the Lax sequencing option is selected, messages are generally delivered in sequence, but if a message is missing after the period of time specified by the Sequencing timeout parameter, a message is sent to the notification queue and the flow of messages continues. The missing message is inserted into the flow when it arrives. When a missing message arrives, it is also written to the .SEQNTFY queue.

By default the system sequencing queues are defined as:

• SYSTEM.BROKER.EDA.EVENTS
• SYSTEM.BROKER.EDA.COLLECTIONS

If the Separate sequence queues parameter is selected for a pattern, sequencing queues specific to the pattern instance are defined by using the Queue prefix parameter as:

• SYSTEM.BROKER.EDA.QueuePrefix.EVENTS
• SYSTEM.BROKER.EDA.QueuePrefix.COLLECTIONS

These nondefault sequencing queues are defined by a configurable service called patternInstance_setSeqQs . The pattern instance creates a file called patternInstance.resequence.configurableservice with a definition of this service that must be created on the integration node on which the pattern instance runs. The Sender flows are also configured to use this configurable service.

If no sequencing is required for a destination, the Resequence node and the report on missing messages are omitted from the flow.

Send and retry in the GenericHL7Output node

The GenericHL7Output node prepares a message for the destination application, changing it into a bit stream and adding the required Minimal Lower Layer Protocol (MLLP) delimiter byte, 0B , to the beginning. The GenericHL7Output node then forwards this prepared message to the TCP/IP output node, which tries to send the message to the destination application.

If the destination application returns an AA success code, the Environment.PatternVariables.FlowMilestoneReached variable is cleared and the message is passed to the Out terminal.

If the destination application returns an AE response code, the Environment.PatternVariables.FlowMilestoneReached variable is set to ACKAE and the message is passed to the Failure terminal. No retries are made after an ACKAE response.

If the message is successfully sent but no acknowledgment is received, or an invalid acknowledgment is received, it is treated in the same way as an AE response, but the Environment.PatternVariables.FlowMilestoneReached variable is set to TIMEOUT , RECEIVEACK , or ACKERROR before the message is passed to the Failure terminal. No retries are made.

If the GenericHL7Output node fails to send the message to the destination, or if an AR acknowledgment is returned from the destination, the message is passed to the Log Retry terminal. The message is retried when control is returned after logging until it is successful or until the number of retries reaches the limit set by the Retry limit parameter.

When the retry limit is reached, the Environment.PatternVariables.FlowMilestoneReached variable is set to ACKARTOOMANYREPEATS and the message is passed to the Failure terminal.

Message validation

Content validation is selected on a destination basis by using the Validation parameter in the Destination communications section. When validation is selected for a destination, the Validation parameter is set to Content on the MQInput node for the relevant Sender flow. The Parse timing property on this node is defined by the pattern as Immediate so that validation occurs before any further processing. The validation gives only validation of the message against the HL7v25P message set. It does not provide full HL7 validation of dependent fields for example.

HL7v25P message set

The HL7v25P message set is used with the MRM parser to parse and write HL7 messages. The resulting message tree can be serialized to an XML canonical form. The message definitions are flexible enough to tolerate local variations without requiring customization, and they can also be extended to allow the parsing of locally defined Z-segments and extra fields. Where local variations occur and the data in these local variations must be processed, the HL7 model must be modified so that it conforms with a matching specification to ensure all data can be accessed.

The canonical form can be used by your organization to hold a representation of your data that runs on any operating system. This data can be in the form of standardized dates and times, formatting of numbers, or any other data standardization requirement that is imposed by your organization. The canonical form represents a separation of the source and destination applications, enabling maximum reuse and minimizing maintenance. A customization subflow for this canonical form is included in patterns that you generate.

The HL7v25P message set contains global element definitions for all segments that are defined in the HL7 v2.5 specification. The components and subcomponents in each segment are modeled with the correct delimiters. You can use a generic message definition with the name HL7 to parse any sequence of HL7 segments.

Output from a pattern instance

In addition to the HL7 messages routed to specified destinations, this pattern provides a number of other outputs. These outputs are either written to a queue or sent to a Publication node. The destination is determined by the pattern parameter Publish . If the Publish option is selected, all information is published by using a topic hierarchy that begins with the pattern instance name.

If the Write to Queue option is selected, output is sent to queues with names that are generated from the pattern parameter Queue prefix and a fixed set of suffixes, as shown in the following table.

Note: The initial facet of each topic and queue (the pattern instance name) is not shown.