Integrating the Healthcare Enterprise with WebSphere Message Broker V7.0

Extending the WebSphere Message Broker Healthcare sample for real-world integration

IBM® WebSphere® Message Broker Version 7.0 includes a set of healthcare assets that let you work more effectively with HL7 messaging. 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.


Lee Surprenant (, Software Engineer, IBM

Photograph of Lee SurprenantLee 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 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.

15 February 2011


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 connecting applications to share data seamlessly and securely across the healthcare ecosystem, and delivering the data to caregivers whenever and wherever needed.

This article:

  • 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.


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.


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 the tutorial).

Resources has links to the prerequisite systems.

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. Figure 1. Navigating to the Healthcare sample
Message Broker Toolkit Samples and Tutorials page

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. 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.

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.

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. Figure 3. New project
    New Flow Project

    You should see the New Message Flow Project shown in Figure 4.

    Figure 4. Figure 4. Flow project references
    New 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. 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";

SET env.ErrorCondition = 'MSH parsing or validation error: ' ||
					'MSH.6.ReceivingFacility is null';
SET env.InputMSH.Field6= MSHFields.hl7:MSH.hl7:"MSH.6.ReceivingFacility".hl7:"HD.1";

SET env.ErrorCondition = 'MSH parsing or validation error: ' ||
					'MSH.7.DateTimeOfMessage is null';
SET env.InputMSH.Field7= MSHFields.hl7:MSH.hl7:"MSH.7.DateTimeOfMessage";
SET env.ErrorCondition = 'MSH parsing or validation error: ' ||
					'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. Figure 5. Patient Identity Feed Route node expression builder
    Patient Identity Feed Route Node Expression Builder
    Figure 6. Figure 6. Patient Identity Feed Route node properties
    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
	--end user add
	THROW USER EXCEPTION VALUES('ACK message with AE or AR received');

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. Figure 7. HL7 Sender subflow
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. Figure 8. Promote Properties
    Promote Properties Selection
  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. Figure 9. Promote the TCP/IP Connection details properties
    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. Figure 10. Patient Identity Feed Router
Patient Identity Feed Router Message Flow

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. 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

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. Figure 11. Initiate Inspector
View of the Patient Record in 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.

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:

Message Header
Query Parameter Definition
Response Control Parameter

Section 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. Figure 12. New Flow Wizard
    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. Figure 13. Start of the PIX adapter flow
    Start of the PIX Adapter Flow
  5. After renaming the Mapping node, double-click it to open the Map node editor.
    Figure 14. Figure 14. New Message Map wizard
    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. Figure 15. PIX Query MSH values
Default values for the PIX Query

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. Listing 3. CreateHL7CurrDate()
	RETURN hl7DateTime;

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 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.


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. Figure 16. PIX Adapter message map
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. Listing 4. PIX Adapter add domain request
                DECLARE hl7 NAMESPACE 'urn:hl7-org:v2xml';
                CREATE COMPUTE MODULE PIXAdapter_AddDomainRequest
                DECLARE RequestedDomain EXTERNAL CHARACTER '';
                CALL CopyEntireMessage();
                IF RequestedDomain IS NOT null THEN
                IF RequestedDomain <> '' THEN
                DECLARE Query REFERENCE TO
                SET Query = Query || '|^^^' || RequestedDomain;
                END IF;
                END IF;
                RETURN TRUE;

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. Figure 17. PIX Adapter user defined properties
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. Listing 5. PIX Adapter - Save original message
                CREATE COMPUTE MODULE PIXAdapter_SaveMessage
                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;
Listing 6. Listing 6. PIX Adapter - Restore original message and replace PID segment
CREATE COMPUTE MODULE PIXAdapter_RestoreMessageAndReplacePID
		SET OutputRoot.Properties = InputRoot.Properties;
			ENCODING InputRoot.Properties.Encoding
			CCSID InputRoot.Properties.CodedCharSetId
			SET InputRoot.Properties.MessageSet
			TYPE InputRoot.Properties.MessageType
			FORMAT InputRoot.Properties.MessageFormat);
		IF CARDINALITY(targetPID.hl7:"PID.3.PatientIdentifierList"[]) > 0 THEN
			SET OutputRoot.MRM.hl7:PID = targetPID;

You should now have a flow that looks something like Figure 18.

Figure 18. Figure 18. PIX Adapter flow diagram
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. Listing 7. HL7 observation result message from an EMR system
MSH|^~\&|EMR|IBM|Initiate Patient|IBM|20101128104152-0500||ADT^A01^ADT_A01|10|P|2.3.1
Listing 8. Listing 8. HL7 observation result message from a lab information system
MSH|^~\&|LIS|IBM|Initiate Patient|IBM|20101128114152-0500||ADT^A01^ADT_A01|11|P|2.3.1

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. Figure 19. Patient identity records in Initiate
Initiate Inspector shows two records for our patient, Developer Works

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. Figure 20. PIX Adapter test application
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 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:


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. Listing 9. HL7 Observation Result message
OBR|1|2|420002354^LA|1002085^CMP|||20040718232700|||TTROXEL|||LAB TO DRAW|20040718232800
OBX|10|NM|1000470^BILI T||0.6|MG/DL|0.4-1.5||||F|||20040718235800

After sending the test message, you should find the following result on the HCA_TEST_ACK_APP_OUT queue.

Listing 10. Listing 10. HL7 Observation Result message
OBR|1|2|420002354^LA|1002085^CMP|||20040718232700|||TTROXEL|||LAB TO DRAW|20040718232800

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.


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.


Solution files for the tutorialsolution.zip50KB
HL7 v2 messages for testinghl7SampleInput.zip2KB



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.


More downloads


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Integrating the Healthcare Enterprise with WebSphere Message Broker V7.0