ORIGINAL PAPER

A Novel System Architecture for the National Integrationof 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 recordsintegration system is to aggregate electronic health recordsconcerning a particular patient at different healthcare pro-viders’ systems to provide a complete medical history of thepatient. It holds the promise to address the two most crucialchallenges to the healthcare systems: improving healthcarequality and controlling costs. Typical approaches for thenational integration of electronic health records are a central-ized architecture and a distributed architecture. This paperproposes a new approach for the national integration ofelectronic health records, the semi-centralized approach, anintermediate solution between the centralized architectureand the distributed architecture that has the benefits of bothapproaches. The semi-centralized approach is provided witha clearly defined architecture. The main data elements need-ed by the system are defined and the main system modulesthat are necessary to achieve an effective and efficient func-tionality of the system are designed. Best practices andessential requirements are central to the evolution of theproposed architecture. The proposed architecture will pro-vide the basis for designing the simplest and the most effec-tive systems to integrate electronic health records on anation-wide basis that maintain integrity and consistencyacross locations, time and systems, and that meet the chal-lenges of interoperability, security, privacy, maintainability,mobility, availability, scalability, and load balancing.

Keywords Semi-centralized EHR . Distributed EHR .

EHR-integration . Medical record linkage . Electronichealth records

Introduction

Electronic health record

Globally, hospitals are moving away from paper-based med-ical records towards Electronic Health Records (EHR). Thepace of the movement differs between countries and betweendifferent health sectors within countries. The benefits ofmoving toward EHR are numerous. Use of EHR help inimproving quality of health information, speed and flexibil-ity in access to health records, improvement in the process ofdecision making for patients. All of these help in reducingmedical errors and in improving on patient safety. In addi-tion, EHR is an integral component of the e-health [1].

According to the Healthcare Information ManagementSystems Society (HIMSS) [2], an EHR is: “a longitudinalelectronic record of patient health information generated byone or more encounters in any care delivery setting. Includedin this information are patient demographics, progress notes,problems, medications, vital signs, past medical history, im-munizations, laboratory data and radiology reports. The EHRautomates and streamlines the clinician’s workflow. The EHRhas the ability to generate a complete record of a clinicalpatient encounter — as well as supporting other care-relatedactivities directly or indirectly via interface — includingevidence-based decision support, quality management, andoutcomes reporting.” [2].

The value of the national integration of electronic healthrecords

Currently, Electronic Health Records (EHRs) are kept in avariety of formats at different healthcare providers’ systemsthat is, in ‘information silos’. The goal of EHRs-integrationsystem is to aggregate the EHRs concerning a particular patientat different healthcare providers’ systems to provide a completemedical history of the patient [3]. The architecture of EHRs-

A. AlJarullah (*) : S. El-MasriDepartment of Information Systems, College of Computer andInformation Sciences, King Saud University, Riyadh, Saudi Arabiae-mail: asma.aljarullah@gmail.com

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

integration systems is defined as a “Model containingnecessary features that can be useful, complete, and effec-tive and maintains integrity across locations, time andsystems” [4]. Integrating EHRs from various sources hasbeen a subject of extensive discussions within the medicalinformatics community.

A recent RAND study [5], on the value of connected EHRsystems for the U.S., estimated a potential efficiency savingsof $77 billion per year at a 90-percent level of adoption;adding the value for safety and health could double thesesaving. This integration would enable clinicians to accesscomplete medical histories of their patients in a standardizedway. Some of the anticipated benefits of EHRs integrationinclude [6]:

& Availability and accessibility of vital health informationanytime regardless of where the person requiring care is.

& More effective and efficient treatment since the medicalhistory of patients is available to healthcare practitioners.

& Accessibility to the medical history of patients helpsavoiding adverse events arising from drug treatmenterrors including drug interactions, duplications or inap-propriate doses or inappropriate treatments being givenbased on incomplete information,

& Reduction of the number of redundant procedures andtests, and therefore, less health risks for the patient andgreater cost savings.

& Empowerment of individuals to exercise greater controlover their own health, by giving them access to their ownpersonal health records, and by enabling them to makeinformed 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 clinicalresearch, medical decision-making, epidemiology andevidence based medicine.

Problems of the current approaches for the nationalintegration of EHRs

Many countries are moving toward the national integrationof EHRs and many approaches to achieve this have beenimplemented (as discussed in “Literature review” section ofthis paper), and among the approaches considered by thesecountries, the most successful approaches that have beenimplemented and put into practice are the centralized archi-tecture and the distributed architecture.

In the centralized architecture (Fig. 1), duplicates of EHRs—either in a comprehensive or summarized form — are trans-mitted to a central nationwide system, which works as arepository of the all patient’s EHRs across a country. This isreferred to as a ‘push’model, based on the concept of pushingthe data from the healthcare providers to the central site [7].The ‘pushing’ of medical data from the medical centers to the

central repositories occurs periodically; for example, InDenmark, it happens every night [8].

In the distributed architecture (Fig. 2), all informationwould be stored and maintained locally within the varioushealthcare providers and facilities. Centrally maintained ref-erence links at a central system would indicate where theoriginal data records are located. This is referred to as a ‘pull’model, since the central agency requests all the data neededfrom the providers whenever a request for a patient’s EHR isissued. The pull model does not involve a central repository,since datamay only be requested when needed by a requestinguser [7].

The centralized architecture has the advantages of avail-ability, performance, and speed of query response. On theother hand, the use of centralized data repository that containdata from multiple sources, usually have difficulty with datacontext and codification, and their complexity of design inmost may cases leads to extensive delays in actual implemen-tation and use [7]. Also, it may require huge costs forimplementing the central store of information, and it suffersfrom data inconsistency on the central system since patientdata are usually sent to the central system periodically. Finally,

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

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

9953, Page 2 of 20 J Med Syst (2013) 37:9953

the creation of nationally accessible system that contains allpatients’ data would increase the risk of security breaks [9].

The distributed architecture has the advantage of de-creased cost for implementing the central system since itdoes not contain any duplication of medical data. Also, thisarchitecture has a unique advantage of data consistency andthat it accesses the latest information about the patient asneeded. Furthermore, this approach helps assure protectionof patient information and addresses concerns about threatsto privacy and security, because patient information remainsat the source rather than being duplicated in a centralizeddatabase. However, queries to access patient’s data on re-mote healthcare providers may take a long time to complete.It places additional overhead burdens on the communicationnetwork and the source systems being accessed, thus accessdelays are likely to be unacceptable [7, 10].

Contribution of the paper

This paper proposes an intermediate solution between thecentralized architecture and the distributed architecture thathas the benefits of both approaches, the Semi-Centralizedapproach (Fig. 3). In this approach, summarized EHRs areproposed to be maintained centrally at a national healthcaresystem with reference links to their comprehensive versionsat their original locations on the various healthcare pro-viders’ systems, where the national healthcare system pro-vides access to EHRs summaries stored locally and compre-hensive EHRs stored remotely at the distributed healthcareprovider’s systems.

In other words, the semi-centralized system stores a sum-marized copy (not a minimal dataset, like the case of somecentralized architectures presented in the “Literature review”)of each electronic health record from each hospital at thecentral system. The clinician will be able to see a small picture

of each electronic health record of the patient in all hospitals.A clinician can extract the full electronic health record detailsfrom the remote hospital as needed.

The idea of this approach is to allow the clinicians to havean idea of what is included inside the patient’s EHRs at eachhealthcare provider from a central location and to have ageneral view of the patient’s medical history, and whenneeded, retrieve the complete EHR of the patient from aremote healthcare provider’s system. This solution has theunique advantage of fast access to summarized patient’smedical history on the national healthcare system, with thepossibility to retrieve a comprehensive EHR from a remotehealthcare provider’s system as needed.

Research question

The paper answers the following research question:

How to integrate EHR links and summaries into thesystem and provide access to them and to remotelystored complete copies in the most effective way?

Research methodology

The paper answers the research question by converting theproposed system into a working model in three major phases:

1. Phase 1: Designing the high-level architecture for theproposed Semi-Centralized National Health InformationSystem (NHIS).

2. Phase 2: Designing the data model for the proposedSemi-Centralized NHIS.

3. Phase 3: Design the modular architecture for the pro-posed Semi-Centralized NHIS.

In the next sections, a literature review exploring andanalyzing the current approaches for EHR-integration foundin practice in many countries around the world or proposedin published papers, then the high level architecture of theproposed NHIS is described, and then the components of thesystem are designed. After that, the data model of the systemis defined. Then the modular architecture of the system isdesigned. Finally, a discussion is provided on the overallSemi-Centralized NIHS and the advantages of the proposedarchitecture.

Literature review

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

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

J Med Syst (2013) 37:9953 Page 3 of 20, 9953

the centralized and distributed architectures have been men-tioned previously, this section will describe them in moredetails by analyzing a number of NHISs that adopted them.Other approaches for EHR integration proposed in the litera-ture are discussed in the other approaches sub-section at theend 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 threecountries are selected for further analysis in the followingsubsections as they introduce a variety of EHR integrationstrategies: Canada’s EHR Solution (EHRS) [11], Australia’sHealthConnect System [12], and England’s Spine System[13].

Canada’s EHR solution (EHRS)

Canada’s e-health structure is based on highly-centralizedEHR systems within each province containing patient re-cords that can be shared nationwide [18]. Canada HealthInfoway [19], funded by the government of Canada, workswith the country’s ten provinces and three territories toimplement private, secure EHR systems. Although eachprovince and territory has an EHR system adapted to itsneeds, all of the provincial and territorial systems are basedon an agreed set of principles and characteristics known asthe Electronic Health Record Solution (EHRS) blueprint.Core components of the EHRS include [11, 20]:

& Client registry: a list of all patients and their relevantpersonal information.

& Provider registry: a list of participating health care pro-fessionals who are authorized to use the system.

& Continuity of care data repository that holds informationon health encounters and health service events (such asallergies), and the clinical observations associated withthose events.

& Diagnostic imaging repository: stores patients’ imagesand reports, such as x-rays and ultrasounds.

& Laboratory information repository: stores patients’ labo-ratory results.

& Drug information repository: stores patient’s medicationhistory.

& Health Information Access Layer (HIAL): a set ofstandards and communication services to sustain theinteroperability of the different components within theinfostructure (the central repositories and registries), aswell as to sustain interoperability between the EHRinfostructure and the point of service healthcare provid-er applications.

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

Australia’s HealthConnect system

The national Australian Healthcare strategy for EHRs wasprepared in the HealthConnect Business architecture [21],which included the constructing of a national health informa-tion network and a sequence of patient event summarieswould form the core of the EHR, which would be stored in afederated HealthConnect record system to be utilized byhealthcare organizations and in the National Data Store forsecondary applications. It involves the collection, storage andsharing of patient clinical information in summary layoutthrough a secure network using precise security protection.

The components of HealthConnect model are a series ofevent summaries, which produced according to definedmetadata covering format, data items and allowable codesets and contain key information about specific healthcareevents, such as, allergies, observations, test orders and re-sults, diagnoses, medications and referrals [12].

HealthConnect does not create a comprehensive longitudi-nal record. Rather, patients, with their providers, will choosewhich elementsmay be extracted from an existing health recordand transmitted to the HealthConnect record. Providers, withthe consent of their patients, may subsequently add data to theHealthConnect record. It follows, therefore, that HealthConnectis a “push” system, selectively sending data to a centralizedrecord. For example, a patient might elect to include details ofhis psychotropic prescriptions in an event summary and con-sent to all his prescribing doctors viewing that data, but onlyconsent to other mental health professionals viewing his psy-chiatrist’s discharge order [10].

However, the summary data that is centralized may notfully support the system’s goals of improving healthcare qual-ity, disseminating professional education, and supportingresearch [12].

England’s Spine system

The National Health Service (NHS) in England implementsthe National Programme for IT (NPfIT) [13] to deliver thecentral electronic healthcare record system. This centralsystem is known as Spine. Spine consists of three corecomponents [22]:

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

9953, Page 4 of 20 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 tosupport safe treatment in emergency care including: NHSnumber, date of birth, name and address, allergies, ad-verse drug reactions and major treatments. These SCRrecords are created manually by clinicians and stored onthe Spine.

& The Secondary Uses Service (SUS) database: uses datafrom patient records to provide anonymised andpseudonymised business reports and statistics for re-search, planning and public health delivery.

Authorized healthcare professionals can access patient’shealthcare SCR. Patients also can access the NHS spinethrough a patient portal on the internet. However, the planof NPfIT has been greatly delayed and frequently criticized.And the EHR and data exchange raise significant privacyconcerns and have caused a considerable resistance regard-less of the obvious benefits [23].

Distributed architecture

This architecture is adopted in the Netherlands [24], andMassachusetts [25]. The following subsection analyzes theNHIS 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 localEHR, under the responsibility of the healthcare providerwhere the data was first recorded [7]. It uses a HealthcareInformation Broker (HIB), a national switch point to enablethe exchange of healthcare information. There is no clinicalinformation stored at the HIB. The clinical data details resideat local health information systems [24].

The participating healthcare providers’ systems areconnected to the HIB through Virtual Private Networks(VPN). All exchange of patient data between healthcare pro-viders passes through the HIB, such that the HIB controls theaccess to patient data using a national authorization protocol,record locator, access log to maintain which healthcare prac-titioners have accessed patient data for accountability, andidentification & authorization module [26].

The HIB performs a number of security measures. Eachprofessional needs a special smartcard with PKI certificates toidentify and authenticate himself or herself to the HIB. Thissmartcard is only issued to registered healthcare professionalsand their assistants. For each query, the HIB consults theauthorization protocol to verify if the healthcare professional,based on his professional title, is allowed to access this type ofpatient data. An assistant may only have access on behalf of

and with permission from a healthcare professional. The HIBalso verifies if the patient has registered an objection againstelectronic exchange of his patient data or against specifichealthcare providers. Only if all verifications are positive, willthe HIB put the query through [26].

Electronic health cards

In this approach, duplicates of the EHRs for each citizen arestored on an electronic card, the Electronic Health Card,which is owned by the citizen. This approach is theGermany’s e-health strategy on the way of EHR implemen-tation [27, 28]. The Electronic Health Card project is con-sidered as one of the biggest IT-projects, not only inGermany but worldwide [27]. However, the German healthcard is still under development, and the infrastructure istested on a trial mode. The overall progress of the EHRproject in Germany has been delayed several times, due tothe technical complexity and strong resistance of health pro-fessionals [28]. There is little protection from loss, theft, ordamage unless there is an online network backup [29].

Online personal EHRs

This approach is quite different in concept. It assumes thatindividual patients will aggregate their diverse records andthen make them selectively available to new providers. Thereare several web-based personal EHR systems such asMyMediConnect [30] and Vital Vault [31] that provide se-cure web space in which patients can aggregate their medicaldata. Most of these systems allow for both end-user input andimportation of data from institutional records to allow man-agement of accounts. And some of them also offer automatedupdating from selected providers. However, the online per-sonal EHRs tend to exhibit limited functionality, and lackperformance [32, 33].

Other approaches

Karel de Smet [24] proposed distributed service architecturefor the Dutch EHR integration model rather than the currentcentralized service architecture, where all patient data isexchanged directly between the endpoint systems. The au-thor also evaluated both architectures on technical and orga-nizational aspects, partly based on practical experience. Theresult was that present centralized services architecture of thenationwide EHR scores better in terms of simplicity, versioncompatibility and service manageability; whereas the distrib-uted services architecture of the Dutch nationwide EHRscores better in terms of functional manageability, flexibility,capacity, scalability and reusability.

Jaminda S. et al. [34] proposed ontology based multi-agent system for exchanging EHRs between two systems.

J Med Syst (2013) 37:9953 Page 5 of 20, 9953

The aim of this system is to achieve the automated integra-tion of heterogeneous EHRs of a patient residing on differenthospital information systems. This is accomplished throughthe use of ontologies. Ontologies define the terms and therelationships between terms with which to model a specificdomain. The raw data is attributed with semantic informationallowing automated reasoning to be carried out. When aclinician makes a query for a patient’s EHR to the ClinicalComputing System (CCS), the mobile agent will then travelto the other CCS agent platforms to present its query. Thelocal agent will resolve any differences in naming conven-tions based on an internal heuristic. The mobile agent’s XMLschema will be attributed with the knowledge contained inthe remote EHR, thus resolving the query.

K. D. Mandl et al. [35] proposed a subscription model forEHR-integration based on a mobile agent. The proposed mod-el is a subscription model, in which a patient establishes anEHR on the system and identifies sources of personal healthdata. The system administrators then define an agent to querythe source periodically, looking for new data for all clients whohave identified that facility as a data source. The agent will thentransform the data from the original source into a form that ismore appropriate for the system and store it in the database.The source of the information must also be maintained so thatchanges in the original source may be captured.

Pavalam S.M et al. [36] proposed a scalable data ware-house based architecture for EHR. The data warehouse is acentral repository of data collected over period of time help-ing in the swift decision making process. The data warehousecollects data from variety of sources and converts them into aunified format. The transformation from external formats toa single format is being taken care by the load manger. TheData Mining applications interact with the query manager toextract the reports. This architecture can help in the analysisof data using OLAP operations, thus supporting goals ofenhancing medical research.

High level architecture of the proposed semi-centralizedNHIS

The high level architecture of the proposed semi-centralizedapproach NHIS is shown in Fig. 4. The semi-centralized ap-proach assumes that summarized EHRs of patients are stored ata nation-wide central system, the National Healthcare Center(NHC) that is built around a country and keeps summarizedEHRs for all people in the country. The proposed NHC alsoprovides access to comprehensive versions of these summa-rized EHRs from the distributed healthcare providers, theHealthcare Centers (HCs).

To protect the medical data during transmission and toprovide a fast delivery of EHRs, the eventual network forEHR transactions between the NHC and the distributed

Healthcare Centers (HCs) is proposed to be conducted overa secure, private Wide Area Network (WAN) where the net-work hardware is owned or leased by the NHC to establishthis connectivity. Although this type of network maybe ex-pensive, it provides high degree of security, privacy, availabil-ity and speed of transmission of medical data. To minimize thecost, other alternatives can be used to establish the connectiv-ity, such as a VPN which uses a public telecommunicationinfrastructure, such as the Internet, to provide the HCs with asecure connection to the NHC. However, the VPN is built on ashared infrastructure, and therefore its availability and perfor-mance are difficult to control. Typically, VPN speeds aremuch slower than those experienced with a traditional con-nection. Andmore importantly, the use of public infrastructurewill made the network less secure than using private owned orleased lines, the exposure to “attacks” from other networks onthe same infrastructure requires comprehensive and complexsecurity 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 differentdatabase models. This results in a severe interoperabilityproblem that impedes the communication of patient’s datafrom one HC to another [3]. Therefore, a small system calledHealth Information System Broker (HISB) is proposed to bebuilt at each HC to control the communication of patient’sdata from local database at the HC to the NHC, that is, itcontains a number ofmodules that cooperate with the modulesof the NHC to achieve the functionality of the system. TheHISB is connected to the HC’s database and acts as a meansthrough which local patient data is submitted to the NHC.

The NHC presents all the system’s services to the endusers and coordinates all the system’s processes. Cliniciansin different HCs can access all the system’s services throughthe WAN connection which is secure and private. In order toprovide clinicians with a means to access basic and essentialsystem services from outside their HCs or while they are inmobility (for example: in emergency cases), and to providepatients with an access to their medical data on the NHC, theNHC provides a web portal that is accessible through theWorld Wide Web (WWW) through their computers orsmartphones 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. Theset of tiers includes the following:

1. Data tier— that manages stored data on the NHC database.2. Business tier — that includes the main processing mod-

ules. These modules are presented at the NHC level and

9953, Page 6 of 20 J Med Syst (2013) 37:9953

at the HISB level, which coordinate together and providethe functionality of the system.

3. Presentation tier— that accepts input, forwards queries tothe requested processes or modules at the business tier,particularly the NHC modules, and displays the results.

Different reasons for adoption of three-tier architecture canbe mentioned. Modification or replacement of a tier does notaffect other tiers. Furthermore, load balancing can be im-proved, due to the separation of the application and databasefunctionality. The different layers provide also extra securityto the system. It is not possible for a client to get direct accessto sensitive data in the data tier. Before getting to the data tier,the client should contact the business tier. Within the businesstier, adequate security policies can be implemented.

The system is composed of five main components, asillustrated in Fig. 5. The following subsections describe eachof them.

The NHC database

The NHC database stores all the patients’ summarized EHRsas well as references to their original comprehensive recordson the original HCs. The NHC database also holds informa-tion on: patients, clinicians, HCs, clinicians’ logs and otherdata required to control the privacy of patient’s data (Thedetails of the system data are provided in next section).

The NHC modules

The NHC is the major component that contains the mainsystem modules. It manages access to the summarized medical

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

The HISB modules

The HISB provides the system interoperability and masksthe heterogeneity between the HC’s database models, datastructures and terminologies. As stated before, Each HC hasa HISB connected to its local database which acts as a meansthrough with local patient data is submitted to the NHC.HISB must be designed specifically for each HC’s databaseto be able to deal with its specific data structures, formats andterminologies (The details of the NHC modules are providedafter the next section).

The NHC Interface

The NHC Interface presents the services to the cliniciansthrough the WAN connection. It handles authentication andidentification and presents the different services of the sys-tem by calling the modules of the NHC. All the clinicianservices 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 aswell as clinicians through the Internet connection. The NHCweb portal handles user authentication and identification andpresents the different NHC services available to the user as aclinician or as a patient. For security, integrity and efficiency

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

J Med Syst (2013) 37:9953 Page 7 of 20, 9953

purposes, the services of the system that involve communi-cation with HISB cannot be implemented over the NHCWebportal. Such services are provided for clinicians through theNHC 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 theSemi-Centralized NHIS. This data model represents the dataelements 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 onthree major goals:

1. Maintaining accurate identification of patients acrossdifferent healthcare provider’s systems.

2. Maintaining summaries of patient’s medical records atthose healthcare provider’s systems in the NHCDatabase and as well as reference links to the compre-hensive versions of these records.

3. Preserving the privacy of patients’ data.

There are two possible options for linking patients to theirmedical data across different HCs: statistical matching (ordemographic matching), and national patient identifiers(NPIDs) [38]. In statistical matching, the NHIS is composedof a number of connected Regional Health InformationOrganizations (RHIOs). Each healthcare provider gives theRHIO located in its region a database consisting of its pa-tients’ 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 RecordLocator Service (RLS) [38].

Retrieving a patient’s medical data in this NHIS is basedon Statistical Matching on these RLSs. Statistical matchingattempts to string together enough identifying informationabout an individual to substitute for a NPID. It involvesmatching attributes, such as last name, first name, birth date,address or zip code, gender, and all or part of the SocialSecurity number. Advanced statistical matching algorithms“score”matches on “closeness” to the input set. Those with ahigh score may be accepted as a match. In such NHISs,whenever a query is sent to the NHIS for retrieval of patientdata, statistical matching is performed [38].

The problem with statistical matching is that personalattribute keys such as name and address are usually notunique to the individual, change over time, and are oftenentered into different systems in different formats. Data-entry errors, such as misspellings, missing fields, and defaultSSNs add to the difficulties with this type of key. Theseproblems lead to false positive errors (assigning a match toa record that actually doesn’t belong to the patient), and falsenegative errors (failing to discover a record that belongs tothe patient). False positive and false negative errors can leadto serious medical errors, waste of resources (e.g., repeats oftests or the wrong tests) and considerable deviation from thepromises of continuity and quality of care postulated for aconnected digital health care system [38]. These errors con-tribute to an overall problem rate of as much as 5 % for asingle RLS, and trending higher for larger systems [39]. Thisinaccuracy of linking patients to their data is one of the mostimportant obstacles impeding provider and patient adoptionof NHISs [40]. Statistical matching approach is adopted inMassachusetts [25], and Indiana [17].

Fig. 5 Components of theproposed system

9953, Page 8 of 20 J Med Syst (2013) 37:9953

The accurate approach for linking patients to their clinicalrecords that are distributed across HCs in a country is theadoption of unique NPIDs, that is, each patient in the NHISgets an entry in a National Medical Patient Index (NMPI)with a NPID to define the identity of that patient. The NPIDis then used to identify, integrate and share the patient’sEHRs across all HCs. A recent RAND study, 2008, [38]shows that a health care system in which every patient hasa unique, non-disclosing NPID is clearly desirable for reduc-ing errors, simplifying interoperability, increasing efficiency,improving patient confidence, promoting the NHIS architec-tural flexibility, and protecting patient privacy. A recentreport published by the Information Technology andInnovation Foundation (ITIF) [41] indicated that a NPIDsystem is implemented in Australia, Denmark, Finland,Netherlands, New Zealand, Sweden, the United Kingdom,and partially in Canada (Canada uses provincial patient IDsrather than NPIDs).

Due to the discussed problems of statistical matching andthe benefits of NPIDs, the preferred approach is the NPID.The correct identification of patients across different HCs is asafety critical issue and a cornerstone for the implementationand use of integrated EHRs. The sharing and integration ofpatient 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], analyzedthe costs associated with the NPID. The authors estimated aone-time cost for issuing a NPID for 300 million individualsas $1.5 to $11.1 billion, depending on the scope of unique-ness and how strong and centrally managed the registrationand authentication (verifying that a person is who he/sheclaims to be) processes are. To put these costs in perspective,the authors indicated that previous studies [43] of the valueof connected EHR systems estimated a potential efficiencysavings of $77 billion per year at the 90-percent level ofadoption; added value for safety and health could doublethese saving, a one-time cost of $1.5 to $11.1 billion for aNPID, to remove the systemic errors in demographicmatching, is small by comparison. The authors indicated thatthe implementation of NPIDs would require some type oforganizational or governmental infrastructure to distributethe new identifiers and to manage the registration processbefore any data could be linked. Also, a procedure is requiredto link historical patient data with the new NPIDs using somedemographic matching systems.

With regards to the second goal of the data model, the mainidea of the proposed Semi-Centralized NHIS is to allow theclinicians to have a general view of the patient’s medicalhistory and to have an idea of what is included inside thepatient’s EHR at each HC’s system from a central location,and when needed, retrieve the complete encounter informa-tion of the patient from a remote healthcare provider’s system.

Thus, the NHC Database should maintain a summary of eachpatient’s encounter and a reference link to the complete ver-sion of the encounter at the original HC’s system.

Preserving privacy is important to ensure acceptance ofthe system. A 1999 survey by the California HealthCareFoundation showed that even when people understood thehuge health advantages that could result from linking theirhealth records, a majority believed that the risks of lost privacyoutweighed the benefits [44]. There are two types of data apatient can and should be given access to — the audit trail,detailing when and who looked up the location of their re-cords; 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 datamodel, the following data will be held at the NHC database:

1. A nationwide master index of patients to identify thepatients 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. Amatching index that links the patient’s NPID to his/her

local IDs at the various HCs.5. A patients’ encounter registry to maintain summary in-

formation on patients’ encounters at all HCs (to maintainsummarized medical histories of the patients) and tomaintain reference links to the original complete en-counter information residing at the various HCs.

6. An Authorization registry to control the privacy of pa-tients’ data on the NHC. It keeps track of which clini-cians are authorized by a patient to view his/her medicaldata (This index will be used by the system to check ifthe clinician is authorized to view a patient’s medicaldata before he is allowed to view it).

7. A clinicians’ log registry to audit the clinicians’ actionson the NHC. In this way an alleged unrightfully accesscan be traced by the various supervisors. Each patienthas the right to inspect his part of the access log.

To hold these types of data, seven tables have been designedfor 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 masterindex 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 clini-cians), Authorization Table (to hold the Authorization registry),and Clinician’s Log (CLog) Table (to hold the clinicians’ logregistry). The following subsections describe the purpose andcontents of each of these tables. These tables are designed at theconceptual level and will need to be divided into more tables atthe physical level.

J Med Syst (2013) 37:9953 Page 9 of 20, 9953

Matching table

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

key to the table and will be used by the some other tables andthe system modules.

HC table

The purpose of this table is to hold essential informationabout HCs. This table holds the HC’s Identifier (HCID), itsname (HCName), and the IP address of its HISB node

Fig. 6 The conceptual data model of the NHC database

Fig. 7 The role of the matchingtable

9953, Page 10 of 20 J Med Syst (2013) 37:9953

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

Encounter table

The proposed system requires that the patient’s EHR at eachHC is identified by the LocalRecID, and is made up of allpatient encounters within that HC. Each encounter representsone visit, whether for some clinic, laboratory department,radiology department, or even just for some immunizations.

The summarized medical history of the patient is a collectionof encounters’ summaries across all HCs where the patientreceived care in. The Encounter table conations a summaryrecord for each patient encounter at each HC. Each patient’sencounter summary record consists of the Matching_ID whichis a foreign key from the Matching Table to refer to the patient’sNPID, the HCID where the patient is treated and the patient’slocalRecID at that HC. The table also holds the patient’s en-counter ID at that HC (EncounterID), the National ClinicianIdentifier (NCID) of the clinician who provides the treatment tothe patient at this encounter, the Health Problems Summary(HealthProblemsSummary) which contains the diagnosis andvital signs, Medications Summary (MedicationsSummary)which indicate the names of medications or immunizationsprovided to the patient at this encounter, Laboratory Test(LabTests) which indicates the names and results of lab testsmade for the patient at this encounter, Radiology Tests(RadiologyTests) which indicates the names and results ofradiology tests made for the patient at this encounter, andthe Date of the encounter (Date). The four data elements:HealthProblemsSummary, MedicationsSummary, LabTests,and RadiologyTests are multivalued and will need to bedivided into more elements at the physical table design.Whenever the clinician needs further detailed information ofthe encounter, he can just request it through the system, andthe system will deliver it from the remote HC’s databaseautomatically. When such a request is generated, the NHCwill send a query to that HC’s HISB requesting the completerecord of the patient’s encounter, the query will contain boththe LocalRecID and the EncounterID. The LocalRecID andthe EncounterID together form the reference to the patient’sencounters at the distributed HCs.

Patient table

The purpose of this table is to identify patients across thecountry. This table holds the NPID and the patient’s demo-graphic 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 theproposed system can only be issued to patients who have

registered to the system through a licensed governmentagency and issued their NPIDs.

The Patient and clinician phone number and address areimportant for the following reasons:

& In cases, when a patient is in a critical situation and needsblood transfer, it will be easy to send a request to allpatients/clinicians carrying the same blood type andwithin the same municipality to volunteer.

& The clinician may need to contact the patient and follow-up with them regarding some important care activities.

& This information is important for statistics reporting,research and development.

Although the patient and clinician phone numbers andaddresses could potentially change frequently, a procedurecan be put to ensure that they are up-to-date like those pro-cedures taken by banks and insurance companies.

Clinician table

The purpose of this table is to identify clinicians across thecountry. This table holds the NCID, the HCID where theclinician works, and the clinician’s demographic data includ-ing: First Name (FName), Last Name (LName), SSN, Dateof Birth (DOB), Telephone Number (TelephoneNo),Cellphone Number (CellphoneNo), Address (Address), andBlood Type (BloodType). The Services of the proposedsystem can only be issued to clinicians who have registeredto the system through a licensed government agency andissued their NCIDs.

Recall that the data model represented in Fig. 6 is repre-sented at the conceptual level. The many-to-many relation-ship between the HC table and the Clinician Table will needto be represented by an intermediate table at the physicaldesign of the data model. This intermediate table will containthree attributes: LinkingID (to represent the ID of eachrecord of the table), HCID, and NCID. Also, the Cliniciantable will need to be modified to include the LinkingIDinstead of the HCID. Finally, the HC table will be modifiedto include the LinkingID. The relationship between the HCTable and the intermediate table and between the ClinicianTable and intermediate table will be one-to-many with themany side located at the intermediate table.

Authorization table

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

J Med Syst (2013) 37:9953 Page 11 of 20, 9953

to check if the clinician is authorized to view a patient’smedical data before he is allowed to view it.

CLog table

This table maintains records of clinician’s actions on theNHC. This table holds the Session ID (SessionID), theClinician’s NCID, the date of the session (Date), the eventperformed by the clinician on the NHC (Event), and the timeat which that event occurred (Time). The event is the mainattribute that shows which operation was performed onwhich data of which patient. In this way an allegedunrightfully access by clinicians can be traced by the varioussupervisors. Each patient has the right to inspect his part ofthe access log.

The data model of the Semi-Centralized NHIS describedin this section accurately links the patient’s data across thedifferent healthcare provider’s systems, effectively preservesthe privacy of patients’ data, and effectively organizes sum-maries of patient’s medical records into the NHC Database.The data elements that form the reference links to the com-plete versions of patient’s medical records at the originalHCs are specified in this section. This data model willfacilitate the jobs of the NHC modules and the HISB mod-ules 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 Semi-Centralized NHIS. The basic system modules areimplemented at the business tier in Fig. 5. These modulesare based on the Service-Oriented Architecture (SOA), thatis, they are distributed between the NHC server and eachconnected HISB and work cooperatively to provide thesystem functionality. The modules of NHC interact withmodules of HISB, and vice versa, in a way that enables onemodule to perform a unit of work on behalf of anothermodule. The following subsections discuss the NHC mod-ules and HISB modules separately.

The NHC modules

The NHC contains the main system modules that can beinvoked directly by the presentation tier and implement thesystem’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 histo-

ry stored locally at the NHC database.

4. Providing access to the comprehensive medical datastored remotely at the HCs’ databases.

5. Supporting emergency cases by retrieving the patients’vital health signs from the NHC database based on thepatient’s NPID.

6. Auditing the clinicians’ actions on the system so that anyunrightfully access to patients’ data by clinicians can betraced by the various supervisors.

Based on these roles, seven basic modules have beendefined to be implemented at the NHC server as shown inFig. 8. Figure 8 shows also which system data each of thesemodules deal with. A detailed description on the purpose andfunctionality of each of these modules is provided in thefollowing subsections.

Identification and authentication module (Iden&AuthenM)

The purpose of this module is to identify clinicians andpatients based on their NCIDs and NPIDs, and to authenti-cate them to access the system.

Authorization module (AuthorM)

The purpose of this module is to control access to thepatients’ medical data; only those clinicians who are autho-rized by a patient can see his/her medical data. For eachquery made by a clinician to access a patient’s medical dataon the system, the NHC consults this module to verify if thatclinician is allowed to access this patient’s data based on theClinician’s NCID and the Patient’s NPID. This is moduleuses the Authorization Table to search for a record with thegiven (NCID) and (NPID), if there is such a record then thequery is executed, otherwise the query is rejected.

It is not necessary that the patient knows the NCID of theclinician to give them the permission to view his records.The user interface of the system can designed in a way thatallows the user to navigate to the required HC, and select therequired clinician within that HC for authorization. Also, insome situations, a large number of clinicians within the sameHC may need access to the patient’s records. The userinterface can be designed to provide the features that allowthe in-charge clinician to suggest the list of clinicians whowill need access to the patient’s records, and the patient canaccept, reject, or modify the list.

Authorization control module (AuthorCM)

The purpose of this module is to allow the patients to have acontrol over which clinicians can view their medical details.The module promotes the privacy of patients’ data; no clini-cian can access a patient’s medical data unless they have

9953, Page 12 of 20 J Med Syst (2013) 37:9953

been authorized by the patient. This module can be invokedonly by patients.

Summarized medical history retrieval module (SMH-RetM)

The purpose of this module is to retrieve the summarizedmedical history of a particular patient from the NHC data-base based on the patient’s NPID. The patient’s NPID is usedby this module to retrieve all the MatchingIDs from theMatching table based on the NPID (the MatchingIDs indi-cate which HC has a local record for this patient and theLocalRecID of the local record of the patient at that HC). TheMatchingID will then be used to retrieve all encounters of thepatient from the Encounter table. This module can be in-voked by clinicians through the NHC Interface or throughthe NHC Web Portal, or by patients through the NHC WebPortal. If the clinician has not been authorized by the patientto view his/her data, no data will be received from thismodule.

Emergency support module (EmergSM)

The purpose of this module is to extract critical medicalinformation of the patient that are considered to be usefulfor emergency cases (ex: blood type and importanthealthcare problems) from the NHC database. This moduleis accessible for any clinician (even non-authorized clini-cians) and can retrieve the critical information of a patientbased on his NPID. If the NPID is not known, the SSN can beused to help find the associated NPID from the NHC. Thismodule can be implemented in many ways, for example, anexpert system may be built on the NHC to retrieve importantinformation that would help in emergency cases from theEncounter table. Any access to this module by a clinician in anone-emergency case can be flagged by the patient since allclinician’s actions are audited through a Clinician LogModule (CLogM) which allows patients to inspect their partsof the access log. This module is proposed to be availablethrough both the NHC Interface and the NHC Web Portal.

Query and forward module (Que&FrwM)

When an authorized clinician requests a complete patientencounter details or test reports from a remote HC, thismodule will send a query to a special module at that HC’sHISB requesting the complete record of the patient’s encoun-ter, the query will contain both the LocalRecID and theEncounterID. When the requested record is received, thismodule forwards it to the requesting clinician. For securitypurposes, this module is proposed to be available for clini-cians only through the NHC Interface (i.e., through theprivate, secure WAN connection) to protect HC’s local data-bases from unauthorized parties on the Internet. Also, toreduce network traffic and provide better performance, thismodule 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 unrightfullyaccess by clinicians can be traced by the various supervisors.Each patient has the right to inspect his or her part of theaccess log.

The HISB modules

As stated before, each HC has a special HISB connected toits local database which acts as a means through with localpatient data is monitored, prepared, and submitted to theNHC. The main roles of HISB modules are:

1. To monitor the HC’s local database for each new localpatient record and record it on the NHC database ontime.

2. To monitor the HC’s local database for each new patientencounter and record a summary of it on the NHCdatabase on time.

3. To submit complete patient encounter details or test re-ports from the HC’s local database to the NHC server asa result of a clinician request on the NHC server.

Fig. 8 The NHC modules

J Med Syst (2013) 37:9953 Page 13 of 20, 9953

Based on these roles, five modules are defined to beimplemented at each HISB as shown in Fig. 9. Figure 9shows also which data each of these modules deal withwhether this data is located at the remote NHC database orat the HC’s local database. A detailed description on thepurpose and functionality of each of these modules is pro-vided in the following subsections.

Patient registration scanning module (PRegistrScanM)

The purpose of this module is to monitor the HC’s localdatabase for each new local patient record, and if there is,request the patient’s NPID on time from the registration staffat the HC. Then this module sends the NPID and theLocalRecID of the patient to the Patient RecordRegistration Module (PR-RegisterM) which in turn recordsthe patient’s local record on the NHC database.

Encounter scanning module (EncScanM)

The purpose of this module is to monitor the HC’s localdatabase for each new patient encounter, and if there is,retrieve a summarized copy of this encounter and send it tothe Encounter Addition Module (Enc-AddM) to record it onthe NHC database. The summary should contain the encoun-ter ID, the LocalRecID, and the encounter summary includ-ing: diagnosis, vital signs, medications, immunizations, laband radiology tests names and results. The retrieval of thesummarized copy of the encounter from the HC’s localdatabase is easy since the HISB is programmed with thespecific data structures, formats and terminologies used bythe HC’s local database so it knows which data elements willbe fired.

In some HCs systems, the immunizations may be provid-ed, or lab tests and radiology tests may be made, withoutbeing linked to some encounter ID. This will not affect theoperations of the EncScanMmodule since these types of dataare linked to the patient’s localRecID. In this case, theEncScanM will create a virtual EncounterID and link it withthe localRecID at the NHC database. Recall that thePRegistrScanM ensures that each patient’s localRecID islinked with the NPID at the NHC database. Any HC’s systemthat does not use LocalRecID will need to be updated beforeit is connected to the proposed system.

Patient record registration module (PR-RegistrM)

This module is triggered by the PRegistrScanM modulewhenever a new local patient record is created. It receivesthe patient’s NPID and the LocalRecID of the patient fromthe Patient PRegistrScanM module and directly writes thisinformation along with the HCID to the Matching Table onthe NHC database, indicating that the patient has a localrecord at this HC.

Encounter addition module (Enc-AddM)

This module is triggered by the EncScanM module whenev-er a new patient encounter record is added to the HC’s localdatabase. It receives the encounter summary informationfrom the EncScanM. Then it retrieves the MatchingID fromthe Matching table on the NHC database based on the HCIDand the patient’s LocalRecID, after that it writes theMatchingID along with the encounter summary to theEncounter Table at the NHC Database. The MatchingID isimportant to be associated with the patient’s encounter since

Fig. 9 The HISB modules

9953, Page 14 of 20 J Med Syst (2013) 37:9953

it refers to the HC where the patient is treated, theLocalRecID of the patient at that HC, and the patient’sNPID on the NHC (the patient’s NPID is not known to theHC’s local database and that’s why the HCID and the pa-tient’s LocalRecID are used to retrieve MatchingID whichrefers to the HCID, LocalRecID, and NPID).

Comprehensive encounter transmission module(ComEncTransM)

This module is called by the Que&FrwM module on theNHC to send a comprehensive copy of a patient’s encounterfrom the local database to the NHC as a result of a clinicianrequest on the NHC. It retrieves the comprehensive copy ofthe patient’s encounter from the local database based on thereceived patient’s LocalRecID and EncounterID. Then itstandardizes this copy and sends it to Que&FrwM on theNHC.

Comprehensive encounter records in different HC sys-tems are of different structures, formats, contents and termi-nologies. Standardizing the contents of a comprehensiveencounter record before transmitting it to the NHC is neces-sary to make the record readable by the other systems.Several standards that aim to structure and markup the clin-ical content of medical records for the purpose of exchangeare provided by many organizations such as Health LevelSeven (HL7) [45] and the European Committee forStandardization (CEN) [46]. These standards can be appliedby the ComEncTransM module to convert the comprehen-sive medical record into an interoperable record before it istransmitted to the NHC. A survey and analysis of thesestandards is provided in [3].

Here, the preferred approach is the Health Level 7 ClinicalDocument Architecture (HL7 CDA) standard [47]. HL7CDA is a document markup standard that specifies thestructure and semantics of clinical documents for the purposeof exchange. CDA documents are encoded in ExtensibleMarkup Language (XML) and can be parsed with any webbrowser, enabling easy exchange of these documents be-tween different systems. A CDA document is a defined andcomplete information object that can include text, images,sounds, and other multimedia content. It can be transferredwithin a message and can exist independently, outside thetransferring message [47]. The rationale for using HL7 CDAis its proximity to industry; it is very common internationallyand many EHR vendors incorporate it within their EHRsystems [47, 48]. A detailed description of HL7 CDA stan-dard can be found in [49].

The proposed system provides the operations needed toretrieve the complete record of a single encounter. If thecomplete EHR of the patient is requested from a remoteHC, all the encounters complete records within that EHRwill be retrieved one by one.

Discussion

Discussion of the overall semi-centralized NHIS approach

Many forms of the Centralized Architecture are found in anumber of NHISs as indicated in the “Introduction” sectionof this paper. Some of which require the complete dupli-cation of the patients’ medical data into a central repositoryto achieve the highest quality possible in healthcare ser-vices such as Canada’s EHRS [11]. Another form of du-plication found in Australia’s HealthConnect system [12]involves in a summary of patient events. However, thesummary data that is centralized may not fully supportthe systems’ goals of improving healthcare quality. A thirdform of duplication is found in the England’s Spine system[13], which duplicates only a summary of patient eventsthat would help in emergency cases.

The Distributed Architecture is introduced to minimizethe cost and complexity of the Centralized Architecturewhile at the same time providing access to complete medicalinformation of patients. This architecture utilizes the HC’slocal databases rather than creating a centralized repository.The centrally maintained reference links to the distributedpatient’s records provide clinicians a means to know whichHCs have medical data of the patient and to direct queries tothese HCs to submit the required data. However, clinicianshave no means to know which record referenced by thoselinks contains the needed data, and anytime the clinicianneeds to access the medical history of the patient, he sendsqueries all HCs holding data for the patient. High networktraffic and access delays are the main limitations of thisapproach.

The Semi-Centralized Architecture proposed in thispaper introduces a new approach. It utilizes the HC’s localdatabases, maintains reference links to patients’ data at acentral system, and provides an indication of what isincluded within each reference link, allowing the clinicianto go directly to what he/she needs and send a request tothe HC holding the needed data. Summarized medicalhistory of patients can be accessed directly through thecentral system. The problem of high network traffic expe-rienced in the distributed approach is minimized in thisapproach, and so as the access delays that were experi-enced due to the high network traffic. Also, the problemof complexity and cost in the Centralized Architecture isminimized in this approach.

Discussion of the semi-centralized NHIS architecture

This section discusses the design aspects of the Semi-Centralized NHIS presented in this paper in terms of: userservices covered by the design and features of the design.

J Med Syst (2013) 37:9953 Page 15 of 20, 9953

Summary of user services covered by the design

With the designed functionalities of the system, the mainservices of the system for patients, and clinicians are outlinedin Table 1. The patient services are accessible through theNHC Web Portal, whereas the clinician’s services are acces-sible through both the NHC Interface and the NHC WebPortal except the second service (Order comprehensive cop-ies of the patient’s medical records from remote HCs).Comprehensive patients’ data that reside at the distributedHCs cannot be requested through the NHC Web Portal forsecurity purposes (to protect against accessing the data heldby the HCs’ databases by unauthorized parties on theInternet).

Features of the proposed semi-centralized NHIS design

The following points summarize the advantages of the pro-posed semi-centralized NHIS architecture:

1. Achieving interoperability while keeping on currentHC’s systems; Each HC has a HISB system connectedto its local database. The HISB component masks theheterogeneity between the HC’s local databases. Withthe implementation of HISB components, the HC willnot need to update its local database to be able to dealwith the proposed system because the HISB componentmasks the heterogeneity between the HC’s local data-bases. However, some institutions grant only one en-counter number for an entire sequence of care, fromclinic visits, to inpatient, to rehabilitation. Such institu-tions will need to update their systems such that: eachpatient is identified by one local ID, and each encounteris identified by an encounter ID. Any type of visit,whether it is emergency department, outpatient or inpa-tient visit, is considered as an encounter. If the dateshould be represented within the encounter ID, the ad-mission date is considered in the inpatient case.

2. High data consistency; whenever a new local patientrecord or encounter is added to the HC’s local database,it is discovered by the HISB system which in turn reg-isters a new “Matching” record at the NHC database andrecords a summary of the new patient encounter on theNHC database on time.

3. Effective automation of processes; the architecturepays a special attention to the effective automation ofprocesses. The addition of new patient’s data from HC’slocal database to the NHC database is done automatical-ly through the HISB system without any user interven-tion. This feature promotes usability of the system.

4. Effective load distribution; the processing modules ofthe system (business tier modules) are divided betweenthe NHC and the connected HISB systems in a waywhich ensures that the NHC is not heavily overloaded.The NHC modules handle most of the read operationswhereas the various HISB systems handle most of thewrite operations to the NHC database. This distributionof operations promotes the scalability of the system.

5. High privacy of the patient’s data; patients have acontrol over who can see their medical data and noclinician can disclose their medical data if he hasn’t beenauthorized by the patient. Patients can inspect their partsof the clinicians’ access logs and report unrightfullyaccess to their medical data.

The proposed approach permits the granting of physicianaccess to patient’s data on an all-or-none basis because it isbased on the NPID. An alternative approach that permits thepatient to restrict the sharing of his information was proposedby ASTM standards (E2553) in 2007. This approach is namedthe “Voluntary Universal Healthcare Identifier (VUHID) sys-tem” [50]. The standards define two types of identifiers: OpenVoluntary Identifiers (used to support unrestricted sharing ofinformation), and Private Voluntary Identifiers (used for re-stricted sharing of information on a wide variety of conditionssuch as psychiatric, genetic, or behavioral health information).A typical patient would have only one open ID but may haveas many private IDs as his or her situation warrants. In thisway, patients are in control of what information will be sharedwith whom.

One way to apply this approach on the proposed system isas follows: The patient can have two types of NPIDs thatuniquely identify him: one Open NPID (used to supportunrestricted sharing of information), and many PrivateNPIDs (used for restricted sharing of information). TheOpen NPID will be linked with the patient’s local record ateach HC and will be dealt with as the normal NPID discussedin this paper. Each Private NPID will be linked with thespecial encounters that fall under the same condition through-out all HCs as the patient demands, and will be transmitted tothe NHC with the encounter summary it is associated with.

Table 1 The main user services covered by the design

Type of user Main services

Patient 1. View his/her medical history in a summarized form.

2. Authorize/un-authorize clinicians to view his/hermedical data.

3. Monitor actions performed on his/her medical dataand report unrightfully access to this data.

Clinician 1. View the summarized medical history of the patient.

2. Order comprehensive copies of the patient’s medicalrecords from remote HCs.

3. View the patient’s critical medical data in emergencycases regardless of authorization.

9953, Page 16 of 20 J Med Syst (2013) 37:9953

That is the Private NPID will be stored at the Encounter Table.In this way, when the physician uses the Open NPID, all thepatient’s encounters summaries will be retrieved by the systemexcept those that are associated with a Private NPID. ThePrivate NPIDs can be used to retrieve information on encoun-ters with which they are associated. The disclosure of encoun-ter data that are linked with some Private NPID requires thatthe physician has been already authorized by the patient toview his data in the Authorization Table, and that the patienthas given the physician his Open as well as Private NPID.

However, although having multiple identifiers could helpmore in protecting patient’s privacy, the use of multiple

identifiers for the same patient keeps the informationfragmented and isolated and hurts legitimate purposes suchas timely access to information and delivery of care [51].

6. Providing security measures; the security measures areprovided in many aspects of the design including:

• The connection between the HCs and the NHC is basedon a secure private line connection (WAN). All the NHCservices are designed to be accessible through this secureconnection, only the server that hosts the NHC webportal 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 (forfull or summarized EHR)

Centralized reference links Centralized data repository (forsummarized EHR) withreference links

2 Data Redundancy - High (in systems with full EHRduplication)

No (no medical data isduplicated)

Low (only summarized EHRduplication)

- Low (in systems with summarizedEHR duplication)

3 Consistency Low High High

4 Medical value - High (in systems with full HERduplication)

High High

- Low (in systems with summarizedEHR duplication, the summarydata that is centralized may notfully support the systems’ goalsof improving healthcare quality)

5 Security - Low (in systems with full EHRduplication)

High Moderate

- Moderate (in systems withsummarized EHR duplication)

6 Privacy Depends on the design High High

7 Network traffic Low High Moderate

8 Availability high low High for summaries. Moderatefor comprehensive records

9 Query response Fast Subject to long delays due tohigh network traffic

Fast for EHR summaries.

Retrieval of comprehensiverecords may subject to delaysdue to network traffic.

10 Maintainability Easy Difficult Difficult

11 Load balancing Low High High

12 Cost/complexity of designand implementation

- High (huge and very complexrepositories for systems withfull EHR duplication)

Low Low (HC’s local databases areutilized, and the HISB masksthe heterogeneity between thedifferent HC’s local databases)- Low (for systems with summarized

EHR duplication)

13 Scalability high Low (high network traffic mayaffect the system’s performancewhen increased in scale).

Moderate, and can be increasedwhen implementing the NHCusing cloud computing.

14 Mobility High Low (allowing the access to thesystem while in mobility mayincrease the network trafficand affect the performance)

High

J Med Syst (2013) 37:9953 Page 17 of 20, 9953

• The NHC web portal provides access only to sum-marized patient data maintained on the NHC.Comprehensive patients’ data that reside at the dis-tributed HCs cannot be requested through the NHCWeb Portal to protect against accessing the data heldby the HCs’ databases by unauthorized parties onthe Internet and to protect against Denial of Serviceattacks (DoS attacks).

• Designing the system on the three-tier architecture pro-vides also extra security to the system. It is not possiblefor a client to get direct access to sensitive data in thedata tier. Before getting to the data tier, the client shouldcontact the business tier. Within the business tier, ade-quate security policies can be implemented.

7. Meeting the flexibility challenge; Building the sys-tem on three tier architecture ensures the flexibilityof the system as system components can be addedor moved.

8. Centralized control of communication; Retrieving acomprehensive patient record from a remote HC iscarried out only through the NHC. This facilitates theauthentication process on the HISB side and improvesthe efficiency and effectiveness of the system as well.

9. Meeting the mobility challenge and providing acces-sibility for both patients and clinicians; this isachieved through Web Portal, which allows cliniciansand patients to access the system through the Internet.Although not all the clinicians’ services are availablethrough the Web Portal, the most important servicesthat will be needed by clinicians while in mobility areavailable through this portal, especially the emergencysupport service.

10. Emergency support features; an important contribu-tion of the paper is the addition of an emergency com-ponent to the system, which allows non-authorizedclinicians to retrieve the patient’s vital health informa-tion that would help greatly in emergency situations.The philosophy behind this is that “no patient shoulddie because a system blocked access to vital data”. Itwill help clinicians in emergency ambulances to takebetter decisions and provide better treatment. Recallthat any access to this service by a clinician in a non-emergency case can be flagged by the patient since allclinicians’ actions are audited.

Comparative analysis summary

The current typical approaches of national EHR integrationalong with the proposed semi-centralized approach havebeen discussed and compared in different parts of the paperin terms of: architecture, advantages, and problems (In both“Introduction” and “Discussion” sections). Table 2 summa-rizes a comparative analysis between the three approaches.

Conclusion

This paper has proposed a new semi-centralized architecturethat links healthcare providers EHR systems with a centralsystem. The architecture is based on SOA and web servicesto communicate and exchange data within all the compo-nents of the system. A unique smart solution to a nationwideEHR integration, that holds summarized encounters at acentral system and links them to the original healthcare pro-viders EHR, has been proposed. This solution provides theflexibility to the clinician to access high level patient clinicinformation represented by a full list of summarized encoun-ters, and a low level of information by extracting full detailsfor each encounter from the original location of thehealthcare provider where this encounter has taken place.

The semi-centralized architecture provides an effectiveframework for achieving interoperability while keeping oncurrent healthcare provider’s systems. It effectively meetschallenges of high data consistency, privacy of patients’ data,mobility, and maintainability. It also provides an effectiveautomation of processes which promotes the usability of thesystem, effective distribution of load among the systemcomponents which promotes the performance and scalabilityof the system, centralized control of communication whichpromotes security of the system, accessibility for both pa-tients and clinicians, and emergency support features.

Future work includes further improvement to the proposedarchitecture by incorporating it with Cloud Computing toprovide more scalability and flexibility to the system.Finally, the system will be implemented using real or simu-lated databases and its performance will be evaluated againstthe existing centralized and distributed architectures.

Acknowledgments This work is part of a 2 year research projectwhich has been fully funded by a grant through King Abdul-Aziz Cityfor Science and Technology (KACST)/National Plan for Science andTechnology (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 designedthe system under the supervision of the second author, and wrote themanuscript. Samir El-Masri conceived the research idea, proposed thesystem, and reviewed final draft of the manuscript.

References

1. Electronic Health Record (EHR) Workgroup At The University OfDammam, Saudi Arabia, http://ehr2011.weebly.com/, last accessedDec 2011.

2. Healthcare Information Management Systems Society (HIMSS),“Electronic Health Record (EHR)”, As of May 2012, http://www.himss.org/asp/topics_ehr.asp.

9953, Page 18 of 20 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 ofMay 2012: www.openehr.org/standards.

5. Girosi, F., Meili, R., and Scoville, R., Extrapolating Evidence ofHealth 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 transformhealth care? Potential health benefits, savings, and costs. Heal. Aff.24(5):1103–1117, 2005.

7. Daglish, D., and Archer, N., “Electronic Personal Health Re-cord Systems: A Brief Review of Privacy, Security, and Archi-tectural Issues,” congress, pp.110-120, 2009 World Congress onPrivacy, Security, Trust and the Management of e-Business,2009.

8. Moller, J.E., and Vosegaard, H., “Experiences with electronic healthrecords,” IT Professional, vol. 10, no. 2, pp. 19–23, March-April2008.

9. Jalal-Karim, A., and Balachandran, W., “The optimal networkmodel’s performance for sharing Electronic Health record”, Pro-ceedings 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 e-health environment. In: Maeder, A., and Hansen, A. (Eds.), Pro-ceedings of the Fourth Australasian Workshop on Health Informat-ics 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 ofMay 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 Pro-gramme for IT in the NHS”, Twentieth Report of Session 2006–07,April 2007, As ofMay 2012: http://www.publications.parliament.uk/pa/cm200607/cmselect/cmpubacc/390/390.pdf.

14. National Health IT Board, “National Health IT Plan: Enabling anIntegrated 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 man-agement of EHR data through a national archive: Experiences fromFinland. World Hosp Health Serv 43(4):38–41, 2007.

16. Tiik, M., and Ross, P., Patient opportunities in the estonian elec-tronic 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 patientcare: A working local health information infrastructure. Heal. Aff.24(4):1214–1220, 2005.

18. Canadian Medical Association or its licensors, “Medical data de-bates: 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.infoway-inforoute.ca/lang-en.

20. Minister of Public Works and Government Services Canada, “Elec-tronic Health Records in Canada, An Overview of Federal andProvincial Audit Reports”, APRIL 2010, Cat. No. FA3-56/2010E-

PDF, ISBN 978-1-100-15353-7, As of May 2012: http://www.oag-bvg.gc.ca/internet/docs/parl_oag_201004_07_e.pdf.

21. HealthConnect., http://www.health.gov.au/internet/hconnect/publishing.nsf/content/home, last accessed May 2012.

22. National Health Service, As of May 2012: http://www.nhs.uk/Pages/HomePage.aspx.

23. Greenhalgh, T., Stramer, K., Bratan, T., Byrne, E., Russell, J., andPotts, H. W. W., Adoption and non-adoption of a shared electronicsummary care record in England: A mixed-method case study. BMJ340:c3111, 2010.

24. Spronk, R., “AORTA, the Dutch national infrastructure”, Righolm,(2008), As of May 2012: http://www.ringholm.de/docs/00980_en.htm.

25. 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 ofcreating regional connectivity. J Am Med Inform Assoc 12(6):596–601, 2005.

26. 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 Architec-ture, 2011.

27. Fragidis, L.L., and Chatzoglou, P.D., “The Use of Electronic HealthRecord in Greece: Current Status,” cit, pp.475-480, 2011 IEEE 11thInternational Conference on Computer and Information Technolo-gy, 2011.

28. Hoerbsta, A., Kohlb, C., Knaupb, P., and Ammenwerthc, E., Atti-tudes and behaviors related to the introduction of electronic healthrecords among Austrian and German citizens. Int J Med Inform79:81–89, 2010.

29. Tang, P. C., Ash, J. S., Bates, D. W., Overhage, J. M., and Sands, D.Z., Personal health records: Definitions, benefits, and strategies forovercoming barriers to adoption. J Am Med Inform Assoc 13:121–126, 2006.

30. MyMediConnect, http://www.mymediconnect.net/, last accessedDec 2011.

31. HealthVault, www.healthvault.com, last accessed Dec 2011.32. 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.

33. 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.

34. Wimalasiri, J.S., Ray, P., andWilson, C.S., “Maintaining security inan ontology driven multi-agent system for electronic health re-cords,” Enterprise Networking and Computing in Healthcare In-dustry, 2004. HEALTHCOM 2004. Proceedings. 6th InternationalWorkshop on, vol., no., pp. 19–24, 28–29 June 2004.

35. Mandl, K. D., Simons, W. W., Crawford, W. C. R., and Abbett, J.M., Indivo: A personally controlled health record for health infor-mation exchange and communication. BMC Med Inform Dec Mak-ing v7:1–10, 2007.

36. Pavalam, S.M., Jawahar, M., and Akorli, F.K., “Data warehousebased Architecture for Electronic Health Records for Rwanda,”Education and Management Technology (ICEMT), 2010 Interna-tional Conference on, vol., no., pp. 253–255, 2–4 Nov. 2010.

37. Shih, T.K., “Advanced Penetration TestingMethodology for VPN”,Journal of Security Engineering, 2008, As of May 2012: http://www.sersc.org/journals/JSE/vol5_no5_2008/7.pdf

38. 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 aunique patient identifier for the U.S. health care system”, SantaMonica, CA: RAND Corporation, MG-753-HLTH, 2008.

39. Hieb, B., The case for a voluntary national healthcare identifier. JASTM Int. 3(No. 2), 2006. doi:10.1520/JAI13891.

J Med Syst (2013) 37:9953 Page 19 of 20, 9953

40. Classen, D. C., Kanbouwa, M., Will, D., Casper, J., Lewin, J., andWalker, J., The patient safety institute demonstration project: Amodel 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 natureof patient identifiers: an ethnographic study of patient identificationat a London walk-in centre. Health Inform J 14:141–150, 2008.

43. Federico, G., Meili R., and Scoville, R., Extrapolating Evidence ofHealth Information Technology Savings and Costs, Santa Monica,Calif.: RAND Corporation, MG-410-HLTH, 2005.

44. Connecting for Health, “Linking health care information: Proposedmethods 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/.

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 & Com-munication Technology (ISMICT), 2011 5th International Sympo-sium 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 HL7clinical document architecture. J AmMed Inform Assoc 8:552–569,2001.

50. American Standards for Testing and Materials (ASTM), E2553-07Standard Guide for Implementation of a Voluntary UniversalHealthcare Identification System, ASTM International, September2007.

51. Appavu, S.I., Analysis of Unique Patient Identifier Options: FinalReport, prepared for the U.S. Department of Health and HumanServices, November 24, 1997a.

9953, Page 20 of 20 J Med Syst (2013) 37:9953