C-CDA integration with Cúram and IBM Integration Bus

IBM Care Management C-CDA integration with Cúram and IBM Integration Bus Document version 1.0 Dhruv Bhatt is a Software Developer on the Smarter Care Advance Care Analytics team at IBM. His work spans several fields: Integration, Content Analytics, Predictive Analytics, and Healthcare Information Systems. He has filed several patents and produced technical publications in the Content Analytics field. Dhruv has a master's degree from Northeastern University in Boston, Massachusetts where his focus was on human-computer interaction. Philip Parker is the Architect of the Smarter Care Advanced Care Analytics team. He joined IBM via an acquisition of a private content integration company in 2004. He has been focused on content and predictive analytics since 2010. Philip Parker, Architect, Smarter Care, Advanced Care Analytics, IBM. Jonathon Shields is a Lead engineer on the Smarter Care Product development team at IBM. He has been involved in the IBM Smarter Care product from its inception, and has worked in developing social and healthcare systems for over 10 years. Jonathan was one of the senior engineers on the IBM Cúram product, working on Outcome Management, Care Management, Global Income support, and the Core platform. Jonathon has a master's degree from the Institute of Technology Tallaght, Dublin.

Copyright International Business Machines Corporation 2015. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

C-CDA integration with Cúram and IBM Integration Bus CONTENTS List of Figures... iv Revision History... v 1 Introduction... 1 2 System Overview... 2 3 Installation and Setup... 3 4 Cúram Web Services... 3 4.1 Outbound Web Service: Request Clinical Data... 3 4.1.1 Creating the Outbound Web Service... 3 4.1.2 Invoking the Outbound Web Service on Patient Registration... 5 4.2 Inbound Web Service: Process Blood Pressure Details... 7 4.2.1 Creating the Inbound Web Service... 7 5 C-CDA Analysis... 10 6 Cúram/IIB Communication... 15 6.1 IIB Message Flow... 15 6.2 SOAP Node Details... 16 6.2.1 SOAP Input Node... 16 6.2.2 JavaCompute Node... 16 6.2.3 File Read Node... 16 6.2.4 MQInput and MQOutput Nodes... 16 7 Conclusion... 17 Appendix A... 18 References... 21 iii

LIST OF FIGURES Figure 1 System Architecture... 2 Figure 2 - Outbound Message Schema... 3 Figure 3 - Sample WSDL Definition... 4 Figure 4 - ws_outbound.xml... 4 Figure 5 - Sample Outbound SOAP Message... 4 Figure 6 - Event Handler Configuration... 5 Figure 7 - Event Handler... 6 Figure 8 - Deferred Process Entity Relationship Diagram... 7 Figure 9 - Inbound Web Service Class... 8 Figure 10 - Inbound Message Schema... 8 Figure 11 - Sample Inbound Message... 9 Figure 12 - Evidence Activation... 9 Figure 13 - Providing a Response... 10 Figure 14 Sample C-CDA... 11 Figure 15 Data Analysis Project Overview View... 11 Figure 16 Data Filter View... 12 Figure 17 Data Paths View... 12 Figure 18 Generate Data Analysis Tools Dialog... 13 Figure 19 Analysis Subflow... 13 Figure 20 Using the Subflow... 14 Figure 21 Example Analysis Results Message... 14 Figure 22 IIB Message Flow... 15 iv

C-CDA integration with Cúram and IBM Integration Bus REVISION HISTORY Date Version Revised By Comments February 17, 2015 1.0 PEP Initial Version v

Introduction 1 Introduction A major challenge that faces healthcare today is creating a unified view of the patient. With a complete view of all pertinent aspects of a patient, more accurate diagnoses can be achieved. Equally important, proper treatment plans can be created. In the IBM Care Management product, Cúram provides tailored views of the patient for several roles in a healthcare organization, from administrators to clinicians. However, in many organizations Cúram is not the only source of data for the patient. Data can lie in Electronic Medical Record (EMR) Systems, billing systems, and other clinical information systems. Healthcare data is also changing to adapt to common access standards and formats, resulting in a complex integration scenario to provide a unified view of a patient. One standardization effort resulted in the creation of the Consolidated-Clinical Document Architecture (C-CDA) standard. This document format serves to standardize the format of information that is exchanged between Electronic Health Record (EHR) and other clinical information systems. It is a key component in Meaningful Use Stage 2 requirements. Fortunately, it is possible to use an integration system such as IBM Integration Bus (IIB) to aid in this effort. This article describes an approach to use IIB as a patient evidence service to extract patient vital information from an external data source and provide this information in the Cúram view of the patient. All software components that are need for this approach are included in the IBM Care Management product, including IIB and Cúram. In the example scenario that is discussed in this document, a request is sent to an IIB system for clinical information about the patient during patient registration. The IIB system retrieves a C-CDA document for the patient, extracts a blood pressure reading from it, and returns the information to the Cúram system. The Cúram system writes this information into patient evidence, which is displayed to the user in the patient view. C-CDA documents can vary in their structure and order, which can make extraction by traditional rules complex. To overcome this difficulty, this approach uses the Data Analysis Perspective (DAP) within the IIB Toolkit to analyze a representative set of documents. The DAP then uses the information learned from the sample documents to analyze subsequent documents and extract information. 1

C-CDA integration with Cúram and IBM Integration Bus 2 System Overview Figure 1 System Architecture A typical deployment scenario for the system is depicted in Figure 1. Cúram and IIB are deployed on separate hosts for logical division of duties. Processing begins on the Cúram system when a new patient is registered in the system. The registration triggers an event, which results in a SOAP request to the IIB system for more data about the patient. On the IIB system, the SOAP message is received. A C-CDA document for the patient is retrieved, and a DAP subflow is used to extract Blood Pressure from the document. Finally, a new SOAP request is made from the IIB system to the Cúram system with the additional data requested for the patient. The additional data is written to the patient record on Cúram, and the Curam user interface presents the data as evidence when a user views the patient. Document structure in a C-CDA varies, resulting in a data mapping problem when looking for specific values in a specific document. The system overcomes this variation by using the DAP within the IIB Toolkit. The DAP is used with a representative set of C-CDA XML documents to learn the various paths to the data that a given medical facility would use. After the sample documents are analyzed, the DAP generates a subflow for runtime processing of future documents. More information on this method is given in subsequent sections. 2

Installation and Setup 3 Installation and Setup As indicated in the System Overview, a typical integration scenario would place Cúram and IIB on separate hosts. Additionally, other systems might be involved when using EMR systems for C-CDA document retrieval. The IIB system should have the Integration Toolkit installed on it. The Integration Toolkit is used extensively for workflow definition and data modeling. 4 Cúram Web Services The integration between Cúram Care Management and IIB requires two web services: an outbound service to request clinical data for a patient, and an inbound service to consume clinical data that is returned from IIB. The intention of this document is not to provide a detailed explanation of how to develop web services in Cúram. Instead, the intention is to illustrate how web services can be integrated into Care Management to facilitate the exchange of clinical data. Reference Integrating with External Applications through Web Services [1], for information on developing web services in Cúram Care Management. 4.1 Outbound Web Service: Request Clinical Data The outbound web service is responsible for sending a request for clinical data for a patient. The request needs to contain a unique identifier for the patient. In a production system, a unique identifier for the request itself may also be required for auditing, resilience, and data provenance purposes. However, for demonstration purposes the outbound message structure remains simple in this example. 4.1.1 Creating the Outbound Web Service The following steps are a high-level summary of steps that are required to produce the outbound web service. Refer to the official Care Management documentation for a complete description of creating Cúram Web Services. 1. Create an XSD schema for the outbound SOAP message, an example of which can be seen in Figure 2. Figure 2 - Outbound Message Schema 3

C-CDA integration with Cúram and IBM Integration Bus 2. Create a hand-crafted WSDL file describing the web service. A sample WSDL file can be found in Appendix A. Figure 3 - Sample WSDL Definition 3. Configure Cúram to generate the stub classes from the specified WSDL. This configuration is done by adding an entry to the following file: EJBServer\components\MyComponent\axis\ws_outbound.xml. For example, the contents of the file might look like Figure 4, where both the WSDL and schema files are placed in the PatientService subdirectory: Figure 4 - ws_outbound.xml 4. Implement the generation and sending of the SOAP message. After the WSDL is configured in Cúram, web service stub classes and operations are generated. You need to create a basic Java class to wrap the generated classes. The Java class you create produces the SOAP message and sends it. A sample SOAP message can be seen in Figure 5. Figure 5 - Sample Outbound SOAP Message 4

Cúram Web Services 4.1.2 Invoking the Outbound Web Service on Patient Registration You can invoke a Web Service during person registration by integrating with an event created during the person registration process. In the Cúram system, patients are registered by registering a person or participant. Complete the following steps to invoke the outbound web service request for the retrieval of clinical data when a patient is registered in the system. 1. Register an event listener in your component's handler_config.xml file. For convenience, you can use the same class as both the listener and the handler. For more information, see the IBM Cúram Server Developer's Guide [2]. Figure 6 - Event Handler Configuration 5

C-CDA integration with Cúram and IBM Integration Bus 2. Create an event handler and listener that accepts the participant case creation event and invoke the web service request. Figure 7 - Event Handler 3. In the eventraised method in Figure 7, a deferred process is queued. The wrapper class that is implemented in point 4 of the previous section is invoked within the deferred process. There are a number of reasons for a deferred process, one of the most important being that the event handler runs in the same transaction as the process that is registering the patient. If an error is encountered while requesting the clinical data the whole transaction is rolled back, including the patient registration. Other reasons include: the ability to reattempt failed requests, performance, and resilience. Figure 8 illustrates an example of an entity relationship diagram for a deferred process that can be implemented to support a deferred flow. The deferred process would invoke the outbound web service request. 6

Cúram Web Services Figure 8 - Deferred Process Entity Relationship Diagram 4.2 Inbound Web Service: Process Blood Pressure Details The responsibility of the inbound web service is to validate the incoming message, extract the blood pressure details, insert the details as evidence, and activate the evidence. 4.2.1 Creating the Inbound Web Service The following steps are a high-level summary of steps that are required to produce the inbound web service. 1. Model a new class, for example ClinicalDataWS, that is responsible for processing the incoming SOAP messages. Be sure to set the stereotype of the class to wsinbound, the WS_Binding_Style attribute to document, and the WS_Is_XML_Document attribute to True. These attribute values tell the Cúram generators that the class methods are dealing with XML documents. 7

C-CDA integration with Cúram and IBM Integration Bus Figure 9 - Inbound Web Service Class 2. Add a method to the ClinicalDataWS class called processbloodpressuredetails. This method is exposed by the Cúram system to receive the incoming SOAP messages. 3. Create an XSD schema for the outbound SOAP message, an example of which can be seen in Figure 10. Figure 10 - Inbound Message Schema 8

Cúram Web Services 4. You should validate the incoming message against its schema. You should also cache the schema to improve the performance of message processing. 5. Based on the schema that is defined in step 3 the message body contains two main attributes, 1) The PatientReference, and 2) The Evidence. The PatientReference is the unique identifier of the patient that was sent as part of the original outbound request. The Evidence is a JSON representation of the blood pressure details as defined by the Cúram Blood Pressure evidence type. The details of both attributes are required to insert the blood pressure evidence. The evidence is inserted by using the DynamicEvidenceMaintenanceExtInf API. The API inserts evidence in an in-edit state. For more information on the API, see the Javadoc. Figure 11 - Sample Inbound Message 6. After the evidence is inserted, it needs to be activated. You can use the result of the DynamicEvidenceMaintenanceExtInf API call with the EvidenceController as illustrated in Figure 12. Figure 12 - Evidence Activation 9

C-CDA integration with Cúram and IBM Integration Bus 7. Provide a response to the sender. The Cúram ResponseManager can be used to provide a response document. The response indicates whether the message was processed successfully, and more error details if the message could not be processed. Figure 13 - Providing a Response 5 C-CDA Analysis The IIB Data Analysis Perspective is used to filter healthcare data that is contained in C- CDA XML files. This section describes how you use the IIB Data Analysis Perspective to analyze and filter C-CDA files. You need sample C-CDA files to get started. In this system, you analyze and filter C-CDA documents to find Systolic Blood Pressure (BP) and Diastolic BP. Figure 1414 shows part of a sample C-CDA XML document that contains Systolic BP and Diastolic BP values. 10

C-CDA Analysis Figure 14 Sample C-CDA Follow these steps: 1. Create new Data Analysis project in IBM Integration Bus Toolkit 2. Open the <DataAnalysisProjectName>.dap file with the Data Analysis perspective. You should see the Data Analysis Project Overview view as in Figure 1515. 3. Analyze the sample CCD documents. Figure 15 Data Analysis Project Overview View 11

C-CDA integration with Cúram and IBM Integration Bus 4. Create new target model, give the name for target model. 5. Open the target model. 6. In the Data Filter view, you should be able to see all the elements you had in the sample C-CDA. See Figure 1616. You should be able to filter the element you want to see by typing its name in the top search box as shown in Figure 1616. In this example, search for BP. Figure 16 Data Filter View You should be able to see those elements in the Data Paths view. See Figure 17. You can drag those elements from the Data Paths view to the Target Model. In this example, it is Systolic BP and Diastolic BP. Figure 17 Data Paths View After you have the elements that you need in the target model as shown in Figure 1717, click "Generate..." to auto generate the subflow. A new WebSphere Message Broker library is created as part of the process and an autogenerated subflow is part of that library. 12

C-CDA Analysis You are asked to give the name of this library as shown in Figure 1818. There is a "Validation of input messages" check box. Leave this check box cleared for this system as shown in Figure 18. If it is checked, the message flow fails when an element is found in the C-CDA document that is not part of the target model. Figure 18 Generate Data Analysis Tools Dialog The Data Analysis Perspective generates a subflow that looks like Figure 1919: Figure 19 Analysis Subflow 13

C-CDA integration with Cúram and IBM Integration Bus You can use this subflow in other message flows. For testing, you can use a File Input node to read the C-CDA XML document and place it in the CCD Input Queue as shown in Figure 2020. Actual usage of the subflow takes place by placing items to be analyzed on the CCD Input Queue and receive output on the Data Analysis output Queue. Figure 20 Using the Subflow After you build the subflow, you can test it with a sample document. Pass a C-CDA document that contains Systolic BP and Diastolic BP information through the message flow. You should be able to see the results of the extraction in the output queue as shown in Figure 2121. Figure 21 Example Analysis Results Message 14

Cúram/IIB Communication 6 Cúram/IIB Communication The IIB system uses IBM Integration Toolkit SOAP nodes for communication with the Cúram system. IIB provides various ways to provide and use SOAP services. This approach uses the SOAP Input node and some custom JavaCompute nodes. 6.1 IIB Message Flow Figure 22 IIB Message Flow A request is received at the SOAP Input node from the Curam system. The patient ID is extracted from the request by the Extract Patient ID node and stored in the local environment for the message. The Extract Patient ID node is a JavaCompute node. For demonstration purposes, a FileInput node is used to acquire a C-CDA document from the file system. In the figure, this FileInput node is named CCD Repository to reflect its purpose. In a production system, the manipulation and C-CDA document retrieval nodes would be system-dependent, potentially accessing a Master Data Management (MDM) system and a Cross-Enterprise Document Sharing (XDS) system. Next, the system writes the C-CDA document to an IBM MQ Queue. In the figure, this node is called HL7 CCD Analysis Queue. The DAP flow then obtains the request from the queue and extracts the data from the message in the CDA Data Extractor node. After the results of analysis are received, the data must be assembled into a new message for submission to the Curam system. This assembly is achieved in the system in a JavaCompute node that transforms the data into the required JSON format and sends the message to the Curam WebService. In the figure, this is called the Curam Dynamic Evidence Write node. The system uses a JavaCompute node in lieu of a SOAP Request node for SOAP communication due to special authentication requirements. Note: Different requirements of error handling can lead to greater or fewer failure output nodes and queues in the system. The diagram is simplified by depicting minimal failure nodes. In a production system, it would likely be desirable to have a failure node for each node in the system for rapid failure analysis. 15

C-CDA integration with Cúram and IBM Integration Bus 6.2 SOAP Node Details This section describes the IIB node types that are used in the system. 6.2.1 SOAP Input Node This node provides a SOAP port to the network. Messages that are received on this port are entered into the IIB System for processing through any message flows listening to that port. In this system, a Web Service Definition Language (WSDL) file from the Cúram system is used to configure the node. 6.2.2 JavaCompute Node This node allows Java manipulation of IIB messages. In the system, it is used to extract patient ID, create a request message, and send the message to the Curam web service. 6.2.3 File Read Node This node reads a file from the file system and inserts the contents thereof as the message body. 6.2.4 MQInput and MQOutput Nodes These node types represent IBM MQ queues in the system. Any messages flowing to/from them are stored in a queue that can be analyzed or stored for later usage. 16

Conclusion 7 Conclusion IIB is a powerful tool for integrating systems. With the approach described in this document, this article shows how a Cúram system can use IIB to obtain existing patient data that is stored as C-CDA documents from other medical systems. 17

APPENDIX A Outbound Web Service WSDL. <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions targetnamespace="http://externalservices.cda.sample.caremanagement.curam" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:ns="http://externalservices.cda.sample.caremanagement.curam" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:ns1="http://org.apache.axis2/xsd" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:cm="http://www.ibm.com/curam/caremanagement/patient"> <wsdl:types> <xsd:schema> <xsd:import schemalocation="patient.xsd" namespace="http://www.ibm.com/curam/caremanagement/patient"/> </xsd:schema> </wsdl:types> <wsdl:message name="requestclinicaldatarequest"> <wsdl:part name="parameters" element="cm:patientreference"/> </wsdl:message> <wsdl:porttype name="processclinicaldataserviceporttype"> 18

<wsdl:operation name="requestclinicaldata"> <wsdl:input message="ns:requestclinicaldatarequest" wsaw:action="urn:requestclinicaldata"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="processclinicaldataservicesoap11binding" type="ns:processclinicaldataserviceporttype"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/> <wsdl:operation name="requestclinicaldata"> <soap:operation soapaction="urn:requestclinicaldata" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> </wsdl:operation> </wsdl:binding> <wsdl:binding name="processclinicaldataservicesoap12binding" type="ns:processclinicaldataserviceporttype"> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/> <wsdl:operation name="requestclinicaldata"> <soap12:operation soapaction="urn:requestclinicaldata" style="document"/> <wsdl:input> <soap12:body use="literal"/> </wsdl:input> </wsdl:operation> </wsdl:binding> <wsdl:binding name="processclinicaldataservicehttpbinding" type="ns:processclinicaldataserviceporttype"> <http:binding verb="post"/> <wsdl:operation name="requestclinicaldata"> <http:operation location="processclinicaldataservice/requestclinicaldata"/> 19

<wsdl:input> <mime:content type="text/xml" part="requestclinicaldata"/> </wsdl:input> </wsdl:operation> </wsdl:binding> <wsdl:service name="processclinicaldataservice"> <wsdl:port name="processclinicaldataservicehttpsoap11endpoint" binding="ns:processclinicaldataservicesoap11binding"> <soap:address location="http://www.valuespecifiedinconfiguration.com"/> </wsdl:port> <wsdl:port name="processclinicaldataservicehttpsoap12endpoint" binding="ns:processclinicaldataservicesoap12binding"> <soap12:address location="http://www.valuespecifiedinconfiguration.com"/> </wsdl:port> <wsdl:port name="processclinicaldataservicehttpendpoint" binding="ns:processclinicaldataservicehttpbinding"> <http:address location="http://www.valuespecifiedinconfiguration.com"/> </wsdl:port> </wsdl:service> </wsdl:definitions> 20

REFERENCES [1] http://www- 01.ibm.com/support/knowledgecenter/SSHJB3_6.0.0/com.ibm.curam.content.doc/WebSer vices/ctr_curamwebservicesguide.html?lang=en [2] http://www- 01.ibm.com/support/knowledgecenter/SSHJB3_6.0.0/com.ibm.curam.content.doc/ServerD eveloper/ctr_curamserverdeveloperguide.html?lang=en 21

Copyright IBM Corporation 2015 IBM United States of America Produced in the United States of America US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-ibm product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PAPER AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes may be made periodically to the information herein; these changes may be incorporated in subsequent versions of the paper. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this paper at any time without notice. Any references in this document to non-ibm Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation 4205 South Miami Boulevard Research Triangle Park, NC 27709 U.S.A. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. This information is for planning purposes only. The information herein is subject to change before the products described become available. If you are viewing this information softcopy, the photographs and color illustrations may not appear.

C-CDA integration with Cúram and IBM Integration Bus Trademarks IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol ( or ), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the web at "Copyright and trademark information" at http://www.ibm.com/legal/copytrade.shtml. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Other company, product, or service names may be trademarks or service marks of others.