IHE: Integrating the Healthcare Enterprise Constantin Hofstetter (0650502) and Gerhard Kober (0215750) University of Vienna Abstract In this work, we provide an overview of the Cisco Medical Data Exchange Solution (MDES) (Section IV) and try to compare it with IBMs IHE solution (overview Section V, comparison Section VI). In section I we provide an overview of todays healthcare environments, followed by an introduction to IHE in section II. In the last section (Section VII), we provide a future outlook to Austrias ELGA initiative and its dependency on IHE. This paper is based largely on Ciscos MDES technical overview 1 and was influenced by our meetings with Cisco Austria and Spirit-Tiani. We were not able to meet with representatives of IBM. I. TODAYS HEALTHCARE ENVIRONMENTS In today s modern healthcare environments, patients often receive medical treatment from a number of physicians, at different sites, based on any number of factors. In order to provide the optimum treatment for the patient, physicians require access to their patients records as part of the overall care process. The records are typically fragmented within different healthcare organizations or, in many cases, restricted for use within a single healthcare system. Optimum patient care requires that the records needed are shared between different healthcare providers. At present, the typical way to transfer the patient record is to either send a fax or make hard copies or, in the case of images, use electronic media such as a CD or DVD. This process needs to be repeated by each physician who provided the patient with care in order to provide a complete picture of the patient s medical history. Alternatively the data exchange becomes the responsibility of the patient to obtain copies and transport them between organizations. This manual process is obviously expensive and inefficient for both the patient and physicians. In many cases, if a person needs to visit an emergency room in a location away from their primary healthcare provider, the records are simply not available. If the records are stored electronically, they probably conform to one or more electronic standards. Since there are different versions of those standards, consistency across vendors varies greatly. Even if the systems are interconnected, there is a good chance that the medical records on one system cannot be read on another. II. IHE: INTEGRATING THE HEALTHCARE ENTERPRISE Integrating the Healthcare Enterprise (IHE) is a global non-profit organization that has developed a framework of standards that allows disparate systems to exchange medical data. The IHE defines Integration Profiles within various 1 http://www.cisco.com/en/us/docs/solutions/verticals/healthcare/mde- Technical-Overview.html domains. Profiles consist of Actors that perform certain roles, Transactions that may be performed between these actors, and the formats and protocols used to execute transactions. There are nine defined domains including radiology, cardiology, pathology, and IT infrastructure. Within the IT Infrastructure domain, there are twelve profiles including Cross- Enterprise Document Sharing (XDS) and Patient Identifier Cross Referencing (PIX). Profiles utilize existing information standards such as HL7, CCOW, DICOM, ebxml, CDA, and PDF for document formats and to execute these transactions. The IHE framework utilizes the concept of Affinity Domains. An Affinity Domain is made of a well-defined set of Document Registries/Repositories and Document Sources/Consumers that have agreed to share clinical documents. An Affinity Domain could be as small as a single provider organization or hospital or could be much larger. In the logical Data Structure in Figure 2, an Affinity Domain would be a Regional (orange) node and the local (yellow) nodes associated with that Regional node. This allows for a very small scale implementation (one or two hospitals or groups) to implement the solution. As multiple instances of Affinity Domains are implemented over time, their simplified interconnection allows the healthcare providers to easily share their clinical information. This allows the system to grow from a few organizations to a larger regional, national, and international scale, avoiding the huge up-front investment of implementing from the top down with no guarantee of success. Even though disparate systems may comply with the different healthcare standards, they still may not be able to directly communicate. For example, different Electronic Health Record (EHR) systems may implement different versions of HL7 (2.5 vs. 3.0) and there are vender-specific (optional field) implementations of DICOM used with radiological images. III. APPROACHES TO IHE There are a couple of different approaches to providing ubiquitous access to medical records. One is to create a central clinical data store. In this approach all of the medical information is uploaded to a central location. As the data is transferred to the central site, everything is converted to a vendor-independent format. The result is rapid, easy access to standardized records with redundancy and simplified backup. This approach however requires a very large central store to contain all of the medical information and therefore does not scale well. While this approach may work well for at local and possibly a regional level, it does not scale for larger deployments.
The second approach is to leave the medical data distributed at the local level and provide a means of indexing the patients and matching them with their records. This federated approach is extremely scalable because the only data that needs to be distributed through the network is the indexing data, which is very small. Since access to large files is usually confined to the local system, bandwidth typically is not an issue. This is the approach taken by the Cisco MDES solution and also the proposed solution for ELGA in Austria (see Section VII). IV. CISCO MEDICAL DATA EXCHANGE SOLUTION A. Introduction The Cisco Medical Data Exchange Solution (MDES) incorporates a master patient index and translation function directly into the network infrastructure. Patient records remain where they were created, but are accessible from anywhere within the healthcare network. The Tiani-Spirit IHE application runs on a Cisco AXP (Application extension Platform) module located within a Cisco 3800 series Integrated Services Router. The patient index creates a registry of patients shared across the data exchange environment. Entities within this environment may be either consumers or publishers of information. Figure 1 depicts the basic functions provided to a publisher and consumer. A publisher needs a MDES instance (AXP/ISR) at its site. A consumer that does not publish information may not need an MDES instance, depending on the capabilities of the local application. There are several different ways to integrate with systems to make participation in the exchange easier. healthcare system, the remote (requesting) system securely locates the patient s local healthcare system and provides the remote physician with a comprehensive list of the information that exists for the patient. An authorized care provider can access the records which their access rights allow, keeping the entire transaction in compliance with local privacy laws. Any data translations that need to occur are performed by the network infrastructure and do not require additional software or customization to the clinical information systems involved in the information sharing transaction. In the event the requested information is a DICOM image, the system maps the vendor-specific DICOM header to align with the IHE frameworks, making it displayable on the target system. If the display device can support a diagnostic quality image, the entire DICOM image is transferred. Note that the solution does not connect directly to a PACS or an imaging medical device. It communicates with the PACS short term storage. If the display device is not high resolution, the user can request that the resolution be adjusted for the appropriate display resolution, again all performed within the network infrastructure. The new medical information gathered by the treatment of the patient at the remote site resides at the remote site. This information is now visible to the patient s local physician as those EMR systems are made aware of the new medical information. This meets the overall goal of achieving a seamless, patient-centric view of a patient s records and access to those records no matter where they are located. Fig. 1. Solution Overview Fig. 2. Federated Data Structure Enabled by MDES (Logical View) The system is deployed in a federated structure as shown in Figure 2 (comparable to the Domain Name System: DNS). The MDES solution communicates with the local record repositories (e.g., CIS, PACS, and other IHE-compliant healthcare systems) and extracts patient indexing information. The information collected is then stored in a database residing on the AXP module. The patient index that was created is replicated one level higher in the hierarchal model in order to provide for high availability and redundancy. As long as the patient stays within his local system, the indexing data is never replicated beyond these two systems. In the event that the patient visits a remote facility outside of their local B. Solution Components The MDES solution, as shown in Figure 3, consists of the Tiani Spirit application running on an Application extension Platform (AXP) module. The AXP module resides in a Cisco 3800 Integrated Services Router. To achieve a federated design, these are distributed throughout the healthcare system based on data interoperability, publishing, and consuming factors. C. Tiani Spirit The Tiani Spirit application provides the middleware, patient indexing, and registry and compliance components to
Fig. 3. MDES Components build a clinical information exchange. Running on an AXP module inside an ISR, the application only utilizes the required functions as needed based on the operational demands and configuration. The Tiani Spirit application is completely based on the IHE Profiles. The application provides adapters to allow the connection of legacy systems, such as hospital information systems, that are not IHE compliant but comply with standards like DICOM or HL7. The adapters provide functionality for protocol conversion and implement various IHE Actors and the business logic required to connect into an IHE-based interoperable environment. In normal operation, if the client is utilizing client software (such as an EHR or PACS workstation) the software is transparent, retrieving the information from the supplying system and delivering to the client system with the client system providing the display and user interface. In the event a client is not available, a Web application is provided for client-side viewing. Figure 4 and Figure 5 are sample screen shots from the Web application. Fig. 5. Fig. 4. Available Patients Partial Screen Documents Available for an Individual Patient Partial Screen The Web application provides client-side functionality for: Patient management Document management Patient Duplicate Management Access to the Audit Record Repository Access to the internal Logging For more information on Tiani Spirit, see http://www.tianispirit.com. D. Cisco Application extension Platform (AXP) The Cisco AXP provides a standards-based Linux hosting environment within the integrated services router, allowing third parties to integrate applications with the router. Tightly integrated to the Cisco IOS and network fabric, the AXP module is configured and managed through the router. Harnessing this integration, an AXP-enabled application can appear to the end user as an extension of the router, as shown in Figure 6. Fig. 6. Cisco Application extension Platform The Cisco AXP solution consists of: Application runtime network module that provides dedicated resources to host applications Cisco AXP hosting environment, which provides the infrastructure to securely host, install, upgrade, and manage third-party applications and services Cisco IOS Software integration application programming interfaces (APIs), which allow the application to integrate and use the features of the router The Cisco AXP comes in a variety of models based on both the Advanced Integration Module (AIM) and Network Module form factors allowing scaling for the particular application being hosted. For the MDE solution, the Tiani Spirit application is hosted on an NME-522 in a Cisco ISR 3800 series router depending on the scale of the deployment. For more information on the Cisco AXP module, see http://www.cisco.com/go/axp. E. Solution Architecture This solution is deployed in a federated fashion as show in Figure 2. At the local level, an ISR with one or more AXP modules is located at a hospital or clinic or shared between individual physicians and/or smaller clinics. At the regional level, an ISR with one or more AXP modules is deployed for each remote node. At the national level, an ISR with one or more AXP modules is used to aggregate a number of regional nodes for a small area (less than a million users). Future inclusion of the Cisco Unified Computing Platform will further improve scalability and cost-effectiveness for large implementations.
Systems that are IHE compliant may possibly communicate directly to higher-level nodes in the IHE federation. Legacy systems that are non-ihe compliant but support standards like HL7 or DICOM require an MDES node to run an adapter to convert the standard messages into IHE compliant messages with the appropriate IHE business logic. Fig. 7. MDES Deployment Hierarchy (System View) Figure 7 is representative of a global architecture from a typical deployment. For the edge node, a Cisco ISR 3825 with a pair of NME- 522 modules is recommended. In this configuration the SQL database and LDAP-based user database run on one AXP module and Web services, along with the Spirit application, run on the second AXP module as shown in Figure 8. This configuration can handle up to 100,000 patients/exams per year and between 25 and 50 concurrent users. This is sufficient for a medium-sized clinic. Larger facilities will of course exceed this capacity and require an additional ISR 3825 for each 100,000 patients/exams. For a site running bandwidth intense application (like a Radiology Image Center or an Oncology Center), the same approach is used but should be scaled at each 50,000 patients/exams per year. In this configuration, the Orange layer is extended into the facility. This allows the facility to operate autonomously in the event of network issues and provides maximum reliability. The information in the facility is replicated in the next layer up. In Figure 8, this is in Data Center 1. For additional reliability the data should also be replicated in a second data center (see Figure 7). For each edge node, an ISR 3845 with four NME-522 modules is required in one of the two data centers. This provides for both a primary and backup copy of the remote AXP. The primary image for a site is stored on two AXP modules in an ISR in Data Center 1 and the backup on a second pair of AXP modules in Data Center 2. Depending on the capabilities of the IT department, the data center images could potentially be run on VM Instances on a blade server. This configuration is scheduled to be validated on the Cisco Unified Computing Platform. The router configuration is less complex to maintain. The red blocks may also be run on Cisco ISR 3845 routers depending on the match and link location. In Figure 9, match and link are performed in the Regional red block and the Fig. 8. Fig. 9. IHE Autonomous System Cross-Domain Indexing
lower level red nodes are just notified. A router is sufficient to do the match and link function for up to 1 million patients. For clinical repositories serving more than 1 million people, a server such as the Cisco Unified Computing System is required. F. Optional Configurations One of the key features of the Tiani Spirit software is its ability to support the IHE s XDS-I (Cross Enterprise Document Sharing for Imaging Profiles) standard and its capabilities. If the PACS Vendor is not able to send a KOS (Key Object Selection) Manifest to the MDES, the MDES is able to generate out of the normal DICOM Message a KOS Manifest for the XDS-I Registry and XDS-I Repository. The MDES also provides a Web Access to DICOM Persistent Objects (WADO) Servlet for resolving any Imaging Document Sharing WADO request. If the DICOM Images are not cached in the MDES, the MDES automatically requests the corresponding DICOM Image from the Long Term Archive. This process is described in Figure 10. Fig. 10. Centralized Image Store Flow 1) DICOM data routed from STS to local AXP. DICOM KOS Objects generated and stored in Local router. 2) DICOM KOS Objects and DICOM data routed To 2nd level AXP. DICOM KOS stored in second level AXP. 3) DICOM Data routed to the LTA. 4) DICOM KOS objects to be viewed in EPR. 5) PACS in hospital queries DICOM Data from LTA back to PACS STS or Diagnostic WS. G. Security Considerations In healthcare patient privacy and security is always a primary concern. The Canadian Personal Information Protection and Electronic Documents Act (PIPEDA), the United States Health Insurance Portability and Accountability (HIPAA) Act, Europe s EC 95/46 Directive, and Japan s HPB 517 regulate the privacy of identifiable patient information. The Audit Trail and Node Authentication (ATNA) Integration Profile establishes security measures which, together with the Security Policy and Procedures, provide patient information confidentiality, data integrity, and user accountability. ATNA limits access between nodes and limits access to a node to authorized users. Network communications between secure nodes in a secure domain are restricted to only other secure nodes in that domain. Secure nodes limit access to authorized users as specified by the local authentication and access control policy. ATNA provides for an audit trail to allow security officers to insure compliance with a security domain s policies. The MDES application implements both Secure Node (SN), Secure Application (SA), and the Audit Record Repository (ARR) actors. The MDES solution generates audit logs on each PHI access transaction it performs and forwards to the ARR. Network Optimization Since the primary information in the MDES system is just indexing data, the bandwidth requirements are not large. However the information referenced by this indexing can be very large. For example, a patient s medical data is permanently stored locally in location A. If some of those records are DICOM images they will be very large, in some cases exceeding 500MB for a complete set of CT images. If that patient has the need for medical care when traveling to location B, when the treating physician requests the patient s records, the initial response is the indexing data from the MDES and is therefore a small transfer. If however the physician determines that they need to see a particular DICOM study in diagnostic quality, the resulting file transfer between the two end systems could oversubscribe the bandwidth available at the remote location. In this scenario the deployment of Cisco Wide Area Application Services (WAAS) could significantly improve the overall performance of the transfer. Cisco WAAS is a powerful application acceleration and WAN optimization solution that optimizes the performance of any TCP-based application operating in a WAN environment. WAAS features focused on optimizing WAN performance include: Transport Flow Optimization (TFO)TFO shields applications from unfavorable WAN conditions by providing slow-start mitigation using large initial windows, virtual window scaling beyond standard TCP window sizes, enhanced packet loss handling, and fairness to all connections. Data Redundancy Elimination (DRE)DRE is an advanced form of network compression that uses a bidirectional database to store previously seen TCP traffic and replace redundant patterns with very small signatures. DRE can provide up to 100:1 compression depending on the data being examined. Adaptive Persistent Session-Based CompressionThis type of compression can provide up to an additional 5:1 compression. V. IBMS IHE SOFTWARE SOLUTION We were not able to find much information about IBMs IHE software solution. See Section VI for more information about IBMs IHE solution. VI. COMPARISON BETWEEN IBM AND CISCO MDES The MDES complies with 62 IHE stars (actor/profile tests) based on the most recent North American IHE Connect-a-
thon 2009 testing. IBMs IHE solution only complied to 22 IHE stars. Specific information on the profiles the different vendors support and additional information on IHE is available at http://www.ihe.net. IHE Connect-a-thon results are available at http://sumo.irisa.fr/con result/. IBM does not offer a Patient Index (PIX) in their in-house solution and the IHE components run on the Websphere plattform (JAVA). Since our contact at IBM was not able to meet with us in time, we could not gain any more insight of IBMs solution. We will provide a more detailed look at IBMs IHE future in our presentation. VII. EHR IN AUSTRIA There is a great discussion about the EHR (also called ELGA: Elektronische Lebenslange Gesundheitsakte). It should also be provided on IHE as a basic standard. In the first step, there should be supported a few applications. There is e-medikation as medication-tool, where people can have a look at all drugs they need, and also the chemist can have a look at it. The tool can also detect drug-interactions. Another part is e-befund-labor, e-befund-radiologie and even e- Entlassungsinformationen. This should just be the beginning, but it is just very difficult. In Austria are many problems unsolved. It is about the Patient-Index (also called Master- Patient-Index), where to provide Data, and the almost biggest Problem is the Access-level. Even the patient is a problem for this System. How to login to this System - may be a great challenge for elderly people. Can be a problem for younger people too, if you try to login with the e-card. Doctors might have a problem too - now they are being controlled in their work. Patients have rights to have a look in their record, but until now, just nobody takes usage of this option. In our opinion IHE would be a great idea for ELGA, so you are not connected to an specific vendor. Everybody who produces a great implementation of the standard, or even substandards can be included. In fact standards are secure in the future, and even cost-effective. There is a lot more to say about ELGA, but it would be a paper on its own. We will discuss it in our presentation, too. ACKNOWLEDGMENT We would like to thank Thomas Mück for providing us with contact information to the representatives of IBM and Cisco, Hans Grainer (Cisco Vienna) and Thomas Schwab (Cisco Salzburg) for the (2 hour) conference call about Cisco MDES and their contact to Martin Tiani. Thanks to Martin Tiani for the great presentation and explanation about Spirit- Tiani software solutions.