Introduction to IBM WebSphere Message Broker Connectivity Pack for Healthcare

IBM® WebSphere® Message Broker Connectivity Pack for Healthcare builds on WebSphere Message Broker to provide support for applications in healthcare environments.

IBM WebSphere Message Broker Connectivity Pack for Healthcare provides the following features:

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.

This diagram 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 HL7, see Health Level Seven International.

Start of change

Medical device integration

IBM WebSphere Message Broker Connectivity Pack for Healthcare includes an input node, the MedicalDeviceInput node, which enables information from connected medical devices to be passed into a message flow. By using this node, you can develop message flows to send medical device data to other systems, for example, a data warehouse, or to a nurses monitoring station.

The devices themselves are each connected individually to separate communications ports (either serial or LAN), and device drivers within the MedicalDeviceInput node are configured to listen on these communications ports. The node configuration identifies the connected devices, and the measurements that are required from each device.

This diagram shows the flow of data from the clinical appliances to the device drivers. The flow then goes to the MedicalDeviceInput node, which sends the status and data information to the rest of the flow.

The diagram shows the flow of data from the clinical appliances at each of Bed 1, Bed 2, and Bed N to the device drivers. For example, from the heart-rate monitors to Driver 1, and from the infusion pumps, through an execution group to Driver 2. The flow then goes to the MedicalDeviceInput node, which sends the status and data information to the rest of the flow.

Configuring the MedicalDeviceInput node

The flow of data from message flows must not be disrupted when the device configurations are updated; for example, when changing the measurements required, or changing the physical connections as devices are added, disconnected, or moved. The configuration data is, therefore, held as a configurable service so that configuration changes can be implemented by the node without the requirement to stop or redeploy the message flow that is receiving the medical data.

The MedicalDeviceInput node is configured by using the Properties tab, which starts an editor for the configurable service. In the Medical Device Configurable Service editor, an administrator first selects the device type from a list of supported devices, then selects the communications type (serial or LAN), and provides the appropriate communications details.

Measurement sets

It is frequently the case that a number of devices of the same type are required to provide the same types of measurement at the same intervals, for example, the heart rate, blood temperature, and respiration rate every 5 minutes. This requirement might be true of a number of devices deployed at all beds in a ward. The Medical Device Configurable Service editor therefore supports the configuration of measurement sets, which specify a number of measurements and can be applied to any number of devices.

When configuring a measurement set, the administrator selects a device type and is presented with a list of measurements that are supported by that device type. The administrator can select the required measurements, and for each measurement the administrator specifies the interval at which measurements are passed into the message flow for processing.

Where many devices and measurements require configuring, the configuration data might be extensive. Therefore, to add clarity, the administrator can provide a description of the location of each device, patient ID information, notes and tags for each device and measurement set.

Using the MedicalDeviceInput node in message flows

The data flowing from the MedicalDeviceInput node can be processed by a message flow by using any of the nodes available to you in WebSphere Message Broker. The measurement data is passed into the message flow as a logical message tree. The message tree uses the DataObject domain and has XML as its serialization format (the message is serialized to XML if the message is written to a message queue). This data can be filtered, transformed, aggregated, and routed, by using standard WebSphere Message Broker capabilities, before being written to target endpoints: databases, WebSphere MQ queues, or service calls, for example.

For more information about using the MedicalDeviceInput node, see Using data from medical devices in message flows and MedicalDeviceInput node.

End of change

Healthcare patterns

The IBM WebSphere Message Broker Connectivity Pack for Healthcare includes the following patterns:
Healthcare: HL7 to HL7 pattern

The Healthcare: HL7 to HL7 pattern mediates between clinical applications that use the HL7 v2 standard for messages. For example, a Patient Administration System (PAS) might issue a single message that is 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. The applications must be able to send and receive the messages by using MLLP over TCP/IP.

The pattern contains three different message flows (if you choose multiple destinations, you get additional message flows) and includes subflows that you can customize.

This diagram shows the message flows in the Healthcare: HL7 to HL7 pattern. The source application sends the message by using MLLP over TCP/IP to the Receiver flow. The Receiver flow uses WebSphere MQ to send the message to the Transform and Route flow. The Transform and Route flow uses WebSphere MQ to send the message to one or more Sender flows. The Sender flows then use MLLP over TCP/IP to send the message to the destination application.

 

Start of changeHealthcare: Medical Devices to EMR patternEnd of change
Start of changeThe Healthcare: Medical Devices to EMR pattern integrates medical devices with an Electronic Medical Record (EMR) application that can receive HL7 v2 observation result messages (ORU R01). The application must be able to receive HL7 ORU R01 messages by using MLLP over TCP/IP. The pattern includes subflows that you can customize.
This diagram shows the message flows in the Healthcare: Medical Devices to EMR pattern. The medical device sends the message to the Medical Devices flow. The Medical Devices flow uses WebSphere MQ to send the message to the Transform and Route flow. The Transform and Route flow reads patient information from a database, which is updated by a Web Services flow with information from a clinicians dashboard. The Transform and Route flow uses WebSphere MQ to send the message to a Sender flow. The Sender flow then uses MLLP over TCP/IP to send the message to the destination application.
End of change
Start of changeHealthcare: HL7 to Reports patternEnd of change
Start of changeThe Healthcare: HL7 to Reports pattern integrates an application that can send HL7 v2 messages with report generation. The source application must be able to send and receive HL7 messages by using MLLP over TCP/IP. The pattern includes subflows that you can customize.
This diagram shows the message flows in the Healthcare: HL7 to Reports pattern. The source application sends the message by using MLLP over TCP/IP to the Receiver flow. The Receiver flow uses WebSphere MQ to send the on to the Processor flow, which generates a report.
End of change

For more information about the patterns, see Developing healthcare message flow applications by using the patterns supplied in IBM WebSphere Message Broker Connectivity Pack for Healthcare.

HL7 nodes

Two HL7 nodes are provided for you to use in your message flows to send and receive HL7 messages:
  • 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

For more information about the HL7 nodes, see GenericHL7Input node and GenericHL7Output node.

Operational monitoring

IBM WebSphere Message Broker Connectivity Pack for Healthcare includes a Healthcare Operational Monitoring view within WebSphere Message Broker Explorer to monitor the flow of messages between your clinical applicationsStart of change and the status of your medical devicesEnd of change. You can use this information to help you to find and fix any connectivity problems that arise.

Message flows that are generated as a pattern instance are defined with properties that enable the operational monitoring in WebSphere Message Broker 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.

This diagram shows the monitored connections both from the source application to the Healthcare: HL7 to HL7 pattern, and from the pattern to the destination applications.

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 one of the patterns in the IBM WebSphere Message Broker Connectivity Pack for Healthcare. 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.

You can monitor the status of medical devices that are connected to a Start of changeMedicalDeviceInputEnd of change node.

For more information about operational monitoring, see Operational monitoring.

HL7v25P message set

If you are an existing user of the HL7v25P message set that is provided with the WebSphere Message Broker Healthcare sample in WebSphere Message Broker Version 7.0, 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 patterns that are included in the IBM WebSphere Message Broker Connectivity Pack for Healthcare. 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 patterns, 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 a 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.

For more information about HL7, see Health Level Seven International.

Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 2011, 2012Copyright IBM Corporation 2011, 2012.

        
        Last updated
        
        Last updated : 2012-04-12 17:14:13


Concept topicConcept topic | Version 7.0.0.2 | ha00010