IBM® Integration Bus Healthcare
Pack builds on IBM Integration Bus to provide support for applications in healthcare environments.
IBM Integration Bus Healthcare
Pack provides the following features:
- Message models that you use to parse, route, and transform HL7 messages in a message flow, see Message models
- Input and output nodes for integrating HL7 clinical applications with your message flows, see HL7 nodes
- Integration with medical devices,
so that you can capture data, see Medical device integration
- Integration with DICOM Picture Archiving Communication
Systems (PACS) and DICOM modalities, so that you can
locate, process, and transfer DICOM images by using message
flows, see DICOM image integration
- Healthcare-specific patterns that you can
use to generate solutions for connecting medical applications, see Healthcare patterns
- Generation of ATNA audit events to
support patient information confidentiality, data integrity, and user accountability, see ATNA audit events
- The capability to extract information from healthcare data in
message flows and to send the information to data warehouses for analysis,
see Healthcare data analysis
- Conversion of HIPAA files to XML files by using the Healthcare: HIPAA to XML pattern, see Healthcare patterns
- Patterns to help you to create integration solutions that conform to Integrating the Healthcare
Enterprise (IHE) PIX, PDQ, and XDS integration profiles, see Healthcare patterns.
The following diagram shows the basic architecture of an IBM Integration Bus Healthcare
Pack
configuration. It shows how IBM Integration Bus Healthcare
Pack 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.
Message models
IBM Integration Bus Healthcare Pack Version
4.0 includes two message models for processing
HL7 messages:
- DFDL message model
- HL7v25P
message set
- DFDL message model
DFDL (Data Format Definition Language) is a universal,
shareable, non-prescriptive description for general text and binary formats that is used in IBM Integration Bus to define message models. For more information about the use of
DFDL in message models, see Message models in the IBM Integration Bus product
documentation.
Note: The
HL7v25P
message set that is available in
IBM WebSphere® Message Broker Connectivity Pack for
Healthcare Version 7.0 is still supported. However, it is recommended
that the
DFDL message model is used for new and updated
applications if possible, as this model has the following benefits.
- DFDL is an open-standard
format whereas MRM and
the HL7v25P
message set are proprietary
to IBM Integration Bus.
- The DFDL editor provides
simpler tools for developing and testing extensions to the HL7 schema compared to MRM and the HL7v25P
message set.
- The DFDL message model supports HL7 versions 2.7, 2.6, 2.5.1
and earlier whereas MRM and
the HL7v25P
message set only support HL7 version 2.5.1 and earlier.
IBM Integration Bus Healthcare
Pack provides three versions of the DFDL message model, one for HL7 version 2.7, one for HL7 version 2.6, and one for HL7 version 2.5.1 and earlier. Each DFDL message model includes a definition of a generic HL7 message. This generic HL7 message is used with the DFDL parser in the pattern to read messages from the source
clinical applications, and write the messages to the destination clinical applications. This HL7 message can process any valid segment that is defined in
HL7 versions 2.7, 2.6, 2.5.1 or earlier.
Note: You can download the
DFDL message model from the pattern
resources for the
Healthcare: HL7 to HL7 DFDL pattern. For more
information, see
Integrating with HL7 applications.
Note: The HL7 patterns that are also available in IBM WebSphere Message Broker Connectivity Pack for
Healthcare Version 7.0 (Healthcare: HL7 to HL7 pattern, and Healthcare: Medical Devices to EMR pattern) use the HL7v25P
message set. However, use of the DFDL message model was introduced in the IBM WebSphere Message Broker Connectivity Pack for
Healthcare Version 8.0, in the Healthcare: HL7 to HL7 DFDL pattern. The DFDL message model is used in the patterns that were added in IBM Integration Bus Healthcare
Pack Version 3.0 (Healthcare: HL7 Transformation and
Healthcare: Home Health patterns.)
- HL7v25P
message set
The HL7v25P
message set includes a definition of the generic HL7 message. This generic HL7 message is used, with the MRM parser in the pattern, to
read messages from the source clinical applications, and write 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.
Although it is recommended to use the DFDL message model instead
of the HL7v25P
message set, there are situations when you might prefer
to use the HL7v25P
message set. For example, if you convert data from
the HL7v2 non-XML standard to an XML representation by
using the HL7v25P
message set, it is not necessary to rename the
elements of the message tree.
Note: You can download the
HL7v25P
message set from the pattern
resources for the
Healthcare: HL7 to HL7 pattern. For more information,
see
Integrating with HL7 applications.
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 your chosen message model 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
message models 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 message model.
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 model, 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.
HL7 nodes
If you are using the
DFDL message model, then the following
HL7 nodes are provided for you to use in your message flows to
send and receive
HL7 messages:
- HL7DFDLInput, 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.
- HL7DFDLOutput, which you can use to pass HL7 messages to a destination over MLLP and to check that a
valid acknowledgment is received.
For more information about these
HL7 nodes, see
HL7DFDLInput node and
HL7DFDLOutput node.
If you are using the HL7v25P
message set, then the followingHL7 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 HL7 messages to a destination over MLLP and to check that a
valid acknowledgment is received.
For more information about these
HL7 nodes, see
GenericHL7Input node and
GenericHL7Output node.
Medical
device integration
IBM Integration Bus Healthcare
Pack 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 nurse's
monitoring station.
Each device is connected to a separate communications port (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.
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 integration server 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 you change
the measurements that are required, or change 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 that are
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 the administrator is 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 that flows from the MedicalDeviceInput node can be
processed by a message flow by using any of the nodes available to you in IBM Integration Bus. 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 IBM Integration Bus capabilities, before it is written to target endpoints, for
example, databases, IBM WebSphere MQ queues, or service calls.
For more information about using the MedicalDeviceInput node,
see Using data from medical devices in message flows and MedicalDeviceInput node.
DICOM image
integration
DICOM (Digital Imaging and
Communications in Medicine) is a standard for handling, storing, printing, and transmitting medical
image information. The information can include DICOM images
and DICOM Structured Reports (SR).
You can use IBM Integration Bus Healthcare
Pack to connect DICOM PACS
(Picture Archiving Communication Systems) and other DICOM
modalities to message flows to allow location, processing, and routing of DICOM images across a healthcare system.
The
DICOM capability that is provided by the
IBM Integration Bus Healthcare
Pack supports a number of key scenarios.
- Collect studies for patient admission
- When a patient is admitted to hospital, you can query DICOM PACS that are in one or more locations to find and
retrieve any studies for the patient. The relevant medical images are then immediately available to
the clinical staff who are treating the patient. For more information about this scenario, see Collect studies for patient admission.
- Second opinion or expert referral
- In locations where radiology skills are limited, you can route DICOM images (for diagnosis or research purposes) to
specialists in other hospitals in a healthcare system. For more information about this scenario, see
Second opinion or expert referral.
- Clinical portal
- You can use a web application to display details of a patient's DICOM studies. In this scenario, only the attributes of the
study (not the image data) are presented, for example, the modality and the date and time of the
study. For more information about this scenario, see Clinical portal. This scenario is also implemented in the Healthcare: Web service to DICOM pattern in the IBM Integration Bus Healthcare
Pack.
IBM Integration Bus Healthcare
Pack includes three nodes.
- The DICOMInput node, which you can use to receive DICOM images from a DICOM Service Class User (SCU) node, for example a DICOM modality. By using this node, you can extract data from a
DICOM image for use in a message flow. This node supports
DICOM C-STORE requests.
- The DICOMOutput node, which you can use to send DICOM images to a DICOM Service Class Provider (SCP) node, for example a DICOM
Picture Archiving Communication System (PACS). By using this node, you can combine metadata from a
message flow with a DICOM image and send the result to an
external destination. This node supports DICOM C-STORE
requests.
- The DICOMFindMove node, which you can use to query an
external source for DICOM images that match given criteria
and optionally move the DICOM images to another location.
This node supports DICOM C-FIND and C-MOVE requests.
Note: The DICOM capability that is provided by the IBM Integration Bus Healthcare
Pack does not support DICOM
C-GET requests.
For more information about using
DICOM nodes in message flows, see
Using data from DICOM images in message flows.
Healthcare patterns
The
IBM Integration Bus Healthcare
Pack includes the following patterns:
- Healthcare: HIPAA to XML pattern
- The Healthcare: HIPAA to XML pattern creates a messages flow that you
can use to convert HIPAA files to XML files.
- Healthcare: Home Health pattern
- The Healthcare: Home Health pattern facilitates data that is recorded on
Home Health devices, such as scales, being transferred to the requesting clinical application. The
Home Health devices send data about patient readings to an Application Hosting Device (AHD). The AHD
sends the data over a WAN to the requesting application.
- Healthcare: HL7 to HL7 pattern
- The Healthcare: HL7 Transformation pattern generates graphical data maps
that you can use to assemble HL7 messages.
- Healthcare: HL7 to HL7 DFDL pattern
Note: There is another version of this pattern available (the
Healthcare: HL7 to HL7 pattern). However, it is recommended that the
Healthcare: HL7 to HL7 DFDL pattern is used for new and updated applications if
possible, as this pattern uses the
DFDL message model instead of
MRM and the
HL7v25P
message set. The
DFDL message model has the following benefits.
- DFDL is an open-standard
format whereas MRM and
the HL7v25P
message set are proprietary
to IBM Integration Bus.
- The DFDL editor provides
simpler tools for developing and testing extensions to the HL7 schema compared to MRM and the HL7v25P
message set.
- The DFDL message model supports HL7 versions 2.7, 2.6, 2.5.1
and earlier whereas MRM and
the HL7v25P
message set only support HL7 version 2.5.1 and earlier.
The Healthcare: HL7 to HL7 DFDL 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.
- Healthcare: Medical Devices to EMR pattern
- The 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.
- Healthcare: Web service to DICOM pattern
- The Healthcare: Web service to DICOM pattern integrates an application that is
written by using web services with DICOM applications that
support C-FIND and C-MOVE operations. You can use the pattern to query patients, studies, series,
and images from a DICOM PACS by using a web service that is
implemented by IBM Integration Bus.
- Healthcare: Patient Identifier Cross-reference Manager pattern
- The Healthcare: Patient Identifier Cross-reference Manager pattern enables you to use IBM
InfoSphere Master Data Management to help you to create a Patient Identifier Cross-reference Manager
for use in the Integrating the Healthcare Enterprise (IHE) Patient Identifier Cross Referencing
(PIX) profile. You can then connect your clinical applications to the pattern, to act as Patient
Identity Source and Patient Identifier Cross-reference Consumer actors, as defined in the PIX
profile.
- Healthcare: Patient Demographics Query Supplier pattern
- The Healthcare: Patient Demographics Query Supplier pattern enables you to use IBM InfoSphere
Master Data Management to help you to create a Patient Demographics Supplier for use in the
Integrating the Healthcare Enterprise (IHE) Patient Demographics Query (PDQ) profile. You can then
connect your clinical applications to the pattern, to act as Patient Demographics Consumer actors,
as defined in the PDQ profile.
- Healthcare: Cross-Enterprise Document Sharing Consumer pattern
- Use the Healthcare: Cross-Enterprise Document Sharing Consumer pattern to find document Unique
Universal Identifiers (UUID) stored in an XDS registry and then use the UUID to retrieve those
documents from the XDS repository. For more information, see Healthcare: Cross-Enterprise Document Sharing
Consumer pattern.
- Healthcare: FHIR Transformation pattern
- Use the Healthcare: FHIR Transformation pattern to transform HL7 FHIR
resources between XML and JSON formats. The HL7 FHIR standard is a Draft Standard for Trial Use
(DSTU), rather than a full normative specification. For more information, see Healthcare: FHIR Transformation pattern.
For more information about the patterns, see Developing healthcare integration solutions by using the patterns supplied in IBM Integration Bus Healthcare Pack.
ATNA audit events
The ATNA (Audit Trail and Node Authentication)
Integration Profile covers several aspects of security, including the standards and processes for
securely routing and storing audit event messages in a repository. Using an ATNAAudit node, you can generate ATNA audit event messages from the healthcare data that is
routed through message flows and send these audit event messages to a specified ATNA audit repository.
For
information about auditing data in message flows, see Auditing data from message flows.
Healthcare data analysis
You can use the
IBM Integration Bus Data Analysis perspective with a Data Analysis profile provided
by
IBM Integration Bus Healthcare
Pack to analyze and filter healthcare data in your message
flows. Healthcare data is often carried in complex documents and messages that are not easily
processed by downstream applications. Using a Data Analysis project, you can analyze healthcare
data, extract key elements, and create a simplified message structure that can be mapped directly
into the database tables that are used by business intelligence tools.
IBM Integration Bus Healthcare
Pack provides four Data Analysis profiles. Each profile is used for
a specific type of healthcare data.
- The HL7 v2 (ORU) profile is used for analyzing ORU (Observation Result)
message data
- The HL7 CDA profile is used for analyzing CDA (Clinical Document
Architecture) documents
- The HL7 v2 profile is used for analyzing otherHL7 data
- The DICOM profile is used for analyzing DICOM data
For more information about analyzing healthcare data, see Analyzing healthcare data in message flows.