Integrating The Healthcare Enterprise With Websphere Message Broker V7.0

Integrating the Healthcare Enterprise with
WebSphere Message Broker V7.0

Extending the WebSphere Message Broker Healthcare sample
for real-world integration
Skill Level: Intermediate
Lee Surprenant (lmsurpre@us.ibm.com)

Software Engineer
IBM
15 Feb 2011
IBM® WebSphere® Message Broker Version 7.0 includes a set of healthcare assets
that let you work more effectively with HL7 messaging. In this tutorial, learn to use the
assets to build a hospital integration strategy centered on the patient identity
management profiles defined by the Integrating the Healthcare Enterprise (IHE) IT
Infrastructure (ITI) Technical Framework. Hands-on examples show how to extend
the WebSphere Message Broker Healthcare Sample to develop re-usable subflows
that leverage IHE Profiles for patient identity management. You can extend the
sample flows for your own HL7 and non-HL7 interfacing projects.
Section 1. Before you start
About this tutorial

There is global focus on healthcare transformation, with an emphasis on quality of
care at an affordable cost. Many studies highlight the role of IT in healthcare
transformation, and administrators and legislators are taking note. There is a
tremendous opportunity to responsibly break down silos of information that can
collectively enable improved care. Interoperability goals in healthcare IT include
Integrating the Healthcare Enterprise with WebSphere Message Broker V7.0 Trademarks
© Copyright IBM Corporation 2011. All rights reserved. Page 1 of 34
developerWorks® ibm.com/developerWorks
connecting applications to share data seamlessly and securely across the

healthcare ecosystem, and delivering the data to caregivers whenever and wherever
needed.
This tutorial:
• Introduces WebSphere Message Broker V7.0 and explores how it can be

applied in key healthcare integration scenarios.
• Builds on support for the healthcare messaging standards defined by
Health Level Seven International (HL7), and shows how to extend the
included healthcare sample into a flow that can perform message-based
routing.
• Explains how the Integrating the Healthcare Enterprise (IHE)
organization's technical frameworks can improve healthcare
interoperability for a select set of high-value integration scenarios.
• Builds upon the HL7 message router flow to develop a reusable subflow
that uses the IHE Patient Identifier Cross-reference (PIX) Query for
improved system integration through a federated patient identity
management solution.
Objectives
You will learn about important healthcare integration standards and how to use them
to implement a high-value patient identity management solution. This tutorial is a
hands-on introduction to the WebSphere Message Broker Healthcare sample. You
will also learn how to extend the samples to leverage IHE profiles to support your
own healthcare integration scenarios.
Prerequisites
No prior WebSphere Message Broker or healthcare integration experience is
assumed or required, though it might be helpful in understanding the concepts
faster.
To follow along with this tutorial, you will need:
• Access to systems with WebSphere Message Broker V7.0 and the

WebSphere Message Broker Toolkit.
• Access to an installation of Initiate Patient or any other Enterprise Master
Patient Index product that implements the IHE Patient Identifier
Cross-reference Manager technical actor (to complete the final steps in
ibm.com/developerWorks developerWorks®
the tutorial).
Resources has links to the prerequisite systems.
Section 2. The WebSphere Message Broker Healthcare

sample
WebSphere Message Broker is an advanced Enterprise Service Bus (ESB). Clients
from many different industries, including healthcare, use the broker at the heart of
their service-oriented architecture (SOA) for simplified application integration and
improved business agility. WebSphere Message Broker includes support for many
interface technologies and several pre-built application adapters to help businesses
build intelligent routing, mediation, and transformation flows that connect
heterogeneous endpoints that would otherwise be isolated within the enterprise.
WebSphere Message Broker Version 7 has a set of healthcare assets including HL7
v2 messaging models and processing assets for the Minimum Lower Layer Protocol
(MLLP). The assets are packaged as a pre-built Healthcare sample that you can
import and run from the WebSphere Message Broker Toolkit. Don't be fooled by the
term sample; the healthcare assets were developed and hardened through a series
of IBM Global Services engagements with medium to large healthcare providers.
Import and run the Healthcare sample

In the WebSphere Message Broker Toolkit, in the Healthcare sample's help
documentation, you can import and deploy the Healthcare sample in a single click.
You can also find the Samples and Tutorials launcher, as shown in Figure 1. (View a
larger version of Figure 1.)
Figure 1. Navigating to the Healthcare sample
After importing and deploying the Healthcare sample, be sure to look at the
generated projects and identify some of the Healthcare processing assets .
Using the WebSphere Message Broker Toolkit

flow tests for HL7 messages
To run the Healthcare sample you can use the predefined flow test
HL7_Text_Test_Message.mbtest to enqueue a sample HL7
message. When modifying this sample message, or creating your
own, note that HL7 v2 messages are typically made up of one or
more message segments separated by a segment terminator
(typically the carriage return character). Because it can be difficult to
create or detect this character in the provided text box, it is
recommended you view the message in hexadecimal to be sure
there is one, and only one, carriage return character (0x0d) between
each segment.
You're now ready to run the sample per the WebSphere Info Center Running the
Healthcare sample instructions.
The sample essentially does a series of enqueueing and dequeueing that tests the
sender and receiver flows, and the HL7-to-CIM and CIM-to-HL7 message
transformations, through a simple send and acknowledge scenario. After
enqueueing the sample message on HCA_TEST_ACK_APP_OUT, it is sent over an
HL7-defined transport MLLP to the Flows.Main Receiver.msgflow. This flow then

processes the message and returns an acknowledgement to the
SendingApplication. The acknowledgement is on the HCA_TEST_ACK_APP_OUT
queue.
The Receiver.msgflow also enqueues the original message on the

HCA_HL7_TO_CIM_IN queue, where it undergoes a transformation to the Common
Information Model (CIM) and back to HL7. The result of this round-trip
transformation is enqueued on the HCA_SENDER_IN queue, where it is picked up
by the Flows.Main Sender.msgflow and sent over MLLP to the ReceivingApplication
sample. The ReceivingApplication then places this message on the
HCA_TEST_RECEIVE_APP_OUT queue, where it can be dequeued and checked
in the HL7_Text_Test_Message.mbtest Test Client view.
Figure 2. Testing the Healthcare sample
When you're done reviewing the sample, be sure to stop the

HealthcareExecutionGroup but do not remove the sample from the broker or the
workspace. You'll be reusing these assets, including the newly created sample
queues, later in the tutorial.
Section 3. Integrating the Healthcare Enterprise (IHE)

IHE is a collaboration between healthcare professionals and industry to improve the
way healthcare computer systems share information. The organization is divided into
related clinical and operational domains. In each domain:
• Users with clinical and operational experience identify integration and

information sharing priorities.
• Vendors of relevant information systems develop consensus,
standards-based solutions to address those priorities.
Each IHE domain publishes its own technical framework, which both leverages and
constrains relevant standards from healthcare and information technology industries.
The framework defines a set of interoperable message exchanges, called
transactions, between information system actors. To solve a given use case or
medical scenario, transactions are grouped together into an IHE Profile.
Health Level Seven (HL7)

In many cases, IHE selects standards from Health Level Seven International, one of
the most prominent healthcare IT standards development organizations. There are
two major versions of HL7 standards: version 2.x and version 3.x. This tutorial
focuses primarily on version 2.x messages.
HL7 v2 allows flexibility, so system implementations are commonly incompatible or

require significant on-site design and customization to work together. To improve
this situation, IHE defined general guidelines for HL7 v2 messaging in Appendix C of
Volume 2x in its IT Infrastructure (ITI) Technical Framework. In addition, each IHE
Profile transaction may define its own requirements for implementers. IHE tests
conformance to the guidelines through various connect-a-thon events, and maintains
a product registry of vendor products that claim conformance. You can find links to
the guidelines and the directory in Resources.
Patient identity management

Arguably, the starting point for interoperability in healthcare is managing patient
identity. To accurately assemble and exchange patient data across application and
data silos, you must have a common identification of the patient. Many applications,
even within an enterprise, create their own patient identifiers. An Enterprise Master
Patient Index (EMPI) will track and manage patient identifiers across multiple
identifier domains. Volume 1 of the IHE IT Infrastructure (ITI) Technical Framework

defines the following set of profiles to help improve interoperability through patient
identity management:
• Patient Identity Cross-referencing (PIX)

• Patient Demographics Query (PDQ)
• Patient Administration Management (PAM)
In support of these profiles, Volume 2 of the Technical Framework defines a set of
numbered transactions, many of which are based on HL7 v2 messaging.
The rest of this tutorial focuses on two of the most frequently used patient identity
management transactions: the Patient Identity Feed (ITI-8) and the PIX Query
(ITI-9). You can find links to both volumes in Downloads.
Sample scenario: Patient Identity Feed router
The first message flow you'll develop is a patient identity feed router. This flow
provides a concrete example of extending the WebSphere Message Broker
Healthcare sample in the context of a simple message exchange that's widely used
in hospitals. The flow will take a compliant HL7 admit, discharge, transfer (ADT)
message and route it to a destination system by checking the intended receiving
application in the message header.
Although the routing flow is developed in the context of the Patient Identity Feed
transaction, you could develop a similar mechanism to handle a wide variety of
message types and transactions from a single endpoint.
Sample scenario: PIX Query Adapter
The second message flow is a PIX Query Adapter subflow that will:
• Take any HL7 input message

• Extract the patient identifier (PID) segment
• Perform a PIX Query using this information
• Replace the original PID with the result
You could use this subflow to adapt HL7 messages between systems so both the
source and destination applications can continue to use their own local identifiers.
This scenario builds on the Patient Identity Feed router to show how middleware
support of the IHE PIX profile can improve integration between various systems in a
healthcare enterprise.
Section 4. Building a Patient Identity Feed router
IHE ITI-8: Patient Identity Feed

HL7 versioning
As of fix pack 1, WebSphere Message Broker V7.0 supports HL7
v2.5.1, which is backwards compatible with previous versions of the
HL7 v2 messaging standards. The message model is more than
capable of handling the v2.3.1 ADT messages required by IHE
ITI-8.
The IHE ITI Patient Identity Feed transaction is based on a simple point-to-point HL7
v2.3.1 ADT message exchange from a Patient Identity Source actor to a receiving
actor, such as a Patient Identifier Cross-reference Manager. The transaction,
sometimes called an ADT feed, can represent a number of patient-related events,
including:
• Admission of an in-patient (A01)

• Registration of an outpatient (A04)
• Pre-admission of an in-patient (A05)
• An update to the patient information on record (A08)
Building a simple identity feed router

If both the sending and receiving systems support the IHE Patient Identity Feed
transaction, it should be possible to configure these systems to work together. Even
so, it might be helpful to use an ESB for routing functions and to improve the visibility
and governance of the architecture. For instance, it can be difficult to maintain
point-to-point integration through maintenance cycles, enterprise acquisitions and
mergers, and other enterprise transformation initiatives.
In the following example, you'll add a simple router for the enterprise patient identity
feeds so each source system can point to a central broker that properly routes their
request based on its header information.
To begin the new project:
1. Open the WebSphere Message Broker Toolkit and select New... -->
Message Broker / Message Flow Project, as shown below.
Figure 3. New project
You should see the New Message Flow Project shown in Figure 4.
Figure 4. Flow project references
Once you've created a new project, create a new message flow for the
Patient Identity Feed router flow. The simplest way to get started is to
base the flow on the existing sample.
2. Navigate to HealthCareAsset --> Flows --> Flows.Main and:
1. Copy the Receiver flow.
2. Paste a copy into your newly created project.
3. Rename it to something meaningful (such as

PatientIdentityFeedRouter).
4. Open the flow.
The IHE ITI Technical Framework requires the use of MLLP for HL7 v2 messages.
This protocol is supported in WebSphere Message Broker through the use of TCP/IP
and the Trim/Add MLLP Bytes nodes. After trimming the flow control bytes in the
Trim MLLP Bytes node, the Receiver.msgflow will attempt to parse the incoming
blob into a proper HL7 message.
Section C.2: "HL7 Implementation Notes" of the framework places several

restrictions on the use of HL7 v2 messages in an IHE transaction. In particular,
section C.2.2: "Message Control" requires systems to include Sending and
Receiving Application and Facilities in the message (MSH.3, MSH.4, MSH.5, and
MSH.6). To ensure that the guidelines are followed, you must add some additional
checks to the parse and validate CheckMSHFields procedure, as shown in Listing
1.
Listing 1. Parse And validate: CheckMSHFields() maximum width
...
SET env.ErrorCondition = 'MSH parsing or validation error: MSH.4.SendingFacility is null';
SET env.InputMSH.Field4= MSHFields.hl7:MSH.hl7:"MSH.4.SendingFacility".hl7:"HD.1";
--begin user add
SET env.ErrorCondition = 'MSH parsing or validation error: ' ||
'MSH.5.ReceivingApplication is null';
SET env.InputMSH.Field5= MSHFields.hl7:MSH.hl7:"MSH.5.ReceivingApplication".hl7:"HD.1";
'MSH.6.ReceivingFacility is null';
SET env.InputMSH.Field6= MSHFields.hl7:MSH.hl7:"MSH.6.ReceivingFacility".hl7:"HD.1";
'MSH.7.DateTimeOfMessage is null';
SET env.InputMSH.Field7= MSHFields.hl7:MSH.hl7:"MSH.7.DateTimeOfMessage";
'MSH.9.MessageType is null';
SET env.InputMSH.Field9= MSHFields.hl7:MSH.hl7:"MSH.9.MessageType";
--end user add
...
As discussed in the WebSphere Message Broker Healthcare sample information

(see Resources for the link), the Detect Duplicate node is an optional subflow that
will filter out repeat messages using the Message Control Identifier in MSH-10.
Similarly, the Add Sequence Number node is optional and will enable first-in/first-out
sequencing on messages in the flow. If you want to use message content-based
sequencing instead, you must remove this Sequence node from the sample and rely
on the source and destination applications to maintain sequence based on data in
the HL7 message. For the sample Patient Identity Feed router flow in this tutorial,
remove the sequence node from the flow.
To create a flow that will route all patient identity messages to their destination
systems using the value in the first component of the message's Receiving
Application field--MSH.5:
1. Remove the Prepare for MQ and Put to HCA_HL7_TO_CIM_IN nodes,

and replace them with a single Route node (found in the Routing pallete).
2. Once the node has been placed, you can add new output terminals.
Right-click the output terminals and select Add Output Terminal.
3. Now that you've created the output terminals, it's time to create the
routing rules.
Figure 5 and Figure 6 show how to create an XPath-based filter that will
use the value of MSH.5.ReceivingApplication to route the message to the

proper terminal.
Figure 5. Patient Identity Feed Route node expression builder
Figure 6. Patient Identity Feed Route node properties
You can also use a DatabaseRoute or simple Compute node to

accomplish a similar task. (View a larger version of Figure 6.)
The incoming messages are now routed by destination, so you can forward them to
their intended endpoints. One way to do this is to modify the sample's
Sender.msgflow into a subflow with a configurable destination. You can:
1. Copy and paste the flow into your new project.
2. Replace the MQInput node with a simple Input node.
3. Hook on an Output node at the end.
Be sure to remove the Maintain Sequence node in order to match your change to
the Receiver flow.
By default, the Check HL7 ACK node will parse and validate the response,
propagating a valid acknowledgement to the "out" terminal. Depending on the
properties of the destination application, you might need to relax the validation
constraints by removing the ValidateContent flag from the parse options on line
105 of Sender.esql in the Sender_Check_HL7_ACK Main() function, as shown
below.
DECLARE options INTEGER BITOR(ValidateException, ValidateDeferred);
If you want to propagate negative and positive acknowledgements, you must alter
the same function at line 137.
IF error THEN
--begin user add
PROPAGATE TO TERMINAL 'out' MESSAGE OutputRoot EXCEPTION OutputExceptionList
FINALIZE NONE DELETE NONE;
--end user add
THROW USER EXCEPTION VALUES('ACK message with AE or AR received');
ELSE
The message flow in Figure 7 will: take the sample message, convert it to a BLOB,
add the necessary MLLP bytes, and attempt to send it to the configured destination.
The flow has some advanced processing, including retry logic and a fairly robust
exception-handling mechanism that features logging based on environment
variables and processing checkpoints. (View a larger version of Figure 7.)
Figure 7. HL7 Sender subflow
The final step in subflow modifications is to promote the Send HL7 Message and
TCPIPClientReceive connection properties to the flow level.
1. Right-click anywhere in the flow and select Promote Property..., as

shown below.
Figure 8. Promote Properties
2. In Figure 9 you can allow a message flow to embed the Sender subflow
and set the destination on a per-node basis.
Figure 9. Promote the TCP/IP Connection details properties
You've altered Sender.msgflow and can use this subflow in the example Patient
Identity Feed Router, as follows.
1. Right-click in the flow editor and select Add Subflow....
2. Add as many subflows as needed.
3. Hook the Route node output terminals to the Sender subflow input
terminals.
4. Configure the Sender nodes' Connection details to point at the desired

endpoints.
Finally, because the destination systems will reply with their own acknowledgment
messages:
1. Replace the Build ACK node with a simple Reset Content Descriptor
node.
2. Configure it to reset the message domain to type BLOB to prepare the

reply for transmission to the original requester.
You should now have a flow that looks something like Figure 10. (View a larger
version of Figure 10.)
Figure 10. Patient Identity Feed Router
Deploying large message models

When deploying flows that reference large message models, such
as the model for HL7 v2.5, it is strongly recommended to place the
message models into their own broker archive file (separate from
the compiled message flows which reference them). You can save
significant time and resource by allowing the flows to be deployed
without forcing an update of the message model.
Ensure that the original sample message flows are not running (to avoid conflicts),
then:
1. Deploy your new Patient Identity Feed Router flow to the broker, along
with the SendingApplication, for testing.
2. Copy and paste the HL7 Message Tester to the new project, or replace
the original sample message with the contents of Listing 2.
Be sure to replace the new lines with proper carriage return characters. As
described in Using the WebSphere Message Broker Toolkit flow tests for HL7
messages, these characters are difficult to create in the editor. It's recommended
you either begin from the original sample message or import the new message by
clicking Import Source... and selecting the proper Listing.txt file from the sample
HL7 v2 messages provided with this tutorial (the link to that zipped file is in
Downloads).
Listing 2. Sample Patient Identity Feed message maximum width
MSH|^~\&|IBM Message Broker|IBM|HIE|IBM|20101118104152-0500||ADTÂ01ÂDT_A01|1|P|2.3.1

EVN||20101118081234-0500
PID|||xxx^^^&1.3.6.1.4.1.21367.2010.1.2.300&ISO||Works^Developer||19501010|F
PV1||I
Initiate Patient
Initiate Patient is one example of an EMPI that implements the Patient Identity
Consumer Actor in the IHE Patient Identity Feed Profile (see Resources for the link
to IBM Initiate Patient). If successful, the previous message would either create a
new record for our patient entity or, if one does not yet exist, a new entity altogether.
Figure 11 shows how the record might look in Initiate Inspector, a web-based viewer
for our Initiate Patient installation. By feeding disparate patient identities into a
system such as Initiate Patient, the enterprise can keep a single view of this patient
across each of their systems. (View a larger version of Figure 11.)
Figure 11. Initiate Inspector
Building an identity feed adapter with the Common Information

Model
Unfortunately, most enterprises deal with heterogeneous systems with varying
degrees of standards support. In such cases, an ESB can provide the most value
through mediation and transformation of message exchanges. A source and
receiver's HL7 implementations might be incompatible due to differing versions, local
"Z-segment" extensions, or perhaps a single side does not support HL7 messaging
at all. Regardless, you should be able to interface with them through WebSphere
Message Broker.
The preferred approach is to use the built-in Common Information Model (CIM) in a
"pivot" format between the systems. You can customize the CIM, which itself is
based on HL7 standards, as an internal messaging model without requiring the user
to modify the standard HL7 message model that's used for interfacing. The model is
designed to provide a canonical view of the message information with reduced
redundancy and improved clarity.
Section 5. Building a Patient Identifier Cross-reference

subflow
IHE ITI-9: PIX Query

The IHE ITI PIX Query transaction consists of an HL7 v2.5 query/response between
a Patient Identifier Cross-reference Consumer and a Patient Identifier
Cross-reference Manager. The transaction retrieves a list of patient identifiers for a
given input identifier. The Patient Identifier Cross-reference Manager role is often
played by a probabilistic EMPI system, such as Initiate Patient.
Anatomy of a PIX Query
A PIX Query request is based on the HL7 QBP_Q23_QBP_Q21 Get

Corresponding Identifiers message, which is made up of three required
segments:
MSH
Message Header
QPD
Query Parameter Definition
RCP
Response Control Parameter
Section 3.9.4.1.2 of "Volume 2a, IHE ITI Technical Framework" details the
requirements for each segment. For the example in this tutorial, the QPD segment
must contain a Person Identifier in the ID component of the QPD-3 field.
In most HL7 v2 messages, patient identification information is included within the

message in a special PID segment. To implement a reusable PIX Query subflow,
you can define a flow that accepts any source system's HL7 message with a PID
segment, and returns the same message with the PID segment replaced by the
corresponding identifier used by the destination system. Though this is just one
possible way to use the PIX Query transaction, it has the benefit of hiding the Patient
Identifier Cross-reference complexity from the end systems. End systems continue
using their local identifiers while reaping the benefits of a global patient
infrastructure.
Creating a basic PIX Query Adapter

First, create a new flow.
1. Go to the New Message Flow wizard and enter the information shown
below.
Figure 12. New Flow Wizard
2. Start off the flow by adding new Input and Output nodes from the
Construction pallete.
3. Put in a placeholder Validation node to validate the incoming message.
4. Create a new Mapping node from the Transformation pallete.

Figure 13. Start of the PIX adapter flow
5. After renaming the Mapping node, double-click it to open the Map node
editor.
Figure 14. New Message Map wizard
PIX Query Mapping node
Once the mapping editor has opened:
1. Expand $target in the Map Script column of the table editor.
2. Right-click on Q21_Query_By_Parameter and select Insert Children...
3. Click Finish to add the required components of the query in the proper
order.
Do the same for the newly created MSH node and its descendent, and add checks
next to MSH.5 and MSH.6 (they are required by IHE). Set the default field values as
shown in Figure 15.
Figure 15. PIX Query MSH values
You should see an error on the mapping indicating that the toolkit is:
Unable to find function, procedure, or module named "CreateHL7CurrDate"

in default broker schema.
You can resolve this error by creating a new ESQL utility in the default package.
Listing 3 shows an example.
Listing 3. CreateHL7CurrDate()
CREATE FUNCTION CreateHL7CurrDate() RETURNS CHAR

BEGIN
DECLARE hl7DateTime CHARACTER;
SET hl7DateTime = CAST(CURRENT_TIMESTAMP AS CHARACTER FORMAT 'yyyyMMddHHmmss');
RETURN hl7DateTime;
END;
You've populated the values of the MSH segment, so we can move on to the QPD
segment. In the top mapping portion of the editor:
1. Expand the QPD node on the target side.
2. Right-click on the CE.1 element of QPD.1.MessageQueryName and

select Enter Expression to enter a Message Query Name.
3. In accordance with section 3.9.4.1.2.2 of Volume 2a, IHE ITI Technical

Framework, set the value to IHE PIX Query.
4. Similarly, because QPD.2: Query Tag is required by IHE, you can add an
expression that will make this value unique for each request.
To facilitate a mapping with the source message, use the
MSH.10.MessageControlID for this value, prefixed with the letter Q (a
common convention for HL7 queries), as shown below.
fn:concat('Q',$source/tns1:HL7/tns1:MSH/tns1:MSH.10.MessageControlID)
Again in the top mapping portion of the editor:
1. Navigate to the PID segment of the source side and drag the
PID.3.PatientIdentifierList from the left onto the
QPD.3.UserParametersInSuccessiveFields on the right, as shown in
Figure 16.
This will create a submap where you can focus on mapping the patient
identifier into QPD.3.
2. In the newly created submap, expand the target node in the Map Script
column of the table editor and enter the following value.
fn:concat($source/tns1:CX.1, '^^^', $source/tns1:CX.4/tns1:HD.1, '&',

$source/tns1:CX.4/tns1:HD.2, '&', $source/tns1:CX.4/tns1:HD.3)
In essence, this statement constructs an HL7 Composite ID from only the

most relevant portions of the incoming patient identifier.
Finally, in the RCP segment, set the RCP.1.QueryPriority to the value I, as

required by IHE, to signify that the response must be returned in Immediate mode.
(View a larger version of Figure 16.)
Figure 16. PIX Adapter message map
You can also construct the PIX Query message in a Compute node. For an
example, check out the ReceivingApplication_Build_ACK module in the WebSphere
Message Broker Healthcare sample.
PIX Query - requested domain
In HL7 messaging, each identifier must have an assigning domain. By default, an

IHE PIX Query will return all corresponding identifiers in the target system. However,
clients can request a specific domain identifier in the response by adding a value in
QPD-4-What Domains Returned.
Listing 4. PIX Adapter add domain request
DECLARE hl7 NAMESPACE 'urn:hl7-org:v2xml';

...
CREATE COMPUTE MODULE PIXAdapter_AddDomainRequest
DECLARE RequestedDomain EXTERNAL CHARACTER '';
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
CALL CopyEntireMessage();
IF RequestedDomain IS NOT null THEN

IF RequestedDomain <> '' THEN
DECLARE Query REFERENCE TO
OutputRoot.MRM.hl7:QPD.hl7:"QPD.3.UserParametersInSuccessiveFields";
SET Query = Query || '|^^^' || RequestedDomain;
END IF;
END IF;
RETURN TRUE;
END;
...
The EXTERNAL keyword in the RequestedDomain declaration signifies that this

property is a user-defined property. For this property to be set as part of the flow,
you must add a property with the identical name to the User Defined Properties tab
of the flow editor.
Figure 17. PIX Adapter user defined properties
Saving and restoring the original request
At this point you need to add the Sender subflow that was developed for the Patient
Identity Feed Router flow. Set the Connection details property of the Sender
node to point at a Patient Identifier Cross-reference Manager, or promote the
property to the subflow level to allow embedding flows to more easily configure the
destination.
The example flow can now extract the patient information from an input HL7
message and perform a cross-reference on the identifier. To complete the subflow
design, the original message must be returned with the original identifier replaced
with that of the cross-reference reply.
1. Save and restore the message from the LocalEnvironment message

tree. Don't forget to change the SaveMessage compute node's Compute
mode property from Message to LocalEnvironment and Message to
ensure that the updates to LocalEnvironment are propagated.
2. Because you're storing the original message in the LocalEnvironment,

you must ensure that no other compute nodes overwrite this value. Select
each of the compute nodes in the Sender.msgflow subflow and change
each one's Compute mode to "Exception and Message."
Listing 5. PIX Adapter - Save original message
CREATE COMPUTE MODULE PIXAdapter_SaveMessage

BEGIN
CALL CopyEntireMessage();
SET OutputLocalEnvironment = InputLocalEnvironment;
DECLARE hl7BitStream BLOB ASBITSTREAM(InputRoot.MRM
ENCODING InputRoot.Properties.Encoding
CCSID InputRoot.Properties.CodedCharSetId
SET InputRoot.Properties.MessageSet
TYPE InputRoot.Properties.MessageType
FORMAT InputRoot.Properties.MessageFormat);
SET OutputLocalEnvironment.originalMessageBlob = hl7BitStream;
RETURN TRUE;
END;
...
Listing 6. PIX Adapter - Restore original message and replace PID segment
CREATE COMPUTE MODULE PIXAdapter_RestoreMessageAndReplacePID

BEGIN
SET OutputRoot.Properties = InputRoot.Properties;
CREATE LASTCHILD OF OutputRoot DOMAIN('MRM') PARSE(
InputLocalEnvironment.originalMessageBlob
ENCODING InputRoot.Properties.Encoding
CCSID InputRoot.Properties.CodedCharSetId
SET InputRoot.Properties.MessageSet
TYPE InputRoot.Properties.MessageType
FORMAT InputRoot.Properties.MessageFormat);
DECLARE targetPID REFERENCE TO InputRoot.MRM.hl7:PID;
IF CARDINALITY(targetPID.hl7:"PID.3.PatientIdentifierList"[]) > 0 THEN
SET OutputRoot.MRM.hl7:PID = targetPID;
END IF;
RETURN TRUE;
END;
END MODULE;
You should now have a flow that looks something like Figure 18.
Figure 18. PIX Adapter flow diagram
Testing the PIX Query Adapter

To properly test the PIX Query Adapter you need access to a Patient Identifier
Cross-reference Manager (or a simulation of one). This tutorial will use the Initiate
Patient system introduced earlier. Initiate Patient can automatically create
relationships between multiple records, such as detecting multiple patient identifiers
for a single patient.
To simulate a patient registration from multiple hospital information systems (for

example, an Electronic Medical Record System and a Laboratory Information
System), send two patient admission messages from separate domains by using the
Patient Identity Feed Router flow. Listing 7 shows a sample HL7 message from an
EMR system for admission of patient "Developer Works", and Listing 8 shows a
sample from a lab information system. As with the previous sample messages, you
must replace the newline characters in these messages with the proper segment
terminator—typically a carriage return. Or, you can import the messages directly
from the HL7 v2 messages for testing found in the zipped file provided with this
tutorial.
Listing 7. HL7 observation result message from an EMR system
MSH|^~\&|EMR|IBM|Initiate Patient|IBM|20101128104152-0500||ADTÂ01ÂDT_A01|10|P|2.3.1
EVN||20101128081234-0500
PID|||xxx^^^&1.3.6.1.4.1.21367.2009.2.3.27&ISO||Works^Developer||19501010|F
PV1||I
Listing 8. HL7 observation result message from a lab information system
MSH|^~\&|LIS|IBM|Initiate Patient|IBM|20101128114152-0500||ADTÂ01ÂDT_A01|11|P|2.3.1
EVN||20101128091234-0500
PID|||yyy^^^&1.3.6.1.4.1.21367.2009.2.3.28&ISO||Works^Developer||19501010|F
PV1||I
Depending on how it's configured, Initiate Patient may automatically detect that the
identifiers relate to the same patient or entity. If the information given to the system
is either too sparse or too generic, the entity must be resolved manually. The system
will often mark such records as "potential duplicates" and flag the records for review.
Once the proper linkage has been made, you can view the records for a given
patient (Developer Works in this case) using the Initiate Inspector.
Figure 19. Patient identity records in Initiate
To test the example system, lets create a very simple flow that:
• Takes an input message from the HCA_TEST_SEND_APP_IN queue

• Calls the PIXAdapter subflow
• Writes the response to HCA_TEST_ACK_APP_OUT
Because these are the same queues you used thus far in the SendingApplication,
you need to stop that flow before putting to the input queue.
Figure 20. PIX Adapter test application
In the PIXAdapterApplication flow editor:
1. Select the PIXAdapter subflow node.
2. Navigate to the Basic tab of the Properties View.
3. Set the value of the RequestedDomain so it matches the patient identity

domain used by the systems at the message destination.
This tutorial assumes that our hospital systems are using Object Identifiers (OIDs)
and will simulate an observation result message from the lab system to the
electronic medical record system. The lab system will use its own identifier for the
patient (in the 1.3.6.1.4.1.21367.2009.2.3.28 domain). Our flow must
perform a PIX Query to retrieve the patient's identifier in the target system, so set the
value of the RequestedDomain to:
&1.3.6.1.4.1.21367.2009.2.3.27&ISO
It's finally time to test the PIX Adapter.
1. Deploy the PIXAdapterApplication flow that you just created.
2. Enqueue a sample HL7 message.
Listing 9 shows an HL7 Observation Result message based on the original

WebSphere Message Broker healthcare sample message provided in
HL7_Text_Test_Message.mbtest.
Once again, the newline characters in the test messages must be replaced with
appropriate segment terminators. Or, you can import the sample messages directly
from the corresponding input files included in the HL7 v2 messages for testing found
in the zipped file provided with this tutorial.
Listing 9. HL7 Observation Result message
MSH|^~\&|LIS|IBM|EMR|IBM|20040718235800|T|ORU^R01|103933-200128565054|T|2.5|1
PID|1||yyy^^^&1.3.6.1.4.1.21367.2009.2.3.28&ISO||Works^Developer||19501010|F||4
OBR|1|2|420002354^LA|1002085^CMP|||20040718232700|||TTROXEL|||LAB TO DRAW|20040718232800
OBX|1|NM|1000050^BUN||9|MG/DL|8-24||||F|||20040718235800
OBX|2|NM|1000070^NA||139|MEQ/L|134-144||||F|||20040718235800
OBX|3|NM|1000080^K||3.6|MEQ/L|3.6-5.3||||F|||20040718235800
OBX|4|NM|1000090^CL||106|MEQ/L|101-111||||F|||20040718235800
OBX|5|NM|1000030^GLU||110|MG/DL|74-118||||F|||20040718235800
OBX|6|NM|1000060^CREAT||1.1|MG/DL|0.5-1.4||||F|||20040718235800
OBX|7|NM|1000120^CA||8.9|MG/DL|8.5-10.3||||F|||20040718235800
OBX|8|NM|1000200^TP||7.2|G/DL|6.1-7.9||||F|||20040718235800
OBX|9|NM|1000210ÂLB||3.8|G/DL|3.5-4.8||||F|||20040718235800
OBX|10|NM|1000470^BILI T||0.6|MG/DL|0.4-1.5||||F|||20040718235800
NTE|1|I|NORMAL RANGE CHANGED 01-15-04.
OBX|11|NM|1000250ÂLKP||89|U/L|38-126||||F|||20040718235800
OBX|12|NM|1000260^SGOT||16|U/L|15-41||||F|||20040718235800
OBX|13|NM|1000100^CO2||26|MEQ/L|22-32||||F|||20040718235800
OBX|14|NM|1000280^SGPT||12|U/L|14-54|L|||F|||20040718235800
OBX|15|NM|1000110ÂGAP||7||7-15||||F|||20040718235800
After sending the test message, you should find the following result on the
HCA_TEST_ACK_APP_OUT queue.
Listing 10. HL7 Observation Result message
MSH|^~\&|LIS|IBM|EMR|IBM|20040718235800|T|ORU^R01|103933-200128565054|T|2.4|1
PID|||xxx^^^CMO_IBM&1.3.6.1.4.1.21367.2009.2.3.27&ISO||Works^Developer
OBR|1|2|420002354^LA|1002085^CMP|||20040718232700|||TTROXEL|||LAB TO DRAW|20040718232800
OBX|1|NM|1000050^BUN||9|MG/DL|8-24||||F|||20040718235800
OBX|2|NM|1000070^NA||139|MEQ/L|134-144||||F|||20040718235800
...
The PID segment of the source message was modified to match the identifier used
for this patient on the destination system. When combined with the router flow
developed previously, this simple subflow could form the foundation of a middleware
solution that allows disparate systems to integrate and to focus on the knowledge
and identifiers within their own domains.
Building a PIX Adapter with the CIM

Similar to the Patient Identity Feed Router flow, you can alter the PIXAdapter
subflow to support non-HL7 endpoints by mapping to and from the IBM WebSphere
Message Broker CIM. By modifying the input and output nodes of the PIXAdapter
subflow to the CIM message model (instead of HL7), the subflow can be easily
reused in an expanded set of scenarios and workflows.
For example, one common use of the IHE Patient Identifier Cross-reference profile is
in Healthcare Information Exchanges that implement the IHE Cross-Enterprise
Document Sharing profile (XDS). Document Source actors could use the PIXAdapter
subflow to upload their documents with local identifiers, leaving the ESB to perform a
PIX Query that will retrieve a corresponding identifier from the XDS Affinity Domain
and add it to the submission metadata.
Section 6. Conclusion
In this tutorial you learned how to use the WebSphere Message Broker V7.0
Healthcare sample to integrate disparate hospital systems. The tutorial introduced
the IHE organization and discussed how its Technical Frameworks and Profiles can
be used to enhance the interoperability of HL7 messages.
The Patient Identity Feed Router flow demonstrated how to extend the provided
healthcare sample flows to route incoming messages based on their header
information. With the PIX Adapter flow, you explored how to use the IHE Patient
Identifier Cross-reference (PIX) Query transaction with an EMPI (Initiate Patient) to
maintain patient identity across systems.
This tutorial only scratched the surface of what is possible in WebSphere Message
Broker. We covered only a small sampling of the breadth of implementation
specifications defined by the domains of IHE. Now that you understand the purpose
and structure of IHE integration profiles, you can extend the sample flows developed
here for your own mediations and flows for HL7 and non-HL7 interfacing projects.
Downloads
Description Name Size Download
method
Solution files for the tutorial solution.zip 50KB HTTP
HL7 v2 messages for testing hl7SampleInput.zip 2KB HTTP
Information about download methods
More downloads
• Product documentation: WebSphere Message Broker Healthcare sample

1
• Specification: IHE IT Infrastructure (ITI) Technical Framework
Note
1. This tutorial references Volumes 1 and 2 of the technical framework. Volume 2a contains the
details of the referenced transactions.
Resources
Learn
• IBM WebSphere Message Broker: Get an overview and the latest news, learn
the features and benefits, see the system requirements, and access the library.
• Healthcare sample: Pre-built packaged assets you can import and run from the
WebSphere Message Broker Toolkit.
• Healthcare processing assets: Explore the Healthcare processing assets
capabilities, and how they are implemented.
• WebSphere Message Broker Information Center: Find detailed instructions on
how to complete the tasks that you need to perform to establish and maintain
your broker environment.
• IBM Initiate Patient: Integrates with disparate systems to accurately match and
link patient identities to create a master view for use by EHRs, portals, and
administrative applications.
• Integrating the Healthcare Enterprise: Read about an initiative by healthcare
professionals and industry to improve the way computer systems in healthcare
share information.
• IHE Product Registry: A way to register and search products supporting IHE
Profiles with published IHE Integration Statements.
• Health Level Seven International: Learn more about the global authority on
standards for interoperability of health information technology.
• IHE IT Infrastructure (ITI) Technical Framework, Volume 1: Integration Profiles.
• IHE IT Infrastructure (ITI) Technical Framework, Volume 2a: Transactions ITI-1
through ITI-28 of the IHE IT Infrastructure Technical Framework.
• User-defined properties in ESQL: Learn about accessing user-defined
properties as variables in your ESQL program by specifying the EXTERNAL
keyword on a DECLARE statement.
• IBM developerWorks Industries: Find the latest industry-specific technical
resources for developers.
• developerWorks podcasts: Listen to interesting interviews and discussions for
software developers.
• developerWorks technical events and webcasts: Stay current with
developerWorks technical events and webcasts.
Get products and technologies
• IBM trial software: Evaluate IBM software products in the method that suits you
best. From trial downloads to cloud-hosted products, developerWorks features

software especially for developers.
Discuss
• Participate in the discussion forum for this content.
• Get involved in the My developerWorks community. Connect with other
developerWorks users while exploring the developer-driven blogs, forums,
groups, and wikis.
About the author

Lee Surprenant
Lee Surprenant is an IBM software engineer on the Emerging Software
Standards team in Research Triangle Park, NC. He is the project lead
of the Stepstone Connected Health project at openhealthtools.org. Lee
represents IBM in the Continua Health Alliance Technical Working
Group, and with the Integrating the Healthcare Enterprise (IHE) Patient
Care Device (PCD) Domain. Lee holds Bachelor of Science degrees in
Computer Sciences and Applied Mathematics from the University of
Wisconsin-Madison.

Integrating The Healthcare Enterprise With Websphere Message Broker V7.0

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Integrating The Healthcare Enterprise With Websphere Message Broker V7.0

Caricato da

Copyright:

Formati disponibili

Integrating the Healthcare Enterprise with

WebSphere Message Broker V7.0

Skill Level: Intermediate

Lee Surprenant (lmsurpre@us.ibm.com)

Section 1. Before you start

About this tutorial

connecting applications to share data seamlessly and securely across the

• Introduces WebSphere Message Broker V7.0 and explores how it can be

To follow along with this tutorial, you will need:

• Access to systems with WebSphere Message Broker V7.0 and the

Section 2. The WebSphere Message Broker Healthcare

Import and run the Healthcare sample

Figure 1. Navigating to the Healthcare sample

Using the WebSphere Message Broker Toolkit

HL7-defined transport MLLP to the Flows.Main Receiver.msgflow. This flow then

The Receiver.msgflow also enqueues the original message on the

Figure 2. Testing the Healthcare sample

When you're done reviewing the sample, be sure to stop the

Section 3. Integrating the Healthcare Enterprise (IHE)

• Users with clinical and operational experience identify integration and

Health Level Seven (HL7)

HL7 v2 allows flexibility, so system implementations are commonly incompatible or

Patient identity management

identifier domains. Volume 1 of the IHE IT Infrastructure (ITI) Technical Framework

• Patient Identity Cross-referencing (PIX)

Sample scenario: Patient Identity Feed router

Sample scenario: PIX Query Adapter

• Take any HL7 input message

Section 4. Building a Patient Identity Feed router

IHE ITI-8: Patient Identity Feed

• Admission of an in-patient (A01)

Building a simple identity feed router

To begin the new project:

Figure 4. Flow project references

2. Navigate to HealthCareAsset --> Flows --> Flows.Main and:

1. Copy the Receiver flow.

2. Paste a copy into your newly created project.

3. Rename it to something meaningful (such as

4. Open the flow.

Section C.2: "HL7 Implementation Notes" of the framework places several

Listing 1. Parse And validate: CheckMSHFields() maximum width

As discussed in the WebSphere Message Broker Healthcare sample information

1. Remove the Prepare for MQ and Put to HCA_HL7_TO_CIM_IN nodes,

use the value of MSH.5.ReceivingApplication to route the message to the

Figure 5. Patient Identity Feed Route node expression builder

Figure 6. Patient Identity Feed Route node properties

You can also use a DatabaseRoute or simple Compute node to

1. Copy and paste the flow into your new project.

2. Replace the MQInput node with a simple Input node.

3. Hook on an Output node at the end.

DECLARE options INTEGER BITOR(ValidateException, ValidateDeferred);

Figure 7. HL7 Sender subflow

1. Right-click anywhere in the flow and select Promote Property..., as

1. Right-click in the flow editor and select Add Subflow....

2. Add as many subflows as needed.

4. Configure the Sender nodes' Connection details to point at the desired

2. Configure it to reset the message domain to type BLOB to prepare the

Figure 10. Patient Identity Feed Router

Deploying large message models

Listing 2. Sample Patient Identity Feed message maximum width

MSH|^~\&|IBM Message Broker|IBM|HIE|IBM|20101118104152-0500||ADT^A01^ADT_A01|1|P|2.3.1

Figure 11. Initiate Inspector