J Med Syst (2013) 37:9953 DOI 10.1007/s10916-013-9953-4

ORIGINAL PAPER

A Novel System Architecture for the National Integration of Electronic Health Records: A Semi-Centralized Approach Asma AlJarullah & Samir El-Masri

Received: 24 February 2013 / Accepted: 30 May 2013 / Published online: 19 June 2013 # Springer Science+Business Media New York 2013

Abstract The goal of a national electronic health records integration system is to aggregate electronic health records concerning a particular patient at different healthcare providers’ systems to provide a complete medical history of the patient. It holds the promise to address the two most crucial challenges to the healthcare systems: improving healthcare quality and controlling costs. Typical approaches for the national integration of electronic health records are a centralized architecture and a distributed architecture. This paper proposes a new approach for the national integration of electronic health records, the semi-centralized approach, an intermediate solution between the centralized architecture and the distributed architecture that has the benefits of both approaches. The semi-centralized approach is provided with a clearly defined architecture. The main data elements needed by the system are defined and the main system modules that are necessary to achieve an effective and efficient functionality of the system are designed. Best practices and essential requirements are central to the evolution of the proposed architecture. The proposed architecture will provide the basis for designing the simplest and the most effective systems to integrate electronic health records on a nation-wide basis that maintain integrity and consistency across locations, time and systems, and that meet the challenges of interoperability, security, privacy, maintainability, mobility, availability, scalability, and load balancing.

Introduction Electronic health record Globally, hospitals are moving away from paper-based medical records towards Electronic Health Records (EHR). The pace of the movement differs between countries and between different health sectors within countries. The benefits of moving toward EHR are numerous. Use of EHR help in improving quality of health information, speed and flexibility in access to health records, improvement in the process of decision making for patients. All of these help in reducing medical errors and in improving on patient safety. In addition, EHR is an integral component of the e-health [1]. According to the Healthcare Information Management Systems Society (HIMSS) [2], an EHR is: “a longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports. The EHR automates and streamlines the clinician’s workflow. The EHR has the ability to generate a complete record of a clinical patient encounter — as well as supporting other care-related activities directly or indirectly via interface — including evidence-based decision support, quality management, and outcomes reporting.” [2].

Keywords Semi-centralized EHR . Distributed EHR . EHR-integration . Medical record linkage . Electronic health records

The value of the national integration of electronic health records

A. AlJarullah (*) : S. El-Masri Department of Information Systems, College of Computer and Information Sciences, King Saud University, Riyadh, Saudi Arabia e-mail: [email protected]

Currently, Electronic Health Records (EHRs) are kept in a variety of formats at different healthcare providers’ systems that is, in ‘information silos’. The goal of EHRs-integration system is to aggregate the EHRs concerning a particular patient at different healthcare providers’ systems to provide a complete medical history of the patient [3]. The architecture of EHRs-

9953, Page 2 of 20

integration systems is defined as a “Model containing necessary features that can be useful, complete, and effective and maintains integrity across locations, time and systems” [4]. Integrating EHRs from various sources has been a subject of extensive discussions within the medical informatics community. A recent RAND study [5], on the value of connected EHR systems for the U.S., estimated a potential efficiency savings of $77 billion per year at a 90-percent level of adoption; adding the value for safety and health could double these saving. This integration would enable clinicians to access complete medical histories of their patients in a standardized way. Some of the anticipated benefits of EHRs integration include [6]: & & &

& &

&

Availability and accessibility of vital health information anytime regardless of where the person requiring care is. More effective and efficient treatment since the medical history of patients is available to healthcare practitioners. Accessibility to the medical history of patients helps avoiding adverse events arising from drug treatment errors including drug interactions, duplications or inappropriate doses or inappropriate treatments being given based on incomplete information, Reduction of the number of redundant procedures and tests, and therefore, less health risks for the patient and greater cost savings. Empowerment of individuals to exercise greater control over their own health, by giving them access to their own personal health records, and by enabling them to make informed choices about options available to them. In addition to providing support for continuity of care, the EHR is expected to be a valuable tool in clinical research, medical decision-making, epidemiology and evidence based medicine.

Problems of the current approaches for the national integration of EHRs Many countries are moving toward the national integration of EHRs and many approaches to achieve this have been implemented (as discussed in “Literature review” section of this paper), and among the approaches considered by these countries, the most successful approaches that have been implemented and put into practice are the centralized architecture and the distributed architecture. In the centralized architecture (Fig. 1), duplicates of EHRs — either in a comprehensive or summarized form — are transmitted to a central nationwide system, which works as a repository of the all patient’s EHRs across a country. This is referred to as a ‘push’ model, based on the concept of pushing the data from the healthcare providers to the central site [7]. The ‘pushing’ of medical data from the medical centers to the

J Med Syst (2013) 37:9953

Fig. 1 The centralized architecture for the national integration of EHRs

central repositories occurs periodically; for example, In Denmark, it happens every night [8]. In the distributed architecture (Fig. 2), all information would be stored and maintained locally within the various healthcare providers and facilities. Centrally maintained reference links at a central system would indicate where the original data records are located. This is referred to as a ‘pull’ model, since the central agency requests all the data needed from the providers whenever a request for a patient’s EHR is issued. The pull model does not involve a central repository, since data may only be requested when needed by a requesting user [7]. The centralized architecture has the advantages of availability, performance, and speed of query response. On the other hand, the use of centralized data repository that contain data from multiple sources, usually have difficulty with data context and codification, and their complexity of design in most may cases leads to extensive delays in actual implementation and use [7]. Also, it may require huge costs for implementing the central store of information, and it suffers from data inconsistency on the central system since patient data are usually sent to the central system periodically. Finally,

Fig. 2 The distributed architecture for the national integration of EHRs

J Med Syst (2013) 37:9953

the creation of nationally accessible system that contains all patients’ data would increase the risk of security breaks [9]. The distributed architecture has the advantage of decreased cost for implementing the central system since it does not contain any duplication of medical data. Also, this architecture has a unique advantage of data consistency and that it accesses the latest information about the patient as needed. Furthermore, this approach helps assure protection of patient information and addresses concerns about threats to privacy and security, because patient information remains at the source rather than being duplicated in a centralized database. However, queries to access patient’s data on remote healthcare providers may take a long time to complete. It places additional overhead burdens on the communication network and the source systems being accessed, thus access delays are likely to be unacceptable [7, 10].

Page 3 of 20, 9953

of each electronic health record of the patient in all hospitals. A clinician can extract the full electronic health record details from the remote hospital as needed. The idea of this approach is to allow the clinicians to have an idea of what is included inside the patient’s EHRs at each healthcare provider from a central location and to have a general view of the patient’s medical history, and when needed, retrieve the complete EHR of the patient from a remote healthcare provider’s system. This solution has the unique advantage of fast access to summarized patient’s medical history on the national healthcare system, with the possibility to retrieve a comprehensive EHR from a remote healthcare provider’s system as needed. Research question The paper answers the following research question:

Contribution of the paper This paper proposes an intermediate solution between the centralized architecture and the distributed architecture that has the benefits of both approaches, the Semi-Centralized approach (Fig. 3). In this approach, summarized EHRs are proposed to be maintained centrally at a national healthcare system with reference links to their comprehensive versions at their original locations on the various healthcare providers’ systems, where the national healthcare system provides access to EHRs summaries stored locally and comprehensive EHRs stored remotely at the distributed healthcare provider’s systems. In other words, the semi-centralized system stores a summarized copy (not a minimal dataset, like the case of some centralized architectures presented in the “Literature review”) of each electronic health record from each hospital at the central system. The clinician will be able to see a small picture

How to integrate EHR links and summaries into the system and provide access to them and to remotely stored complete copies in the most effective way? Research methodology The paper answers the research question by converting the proposed system into a working model in three major phases: 1. Phase 1: Designing the high-level architecture for the proposed Semi-Centralized National Health Information System (NHIS). 2. Phase 2: Designing the data model for the proposed Semi-Centralized NHIS. 3. Phase 3: Design the modular architecture for the proposed Semi-Centralized NHIS. In the next sections, a literature review exploring and analyzing the current approaches for EHR-integration found in practice in many countries around the world or proposed in published papers, then the high level architecture of the proposed NHIS is described, and then the components of the system are designed. After that, the data model of the system is defined. Then the modular architecture of the system is designed. Finally, a discussion is provided on the overall Semi-Centralized NIHS and the advantages of the proposed architecture.

Literature review

Fig. 3 The semi-centralized architecture for the national integration of EHRs

Many National Health Information Systems (NHISs) implemented in the world countries [11–33] have been reviewed. All of the reviewed NHISs can be divided into four categories: Centralized Architecture, Distributed Architecture, Electronic health Cards, and Online Personal EHR. Although

9953, Page 4 of 20

the centralized and distributed architectures have been mentioned previously, this section will describe them in more details by analyzing a number of NHISs that adopted them. Other approaches for EHR integration proposed in the literature are discussed in the other approaches sub-section at the end of this section. Centralized architecture This approach is adopted in Canada [11], Australia [12], England [13], Denmark [8], New Zealand [14], Finland [15], Estonia [16], and Indiana [17]. The NHISs of three countries are selected for further analysis in the following subsections as they introduce a variety of EHR integration strategies: Canada’s EHR Solution (EHRS) [11], Australia’s HealthConnect System [12], and England’s Spine System [13]. Canada’s EHR solution (EHRS) Canada’s e-health structure is based on highly-centralized EHR systems within each province containing patient records that can be shared nationwide [18]. Canada Health Infoway [19], funded by the government of Canada, works with the country’s ten provinces and three territories to implement private, secure EHR systems. Although each province and territory has an EHR system adapted to its needs, all of the provincial and territorial systems are based on an agreed set of principles and characteristics known as the Electronic Health Record Solution (EHRS) blueprint. Core components of the EHRS include [11, 20]: & & &

& & & &

Client registry: a list of all patients and their relevant personal information. Provider registry: a list of participating health care professionals who are authorized to use the system. Continuity of care data repository that holds information on health encounters and health service events (such as allergies), and the clinical observations associated with those events. Diagnostic imaging repository: stores patients’ images and reports, such as x-rays and ultrasounds. Laboratory information repository: stores patients’ laboratory results. Drug information repository: stores patient’s medication history. Health Information Access Layer (HIAL): a set of standards and communication services to sustain the interoperability of the different components within the infostructure (the central repositories and registries), as well as to sustain interoperability between the EHR infostructure and the point of service healthcare provider applications.

J Med Syst (2013) 37:9953

Clinical data to share is “pushed” from source systems into the central EHR in near real time. EHR data is “pulled” into the provider’s application for one integrated view that includes patient information, medical history, drug profile, diagnostic images, and lab reports [19].

Australia’s HealthConnect system The national Australian Healthcare strategy for EHRs was prepared in the HealthConnect Business architecture [21], which included the constructing of a national health information network and a sequence of patient event summaries would form the core of the EHR, which would be stored in a federated HealthConnect record system to be utilized by healthcare organizations and in the National Data Store for secondary applications. It involves the collection, storage and sharing of patient clinical information in summary layout through a secure network using precise security protection. The components of HealthConnect model are a series of event summaries, which produced according to defined metadata covering format, data items and allowable code sets and contain key information about specific healthcare events, such as, allergies, observations, test orders and results, diagnoses, medications and referrals [12]. HealthConnect does not create a comprehensive longitudinal record. Rather, patients, with their providers, will choose which elements may be extracted from an existing health record and transmitted to the HealthConnect record. Providers, with the consent of their patients, may subsequently add data to the HealthConnect record. It follows, therefore, that HealthConnect is a “push” system, selectively sending data to a centralized record. For example, a patient might elect to include details of his psychotropic prescriptions in an event summary and consent to all his prescribing doctors viewing that data, but only consent to other mental health professionals viewing his psychiatrist’s discharge order [10]. However, the summary data that is centralized may not fully support the system’s goals of improving healthcare quality, disseminating professional education, and supporting research [12].

England’s Spine system The National Health Service (NHS) in England implements the National Programme for IT (NPfIT) [13] to deliver the central electronic healthcare record system. This central system is known as Spine. Spine consists of three core components [22]: &

The Personal Demographics Service (PDS) Database, which stores patients’ demographic information including unique patient identifiers — NHS Numbers;

J Med Syst (2013) 37:9953

&

&

Personal Spine Information Service (PSIS) database, which stores Summary Care Records (SCRs) of patients. The SCR contains a core set of essential information to support safe treatment in emergency care including: NHS number, date of birth, name and address, allergies, adverse drug reactions and major treatments. These SCR records are created manually by clinicians and stored on the Spine. The Secondary Uses Service (SUS) database: uses data from patient records to provide anonymised and pseudonymised business reports and statistics for research, planning and public health delivery.

Authorized healthcare professionals can access patient’s healthcare SCR. Patients also can access the NHS spine through a patient portal on the internet. However, the plan of NPfIT has been greatly delayed and frequently criticized. And the EHR and data exchange raise significant privacy concerns and have caused a considerable resistance regardless of the obvious benefits [23].

Page 5 of 20, 9953

and with permission from a healthcare professional. The HIB also verifies if the patient has registered an objection against electronic exchange of his patient data or against specific healthcare providers. Only if all verifications are positive, will the HIB put the query through [26]. Electronic health cards In this approach, duplicates of the EHRs for each citizen are stored on an electronic card, the Electronic Health Card, which is owned by the citizen. This approach is the Germany’s e-health strategy on the way of EHR implementation [27, 28]. The Electronic Health Card project is considered as one of the biggest IT-projects, not only in Germany but worldwide [27]. However, the German health card is still under development, and the infrastructure is tested on a trial mode. The overall progress of the EHR project in Germany has been delayed several times, due to the technical complexity and strong resistance of health professionals [28]. There is little protection from loss, theft, or damage unless there is an online network backup [29].

Distributed architecture Online personal EHRs This architecture is adopted in the Netherlands [24], and Massachusetts [25]. The following subsection analyzes the NHIS of the Netherlands, which is named AORTA. The Netherlands’ AORTA system The Dutch national EHR system, AORTA, is a virtual EHR, based on the principle that all patient data remain in the local EHR, under the responsibility of the healthcare provider where the data was first recorded [7]. It uses a Healthcare Information Broker (HIB), a national switch point to enable the exchange of healthcare information. There is no clinical information stored at the HIB. The clinical data details reside at local health information systems [24]. The participating healthcare providers’ systems are connected to the HIB through Virtual Private Networks (VPN). All exchange of patient data between healthcare providers passes through the HIB, such that the HIB controls the access to patient data using a national authorization protocol, record locator, access log to maintain which healthcare practitioners have accessed patient data for accountability, and identification & authorization module [26]. The HIB performs a number of security measures. Each professional needs a special smartcard with PKI certificates to identify and authenticate himself or herself to the HIB. This smartcard is only issued to registered healthcare professionals and their assistants. For each query, the HIB consults the authorization protocol to verify if the healthcare professional, based on his professional title, is allowed to access this type of patient data. An assistant may only have access on behalf of

This approach is quite different in concept. It assumes that individual patients will aggregate their diverse records and then make them selectively available to new providers. There are several web-based personal EHR systems such as MyMediConnect [30] and Vital Vault [31] that provide secure web space in which patients can aggregate their medical data. Most of these systems allow for both end-user input and importation of data from institutional records to allow management of accounts. And some of them also offer automated updating from selected providers. However, the online personal EHRs tend to exhibit limited functionality, and lack performance [32, 33]. Other approaches Karel de Smet [24] proposed distributed service architecture for the Dutch EHR integration model rather than the current centralized service architecture, where all patient data is exchanged directly between the endpoint systems. The author also evaluated both architectures on technical and organizational aspects, partly based on practical experience. The result was that present centralized services architecture of the nationwide EHR scores better in terms of simplicity, version compatibility and service manageability; whereas the distributed services architecture of the Dutch nationwide EHR scores better in terms of functional manageability, flexibility, capacity, scalability and reusability. Jaminda S. et al. [34] proposed ontology based multiagent system for exchanging EHRs between two systems.

9953, Page 6 of 20

The aim of this system is to achieve the automated integration of heterogeneous EHRs of a patient residing on different hospital information systems. This is accomplished through the use of ontologies. Ontologies define the terms and the relationships between terms with which to model a specific domain. The raw data is attributed with semantic information allowing automated reasoning to be carried out. When a clinician makes a query for a patient’s EHR to the Clinical Computing System (CCS), the mobile agent will then travel to the other CCS agent platforms to present its query. The local agent will resolve any differences in naming conventions based on an internal heuristic. The mobile agent’s XML schema will be attributed with the knowledge contained in the remote EHR, thus resolving the query. K. D. Mandl et al. [35] proposed a subscription model for EHR-integration based on a mobile agent. The proposed model is a subscription model, in which a patient establishes an EHR on the system and identifies sources of personal health data. The system administrators then define an agent to query the source periodically, looking for new data for all clients who have identified that facility as a data source. The agent will then transform the data from the original source into a form that is more appropriate for the system and store it in the database. The source of the information must also be maintained so that changes in the original source may be captured. Pavalam S.M et al. [36] proposed a scalable data warehouse based architecture for EHR. The data warehouse is a central repository of data collected over period of time helping in the swift decision making process. The data warehouse collects data from variety of sources and converts them into a unified format. The transformation from external formats to a single format is being taken care by the load manger. The Data Mining applications interact with the query manager to extract the reports. This architecture can help in the analysis of data using OLAP operations, thus supporting goals of enhancing medical research.

High level architecture of the proposed semi-centralized NHIS The high level architecture of the proposed semi-centralized approach NHIS is shown in Fig. 4. The semi-centralized approach assumes that summarized EHRs of patients are stored at a nation-wide central system, the National Healthcare Center (NHC) that is built around a country and keeps summarized EHRs for all people in the country. The proposed NHC also provides access to comprehensive versions of these summarized EHRs from the distributed healthcare providers, the Healthcare Centers (HCs). To protect the medical data during transmission and to provide a fast delivery of EHRs, the eventual network for EHR transactions between the NHC and the distributed

J Med Syst (2013) 37:9953

Healthcare Centers (HCs) is proposed to be conducted over a secure, private Wide Area Network (WAN) where the network hardware is owned or leased by the NHC to establish this connectivity. Although this type of network maybe expensive, it provides high degree of security, privacy, availability and speed of transmission of medical data. To minimize the cost, other alternatives can be used to establish the connectivity, such as a VPN which uses a public telecommunication infrastructure, such as the Internet, to provide the HCs with a secure connection to the NHC. However, the VPN is built on a shared infrastructure, and therefore its availability and performance are difficult to control. Typically, VPN speeds are much slower than those experienced with a traditional connection. And more importantly, the use of public infrastructure will made the network less secure than using private owned or leased lines, the exposure to “attacks” from other networks on the same infrastructure requires comprehensive and complex security measures [37]. Currently, HCs have widely differing information systems, which have been written in different application languages, and store the data in different structures and in different database models. This results in a severe interoperability problem that impedes the communication of patient’s data from one HC to another [3]. Therefore, a small system called Health Information System Broker (HISB) is proposed to be built at each HC to control the communication of patient’s data from local database at the HC to the NHC, that is, it contains a number of modules that cooperate with the modules of the NHC to achieve the functionality of the system. The HISB is connected to the HC’s database and acts as a means through which local patient data is submitted to the NHC. The NHC presents all the system’s services to the end users and coordinates all the system’s processes. Clinicians in different HCs can access all the system’s services through the WAN connection which is secure and private. In order to provide clinicians with a means to access basic and essential system services from outside their HCs or while they are in mobility (for example: in emergency cases), and to provide patients with an access to their medical data on the NHC, the NHC provides a web portal that is accessible through the World Wide Web (WWW) through their computers or smartphones and tablets.

Components of the semi-centralized NHIS The components of the proposed system are shown in Fig. 5. The proposed system is based on the three-tier design. The set of tiers includes the following: 1. Data tier — that manages stored data on the NHC database. 2. Business tier — that includes the main processing modules. These modules are presented at the NHC level and

J Med Syst (2013) 37:9953

Page 7 of 20, 9953

Fig. 4 The high level architecture of the proposed semi-centralized NHIS

at the HISB level, which coordinate together and provide the functionality of the system. 3. Presentation tier — that accepts input, forwards queries to the requested processes or modules at the business tier, particularly the NHC modules, and displays the results.

data stored locally in the NHC database, and provides access to the comprehensive medical data stored remotely at the HCs (The details of the NHC modules are provided after the next section). The HISB modules

Different reasons for adoption of three-tier architecture can be mentioned. Modification or replacement of a tier does not affect other tiers. Furthermore, load balancing can be improved, due to the separation of the application and database functionality. The different layers provide also extra security to the system. It is not possible for a client to get direct access to sensitive data in the data tier. Before getting to the data tier, the client should contact the business tier. Within the business tier, adequate security policies can be implemented. The system is composed of five main components, as illustrated in Fig. 5. The following subsections describe each of them. The NHC database The NHC database stores all the patients’ summarized EHRs as well as references to their original comprehensive records on the original HCs. The NHC database also holds information on: patients, clinicians, HCs, clinicians’ logs and other data required to control the privacy of patient’s data (The details of the system data are provided in next section). The NHC modules The NHC is the major component that contains the main system modules. It manages access to the summarized medical

The HISB provides the system interoperability and masks the heterogeneity between the HC’s database models, data structures and terminologies. As stated before, Each HC has a HISB connected to its local database which acts as a means through with local patient data is submitted to the NHC. HISB must be designed specifically for each HC’s database to be able to deal with its specific data structures, formats and terminologies (The details of the NHC modules are provided after the next section). The NHC Interface The NHC Interface presents the services to the clinicians through the WAN connection. It handles authentication and identification and presents the different services of the system by calling the modules of the NHC. All the clinician services of the system can be accessed through this interface, i.e., through the WAN connection. The NHC Web portal The NHC Web portal presents the services to the patients as well as clinicians through the Internet connection. The NHC web portal handles user authentication and identification and presents the different NHC services available to the user as a clinician or as a patient. For security, integrity and efficiency

9953, Page 8 of 20

J Med Syst (2013) 37:9953

Fig. 5 Components of the proposed system

purposes, the services of the system that involve communication with HISB cannot be implemented over the NHC Web portal. Such services are provided for clinicians through the NHC Interface only, i.e., through the WAN connection.

The data model of the semi-centralized NHIS The aim of this section is to specify the data model of the Semi-Centralized NHIS. This data model represents the data elements to be stored on the NHC Database. Goals of the data model of the semi-centralized NHIS The data model of the Semi-Centralized NHIS is based on three major goals: 1. Maintaining accurate identification of patients across different healthcare provider’s systems. 2. Maintaining summaries of patient’s medical records at those healthcare provider’s systems in the NHC Database and as well as reference links to the comprehensive versions of these records. 3. Preserving the privacy of patients’ data. There are two possible options for linking patients to their medical data across different HCs: statistical matching (or demographic matching), and national patient identifiers (NPIDs) [38]. In statistical matching, the NHIS is composed of a number of connected Regional Health Information Organizations (RHIOs). Each healthcare provider gives the RHIO located in its region a database consisting of its patients’ attributes (e.g., name, gender, date of birth, zip code, and SSN) plus that patient’s medical record number. The

RHIO stores this information in a database called a Record Locator Service (RLS) [38]. Retrieving a patient’s medical data in this NHIS is based on Statistical Matching on these RLSs. Statistical matching attempts to string together enough identifying information about an individual to substitute for a NPID. It involves matching attributes, such as last name, first name, birth date, address or zip code, gender, and all or part of the Social Security number. Advanced statistical matching algorithms “score” matches on “closeness” to the input set. Those with a high score may be accepted as a match. In such NHISs, whenever a query is sent to the NHIS for retrieval of patient data, statistical matching is performed [38]. The problem with statistical matching is that personal attribute keys such as name and address are usually not unique to the individual, change over time, and are often entered into different systems in different formats. Dataentry errors, such as misspellings, missing fields, and default SSNs add to the difficulties with this type of key. These problems lead to false positive errors (assigning a match to a record that actually doesn’t belong to the patient), and false negative errors (failing to discover a record that belongs to the patient). False positive and false negative errors can lead to serious medical errors, waste of resources (e.g., repeats of tests or the wrong tests) and considerable deviation from the promises of continuity and quality of care postulated for a connected digital health care system [38]. These errors contribute to an overall problem rate of as much as 5 % for a single RLS, and trending higher for larger systems [39]. This inaccuracy of linking patients to their data is one of the most important obstacles impeding provider and patient adoption of NHISs [40]. Statistical matching approach is adopted in Massachusetts [25], and Indiana [17].

J Med Syst (2013) 37:9953

The accurate approach for linking patients to their clinical records that are distributed across HCs in a country is the adoption of unique NPIDs, that is, each patient in the NHIS gets an entry in a National Medical Patient Index (NMPI) with a NPID to define the identity of that patient. The NPID is then used to identify, integrate and share the patient’s EHRs across all HCs. A recent RAND study, 2008, [38] shows that a health care system in which every patient has a unique, non-disclosing NPID is clearly desirable for reducing errors, simplifying interoperability, increasing efficiency, improving patient confidence, promoting the NHIS architectural flexibility, and protecting patient privacy. A recent report published by the Information Technology and Innovation Foundation (ITIF) [41] indicated that a NPID system is implemented in Australia, Denmark, Finland, Netherlands, New Zealand, Sweden, the United Kingdom, and partially in Canada (Canada uses provincial patient IDs rather than NPIDs). Due to the discussed problems of statistical matching and the benefits of NPIDs, the preferred approach is the NPID. The correct identification of patients across different HCs is a safety critical issue and a cornerstone for the implementation and use of integrated EHRs. The sharing and integration of patient data rely on the accurate retrieval of patient records, thus electronic patient records should be matched, merged, and transferred on the basis of a unique NPID [42]. A monograph published by RAND in 2008 [38], analyzed the costs associated with the NPID. The authors estimated a one-time cost for issuing a NPID for 300 million individuals as $1.5 to $11.1 billion, depending on the scope of uniqueness and how strong and centrally managed the registration and authentication (verifying that a person is who he/she claims to be) processes are. To put these costs in perspective, the authors indicated that previous studies [43] of the value of connected EHR systems estimated a potential efficiency savings of $77 billion per year at the 90-percent level of adoption; added value for safety and health could double these saving, a one-time cost of $1.5 to $11.1 billion for a NPID, to remove the systemic errors in demographic matching, is small by comparison. The authors indicated that the implementation of NPIDs would require some type of organizational or governmental infrastructure to distribute the new identifiers and to manage the registration process before any data could be linked. Also, a procedure is required to link historical patient data with the new NPIDs using some demographic matching systems. With regards to the second goal of the data model, the main idea of the proposed Semi-Centralized NHIS is to allow the clinicians to have a general view of the patient’s medical history and to have an idea of what is included inside the patient’s EHR at each HC’s system from a central location, and when needed, retrieve the complete encounter information of the patient from a remote healthcare provider’s system.

Page 9 of 20, 9953

Thus, the NHC Database should maintain a summary of each patient’s encounter and a reference link to the complete version of the encounter at the original HC’s system. Preserving privacy is important to ensure acceptance of the system. A 1999 survey by the California HealthCare Foundation showed that even when people understood the huge health advantages that could result from linking their health records, a majority believed that the risks of lost privacy outweighed the benefits [44]. There are two types of data a patient can and should be given access to — the audit trail, detailing when and who looked up the location of their records; and the location of their clinical information itself [44]. Components of the data model of the semi-centralized NHIS To achieve the goals of the Semi-Centralized NHIS’s data model, the following data will be held at the NHC database: 1. A nationwide master index of patients to identify the patients involved in the system. 2. A nationwide master index of HCs to identify all HCs. 3. A nationwide master index of clinicians to identify all clinicians involved in the system. 4. A matching index that links the patient’s NPID to his/her local IDs at the various HCs. 5. A patients’ encounter registry to maintain summary information on patients’ encounters at all HCs (to maintain summarized medical histories of the patients) and to maintain reference links to the original complete encounter information residing at the various HCs. 6. An Authorization registry to control the privacy of patients’ data on the NHC. It keeps track of which clinicians are authorized by a patient to view his/her medical data (This index will be used by the system to check if the clinician is authorized to view a patient’s medical data before he is allowed to view it). 7. A clinicians’ log registry to audit the clinicians’ actions on the NHC. In this way an alleged unrightfully access can be traced by the various supervisors. Each patient has the right to inspect his part of the access log. To hold these types of data, seven tables have been designed for the NHC Database as shown in Fig. 6. These tables are: Patient Table (to hold the nationwide master index of patients), Healthcare Center (HC) Table (to hold the nationwide master index of HCs), Matching table (to hold the matching index), Encounter Table (to hold the patients’ encounter index), Clinician table (to hold the nationwide master index of clinicians), Authorization Table (to hold the Authorization registry), and Clinician’s Log (CLog) Table (to hold the clinicians’ log registry). The following subsections describe the purpose and contents of each of these tables. These tables are designed at the conceptual level and will need to be divided into more tables at the physical level.

9953, Page 10 of 20

J Med Syst (2013) 37:9953

Fig. 6 The conceptual data model of the NHC database

Matching table The purpose of this table is to keep track of all patients’ local records at the various HCs and to match between the NPID and the local patient identifiers at various HCs (LocalRecID), as illustrated in Fig. 7. In this way, all local patients’ identifiers at the various HCs are associated with the patient’s NPID. The matching identifier (Matching_ID) is provided as a primary Fig. 7 The role of the matching table

key to the table and will be used by the some other tables and the system modules. HC table The purpose of this table is to hold essential information about HCs. This table holds the HC’s Identifier (HCID), its name (HCName), and the IP address of its HISB node

J Med Syst (2013) 37:9953

Page 11 of 20, 9953

(HISB_IP). The IP addresses of HISB nodes will be used by the modules on the NHC when directing queries to the modules on a particular HISB.

registered to the system through a licensed government agency and issued their NPIDs. The Patient and clinician phone number and address are important for the following reasons:

Encounter table

&

The proposed system requires that the patient’s EHR at each HC is identified by the LocalRecID, and is made up of all patient encounters within that HC. Each encounter represents one visit, whether for some clinic, laboratory department, radiology department, or even just for some immunizations. The summarized medical history of the patient is a collection of encounters’ summaries across all HCs where the patient received care in. The Encounter table conations a summary record for each patient encounter at each HC. Each patient’s encounter summary record consists of the Matching_ID which is a foreign key from the Matching Table to refer to the patient’s NPID, the HCID where the patient is treated and the patient’s localRecID at that HC. The table also holds the patient’s encounter ID at that HC (EncounterID), the National Clinician Identifier (NCID) of the clinician who provides the treatment to the patient at this encounter, the Health Problems Summary (HealthProblemsSummary) which contains the diagnosis and vital signs, Medications Summary (MedicationsSummary) which indicate the names of medications or immunizations provided to the patient at this encounter, Laboratory Test (LabTests) which indicates the names and results of lab tests made for the patient at this encounter, Radiology Tests (RadiologyTests) which indicates the names and results of radiology tests made for the patient at this encounter, and the Date of the encounter (Date). The four data elements: HealthProblemsSummary, MedicationsSummary, LabTests, and RadiologyTests are multivalued and will need to be divided into more elements at the physical table design. Whenever the clinician needs further detailed information of the encounter, he can just request it through the system, and the system will deliver it from the remote HC’s database automatically. When such a request is generated, the NHC will send a query to that HC’s HISB requesting the complete record of the patient’s encounter, the query will contain both the LocalRecID and the EncounterID. The LocalRecID and the EncounterID together form the reference to the patient’s encounters at the distributed HCs.

& &

In cases, when a patient is in a critical situation and needs blood transfer, it will be easy to send a request to all patients/clinicians carrying the same blood type and within the same municipality to volunteer. The clinician may need to contact the patient and followup with them regarding some important care activities. This information is important for statistics reporting, research and development.

Although the patient and clinician phone numbers and addresses could potentially change frequently, a procedure can be put to ensure that they are up-to-date like those procedures taken by banks and insurance companies. Clinician table The purpose of this table is to identify clinicians across the country. This table holds the NCID, the HCID where the clinician works, and the clinician’s demographic data including: First Name (FName), Last Name (LName), SSN, Date of Birth (DOB), Telephone Number (TelephoneNo), Cellphone Number (CellphoneNo), Address (Address), and Blood Type (BloodType). The Services of the proposed system can only be issued to clinicians who have registered to the system through a licensed government agency and issued their NCIDs. Recall that the data model represented in Fig. 6 is represented at the conceptual level. The many-to-many relationship between the HC table and the Clinician Table will need to be represented by an intermediate table at the physical design of the data model. This intermediate table will contain three attributes: LinkingID (to represent the ID of each record of the table), HCID, and NCID. Also, the Clinician table will need to be modified to include the LinkingID instead of the HCID. Finally, the HC table will be modified to include the LinkingID. The relationship between the HC Table and the intermediate table and between the Clinician Table and intermediate table will be one-to-many with the many side located at the intermediate table.

Patient table Authorization table The purpose of this table is to identify patients across the country. This table holds the NPID and the patient’s demographic data including: First Name (FName), Last Name (LName), SSN, Date of Birth (DOB), Telephone Number (TelephoneNo), Cellphone Number (CellphoneNo), Address (Address), and Blood Type (BloodType). The services of the proposed system can only be issued to patients who have

The authorization table holds the Patient’s NPID and the authorized Clinician’s NCID for each patient. When a patient authorizes a clinician to view his medical data at the NHC, a record consisting of the clinician’s NCID and the patient’s NPID is added to the authorization table to represent an authorization record. This table will be used by the system

9953, Page 12 of 20

to check if the clinician is authorized to view a patient’s medical data before he is allowed to view it. CLog table This table maintains records of clinician’s actions on the NHC. This table holds the Session ID (SessionID), the Clinician’s NCID, the date of the session (Date), the event performed by the clinician on the NHC (Event), and the time at which that event occurred (Time). The event is the main attribute that shows which operation was performed on which data of which patient. In this way an alleged unrightfully access by clinicians can be traced by the various supervisors. Each patient has the right to inspect his part of the access log. The data model of the Semi-Centralized NHIS described in this section accurately links the patient’s data across the different healthcare provider’s systems, effectively preserves the privacy of patients’ data, and effectively organizes summaries of patient’s medical records into the NHC Database. The data elements that form the reference links to the complete versions of patient’s medical records at the original HCs are specified in this section. This data model will facilitate the jobs of the NHC modules and the HISB modules that will be described in more details in the next section.

Modular architecture of the semi-centralized NHIS This section specifies the basic modules of the SemiCentralized NHIS. The basic system modules are implemented at the business tier in Fig. 5. These modules are based on the Service-Oriented Architecture (SOA), that is, they are distributed between the NHC server and each connected HISB and work cooperatively to provide the system functionality. The modules of NHC interact with modules of HISB, and vice versa, in a way that enables one module to perform a unit of work on behalf of another module. The following subsections discuss the NHC modules and HISB modules separately. The NHC modules The NHC contains the main system modules that can be invoked directly by the presentation tier and implement the system’s services. The main roles of the NHC modules are: 1. Identification and authentication of system users. 2. Protecting the privacy of patients’ medical data and controlling access to them. 3. Providing access to summarized patients’ medical history stored locally at the NHC database.

J Med Syst (2013) 37:9953

4. Providing access to the comprehensive medical data stored remotely at the HCs’ databases. 5. Supporting emergency cases by retrieving the patients’ vital health signs from the NHC database based on the patient’s NPID. 6. Auditing the clinicians’ actions on the system so that any unrightfully access to patients’ data by clinicians can be traced by the various supervisors. Based on these roles, seven basic modules have been defined to be implemented at the NHC server as shown in Fig. 8. Figure 8 shows also which system data each of these modules deal with. A detailed description on the purpose and functionality of each of these modules is provided in the following subsections. Identification and authentication module (Iden&AuthenM) The purpose of this module is to identify clinicians and patients based on their NCIDs and NPIDs, and to authenticate them to access the system. Authorization module (AuthorM) The purpose of this module is to control access to the patients’ medical data; only those clinicians who are authorized by a patient can see his/her medical data. For each query made by a clinician to access a patient’s medical data on the system, the NHC consults this module to verify if that clinician is allowed to access this patient’s data based on the Clinician’s NCID and the Patient’s NPID. This is module uses the Authorization Table to search for a record with the given (NCID) and (NPID), if there is such a record then the query is executed, otherwise the query is rejected. It is not necessary that the patient knows the NCID of the clinician to give them the permission to view his records. The user interface of the system can designed in a way that allows the user to navigate to the required HC, and select the required clinician within that HC for authorization. Also, in some situations, a large number of clinicians within the same HC may need access to the patient’s records. The user interface can be designed to provide the features that allow the in-charge clinician to suggest the list of clinicians who will need access to the patient’s records, and the patient can accept, reject, or modify the list. Authorization control module (AuthorCM) The purpose of this module is to allow the patients to have a control over which clinicians can view their medical details. The module promotes the privacy of patients’ data; no clinician can access a patient’s medical data unless they have

J Med Syst (2013) 37:9953

Page 13 of 20, 9953

Fig. 8 The NHC modules

been authorized by the patient. This module can be invoked only by patients. Summarized medical history retrieval module (SMH-RetM) The purpose of this module is to retrieve the summarized medical history of a particular patient from the NHC database based on the patient’s NPID. The patient’s NPID is used by this module to retrieve all the MatchingIDs from the Matching table based on the NPID (the MatchingIDs indicate which HC has a local record for this patient and the LocalRecID of the local record of the patient at that HC). The MatchingID will then be used to retrieve all encounters of the patient from the Encounter table. This module can be invoked by clinicians through the NHC Interface or through the NHC Web Portal, or by patients through the NHC Web Portal. If the clinician has not been authorized by the patient to view his/her data, no data will be received from this module. Emergency support module (EmergSM) The purpose of this module is to extract critical medical information of the patient that are considered to be useful for emergency cases (ex: blood type and important healthcare problems) from the NHC database. This module is accessible for any clinician (even non-authorized clinicians) and can retrieve the critical information of a patient based on his NPID. If the NPID is not known, the SSN can be used to help find the associated NPID from the NHC. This module can be implemented in many ways, for example, an expert system may be built on the NHC to retrieve important information that would help in emergency cases from the Encounter table. Any access to this module by a clinician in a none-emergency case can be flagged by the patient since all clinician’s actions are audited through a Clinician Log Module (CLogM) which allows patients to inspect their parts of the access log. This module is proposed to be available through both the NHC Interface and the NHC Web Portal.

Query and forward module (Que&FrwM) When an authorized clinician requests a complete patient encounter details or test reports from a remote HC, this module will send a query to a special module at that HC’s HISB requesting the complete record of the patient’s encounter, the query will contain both the LocalRecID and the EncounterID. When the requested record is received, this module forwards it to the requesting clinician. For security purposes, this module is proposed to be available for clinicians only through the NHC Interface (i.e., through the private, secure WAN connection) to protect HC’s local databases from unauthorized parties on the Internet. Also, to reduce network traffic and provide better performance, this module is proposed to be available only for clinicians. Clinician Log module (CLogM) The purpose of this module is to keep track of the clinicians’ actions on the system. In this way, an alleged unrightfully access by clinicians can be traced by the various supervisors. Each patient has the right to inspect his or her part of the access log. The HISB modules As stated before, each HC has a special HISB connected to its local database which acts as a means through with local patient data is monitored, prepared, and submitted to the NHC. The main roles of HISB modules are: 1. To monitor the HC’s local database for each new local patient record and record it on the NHC database on time. 2. To monitor the HC’s local database for each new patient encounter and record a summary of it on the NHC database on time. 3. To submit complete patient encounter details or test reports from the HC’s local database to the NHC server as a result of a clinician request on the NHC server.

9953, Page 14 of 20

Based on these roles, five modules are defined to be implemented at each HISB as shown in Fig. 9. Figure 9 shows also which data each of these modules deal with whether this data is located at the remote NHC database or at the HC’s local database. A detailed description on the purpose and functionality of each of these modules is provided in the following subsections. Patient registration scanning module (PRegistrScanM) The purpose of this module is to monitor the HC’s local database for each new local patient record, and if there is, request the patient’s NPID on time from the registration staff at the HC. Then this module sends the NPID and the LocalRecID of the patient to the Patient Record Registration Module (PR-RegisterM) which in turn records the patient’s local record on the NHC database. Encounter scanning module (EncScanM) The purpose of this module is to monitor the HC’s local database for each new patient encounter, and if there is, retrieve a summarized copy of this encounter and send it to the Encounter Addition Module (Enc-AddM) to record it on the NHC database. The summary should contain the encounter ID, the LocalRecID, and the encounter summary including: diagnosis, vital signs, medications, immunizations, lab and radiology tests names and results. The retrieval of the summarized copy of the encounter from the HC’s local database is easy since the HISB is programmed with the specific data structures, formats and terminologies used by the HC’s local database so it knows which data elements will be fired.

Fig. 9 The HISB modules

J Med Syst (2013) 37:9953

In some HCs systems, the immunizations may be provided, or lab tests and radiology tests may be made, without being linked to some encounter ID. This will not affect the operations of the EncScanM module since these types of data are linked to the patient’s localRecID. In this case, the EncScanM will create a virtual EncounterID and link it with the localRecID at the NHC database. Recall that the PRegistrScanM ensures that each patient’s localRecID is linked with the NPID at the NHC database. Any HC’s system that does not use LocalRecID will need to be updated before it is connected to the proposed system. Patient record registration module (PR-RegistrM) This module is triggered by the PRegistrScanM module whenever a new local patient record is created. It receives the patient’s NPID and the LocalRecID of the patient from the Patient PRegistrScanM module and directly writes this information along with the HCID to the Matching Table on the NHC database, indicating that the patient has a local record at this HC. Encounter addition module (Enc-AddM) This module is triggered by the EncScanM module whenever a new patient encounter record is added to the HC’s local database. It receives the encounter summary information from the EncScanM. Then it retrieves the MatchingID from the Matching table on the NHC database based on the HCID and the patient’s LocalRecID, after that it writes the MatchingID along with the encounter summary to the Encounter Table at the NHC Database. The MatchingID is important to be associated with the patient’s encounter since

J Med Syst (2013) 37:9953

it refers to the HC where the patient is treated, the LocalRecID of the patient at that HC, and the patient’s NPID on the NHC (the patient’s NPID is not known to the HC’s local database and that’s why the HCID and the patient’s LocalRecID are used to retrieve MatchingID which refers to the HCID, LocalRecID, and NPID). Comprehensive encounter transmission module (ComEncTransM) This module is called by the Que&FrwM module on the NHC to send a comprehensive copy of a patient’s encounter from the local database to the NHC as a result of a clinician request on the NHC. It retrieves the comprehensive copy of the patient’s encounter from the local database based on the received patient’s LocalRecID and EncounterID. Then it standardizes this copy and sends it to Que&FrwM on the NHC. Comprehensive encounter records in different HC systems are of different structures, formats, contents and terminologies. Standardizing the contents of a comprehensive encounter record before transmitting it to the NHC is necessary to make the record readable by the other systems. Several standards that aim to structure and markup the clinical content of medical records for the purpose of exchange are provided by many organizations such as Health Level Seven (HL7) [45] and the European Committee for Standardization (CEN) [46]. These standards can be applied by the ComEncTransM module to convert the comprehensive medical record into an interoperable record before it is transmitted to the NHC. A survey and analysis of these standards is provided in [3]. Here, the preferred approach is the Health Level 7 Clinical Document Architecture (HL7 CDA) standard [47]. HL7 CDA is a document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange. CDA documents are encoded in Extensible Markup Language (XML) and can be parsed with any web browser, enabling easy exchange of these documents between different systems. A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content. It can be transferred within a message and can exist independently, outside the transferring message [47]. The rationale for using HL7 CDA is its proximity to industry; it is very common internationally and many EHR vendors incorporate it within their EHR systems [47, 48]. A detailed description of HL7 CDA standard can be found in [49]. The proposed system provides the operations needed to retrieve the complete record of a single encounter. If the complete EHR of the patient is requested from a remote HC, all the encounters complete records within that EHR will be retrieved one by one.

Page 15 of 20, 9953

Discussion Discussion of the overall semi-centralized NHIS approach Many forms of the Centralized Architecture are found in a number of NHISs as indicated in the “Introduction” section of this paper. Some of which require the complete duplication of the patients’ medical data into a central repository to achieve the highest quality possible in healthcare services such as Canada’s EHRS [11]. Another form of duplication found in Australia’s HealthConnect system [12] involves in a summary of patient events. However, the summary data that is centralized may not fully support the systems’ goals of improving healthcare quality. A third form of duplication is found in the England’s Spine system [13], which duplicates only a summary of patient events that would help in emergency cases. The Distributed Architecture is introduced to minimize the cost and complexity of the Centralized Architecture while at the same time providing access to complete medical information of patients. This architecture utilizes the HC’s local databases rather than creating a centralized repository. The centrally maintained reference links to the distributed patient’s records provide clinicians a means to know which HCs have medical data of the patient and to direct queries to these HCs to submit the required data. However, clinicians have no means to know which record referenced by those links contains the needed data, and anytime the clinician needs to access the medical history of the patient, he sends queries all HCs holding data for the patient. High network traffic and access delays are the main limitations of this approach. The Semi-Centralized Architecture proposed in this paper introduces a new approach. It utilizes the HC’s local databases, maintains reference links to patients’ data at a central system, and provides an indication of what is included within each reference link, allowing the clinician to go directly to what he/she needs and send a request to the HC holding the needed data. Summarized medical history of patients can be accessed directly through the central system. The problem of high network traffic experienced in the distributed approach is minimized in this approach, and so as the access delays that were experienced due to the high network traffic. Also, the problem of complexity and cost in the Centralized Architecture is minimized in this approach.

Discussion of the semi-centralized NHIS architecture This section discusses the design aspects of the SemiCentralized NHIS presented in this paper in terms of: user services covered by the design and features of the design.

9953, Page 16 of 20

Summary of user services covered by the design With the designed functionalities of the system, the main services of the system for patients, and clinicians are outlined in Table 1. The patient services are accessible through the NHC Web Portal, whereas the clinician’s services are accessible through both the NHC Interface and the NHC Web Portal except the second service (Order comprehensive copies of the patient’s medical records from remote HCs). Comprehensive patients’ data that reside at the distributed HCs cannot be requested through the NHC Web Portal for security purposes (to protect against accessing the data held by the HCs’ databases by unauthorized parties on the Internet). Features of the proposed semi-centralized NHIS design The following points summarize the advantages of the proposed semi-centralized NHIS architecture: 1. Achieving interoperability while keeping on current HC’s systems; Each HC has a HISB system connected to its local database. The HISB component masks the heterogeneity between the HC’s local databases. With the implementation of HISB components, the HC will not need to update its local database to be able to deal with the proposed system because the HISB component masks the heterogeneity between the HC’s local databases. However, some institutions grant only one encounter number for an entire sequence of care, from clinic visits, to inpatient, to rehabilitation. Such institutions will need to update their systems such that: each patient is identified by one local ID, and each encounter is identified by an encounter ID. Any type of visit, whether it is emergency department, outpatient or inpatient visit, is considered as an encounter. If the date should be represented within the encounter ID, the admission date is considered in the inpatient case.

Table 1 The main user services covered by the design Type of user Main services Patient

Clinician

1. View his/her medical history in a summarized form. 2. Authorize/un-authorize clinicians to view his/her medical data. 3. Monitor actions performed on his/her medical data and report unrightfully access to this data. 1. View the summarized medical history of the patient. 2. Order comprehensive copies of the patient’s medical records from remote HCs. 3. View the patient’s critical medical data in emergency cases regardless of authorization.

J Med Syst (2013) 37:9953

2. High data consistency; whenever a new local patient record or encounter is added to the HC’s local database, it is discovered by the HISB system which in turn registers a new “Matching” record at the NHC database and records a summary of the new patient encounter on the NHC database on time. 3. Effective automation of processes; the architecture pays a special attention to the effective automation of processes. The addition of new patient’s data from HC’s local database to the NHC database is done automatically through the HISB system without any user intervention. This feature promotes usability of the system. 4. Effective load distribution; the processing modules of the system (business tier modules) are divided between the NHC and the connected HISB systems in a way which ensures that the NHC is not heavily overloaded. The NHC modules handle most of the read operations whereas the various HISB systems handle most of the write operations to the NHC database. This distribution of operations promotes the scalability of the system. 5. High privacy of the patient’s data; patients have a control over who can see their medical data and no clinician can disclose their medical data if he hasn’t been authorized by the patient. Patients can inspect their parts of the clinicians’ access logs and report unrightfully access to their medical data. The proposed approach permits the granting of physician access to patient’s data on an all-or-none basis because it is based on the NPID. An alternative approach that permits the patient to restrict the sharing of his information was proposed by ASTM standards (E2553) in 2007. This approach is named the “Voluntary Universal Healthcare Identifier (VUHID) system” [50]. The standards define two types of identifiers: Open Voluntary Identifiers (used to support unrestricted sharing of information), and Private Voluntary Identifiers (used for restricted sharing of information on a wide variety of conditions such as psychiatric, genetic, or behavioral health information). A typical patient would have only one open ID but may have as many private IDs as his or her situation warrants. In this way, patients are in control of what information will be shared with whom. One way to apply this approach on the proposed system is as follows: The patient can have two types of NPIDs that uniquely identify him: one Open NPID (used to support unrestricted sharing of information), and many Private NPIDs (used for restricted sharing of information). The Open NPID will be linked with the patient’s local record at each HC and will be dealt with as the normal NPID discussed in this paper. Each Private NPID will be linked with the special encounters that fall under the same condition throughout all HCs as the patient demands, and will be transmitted to the NHC with the encounter summary it is associated with.

J Med Syst (2013) 37:9953

Page 17 of 20, 9953

That is the Private NPID will be stored at the Encounter Table. In this way, when the physician uses the Open NPID, all the patient’s encounters summaries will be retrieved by the system except those that are associated with a Private NPID. The Private NPIDs can be used to retrieve information on encounters with which they are associated. The disclosure of encounter data that are linked with some Private NPID requires that the physician has been already authorized by the patient to view his data in the Authorization Table, and that the patient has given the physician his Open as well as Private NPID. However, although having multiple identifiers could help more in protecting patient’s privacy, the use of multiple

identifiers for the same patient keeps the information fragmented and isolated and hurts legitimate purposes such as timely access to information and delivery of care [51]. 6. Providing security measures; the security measures are provided in many aspects of the design including: • The connection between the HCs and the NHC is based on a secure private line connection (WAN). All the NHC services are designed to be accessible through this secure connection, only the server that hosts the NHC web portal is designed to be accessible through the Internet.

Table 2 A comparative analysis summary between the current approaches and the proposed one No.

Aspect

Centralized approach

Distributed approach

Semi-centralized approach

1

Architecture

Centralized data repository (for full or summarized EHR)

Centralized reference links

2

Data Redundancy

No (no medical data is duplicated)

3 4

Consistency Medical value

High High

High High

5

Security

High

Moderate

6 7 8

Privacy Network traffic Availability

- High (in systems with full EHR duplication) - Low (in systems with summarized EHR duplication) Low - High (in systems with full HER duplication) - Low (in systems with summarized EHR duplication, the summary data that is centralized may not fully support the systems’ goals of improving healthcare quality) - Low (in systems with full EHR duplication) - Moderate (in systems with summarized EHR duplication) Depends on the design Low high

Centralized data repository (for summarized EHR) with reference links Low (only summarized EHR duplication)

High High low

High Moderate High for summaries. Moderate for comprehensive records

9

Query response

Fast

Subject to long delays due to high network traffic

10 11 12

Maintainability Load balancing Cost/complexity of design and implementation

Difficult High Low

13

Scalability

Easy Low - High (huge and very complex repositories for systems with full EHR duplication) - Low (for systems with summarized EHR duplication) high

Fast for EHR summaries. Retrieval of comprehensive records may subject to delays due to network traffic. Difficult High Low (HC’s local databases are utilized, and the HISB masks the heterogeneity between the different HC’s local databases)

14

Mobility

High

Low (high network traffic may affect the system’s performance when increased in scale). Low (allowing the access to the system while in mobility may increase the network traffic and affect the performance)

Moderate, and can be increased when implementing the NHC using cloud computing. High

9953, Page 18 of 20

•

The NHC web portal provides access only to summarized patient data maintained on the NHC. Comprehensive patients’ data that reside at the distributed HCs cannot be requested through the NHC Web Portal to protect against accessing the data held by the HCs’ databases by unauthorized parties on the Internet and to protect against Denial of Service attacks (DoS attacks). • Designing the system on the three-tier architecture provides also extra security to the system. It is not possible for a client to get direct access to sensitive data in the data tier. Before getting to the data tier, the client should contact the business tier. Within the business tier, adequate security policies can be implemented. 7. Meeting the flexibility challenge; Building the system on three tier architecture ensures the flexibility of the system as system components can be added or moved. 8. Centralized control of communication; Retrieving a comprehensive patient record from a remote HC is carried out only through the NHC. This facilitates the authentication process on the HISB side and improves the efficiency and effectiveness of the system as well. 9. Meeting the mobility challenge and providing accessibility for both patients and clinicians; this is achieved through Web Portal, which allows clinicians and patients to access the system through the Internet. Although not all the clinicians’ services are available through the Web Portal, the most important services that will be needed by clinicians while in mobility are available through this portal, especially the emergency support service. 10. Emergency support features; an important contribution of the paper is the addition of an emergency component to the system, which allows non-authorized clinicians to retrieve the patient’s vital health information that would help greatly in emergency situations. The philosophy behind this is that “no patient should die because a system blocked access to vital data”. It will help clinicians in emergency ambulances to take better decisions and provide better treatment. Recall that any access to this service by a clinician in a nonemergency case can be flagged by the patient since all clinicians’ actions are audited.

J Med Syst (2013) 37:9953

Conclusion This paper has proposed a new semi-centralized architecture that links healthcare providers EHR systems with a central system. The architecture is based on SOA and web services to communicate and exchange data within all the components of the system. A unique smart solution to a nationwide EHR integration, that holds summarized encounters at a central system and links them to the original healthcare providers EHR, has been proposed. This solution provides the flexibility to the clinician to access high level patient clinic information represented by a full list of summarized encounters, and a low level of information by extracting full details for each encounter from the original location of the healthcare provider where this encounter has taken place. The semi-centralized architecture provides an effective framework for achieving interoperability while keeping on current healthcare provider’s systems. It effectively meets challenges of high data consistency, privacy of patients’ data, mobility, and maintainability. It also provides an effective automation of processes which promotes the usability of the system, effective distribution of load among the system components which promotes the performance and scalability of the system, centralized control of communication which promotes security of the system, accessibility for both patients and clinicians, and emergency support features. Future work includes further improvement to the proposed architecture by incorporating it with Cloud Computing to provide more scalability and flexibility to the system. Finally, the system will be implemented using real or simulated databases and its performance will be evaluated against the existing centralized and distributed architectures. Acknowledgments This work is part of a 2 year research project which has been fully funded by a grant through King Abdul-Aziz City for Science and Technology (KACST)/National Plan for Science and Technology (NPST) in the Kingdom of Saudi Arabia. Grant number: 09-INF880-02 Conflicts of interest No conflict of interest exists. Authorship Asma AlJarullah carried out the research and designed the system under the supervision of the second author, and wrote the manuscript. Samir El-Masri conceived the research idea, proposed the system, and reviewed final draft of the manuscript.

Comparative analysis summary References The current typical approaches of national EHR integration along with the proposed semi-centralized approach have been discussed and compared in different parts of the paper in terms of: architecture, advantages, and problems (In both “Introduction” and “Discussion” sections). Table 2 summarizes a comparative analysis between the three approaches.

1. Electronic Health Record (EHR) Workgroup At The University Of Dammam, Saudi Arabia, http://ehr2011.weebly.com/, last accessed Dec 2011. 2. Healthcare Information Management Systems Society (HIMSS), “Electronic Health Record (EHR)”, As of May 2012, http://www. himss.org/asp/topics_ehr.asp.

J Med Syst (2013) 37:9953 3. Eichelberg, M., Aden, T., Riesmeier, J., Dogac, A., and Laleci, G., A survey and analysis of electronic healthcare record standards. ACM Comput Surv 37(4):277–315, 2005. 4. ISO, “Requirements of an EHR reference architecture”, 2002, As of May 2012: www.openehr.org/standards. 5. Girosi, F., Meili, R., and Scoville, R., Extrapolating Evidence of Health Information Technology Savings and Costs, Santa Monica, Calif.: RAND Corporation, MG-410-HLTH, 2005. 6. Hillestad, R., Bigelow, J., Bower, A., Girosi, F., Meili, R., Scoville, R., and Taylor, R., Can electronic medical record systems transform health care? Potential health benefits, savings, and costs. Heal. Aff. 24(5):1103–1117, 2005. 7. Daglish, D., and Archer, N., “Electronic Personal Health Record Systems: A Brief Review of Privacy, Security, and Architectural Issues,” congress, pp.110-120, 2009 World Congress on Privacy, Security, Trust and the Management of e-Business, 2009. 8. Moller, J.E., and Vosegaard, H., “Experiences with electronic health records,” IT Professional, vol. 10, no. 2, pp. 19–23, March-April 2008. 9. Jalal-Karim, A., and Balachandran, W., “The optimal network model’s performance for sharing Electronic Health record”, Proceedings of the 12th IEEE International Multitopic Conference, December 23-24, 2008. 10. Liu, V., Caelli, W., Smith, J., May, L., Lee, M.H., Ng, Z.H., Foo, J.H., and Li, W., A secure architecture for Australia’s index based ehealth environment. In: Maeder, A., and Hansen, A. (Eds.), Proceedings of the Fourth Australasian Workshop on Health Informatics and Knowledge Management - Volume 108 (HIKM '10), Vol. 108. Australian Computer Society, Inc., Darlinghurst, Australia, Australia, 7–16, 2010. 11. Canada Health Infoway, EHRS Bluprint, v2, March 2006, As of May 2012: https://knowledge.infoway-inforoute.ca/EHRSRA/doc/ EHRS-Blueprint.pdf. 12. Australian Government Department of Health and Ageing, authors. HealthConnect Business Architecture version 1.0. 2003. Apr, pp. 30– 31., As of May 2012: http://www.health.gov.au/internet/hconnect/ publishing.nsf/content/43598FE37A3E7270CA257128007B7EB7/ $File/v3-6.pdf. 13. House of Commons, “Department of Health: The National Programme for IT in the NHS”, Twentieth Report of Session 2006–07, April 2007, As of May 2012: http://www.publications.parliament.uk/ pa/cm200607/cmselect/cmpubacc/390/390.pdf. 14. National Health IT Board, “National Health IT Plan: Enabling an Integrated healthcare Model”, Sep 2010, As of May 2012: http:// www.ithealthboard.health.nz/sites/all/files/National%20Health% 20IT%20Plan%20v11_1.pdf. 15. Ruotsalainen, P., Doupi, P., and Hämäläinen, P., Sharing and management of EHR data through a national archive: Experiences from Finland. World Hosp Health Serv 43(4):38–41, 2007. 16. Tiik, M., and Ross, P., Patient opportunities in the estonian electronic health record system. In: Medical and Care Compunetics 6. London, UK: IOSPress, 2010, p. 171–177. 17. McDonald, C. J., Overhage, J. M., Barnes, M., Schadow, G., Blevins, L., Dexter, P. R., and Mamlin, B., The Indiana network for patient care: A working local health information infrastructure. Heal. Aff. 24(4):1214–1220, 2005. 18. Canadian Medical Association or its licensors, “Medical data debates: Big is better? Small is beautiful?”, CMAJ, 2011, DOI:10.1503/ cmaj.109-3799, available online at http://www.cmaj.ca/content/early/ 2011/02/22/cmaj.109-3799.full.pdf. 19. Canada Health Infoway, As of May 2012: https://www.infowayinforoute.ca/lang-en. 20. Minister of Public Works and Government Services Canada, “Electronic Health Records in Canada, An Overview of Federal and Provincial Audit Reports”, APRIL 2010, Cat. No. FA3-56/2010E-

Page 19 of 20, 9953

21. 22. 23.

24.

25.

26.

27.

28.

29.

30. 31. 32.

33.

34.

35.

36.

37.

38.

39.

PDF, ISBN 978-1-100-15353-7, As of May 2012: http://www.oagbvg.gc.ca/internet/docs/parl_oag_201004_07_e.pdf. HealthConnect., http://www.health.gov.au/internet/hconnect/ publishing.nsf/content/home, last accessed May 2012. National Health Service, As of May 2012: http://www.nhs.uk/ Pages/HomePage.aspx. Greenhalgh, T., Stramer, K., Bratan, T., Byrne, E., Russell, J., and Potts, H. W. W., Adoption and non-adoption of a shared electronic summary care record in England: A mixed-method case study. BMJ 340:c3111, 2010. Spronk, R., “AORTA, the Dutch national infrastructure”, Righolm, (2008), As of May 2012: http://www.ringholm.de/docs/00980_ en.htm. Halamka, J., Atranow, M., Ascenzo, C., Bates, D., Debor, G., Glaser, J., Goroll, A., Stowe, J., Tripath, M., and Vineyard, G., Health care IT collaboration in Massachusetts: The experience of creating regional connectivity. J Am Med Inform Assoc 12(6):596– 601, 2005. de Smet, K., “The Dutch Nationwide Electronic Health Record: Why the Centralised Services Architecture?” wicsa, pp.181-186, 2011 Ninth Working IEEE/IFIP Conference on Software Architecture, 2011. Fragidis, L.L., and Chatzoglou, P.D., “The Use of Electronic Health Record in Greece: Current Status,” cit, pp.475-480, 2011 IEEE 11th International Conference on Computer and Information Technology, 2011. Hoerbsta, A., Kohlb, C., Knaupb, P., and Ammenwerthc, E., Attitudes and behaviors related to the introduction of electronic health records among Austrian and German citizens. Int J Med Inform 79:81–89, 2010. Tang, P. C., Ash, J. S., Bates, D. W., Overhage, J. M., and Sands, D. Z., Personal health records: Definitions, benefits, and strategies for overcoming barriers to adoption. J Am Med Inform Assoc 13:121– 126, 2006. MyMediConnect, http://www.mymediconnect.net/, last accessed Dec 2011. HealthVault, www.healthvault.com, last accessed Dec 2011. Schneider, J. H., Online personal medical records: Are they reliable for acute/critical care? Crit. Care Med. 29(8 Suppl):N196–N201, 2001. doi:10.1097/00003246-200108001-00009. Kim Matthew, I., and Johnson, K. B., Personal health records: Evaluation of functionality and utility. J Am Med Inform Assoc. 9(2):171–180, 2002. doi:10.1197/jamia.M0978. Wimalasiri, J.S., Ray, P., and Wilson, C.S., “Maintaining security in an ontology driven multi-agent system for electronic health records,” Enterprise Networking and Computing in Healthcare Industry, 2004. HEALTHCOM 2004. Proceedings. 6th International Workshop on, vol., no., pp. 19–24, 28–29 June 2004. Mandl, K. D., Simons, W. W., Crawford, W. C. R., and Abbett, J. M., Indivo: A personally controlled health record for health information exchange and communication. BMC Med Inform Dec Making v7:1–10, 2007. Pavalam, S.M., Jawahar, M., and Akorli, F.K., “Data warehouse based Architecture for Electronic Health Records for Rwanda,” Education and Management Technology (ICEMT), 2010 International Conference on, vol., no., pp. 253–255, 2–4 Nov. 2010. Shih, T.K., “Advanced Penetration Testing Methodology for VPN”, Journal of Security Engineering, 2008, As of May 2012: http:// www.sersc.org/journals/JSE/vol5_no5_2008/7.pdf Hillestad, R., Bigelow, J.H., Chaudhry, B., Dreyer, P., Greenberg, M.D., Meili, R.C., Ridgely, M.S., Rothenberg, J., and Taylor, R., “Identity crisis: An examination of the costs and benefits of a unique patient identifier for the U.S. health care system”, Santa Monica, CA: RAND Corporation, MG-753-HLTH, 2008. Hieb, B., The case for a voluntary national healthcare identifier. J ASTM Int. 3(No. 2), 2006. doi:10.1520/JAI13891.

9953, Page 20 of 20 40. Classen, D. C., Kanbouwa, M., Will, D., Casper, J., Lewin, J., and Walker, J., The patient safety institute demonstration project: A model for implementing a local health information infrastructure. J Healthc Inf Manag 19(4):75–86, 2005. 41. Castro D., Explaining International IT Application Leadership: Health IT, Information Technology and Innovation Foundation, Septemper 2009, As of 12 May 2012: http://www.itif.org/files/ 2009-leadership-healthit.pdf. 42. Lichtner, V., Wilson, S., and Galliers, J. R., The challenging nature of patient identifiers: an ethnographic study of patient identification at a London walk-in centre. Health Inform J 14:141–150, 2008. 43. Federico, G., Meili R., and Scoville, R., Extrapolating Evidence of Health Information Technology Savings and Costs, Santa Monica, Calif.: RAND Corporation, MG-410-HLTH, 2005. 44. Connecting for Health, “Linking health care information: Proposed methods for improving care and protecting privacy”. New York: Markle Foundation, 2005. As of May 2012: http://www.markle.org/ sites/default/files/linking_report_2_2005.pdf. 45. Health Level Seven International (HL7), As of May 2012: http:// www.hl7.org/.

J Med Syst (2013) 37:9953 46. CEN - European Comittee for Standarization, As of May 2012: http://www.cen.eu/. 47. Health Level Seven Clinical Document Architecture (HL7 CDA), As of May 2012: http://www.hl7.org/implement/standards/product_ brief.cfm?product_id=7 48. Brzezinski, J., Czajka, S., Kobusinski, J., and Piernik, M., “Healthcare Integration Platform”, Medical Information & Communication Technology (ISMICT), 2011 5th International Symposium on, 02 May 2011, 11973621:52. 49. Dolin, R. H., Alschuler, L., Beebe, C., Biron, P. V., Boyer, S. L., Essin, D., Kimber, E., Lincoln, T., and Mattison, J. E., The HL7 clinical document architecture. J Am Med Inform Assoc 8:552–569, 2001. 50. American Standards for Testing and Materials (ASTM), E2553-07 Standard Guide for Implementation of a Voluntary Universal Healthcare Identification System, ASTM International, September 2007. 51. Appavu, S.I., Analysis of Unique Patient Identifier Options: Final Report, prepared for the U.S. Department of Health and Human Services, November 24, 1997a.