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.
- 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
After importing and deploying the Healthcare sample, be sure to look at the generated projects and identify some of the Healthcare processing assets .
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
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:
- Open the WebSphere Message Broker Toolkit and select New...
--> Message Broker / Message Flow Project, as shown below.
Figure 3. Figure 3. New project
You should see the New Message Flow Project shown in Figure 4.
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.
- Navigate to HealthCareAsset --> Flows -->
- Copy the Receiver flow.
- Paste a copy into your newly created project.
- Rename it to something meaningful (such as PatientIdentityFeedRouter).
- 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
Listing 1. Listing 1. Parse And validate:
... 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
- 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).
- Once the node has been placed, you can add new output terminals. Right-click the output terminals and select Add Output Terminal.
- Now that you've created the output terminals, it's time to create the
Figure 5. Figure 5. Patient Identity Feed Route node expression builder
Figure 6. 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:
- Copy and paste the flow into your new project.
- Replace the MQInput node with a simple Input node.
- 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
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. Figure 7. HL7 Sender subflow
The final step in subflow modifications is to promote the
Send HL7 Message and
TCPIPClientReceive connection properties to the
- Right-click anywhere in the flow and select Promote
Property..., as shown below.
Figure 8. Figure 8. Promote Properties
- 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
You've altered Sender.msgflow and can use this subflow in the example Patient Identity Feed Router, as follows.
- Right-click in the flow editor and select Add Subflow....
- Add as many subflows as needed.
- Hook the Route node output terminals to the Sender subflow input terminals.
- Configure the Sender nodes' Connection details to point at the desired endpoints.
Finally, because the destination systems will reply with their own acknowledgment messages:
- Replace the Build ACK node with a simple Reset Content Descriptor node.
- Configure it to reset the message domain to type
BLOBto prepare the reply for transmission to the original requester.
Figure 10. Figure 10. Patient Identity Feed Router
Ensure that the original sample message flows are not running (to avoid conflicts), then:
- Deploy your new Patient Identity Feed Router flow to the broker, along with the SendingApplication, for testing.
- 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 EVN||20101118081234-0500 PID|||xxx^^^&18.104.22.168.4.1.21367.2010.1.2.300&ISO||Works^Developer||19501010|F PV1||I
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
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 22.214.171.124.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
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.
- Go to the New Message Flow wizard and enter the information shown
Figure 12. Figure 12. New Flow Wizard
- Start off the flow by adding new Input and Output nodes from the Construction pallete.
- Put in a placeholder Validation node to validate the incoming message.
- Create a new Mapping node from the Transformation pallete.
Figure 13. Figure 13. Start of the PIX adapter flow
- After renaming the Mapping node, double-click it to open the Map node
Figure 14. Figure 14. New Message Map wizard
PIX Query Mapping node
Once the mapping editor has opened:
$targetin the Map Script column of the table editor.
- Right-click on Q21_Query_By_Parameter and select Insert Children...
- 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
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.
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:
- Expand the QPD node on the target side.
- Right-click on the CE.1 element of QPD.1.MessageQueryName and select Enter Expression to enter a Message Query Name.
- In accordance with section 126.96.36.199.2.2 of Volume 2a, IHE ITI
Technical Framework, set the value to
IHE PIX Query.
- 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.MessageControlIDfor 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:
- 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.
- 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
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 ''; 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; ...
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
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.
- Save and restore the message from the
LocalEnvironmentmessage tree. Don't forget to change the SaveMessage compute node's
Compute modeproperty from
LocalEnvironment and Messageto ensure that the updates to
- 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 modeto "Exception and Message."
Listing 5. Listing 5. PIX Adapter - Save original message
CREATE COMPUTE MODULE PIXAdapter_SaveMessage CREATE FUNCTION Main() RETURNS BOOLEAN 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. Listing 6. PIX Adapter - Restore original message and replace PID segment
CREATE COMPUTE MODULE PIXAdapter_RestoreMessageAndReplacePID CREATE FUNCTION Main() RETURNS BOOLEAN 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. 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. 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 EVN||20101128081234-0500 PID|||xxx^^^&188.8.131.52.4.1.21367.2009.2.3.27&ISO||Works^Developer||19501010|F PV1||I
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 EVN||20101128091234-0500 PID|||yyy^^^&184.108.40.206.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. 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. Figure 20. PIX Adapter test application
In the PIXAdapterApplication flow editor:
- Select the PIXAdapter subflow node.
- Navigate to the Basic tab of the Properties View.
- Set the value of the
RequestedDomainso 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
220.127.116.11.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:
It's finally time to test the PIX Adapter.
- Deploy the PIXAdapterApplication flow that you just created.
- Enqueue a sample HL7 message.
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
MSH|^~\&|LIS|IBM|EMR|IBM|20040718235800|T|ORU^R01|103933-200128565054|T|2.5|1 PID|1||yyy^^^&18.104.22.168.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^ALB||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^ALKP||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^AGAP||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. 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&22.214.171.124.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.
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 tutorial||solution.zip||50KB|
|HL7 v2 messages for testing||hl7SampleInput.zip||2KB|
- 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.
- developerWorks podcasts: Listen to interesting interviews and discussions for software developers.
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.
- Product documentation: WebSphere Message Broker Healthcare sample
- Specification: IHE IT Infrastructure (ITI) Technical Framework (This tutorial references Volumes 1 and 2 of the technical framework. Volume 2a contains the details of the referenced transactions.)