Table Of Contents
Cisco Medical Data Exchange Solution Technical Overview
IHE—Integrating the Healthcare Enterprise
The Cisco Application eXtension Platform (AXP)
Appendix—Relevant IHE Actors Implemented in the Tiani Spirit Application
Cisco Medical Data Exchange Solution Technical Overview
Introduction
This document provides an overview of the Cisco Medical Data Exchange Solution (MDES), the industry drivers for the solution, and the solution architecture, components, and recommended configurations. The intended use for this document is to provide a sufficient understanding of the solution to enable positioning with a client. It is not a detailed implementation or design guide.
Overview
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.
An example of the lack of interoperability that MDES can address is a leading healthcare provider in Europe that struggled with providing a patient centric view of data across its environment. This 1,300 bed healthcare organization services an area comprised of 600,000 residents offering 24-hour specialized medical treatment. Prior to MDES, medical records consisted of disjointed paper copies of medical records, segmented by facility. Where there were digital systems employed, incompatibility between the systems limited sharing among providers. The scope of the problem was widespread and involved 64 different systems utilizing 1,500 proprietary data interfaces, each with a different patient index. As a result, clinical documentation was rarely reused and it was difficult to integrate local physicians into the hospital environment. This organization suffered from degradation in care as well as high operational costs. This problem is not isolated to this specific healthcare system and exists globally in many healthcare organizations.
The MDES solution addresses these challenges and provides the means to create an intelligent infrastructure providing a patient-centric view of clinical information. It enables the network infrastructure to eliminate the operational costs of manual transport or proprietary health information exchanges (HIE) and reduce the delays associated with alternative solutions. The MDES solution from Cisco integrates IHE standards-based applications from Tiani-Spirit onto a Cisco Application Extension Platform (AXP) to form the basis for efficient exchange of clinical information between disparate systems.
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 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 MDES complies with 62 IHE stars (actor/profile tests) based on the most recent North American IHE Connectathon 2009 testing. Specific information on the profiles the MDES supports and additional information on IHE is available at http://www.ihe.net. IHE Connectathon results are available at http://sumo.irisa.fr/con_result/.
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. MDES is able to bridge the syntactic gaps that exist through its advanced transformation services.
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.
The 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.
Figure 1 Solution Overview
The system is deployed in a federated structure as shown in Figure 2. 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 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.
Figure 2 Federated Data Structure Enabled by MDES (Logical View)
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.
Figure 3 MDES Components
Tiani Spirit
The Tiani Spirit application provides the middleware, patient indexing, and registry and compliance components to 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. A graphical user interface based on Flash is provided for the configuration and monitoring of the application as seen in Figure 4 and Figure 5.
Figure 4 Tiani-Spirit Web Admin Interface Login
Figure 5 Tiani-Spirit Web Admin Interface
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 6 and Figure 7 are sample screen shots from the Web application.
Figure 6 Available Patients Partial Screen
Figure 7 Documents Available for an Individual Patient Partial Screen
The Web application provides client-side functionality for:
•
Patient management
•
•
•
•
For more information on Tiani Spirit, see http://www.tiani-spirit.com.
The 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 8.
Figure 8 Cisco Application eXtension Platform
The Cisco AXP solution consists of:
•
•
•
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.
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.
Figure 9 MDES Deployment Hierarchy (System View)
Figure 9 is representative of a global architecture from a typical deployment.
Figure 10 IHE Autonomous System
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 10.
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 10, this is in Data Center 1. For additional reliability the data should also be replicated in a second data center (see Figure 9). 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.
Figure 11 Cross-Domain Indexing
The red blocks may also be run on Cisco ISR 3845 routers depending on the match and link location. In Figure 11, match and link are performed in the Regional red block and the 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.
Table 1 Hardware Requirements
Patient Index (Red)
CISCO3845
NME-APPR-522
AXP1: DB, LDAP
AXP2: Spirit
AXP3: Backup of AXP1
AXP4: Backup of AXP2
Cross-Enterprise (Orange)
CISCO3845
NME-APPR-522
AXP1: DB, LDAP for Enterprise Location 11
AXP2: Spirit, Web for Enterprise Location 11
AXP3: DB, LDAP for Enterprise Location 21
AXP4: Spirit, Web for Enterprise Location 21
Local (Yellow/ Orange)
CISCO3825
NME-APPR-522
AXP1: DB, LDAP
AXP2: Spirit, Web
1 Primary/Backup for each Enterprise location will be split across 2 Orange Level routers.
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 12.
Figure 12 Centralized Image Store Flow
1.
2.
3.
4.
5.
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. For further information, see http://www.ihe.net.
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:
•
•
•
For more information on WAAS and the supporting architecture, see: http://www.cisco.com/go/waas.
Appendix—Relevant IHE Actors Implemented in the Tiani Spirit Application
These IHE Actors (Profile) are implemented:
•
–
–
–
–
–
–
–
–
–
–
•
–
–
–
–
–
–
–
–
•
–
–
–
For More Information
•
•
–
–
–
•
•
•
–
–
Guest
