IBM Integration Bus includes the Healthcare sample. This sample is a basic example of the Healthcare: HL7 to HL7 pattern, which is included as part of IBM WebSphere Message Broker Connectivity Pack for Healthcare.
Introduction to IBM WebSphere Message Broker Connectivity Pack for Healthcare
IBM WebSphere Message Broker Connectivity Pack for Healthcare builds on IBM Integration Bus to provide support for applications in healthcare environments.
IBM WebSphere Message Broker Connectivity Pack for Healthcare provides the following features:
- A healthcare-specific pattern to generate solutions for connecting clinical applications, see Healthcare pattern
- Two HL7 nodes, GenericHL7Input and GenericHL7Output, for using HL7messages in your message flows, see HL7 nodes
- Operational monitoring of data transmission to medical applications, see Operational monitoring
- The HL7v25P message set, which models the format of HL7 messages, see HL7v25P message set
The following diagram shows the basic architecture of an IBM WebSphere Message Broker Connectivity Pack for Healthcare configuration. It shows how IBM WebSphere Message Broker Connectivity Pack for Healthcare can connect to a wide variety of healthcare systems, including medical devices, clinical applications, device gateways, billing systems, and health information exchanges.
For more information about the IBM WebSphere Message Broker Connectivity Pack for Healthcare, see IBM Integration Bus.
Healthcare pattern
The Healthcare: HL7 to HL7 pattern that is included in IBM WebSphere Message Broker Connectivity Pack for Healthcare mediates between clinical applications that use the HL7 v2 standard for messages. For example, a Patient Administration System (PAS) might issue messages that are distributed to one or more clinical applications that require the patient information.
The pattern is not constrained to deal with messages of a single HL7 type (for example ADT) and code (for example A01), but can receive and process any message with a valid message type and code. For more information about HL7, see Health Level Seven International.
The pattern contains three different message flows (if you choose multiple destinations, you get additional message flows).
- Receiver flow
-
The Receiver flow receives HL7 v2.x messages from an HL7
clinical application. This connection uses the MLLP protocol over TCP/IP. Messages are stripped of MLLP
bytes, and the resulting record is parsed against the HL7 message type that is
defined in the HL7v25P message set , which models all the standard HL7 segments. The HL7 message type represents a generic HL7 message, and all segments in the incoming message are read. Any filtering of segments
occurs in subsequent flows.
After processing the message, this flow puts the message on a WebSphereMQ queue, from where it is read by subsequent flows in the pattern, and then returns an acknowledgment to the source application. After the message has been sent, the remaining flows ensure that the message data is not lost, and the message is either sent to all destinations or sent to an error queue.
- Transform and Route flow
-
The Transform and Route flow prepares the HL7 data for all the required
destinations. For each destination:
- A filter is applied to determine whether the message is required for that destination. This message filter is configured from the pattern parameters.
- When a message is required for a destination, a segment filter is applied. The segment filter, which can also be configured from pattern parameters, removes any segments in the incoming message that are not required by, or cannot be processed by, the clinical application to which the message is sent.
- Finally, the Transform and Route flow sends the message to the queue for the Sender flow for this destination.
The Transform and Route flow includes subflows, which you can customize. These subflows can include the transformation of data for clinical applications that might contain non-standard features. You can use these customization points to make changes, without changing the structure of the overall flows.
- Sender flows
- A separate Sender flow is created for each destination. A Sender flow is single threaded, and after resequencing the messages the Sender flow sends each message to its correct destination. If a message arrives out of sequence, it is stored on a sequencing queue until it can be sent.
When you use the Healthcare: HL7 to HL7 pattern, you must configure the processing of the incoming HL7 message, the number of destinations that you require, and how to transform the messages for each destination. Details about the configuration are given in the pattern specification that is displayed when the Healthcare: HL7 to HL7 pattern is selected in the Patterns Explorer view .
- Duplicate detection
-
The option to detect duplicates is managed in the Receiver flow. The HL7 message
identifier for each message is checked against the identifiers of all previous messages that were received
within a specified time frame. If a duplicate identifier is found, that message is not processed, but the
same acknowledgment is returned to the source application that was returned with the first message with
that identifier.
If you want to know when duplicates occur, the pattern also optionally reports any duplicates that it finds.
- Message sequencing
- In some cases (for example, registering a patient before requesting a test), it might be important that messages are received by the clinical applications in the order in which they were generated. You can configure the message sequencing capabilities to support correct sequencing.
- Reports and notifications
-
You can configure the pattern to provide output in addition to passing messages to the configured
destination applications. The pattern can provide:
- Reports about duplicate messages.
- Reports about additional fields that are not modeled in the HL7 message set.
- A copy of the source message in HL7 format to a WebSphereMQ queue, or publication point, to allow other IBM WebSphere Message Broker Connectivity Pack for Healthcare message flow applications to process the messages. You might use these copies of the message to feed a data warehouse, for auditing, or for journaling beyond that supported in the pattern.
- A copy of the message in HL7 v2 format with the MLLP bytes removed, after the first customization flow has been applied. You might use these copies of the message to feed other IBM WebSphere Message Broker Connectivity Pack for Healthcare message flow applications.
- Reports about messages that arrive out of sequence.
- Error messages to assist with the discovery and resolution of problems.
HL7 nodes
- GenericHL7Input, which you can use in a message flow to receive HL7 messages to process in your message flow and to determine whether a message is a duplicate
- GenericHL7Output, which you can use to pass messages to a destination over MLLP and to check that a valid acknowledgment is received
IBM WebSphere Message Broker Connectivity Pack for Healthcare includes a Healthcare Operational Monitoring view within IBM Integration Explorer to monitor the flow of messages between your clinical applications, thus helping to identify and rectify any connectivity problems that arise.
Message flows that are generated as a pattern instance are defined with properties that enable the operational monitoring in IBM Integration Explorer to identify the TCP/IP connections of each message flow and the applications that are associated with each of these TCP/IP connections. Therefore, the monitoring panels can display a warning icon that identifies when an application is disconnected so that the administrator can take remedial action.
The TCP/IP monitoring panel can also display the state of the TCP/IP connections that are part of message flows that have not been generated by the Healthcare: HL7 to HL7 pattern; for example, flows developed by using the HL7v25P message set . These flows do not have the additional information that is configured by the pattern instance unless the flows are defined with the same properties as those properties used by the pattern.
The Healthcare Operational Monitoring view for operational monitoring also displays the status of queues that are used by the message flows of a pattern instance. All queues for a given pattern instance are named with a queue prefix specific to the pattern instance. The use of a queue prefix enables an administrator to view all the queues for a pattern instance, monitor the queue depth, and identify when a threshold is reached, which is indicated by a warning icon that is displayed for the queue. The ability to view all the queues enables further problem determination, in particular the buildup of messages on sequencing queues, which indicate that a missing message in a sequence is causing following messages to be held for delivery until the missing message arrives. This action ensures that you can take remedial action to keep the messages flowing from source to destination.
You can monitor queues, in the same way as TCP/IP connections, in Healthcare message flow applications that are developed by using the HL7v25P message set . If monitoring is required, the queues that you want to monitor must all be named with the same prefix to allow grouping of information for the clinical application on the monitoring displays.
HL7v25P message set
If you are an existing user of the HL7v25P message set that is provided with the IBM Integration Bus Healthcare sample, you are familiar with the CIM canonical message set. The IBM WebSphere Message Broker Connectivity Pack for Healthcare does not use the CIM canonical form, but provides an additional XML wire format layer on the HL7v25P message set . While you can use the XML wire format layer to hold a platform independent representation of your data, you should note that this format is not HL7 XML (as defined by the industry standard) and is also different to the previously supplied IBM CIM canonical form.
The HL7v25P message set includes a definition of the generic HL7 message that is used by the Healthcare: HL7 to HL7 pattern. This generic HL7 message is used, with the MRM parser in the pattern, to read messages that have any sequence of HL7 segments from the source clinical applications, and writes the messages to the destination clinical applications. This HL7 message can process any valid segment that is defined in HL7 version 2.5.1 or earlier.
Clinical applications can also communicate non-standard information by using Z-segments in HL7 messages. When you are using this type of message with the pattern, you can add additional non-standard Z-segments to the HL7 message to support these site-specific Z-segments .
When an HL7 message is read into the pattern instance, you can also use the HL7v25P message set to output the canonical form (XML format), which is generated after the first customization point. The canonical form that is output by the pattern is not HL7 XML, but you can use it to hold a representation of your data that is platform independent. This data might be in the form of standardized dates and times, formatting of numbers, or any other data standardization requirement that is imposed.
The generic approach of the Healthcare: HL7 to HL7 pattern produces message flows that handle any HL7 segment. You might also be required to handle the exchange of a specific HL7 message between clinical applications. The HL7v25P message set can also process HL7 messages of a specific type and event code. If you want to implement message flow applications that process a message for a specific HL7 chapter, the messages must be read, and written, by using the appropriate message type from the chapter definitions in the HL7v25P message set . HL7 divides all its messages into groups that are called chapters, which correspond to the chapters of the HL7 standard. When you are working with specific HL7 messages from the message set, it is possible to output the messages in either HL7 format or in HL7 XML format. Using these formats also simplifies the use of graphical mapping in the transformation of a message between source and destination messages.