Integrating the Healthcare Enterprise with WebSphere Message Broker V7.0

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.

Back to top

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.

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.

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

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.

                
                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.

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

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

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.

Back to top

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.

MSH|^~\&|EMR|IBM|Initiate Patient|IBM|20101128104152-0500||ADT^A01^ADT_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

MSH|^~\&|LIS|IBM|Initiate Patient|IBM|20101128114152-0500||ADT^A01^ADT_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.

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.

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.

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

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.

Back to top

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.

5 of 9 | Previous | Next

Comments

Back to top

Table of contents

• Before you start
• The WebSphere Message Broker Healthcare sample
• Integrating the Healthcare Enterprise (IHE)
• Building a Patient Identity Feed router
• Building a Patient Identifier Cross-reference subflow
• Conclusion
• Downloads
• Resources
• About the author

---

5 of 9 | Previous | Next

Next steps from IBM

• Try: WebSphere Message Broker
• Briefing: WebSphere flexible business processes
• Buy: WebSphere Message Broker

Dig deeper into Industries on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers