Integration of Various Health Record Systems

Abstract

This chapter discusses the integration between the Health Record Systems and Patient Record System. The chapter also highlights the importance of a Patient Centric Health Record system. Such systems can empower patients to participate in improving health care quality.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

This chapter discusses the integration between the Health Record Systems and Patient Record System. The chapter also highlights the importance of a Patient Centric Health Record system. Such systems can empower patients to participate in improving health care quality. It would also provide an economically viable solution to the need for better healthcare without escalating costs by avoiding duplication. The proposed system is cloud based system so patients and healthcare providers can access it from any location. The use of cloud computing architecture will allow consumers to address the challenge of sharing medical data that is overly complex and highly expensive to address with traditional technologies.

Introduction

Generally health information is scattered across many different providers and facilities. A visit to a new doctor or any member of a CDO often results in lengthy process of filling all the information in a new system from where which such information is not ported to any other system. A new hospital encounter often results in repeated tests and all previous conversations are ignored due to the absence of any central repository of all data. This naturally results in higher cost to the patients, health insurance companies and government. Most of the times this health information is stored in chapter files, which are difficult to organize and share with others. Moreover, the information is not stored in standardized formats. Allowing patients to access their own medical records will encourage patients to be involved in their own healthcare and that will further strengthen the patient–provider relationship. Such an effort will enhance and increase the effectiveness of healthcare management. Healthcare institutions around the world are encouraged to develop the Electronic Health Record (EHR) systems. Personal Health Record (PHR) Systems that would track all such EHRs from various encounters with a variety of health professionals over years can be seen as one of the means that can empower patients in their own healthcare. It is noted that consumers that are well informed about their illnesses tend to understand and follow instructions and ask more insightful questions [2, 10]. We can define the PHR as an electronic application through which individuals can access, manage and share their health information in a secure and confidential environment [3]. It allows people to access and coordinate their lifelong health information and make appropriate parts of it available to those who need it. Thus, it differs from the EHR [15], which is “an electronic version of the patient medical record” kept by physicians and hospitals. The data in the EHR are controlled by and intended for use by medical providers. EMR is the basic building block, the source of information that feeds the EHR. The EHR is the longitudinal record made possible by RHIO’s (Regional Health Information organizations) and interoperability across care delivery organizations; and the PHR is the record owned, accessed, and managed by the consumer. The interdependencies are clear. Without linkages to the EMR, the PHR depends on the consumer to manually input vital data, like laboratory results. Without an EHR, the PHR cannot accept information from multiple providers.

EMR is the basic building block, the source of information that feeds the EHR. The EHR is the longitudinal record made possible by RHIO’s (Regional Health Information organizations) and interoperability across care delivery organizations; and the PHR is the record owned, accessed, and managed by the consumer. The interdependencies are clear. Without linkages to the EMR, the PHR depends on the consumer to manually input vital data, like laboratory results. Without an EHR, the PHR cannot accept information from multiple providers [28].

This chapter discusses an emerging concept of a cloud computing based Patient Centric Medical Information System framework that will allow various authorized users to securely access patient records from various Care Delivery Organizations (CDOs) such as hospitals, urgent care centers, doctors, laboratories, imaging centers among others, from any location. Such a system must seamlessly integrate all patient records including images such as CT- SCANS and MRI’S which can easily be accessed from any location and reviewed by any authorized user. In such a scenario the storage and transmission of medical records will have be conducted in a totally secure and safe environment with a very high standard of data integrity, protecting patient privacy and complying with all Health Insurance Portability and Accountability Act (HIPAA) regulations. Such as system would allow us to overcome the challenges by allowing patients to collect and manage their health information such as medical history, past surgeries, medications, and allergies), to request self-referrals, and to store a record of their consultations among others.

Further, the sharing of medical records, specifically radiology imaging databases with CDOs will have potential to drastically reduce medical redundancies, exposure to radiations, costs to patients. In addition such system can empower the patients with the automated ownership of their secure personal medical information. It is essential to use the cloud computing in this application since it would allow the CDOs to address the challenge of sharing medical data that is overly complex and highly expensive to address with traditional technologies. In addition to providing community of care, proposed system can also serve as a valuable tool in clinical research, medical decision-making, epidemiology, evidence-based medicine, and in formulating public health policy. Figure 23.1 shows a high level simplified overview of the designed system.

Fig. 23.1

Overview of global medical information system model

The system is conceptualized to shift from institute centered hospital information system towards a regional/global medical information system by developing standards based Service-Oriented-Architecture (SOA) for interfacing heterogeneous medical information systems such that it would allow real-time access to all medical records from one medical information system to another. The system integrates a Lossless Presentation layer for viewing the radiology imaging. This chapter discuss a brief architecture of “Lossless Accelerated Presentation Layer” that will allow one to view all radiology images (Digital Imaging and Communication in Medicine (DICOM) objects) that reside in a cloud based distributed database. We further will demonstrate the web-based interface that will provide a holistic view of all medical records to every patient. Figure 23.2 shows the layered view of the proposed system.

Fig. 23.2

Layered architecture for the proposed medical information system

Potential Impact of Proposed Medical Informatics System

This project focuses on the development of an architecture for integrating heterogeneous medical information systems such as (Hospital Information System, Radiology Information System, and Electronic Medical Records among others). These systems in their current form do not transfer information from one system into another outside a network. The proposed approach for a global medical informatics system would allow all medical records to be completely portable. In the current system a significant amount of delay is involved in transmitting medical records from one CDO to another, leading to repetitive medical testing and increased cost of healthcare to the patient, insurance companies and federal government. The development of a cloud based service oriented architecture that will provide all patients with an interactive view of all their medical records. Such a system would provide all patients with the ownership of their medical records, thereby eliminating the need to repetitive procedures.

The proposed system architecture drastically reduces the Medicare spending for imaging services. The sharing of medical records, specifically radiology imaging databases, will drastically reduce medical redundancies, and exposure to radiations. Total national healthcare spending is in excess of $2.6 Trillion or about 17 % of our Gross Domestic Product. The proposed architecture would significantly contribute the reduction in national healthcare spending by eliminating the repetition of procedure due to unavailability of medical records. In year 2006 itself various medical imaging services accounted for 58 % of Medicare’s physician office spending. In order to control this spending on medical imaging, the “Deficit Reduction Act” (DRA) was created in year 2005 to reduce medical imaging spending by $2.8 Billion by 2011. This project will allow various CDOs to share the medical records and imaging thereby, eliminating the need to repeat the procedures during a defined time period thereby, serving the objectives of Deficit Reduction Act. Please note with the current technology radiology imaging can be shared within a CDO, however not among various CDOs. The development of a lossless accelerated presentation layer would allow to access all radiology images residing on a cloud based distributed database in a lossless manner through a web-based DICOM viewer. This layer would provide a seamless access to all radiology imaging from any location in real-time thereby increasing the efficiency of overall medical record systems.

Centralizing medical records can also create new and more intelligent perspectives in medicine. Such database with medical information will be extremely valuable for advanced data mining in clinical research. This will have potential to analytically evaluate and innovate new disease information and test methods that will improve the health care delivery and lead the exploration of new preventive treatment. In addition, the proposed project also serves the criteria of national Health Information Technology agenda.

Background and Related Work

The focus of healthcare has recently been shifted from healthcare providers’ paternalistic approach to the consumer oriented approach. There are several efforts in such direction. Microsoft and Google’s open source health initiatives are just two examples of big corporation’s future interest in this domain. The Personal health record is a concept that has been developing over several years. The early form of PHR used to be paper-based records. Problems caused due to the lack of availability of chapter based medical records and the lack of data transferability has been well described. Moving these records into an electronic format that is used universally has been proposed as a way to solve some of these problems. As a result, the focus on electronic PHRs has steadily increased over the past several years, with more than 200 systems available in 2006 [12, 13, 19, 29]. Moreover, the effective use of information technology is a key focal point for improving healthcare in terms of patient safety, quality outcomes, and economic efficiency. The electronic PHR systems have many forms. In addition to Web-based systems, information in electronic PHRs may be stored on portable computer drives (such as USB “flash drives”), “smart cards,” or other electronic storage devices. Functionally, PHRs are diverse. Some contain tools for managing care, such as delivering electronic test results, providing support for remote monitoring (e.g. weight, blood pressure, blood glucose), and providing secure communication services between patient/family and health care professional or access to health-related content. Some PHRs have the ability to transfer information using standardized data formats or to transfer data to a patient-controlled health data record or repository. System Integration has been always the most critical issue for the development of information systems in healthcare industry. Medical Information Systems (MIS) are heterogeneous in nature and therefore pose a severe challenge in their interoperability [16, 22, 23, 31]. A large number of healthcare applications are isolated and do not communicate with each other. Therefore, the integration of existing information systems represents one of the most urgent priorities of healthcare information systems [25]. Many efforts have been made on integrating the heterogeneous systems in hospitals. Healthcare industry has developed several standards through which relevant data can be transferred among different information systems. These standards are Health Language Seven (HL7), Electronic Data Interchange (EDI) X12 Version 4010, Health Insurance Portability And Accountability (HIPAA), Digital Image Communication in Medicine (DICOM), Integrating Healthcare Enterprise (IHE) among others [21]. All these standards are currently being widely used in healthcare industry. According to Open Source Clinical Research Group HL7 is the most widely used messaging standard in health, not only in North America, but also around the world. Further, a 1998 survey found the HL7 standard in use in more than 95 % of hospitals with more than 400 beds. Overall, more than 80 % of the respondents in that study reported using HL7 in their information system departments with another 13.5 % planning to do so. The proposed solution will be able to integrate all medical information systems that are in compliance with HL7 standard.

Standardized interfaces are available to many healthcare “Object Oriented Sevices” such as CORBAmed (Common Object Request Broker Architecture in Medicine), which realizes the share of common functionalities like access control among different systems. Others, like DICOM, HL7 (Health Level Seven) and the initiative of IHE (Integrating the Healthcare Enterprise) [7], specify the guidelines or standards for exchanging messages among different systems, which make the different systems work in harmony and implement the workflow integration [22] [30]. Broker, an embedded device facilitated the communication between HIS, RIS and Picture Archiving and Communication System (PACS) by integrating HL7 with DICOM. Broker accepted HL7 messages from RIS, translated and mapped the data to produce DICOM messages for transmission to PACS. However, the Broker system posed a challenge since it allowed RIS information to flow only in one direction resulting in the duplication of databases. IHE initiative, jointly established by Hospital Information Management Systems Society (HIMSS) and the Radiological Society of North America (RSNA), later addressed the issue by allowing the integration of clinical information within a healthcare delivery network. Later a consolidated solution with RIS/PACS/HIS integration was offered by healthcare companies. This was a major step towards the successful integration of patient records within a network [4]. Assurance of consumer control of privacy is essential to the acceptance and adoption of PHR’s. With appropriate access controls, patients can allow portions of the PHR to be made available to family members, various care providers, and others.

Various researches have been conducted on personal health record systems such as Evaluation of Functionality and Utility [20], improvement of quality and usability of existing systems and analysis of security protection of personal health record systems. Mostly the current PHR research is focused on areas of PHR function that allow patients to manage their own health data and data/information exchange with others. However studies suggest that in these areas PHR has potential to improve the patient–provider relationship and enhance patient and shared decision making [18].

There have been some efforts to share the patient information within a limited group of in order to facilitate the teamwork and effective healthcare management. The Medical Informatics Network Tool (MTNL). The software included an intelligent engine that was used for treating only Schizophrenia, a chronic brain disorder [32]. The software allowed collecting useful information about the patient and facilitating the communication among all the team members in addition to other providing other useful information related to Schizophrenia. This system was very helpful in taking meaningful decisions quickly and therefore had a positive impact on the patient healthcare. Similarly, the proposed solution would provide all information regarding a patient in a centralized location. Aggregation of such information will have profound impact on the overall patient healthcare and would reduce the probability of making wrong decisions such as prescribing conflicting prescriptions. In 2006 Al-Busaidi et al. researched on introducing a personalized patient information that was extracted from a single patient database [5]. This research was more focused on web mining and intelligent information retrieval from web that can provide a simplified and meaningful description to the problem that a patient might be experiencing. Project was more focused towards analyzing the information based on conceptual integration of ontology. However in this project our focus is to integrate several patient record systems (Radiology Information System (RIS), Electronic Medical Records (EMR), Hospital Information System (HIS), Patient Health Record (PHR) and Clinical Information System (CIS) among others) and provide a cloud computing based patient centric interface for all patient records.

Recently service oriented architecture type IT platforms are emerging as solutions for clinical enterprises [26]. Web Services (WS) provide an open and standardized way to achieve interoperation between different software applications, running on a variety of platforms and/or frameworks. Therefore, they constitute an important technological tool toward the incremental delivery of advanced inter-enterprise services. Significant advantages of using WS on top of any existing middleware solution is location transparency, language and platform independence, together with their embracement by big vendors and the acceptance they enjoy between the users. WS, with their extensible markup language (XML) roots, open the door for the next generation, loosely coupled, coarse-grained, document-oriented architectures. The term “loosely coupled” is used to characterize services where the assumptions made by the communicating parties about each other’s implementation, internal structure, and the communication itself are kept to a minimum. In [30] researchers have proposed the use of a SOA for combining few workflows for integrating various health information systems. Although the workflows are not complete however it is an important contribution towards integrating various informatics systems.

Harvard Medical School CIO John Halamka quoted, “Putting servers and exchanges into doctors’ offices is not going to work”. He suggested a better model is using regional health-care information technology centers that use cloud computing systems to work with doctors [11]. Computing done at cloud scale allows users to access virtual supercomputer-level [14]. Cloud computing’s aim is to deliver tens of trillions of computations per second to problems such as delivering medical information in a way that users can tap through the Web. When implemented correctly, cloud computing allows the development and deployment of applications that can easily grow capacity, deliver needed performance, and have a high-degree of fault tolerance, all without any concern as to the nature and location of the underlying infrastructure [6]. IBM announced that American Occupational Network and HyGen Pharmaceuticals are improving patient care by digitizing health records and streamlining their business operations using cloud-based software. GoogleHealth and Microsoft Vault health solutions are commercial steps in the direction of aggregating patient records in a unified environment. However, the major issue with their solution is the inability of CDOs to upload patient health records in a central data repository. In both systems patients must upload all the records, which require patients to first gain access to their medical history. It is important to note that EMR is the basic building block, the source of information that feeds the Electronic Health Record (EHR). The EHR is the longitudinal record made possible by Regional Health Information organizations (RHIOs). While he Patient Health Record (PHR) is the record owned, accessed, and managed by the consumer. The interdependencies among them are very clear. Without linking (interfacing) a EMR with a PHR, the consumer will have to manually input vital data, like laboratory results. Without an EHR, the PHR cannot accept information from multiple providers. This is the case in both solutions offered by Microsoft and Google. Often it takes several weeks before one can gain access to their medical records from a hospital thereby, limiting its usage. In addition, both Google and Microsoft health solutions do not provide a lossless solution to the imaging services, which are important component of the overall patient centric system. In this chapter, we discuss a framework that will allow us to interface all medical records systems those are HL7 compliant and store the data in a multi-cloud based distributed database system.

Brief Discussion of Medical Standards

Healthcare industry currently has several standards through which relevant data is transferred between different information systems, these standards are HL7, EDI X12 Version 4010 (EDI X12), HIPAA, DICOM, IHE among others. A brief discussion of these standards is discussed below:

Health Language 7: aims at enabling communication between applications provided by different vendors, using different platforms, operating systems, application environments (e.g. programming languages, tools). In principle, HL7 enables communication between any systems regardless of their architectural basis and their history. Therefore, HL7 supports communication between real-world systems, newly developed or legacy. This is achieved through syntactically and semantically standardized messages. HL7 interfaces realize the request/service procedure by sending and receiving these standardized messages. HL7 functional areas include typical health-care (clinical) domains as Admission Discharge and Transfers (ADT), Patient Registration, Orders, Results, Financial and Master files. More recent versions of HL7 also include Non-ASCII character sets, Query language support, Medical documents, Clinical trials, Immunization reporting, Ad6erse drug, Reactions, Scheduling, Referrals, and Problems and goals. An example of an HL7 transaction set is shown below:

Electronic Data Interchange: is a data format based on ASC (Accredited Standards Committee) X12 standards. It is used to exchange specific data between two or more trading partners. Term ‘trading partner’ may represent organization, group of organizations or some other entity. EDI X12 is governed by standards released by ASC X12. Each release contains set of message types like invoice, purchase order, healthcare claim, etc. Each message type has specific number assigned to it instead of name. For example: an invoice is 810, purchase order is 850 and healthcare claim is 837. Some key EDI transactions are:

• 837: Medical claims with subtypes for professional, institutional, and dental varieties

• 820: Payroll deducted and other group premium payment for insurance products

• 834: Benefits enrollment and maintenance

• 835: Electronic remittances

• 270/271: Eligibility inquiry and response

• 276/277: Claim status inquiry and response

• 278: Health services review request and reply

Health Insurance Portability and Accountability: regulation impacts those in healthcare that exchange patient information electronically. HIPAA regulations were established to protect the integrity and security of health information, including protecting against unauthorized use or disclosure of the information. HIPAA states that a security management process must exist in order to protect against “attempted or successful unauthorized access, use, disclosure, modification, or interference with system operations”. In allows monitoring, reporting and sounding alert on attempted or successful access to systems and applications that contain sensitive patient information. Current version of HIPAA is X12 4010 and recently a new guideline X12 5010 was released and mandated by the Department of Health to be complied with and implemented by all care givers before January 2013.

Digital Imaging and Communication in Medicine: is the industry standard for storing and transferring all radiology images. The standard ensures the interoperability of system and can be use to produce, display, send, query, store, process, retrieve, and print DICOM objects. Patterned after the Open System Interconnection of the International Standards Organization, DICOM enables digital communication between diagnostic and therapeutic equipment and systems from various manufacturers. The DICOM 3.0 standard, developed by the American College of Radiology (ACR) and National Electrical Manufacturers Association (NEMA), evolved from versions 1.0 and 2.0 which evolved in 1985 and 1988 respectively.

In addition to these standards it is must that the designed medical informatics system is in compliance with the following requirements.

Patient Safety: One of the most important requirements of any medical informatics system is the availability of consistent and correct information. At no point should the system show inaccurate, incomplete and unintended information that may jeopardize the safety of a patient.

Disaster Recovery: Since the proposed system is cloud computing based (hosted on Internet) there must be provision for backing up the entire system data incase of a system failure. A method must be included that would prevent the data from being corrupted or lost. If not done so this may lead to major crisis in terms of patient safety.

Accuracy, Availability and Accessibility: It is must that health informatics system must achieve the availability target of above 99 % since the system stores critical information. The data stored must be accurate, available and always accessible from any location.

Integration: As discussed above, for the system to serve as a global medical record that will include all patient records, all medical standards must be correctly and carefully integrated into the system. Several of these standards have already been discussed above.

Ease of use and Customer Satisfaction: It is expected that the system will be widely used by all patients, doctors, nurses and other entities involved in healthcare. Therefore, the system must provide a simple user interface for all entities (users) involved. Inability to achieve this may prohibit users in using the system thereby reducing the potential impact of the proposed informatics system.

Government Compliance: The most important system requirement is security and the HIPAA compliance. The system must support both. Each workflow must be carefully designed such that it meets the HIPAA standard.

Architecture Description and System Design

Currently clinical data, in standardized format, is distributed among Care Delivery Organizations (CDO) such as hospitals, pharmacies, insurance companies among others. We proposed an approach which would create and authorize and allow secured sharing of this data repository on cloud(s) based distributed database. In this section we provide an architecture description of each layer of our proposed medical information system as shown in Fig. 23.2.

A Service Oriented Architecture for Interfacing Medical Messages

This section discusses the approach that has been adopted for interfacing several medical systems in order to centralize all patient records. The proposed solution does not focus on the developing yet another standard which would try and enforce other organizations to comply with. Rather the federated approach was selected, based on a set of already existing healthcare industry standards through which medical messages are transferred between different information systems. Currently medical messaging standards enable data transfer between systems in a request—service manner, where in the data is sent from one system to another directly or via a modulator like an EDI VAN service provider. Such data transfer is occurs only upon the request and is not based on the occurrence of an event such as admission of patient.

Fig. 23.3

Layered view of the proposed service oriented architecture for interfacing medical messages

Through a service oriented architecture various medical information systems can be integrated by collecting standardized data on a cloud based distributed database repository. In this architecture Web-services will be hosted securely on a cloud while the Web service clients serving as agents will be running on various health-information-systems. In order to facilitate a seamless integration of various medical information databases the schemas of the distributed database residing on cloud(s) will imitate the existing schema of healthcare standards like HL7, EDI and DICOM. During initial setup of the web-service clients, the schema of the existing HIS or EMR systems will be mapped to the proposed cloud based distributed database schema. This would allow the agent to periodically query the client databases through established connections which will facilitate the transfer of data to the cloud(s) over secure HTTP connection. Figure 23.3 shows the proposed approach as discussed above.

Web-Services (WS) is major, service-oriented, connection technologies which is specification based and mostly open. In addition to its open source development potential in a technology neutral environment, major vendors are embracing World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) efforts. Significant advantages of using WS on top of any existing middleware solution are location transparency, language and platform independence, in addition to their adoption by big vendors and wide acceptance. WS, with their XML roots, open the door for the next generation, loosely coupled, coarse-grained, document-oriented architectures. Security should not be considered an afterthought but it should be built into the communication platform itself. WS were originally considered as an easy way to do business across the Internet since it allows tunneling through the hypertext transfer protocol that usually bypasses corporate firewalls. The use of transport layer security may not be enough to provide the desired levels of authentication, authorization, and trust. The use of technologies like XML-Signature, XML-Encryption, and WS-Security should be mandatory in order to achieve the necessary quality of protection for message integrity and confidentiality. Additional efforts such as WS-Trust, WS-Policy, and WS-Secure Conversation must be consideration as well. Currently, the most common technological tool to cover various security aspects is the Public Key Infrastructure (PKI). PKI is used to describe the processes, policies, and standards that govern the issuance, maintenance, and revocation of the certificates, public, and private keys that the encryption and signing operations require. PKI incorporates the necessary techniques to enable two entities that do not know each other to securely exchange information using an insecure network such as the Internet.

Lossless Accelerated Presentation Layer for Viewing DICOM Objects on Cloud

A key requirement for DICOM viewers is lossless image coding; users accessing DICOM images should receive lossless image to rule out any compression artifacts. Figure 23.4 shows the proposed architecture for the imaging sub-system. When users open a DICOM image, a DICOM viewer is executed in the cloud. The views rendered by the DICOM viewer have to be communicated to the users remotely accessing the image. Commercial remote access tools such as Citrix use lossy compression for remote viewing and hence are not suitable for medical imaging application. A few hospitals have used such solution for making the DICOM objects available outside the hospital network. However, such use of lossy compression may not be an acceptable solution under several medical conditions. For instance, such a lossy compression may provide wrong information about the size of a cancer cells that may be growing in any part of a body. Since the stage of a cancer is determined by the volume of the cancer cells; a lossy image may show a reduced volume by removing some pixels.

Fig. 23.4

The proposed architecture for the imaging sub-system

Our proposed solution is to use the open source remote control software TightVNC as a basis and modify the image coding engine to support lossless images. The complexity of encoding and the compression achieved varies with algorithms. One can easily evaluate and measure the compression performance for lossless JPEG-2000 and JPEG. High performing compression algorithms can then be selected to get maximum performance of the imaging sub-system.

Fig. 23.5

Service oriented architecture for presentation layer

Web Based Interface for Patient Health Records

Patient health records stored in a centralized data repository over the distributed cloud(s) can be instantly viewed by any authorized user connected to this system through a web-based interface designed as part of the proposed system. The data can be accessed by existing health information systems with the help of remote calls to cloud hosted web services as shown in Fig. 23.5. The proposed SOA would allow various medical information systems to interface with these web-services through their interfacing clients. All clients will go through a standard layer of authentication and authorization through public key encryptions standards.

Since the data is stored in the standardized format (HL7 or EDI) on the cloud based GHIS database, we must present the data in a readable format. The web portal can provide all users with the ability to search for a patient’s identity given a set of demographic criteria and retrieval of all the related health and medical information pertaining to the patient under consideration. Additional filtering of patient data will be possible if the consumer of the service is only restricted to view some parts of the patient’s medical records. This will be accomplished by the use of user roles and access grants. Secured logins to access patient records for authorized users such as physicians, radiologists, laboratory technicians among others can be created using the existing methods like one-time passwords (OTP). OTP methods can be facilitated through the use of a standard medical hardware device such as a “Token” that would generate a time synchronized one time password to allow the access to patient database.

A web-based ImageJ interface can be easily made available through this web-portal system for viewing DICOM objects. ImageJ is a public domain Java image processing program inspired by NIH ImageJ for the Macintosh. It was designed with an open architecture that provides extensibility via Java plugins. ImageJ will be integrated with a PACS server on the cloud to read DICOM objects residing on the distributed database. The user interface of ImageJ viewer application would depend upon the role of the accessing user. For instance, a radiologist will have the permission to alter the DICOM object that will be stored as a new version in form of a separate image layer. A web-browser presents the remote ‘desktop’ from which an authorized user may launch ImageJ to open DICOM objects. Users interact with ImageJ directly using the controls provided by ImageJ. As the views of ImageJ change, a view encoder based on the TightVNC server compresses the ‘desktop’ and transmits this to the user. TightVNC uses the standard Remote Frame Buffering (RFB) protocol for desktop sharing and control.  Since lossless compression will be used in the View Encoder, the users will see images that are identical to the images rendered by ImageJ.

A Globally Distributed Dynamically Scalable Cloud Based Application Architecture

The proposed medical information system concept is for patients, doctors and other care providers to have immediate access to medical records, images and other digital resources. Once connected to information system, the services available to a consumer will be filtered depending upon the consumer’s role, type or responsibility. Figure 23.6 shows high level layered architecture for a proposed globally distributed dynamically scalable cloud that will be used for storing all medical data. Every tier in the Fig. 23.6 includes multiple instances in the local and geographically distributed clouds.

Fig. 23.6

Layered architecture for a globally distributed dynamically scalable cloud

Tier 1 (Security Tier) of each application partition would include firewall with VPN, traffic filtering, statistical reporting and balancing functionalities and capabilities. In order increase efficiency of the tier, one would explore combining few of these services together on the same host or device, though cross-cloud Virtual Private Network (VPN) services will reside on isolated hosts. Additionally, due to the sensitive nature of the Internet Protocol Security (IPSEC) hosts and to ensure data security, this separation is considered necessary.

Tier 2 (Presentation Tier) represents a web server for serving of http clients. Ultimately each instance on this tier should be able to detect a failed node on its tier and take over the load in order to provide fault tolerance in our overall proposed system. This can be accomplished by using the “Linux-Ha” clustering software in an active/active configuration (http://www.linux-ha.org/GettingStarted/TwoApaches). Secure Socket Layer (SSL)/Transport Layer Security (TLS) and http proxy services are somewhat compute intensive therefore their impact on overall performance is close to linear. Thus, resources on this layer can be estimated based on number of connections.

Tier 3 (Application Tier) is the actual application/business logic tier. The primary platforms in this tier are Apache Tomcat and Sun Java. Since the load balancing will be done mostly on the outer perimeter and http tier, high availability becomes the primary concern at this level. It being a healthcare domain, one of our prime objectives is to ensure the application availability all the time. Being data critical, healthcare applications cannot afford to lose the connection even during the major hardware outage of $x-1$ nodes (where x is the number of nodes serving the application via Apache Tomcat), the layer would ensure the constant availability of all applications.

The final Tier, Tier 4 (Database Tier) of the server systems is the database systems. We discuss a brief architecture of our proposed system.

Distributed Data Consistency Across Clouds

One can easily carry out a detailed performance evaluation and benchmarking of various database storage methodologies such as traditional relational database management systems (RDBMS) Object Oriented Database Systems and Distributed Key-Value Persistence. The performing database architecture could then be implemented on a single-cloud in a standard master-slave topology with distributed reads and master-only writes.

A special replication server can be configured to replicate the data from the master database after every 20–60 min. Such configuration would allow us to preserve a consistent data state which is lagged by 20–60 min. In case of a system failure the data from this state can be recovered. All data-backups can be scheduled to run from the special replication server such as to avoid affecting read or write performance. The existence of multiple databases scattered over multiple clouds will pose a data consistence issue [17, 24]. Cross-cloud architecture can be developed to handle this issue safely and efficiently. Figure 23.7 shows the proposed method for distributed master database synchronization technique.

Fig. 23.7

Proposed method for distributed master database synchronization

The proposed solution is to perform offline synchronization on a schedule. On the system being replicated to, we can develop an agent to stop and reroute new connections, pause all automated maintenance agents flush all the caches on each node of each system and then perform cross replication from a replica of the online system to its own master.

The agents responsible for this will also communicate amongst each other to ensure that it would be performed in a rolling pattern, where no more than 1/3 to 1/2 of the individual global cloud instances are unavailable at any given time. This will eliminate perceived service interruption. Since this data is ultra sensitive and must be protected at all costs, an industry standard IPSEC VPN must be implemented to facilitate this cross-cloud replication or synchronization (Fig. 23.8).

Fig. 23.8

Geographic proximity cloud selection

Higher Availability and Application Scalability

We propose the architecture of a global medical information system that may have millions of users accessing the system for accessing personal health records. Therefore the system must ensure high scalability in order to serve increasing number of users on the system. Further, it will be imperative to ensure the persistence and integrity of the information store while maintaining high performance.

Fig. 23.9

Application cluster

Once can easily explore and benchmark the methods for distributed HTTP serving [33]. One method distributed HTTP serving, referred to as Geographic Load Balancing, is controversial as to its effectiveness yet being quite heavily used among large web presences like Google, Inc. or Amazon.com. The premise of Geographic Load Balancing method is that any host with a public IP address can be cross referenced with the IP address block assignments on a per country basis [8].

For the application tier, we propose to implement load balancing using the JK connector from the http layer in a weighted round robin load balancing scheme. The application cluster software stack will include Apache Tomcat on Sun $\mathrm{Java}^{{\textsc {TM}}}$ and a JVM heap clustering suite, Terracotta (see Fig. 23.9) [9, 27].

On cloud computing clusters one can spawn new computing resources, virtual machines, dynamically. We propose to that one should develop a method that would allow us to effectively allocate/deallocate a new application instance in a timely manner. Such a method would further interface with the JK connector(s) in order to dynamically alter connection weights and notify the HTTP layer of a new resource against which it can balance [1]. The proposed system would include four application partitions: Core System Services, Hospital Information Web Services, PACS System and Accelerated DICOM Presentation Services. The agent will know which of these services needs more resources. We will develop an algorithm to detect rate of load increase based on the special needs of each subsystem.

Concerning Low Level Security

Although user authentication and authorization will reside in the application and integration services, the GMIS Infrastructure must be developed in such a way so as to ensure trustworthy use of the cloud systems and networks. GMIS security components and layers will be enforced on any internet capable platform. The existing security methods such as use of firewalls with a minimum necessary access policy and Public key infrastructure will be deployed in order to ensure secured access to the healthcare cloud. Further, one must aim at certifying all clients by GMIS Root Certificate Authority which in-turn may be certified by a third party. Figure 23.10 shows a simplified view of trusted client connection to the healthcare cloud.

The public key infrastructure should be used for accessing the services and applications using Transport Layer Security (TLS) and require the servers to provide their credentials to the client. Additionally, by requiring the client also to present their security credentials (or certificate) we can easily establish a low level trust and assume that both parties are very likely to be who they claim. One must further configure the SSL/TLS processing servers with an HTTP based reverse proxy and Intrusion Detection suite.

Fig. 23.10

Trusted client connection to the healthcare cloud

Implementation Example

Fig. 23.11

Interaction of various CDO’s and patient with the cloud computing network

The proposed cloud computing based PHR System can allow various authorized users to securely access patient records from various CDO from any location. The system will seamlessly integrate all patient records including images such as CTSCANS and MRI’S which can easily be accessed from any location and reviewed by any authorized user. Figure 23.11 shows the overall view of such a PHR.

The architecture of the proposed system is shown in Fig. 23.12. It is a web application that runs on J2EE platform and could be deployed on cloud computing network such as Amazon EC2 and uses Microsoft SQL Server 2005. The J2EE platform is chosen for its platform independent features and availability of rich web application framework library.

Fig. 23.12

Proposed personal health record system architecture

The user interface layer for PHRS is based on J2EE, a platform for web applications hosted by the JBOSS Application server. The user interface is divided into role-specific pages (system administrator, patient, CDO, researchers and insurance providers) and common pages (messaging and account maintenance).

The database layer of the system consists of two components: the First component is DCM4CHE server [16], which is a collection of open source applications and utilities for the healthcare enterprise. These applications have been developed in the Java programming language for performance and portability, supporting deployment on JDK 1.4 and up. Also contained within the dcm4che project is dcm4chee. Dcm4chee is an Image Manager/Image Archive (according to IHE). The application contains the DICOM, HL7 services and interfaces that are required to provide storage, retrieval, and workflow to a healthcare environment. DCM4CHEE is pre-packaged and deployed within the JBoss application server. The basic work of the DCM4CHE server is to handle the implementation of the DICOM standard images uploaded by the patient.

The second component, which is a SQL server, is needed to store the general demographic information of the patient along with other patient health related data, such as, Insurance provider details, frequent CDO visit logs and prescription, lab reports etc.

The Web viewer interface used is open source Image J [17] which is a Java based image processing program. Image J is chosen because it can work as an online application and can read a variety of image formats including TIFF, GIF, JPEG, BMP and DICOM. The scalable and modular personal health record system is capable of importing/Exporting information with various computer based medical record system such as Electronic Medical record (EMR), Electronic Health Record (EHR). The users can also share the information including medical imaging (DICOM images) with the various care providers.

To ensure the security of the data we plan to implement password protected access to the system and only registered patients, CDO’s and specialists can log in to the system. Patients are restricted to viewing and modifying and sharing only their own records and CDO’s and other care units can only access those records, which are shared with them. Patients can edit the access privileges on their records at the granularity of the categories.

Use Case for Personal Health Record System

One approach to establishing a foundation for evaluating information design in PHRS is “use cases” that categorize and describe discrete functional scenarios and how computer interactions are carried out. The use cases are intended to serve as a framework demonstrating and establishing the relationship between high-level clinical functions and related standards in information design and usability. Figures 23.13, 23.14 and 23.15 outline the use of the proposed PHRS.

The user first logs into the web based personal health record system (see Fig. 23.13). If the user is a first time customer then he/she will have to create a user account in system before storing/accessing the medical information. Once the account is created, user can select the desired user type and can login into the system.

Fig. 23.13

Login flow usecase for the proposed system

Fig. 23.14

Patient centric usecase flow for proposed PHRS system

As soon as users logs into the system with user type as Patient, they will be first asked to first create their profile. The data in the profile comprises of demographic information of the patient and the past laboratory results including images, MRI, X-rays and other scanned documents. All the demographic information entered by the patient will be stored in the SQL database and all the imaging data will be processed and stored by the Dcm4che server.

Patients can View/Update or Add new information in the exiting profile. The patients can also share the medical records and their laboratory test results (including imaging information) with various CDO’s and insurance providers by giving access to them. The patients can control the data sharing mechanism and can either share the complete profile or only the selected information with the care provider or insurance provider companies.

Fig. 23.15

CDO usecase for proposed PHRS system

When user shares any information to any of the registered CDO it will be displayed on that particular CDO’s dashboard. Any information to the CDO can be shared either in read only mode or with the read/write mode. The patients control the access levels. Once any patient case is displayed in the dashboard, they can then examine the patient data and can suggests if any medication or radiology is required. Later the details can be stored into the database.