Personal health record architectures: Technology infrastructure implications and dependencies

Authors


Abstract

The existing literature in relation to electronic personal health records (PHRs) has typically focused on the discussion of several key issues—namely, their design, functional evaluation, privacy, security and architecture. The benefits of PHRs and barriers preventing their adoption are also widely discussed. These issues are affected by technology infrastructure, and current and planned technology infrastructure deployment will be key determinants in the selection and design of PHR architectures. Assumptions about the community-wide deployment of required technologies such as hardware and internet accessibility are implicit in the architectural selection of PHRs and these dependencies have not been fully appreciated or addressed in the existing literature. This review article introduces and describes two infrastructural drivers—ubiquitous technology baseline for PHRs and connectivity coverage—and examines their inter-relationships with the selected PHR architectures. Eleven functional capabilities are also described, providing a basis for the analysis of the relationships between the two infrastructural drivers and architectural selection.

1. Introduction

Contemporarily, a patient's health record is typically stored in an electronic health record (EHR) system. These systems, typically managed by a health care provider, have contributed to improving the quality and safety of health care and are a central component of health care providers' employment of information technologies (Haux, 2006). As health records are generally stored with the health care provider, access to his/her health data may not be readily available to an individual to support such personal health activities as decision making and health planning. To provide patients with access to their health data, health care providers are now supplying their patients with either a paper or electronic-copy of their records, and in some cases secured online access is also provided (Perlin, Kolodner, & Rosswell, 2004; Jones, Shipman, Plaut, & Selden, 2010). However, due to the high likelihood an individual will have visited multiple health care providers during the course of their lifetime or at any one time, their health data are likely to be distributed, therefore posing significant difficulties when the need to access the patient's complete health information arises (Eichelberg, Aden, Riesmeier, Dogac, & Laleci, 2005). In fact, without a proper medium that can facilitate the integration and sharing of data between various EHR systems, the acquisition of information capable of comprehensively incorporating a patient's health history can be a formidable task. Such obstacles are also likely to prevent patients from accessing their personal health information during emergencies or proactively being more involved in their health management.

The inability to provide patients with easy access to their health records has led to realizations that the current health care system remains relatively institution-centered, which can prevent health care providers from effectively tailoring care to their patients' individual needs. Efforts to deliver care that caters to the individual needs of the patient have led to changes within the current health care system; shifting the health care delivery model from one that is institution-centered to a more patient-centered model (Perlin et al., 2004). This emerging trend is transferring the current institution-centered capturing and storing of information to a more patient-controlled information handling that enables patients to store and access their personal health records using available computing technologies and infrastructure (Eichelberg et al., 2005) and has led to the development of electronic personal health record (PHR) systems. Existing work has indicated that PHRs capable of a patient-centered health care approach can enhance the quality of health care, potentially providing health benefits to patients (Archer, Fevrier-Thomas, Lokker, McKibbon, & Strauss, 2011; Endsley, Kibbe, Linares, & Colorafi, 2006; Krist & Woolf, 2011 Lobach, Willis, Macri, Simo, & Anstrom, 2006; Ralston et al., 2007; Tang, Ash, Bates, Overhage, & Sands, 2006; Weingart, Rind, Tofias, & Sand, 2006). A significant national initiative in this regard is currently underway in Australia with the planned nationwide deployment of the Personally Controlled Electronic Health Record (PCEHR) (DoHA, 2011), that is scheduled to be initially available to all Australians by July 2012.

Due to the fact that electronic PHRs represent a recently emerging concept with various definitions, there is no commonly accepted definition. The Markle Foundation (2003) has defined PHR as “an electronic application through which individuals can access, manage and share their health information, and that of others for whom they are authorized, in a private, secure, and confidential environment.” As its definition is still evolving (AHIMA, 2005; Markle Foundation, 2003; Pratt, Unruh, Civan, & Skeels, 2006), currently there is no concrete specification over all the functionalities and objectives that should be included in a PHR. Furthermore, there are several variations as to how it has been named, for example, electronic Personal Health Records (ePHRs) (Bourgeois, Taylor, Emans, Nigrin, & Mandl, 2008; Choemprayong, Oh, & Sheble, 2006; Markle Foundation, 2006; Pagliari, Detmer, & Singleton, 2007; Simons, Mandl, & Kohane, 2005; Steele & Min, 2010; Steinbrook, 2008; Zeng, Bodenreider, & Nelson, 2008) or Personal Health Information Management System (PHIMS) (Pratt et al., 2006; Wang, Lau, Matsen, & Kim, 2004) or Personally Controlled Electronic Health Records (PCEHR) (DoHA, 2011).

Recent studies (Brennan, Downs, & Casper, 2010; Endsley et al., 2006; Jones et al., 2010; Lobach et al., 2006; McClain & Thompson, 2010; Ralston et al., 2007; Tang et al., 2006; Weingart et al., 2006) have illustrated growth in the interest in using PHRs as well as acknowledgements of their potential benefits such as increasing the quality of care and safety and providing convenience to individuals when undertaking health-related activities. Patients also recognized that PHRs integrated with EHRs were useful in obtaining scripts for medication refills and facilitating secure messaging between themselves and their physicians (Ralston et al., 2007). Despite the obvious benefits, the number of health care providers who consider PHRs as a main source of information in the delivery of care remains relatively low (Fuji, Galt, & Serocca, 2008), possibly due to barriers experienced during adoption such as the reliability of patient-generated data (Archer et al., 2011; Simborg, 2009; Tang et al., 2006) and economic cost/benefit considerations (Clarke & Meiris, 2006; Raisinghani & Young, 2008; Shah et al., 2008). Similarly, the adoption rate of PHRs remains relatively low amongst patients and this may be attributed to barriers such as the possible digital divide, privacy and security concerns, user interface and usability issues, patient engagement and aging and disability (Botts, Horan, & Thoms, 2011; Clarke & Meiris, 2006; Hourcade et al., 2011; Lafky & Horan, 2011; Lober et al., 2006; Pagliari et al., 2007; Raisinghani & Young, 2008; Yamin et al., 2011).

Existing work on PHRs has mainly focused on issues regarding the design, functional evaluation, privacy and security, and architecture of PHRs (Goldberg et al., 2011; Halamka, Mandl, & Tang, 2008; Hourcade et al., 2011; Johnson et al., 2007; Kaelber, Jha, Johnston, Middleton, & Bates, 2008; Kim & Johnson, 2002; Lafky & Horan, 2011; Sujansky, Faus, Stone, & Brennan, 2010) or upon utilizing emerging technologies such as cloud computing (Botts et al., 2011; Fox, James, & Manfred, 2011) or social networks (Hasan & Rotenstreich, 2008). A considerable amount of work has also been devoted to the investigation of the benefits of PHRs and barriers to their adoption as mentioned above (Botts et al., 2011; Clarke & Meiris, 2006; Lober et al., 2006; Pagliari et al., 2007; Raisinghani & Young, 2008; Tang et al., 2006; Yamin et al., 2011). However, there are also significant infrastructural implications of PHRs that can influence the selection of PHR architecture and design. Assumptions about the community-wide deployment of required technologies such as hardware, software and internet accessibility are implicit in the architectural selection of PHRs and these dependencies have not been fully appreciated or addressed in the existing literature.

This review article introduces and describes two infrastructural drivers—ubiquitous technology baseline for PHRs and connectivity coverage—which are interdependent with the selection of PHR architectures. This article also describes eleven functional capabilities, providing analyses of the relationships between the two infrastructural drivers and architectural choices based on these capabilities. For example, the selection of PHR architecture may imply different functional capabilities and architectural approaches for community or nation-wide health care systems: some such examples being smartcard-based PHRs in Europe and web-based PHRs in the USA and Australia (ABC, 2011; Clarke & Meiris, 2006; Cross, 2008).

1.1 Literature Review Purpose and Scope

There is no existing review comprehensively considering infrastructure, PHR architectural choices and PHR functionality and benefits. The focus of this article is to explicitly consider how available infrastructure impacts PHR architecture and how this impacts PHR functionality and benefits. While there is no existing comprehensive review to address this inter-relationship, we have hence included as the scope of the literature review (1) articles describing current and emerging underlying infrastructure and technologies potentially used by PHRs, (2) articles describing current, proposed or potential PHR architectures, and (3) articles describing PHR functionalities and benefits. What is missing from the current literature is an end-to-end consideration of the implication of those three areas on PHR choices. The selection and scope of the literature identified and reviewed is derived from the need to consider together these areas of PHR-related literature. The end-to-end consideration and review of this area entails that all three of these categories of existing papers are included in the scope and analysis of this review article.

2. Existing Architectural Classifications

A PHR architecture, following the widely accepted NIST's (National Institute of Standards and Technology) architectural model (Fong & Goldfine, 1989), typically provides a description of how it addresses the storage, management and access of its health data (Halamka et al., 2008; Kaelber et al., 2008; Koufi, Malamateniou, & Vassilacopoulos, 2010; Markle Foundation, 2006; Tang et al., 2006). It also provides descriptions of the hardware, software and networking components required for the delivery of data to allow for goals such as the enablement of on-demand access to data. Compared to other electronic applications with typical access control policies such as role-based access control, PHRs may require a more rigorous and dynamic access policy to control access to health records and trusted information sharing (Liu & Chetal, 2005; Steele, Gardner, Chandra, & Dillon, 2007; Sujansky et al., 2010). For example, depending on the scenario at the point-of-care, a general practitioner or emergency staff may need to access different parts of a patient's health record. Requiring a stringent access control policy to ensure the privacy and security of a patient's health record can sometimes create more barriers for health professionals to access required information (Kim & Johnson, 2002; Lafky & Horan, 2011; Maloney & Wright, 2009).

The above mentioned issues can influence the design and development of PHR architectures which can affect how data can be accessed or stored. For example, patients can keep their own health data in a standalone PHR which requires the use of either paper or a personal data storage device (Maloney & Wright, 2009). Alternatively, health care providers may provide patients with access and management of their health data in the convenience of their own home. For instance, PHRs integrated with the providers' health information systems such as Dossia (www.dossia.com), MyGroupHealth (www.ghc.org) and My HealtheVet (www.myhealth.va.gov) are called tethered PHRs (Tang et al., 2006) being a component of EHRs controlled and maintained by health care providers. It should be pointed out that different user perspectives on a PHR can also affect how its architecture takes shape (Botts et al., 2011; Clarke & Meiris, 2006; Gearon, 2007; Hourcade et al., 2011) to provide different levels of access suitable for different types of users.

Table 1 shows existing research which has classified PHRs in terms of connectivity with other health systems (Tang et al., 2006), the types of tools available (Pratt et al., 2006), the source of its data and connectivity (Raisinghani & Young, 2008) or primary source of data (Kaelber & Pan, 2008). The Markle Foundation (2006) described PHRs as a cooperative subpart of the national health information network and an individual's PHR should be integrated with one of three networked architectures. In terms of integration with other health information systems, PHRs such as Google's (former) Google Health (www.google.com/health/) can be classified as an independent web-based PHR, and HealthVault (www.healthvault.com) as an interconnected web-based PHR. There are also web-based PHRs that are integrated with EHRs, for example, MyChart (www.epicsystems.com), My HealtheVet, and MyGroupHealth.

Table 1. Existing classifications of PHRs
CategoryClassification
Connectivity Type (Tang et al., 2006)Standalone
  • Individual creation of PHRs, not connected with other systems
Interconnected
  • PHRs connected to various health care systems
Tethered
  • Integrated with a health care provider's health information systems (e.g. the provider EHR).
Mode of Data Integration (Markle Foundation, 2003)Patient-centered
  • Integration of data relies on the patient
Intermediary
  • Data is collected, integrated and stored on a third party's database, connection between the third-party and PHR is provided to facilitate data access
Integrated health systems
  • Data from all components of health care are “gathered” such that only one single point of access is provided for data access
Tools Available (Pratt et al., 2006)Web-based interface
  • Secure Internet access to portions of data maintained and owned by their health-care provider organizations
Standalone tools
  • Patients use to create and maintain their own medical records
Data Location / Storage Type (Markle Foundation, 2006)Centralized
  • One database contains all the health related information available on an individual
Distributed, Decentralized
  • Different data stored on different databases, connections to all databases required to retrieve individual health data
Peer-to-Peer
  • Consumer would have to create and manage separate data streams between her PHR and each system that holds her data.
Service provider of PHR and its connectivity (Raisinghani & Young, 2008)Provider-based PHR
  • PHRs offered by the healthcare providers
Payer-based PHR
  • PHRs offered by the health insurance companies
Commercial (virtual bank vault) PHR
  • PHRs most likely created and maintained by technology companies
PHR Type—as based on its primary source of data (Kaelber & Pan, 2008)Provider-tethered PHR
  • PHR tethered to healthcare providers' information systems
Payer-tethered PHR
  • PHR tethered to healthcare payers' information systems
Third-party PHR
  • PHR provided by non-healthcare related organizations (e.g. GoogleHealth, HealthVault)
Interoperable PHR
  • Centralized system with collection, sharing, exchange, and self management functions

As past classifications mainly focus on the source of data and connectivity, little has been done to address the fact that currently available technologies can also play an important role in the selection of an appropriate PHR architecture. As the type of connection available and the types of ubiquitous devices capable of being used in conjunction with a PHR system can determine how its architecture takes shape, this review article will present a novel approach for the classification of PHR architectures based on two infrastructural drivers, connectivity coverage and ubiquitous technology baseline, in the next section.

3. PHR Classification Based on Architecture and Infrastructure Interdependence

Differing from the existing classifications as presented in Table 1, a novel and more detailed PHR classification approach is presented here based on two infrastructural drivers—connectivity coverage, which impacts the physical location of the PHR data, and ubiquitous technology baseline, which deals with issues such as whether its storage device is fixed or portable, its concomitant software/hardware requirements and the required web-based infrastructure. Table 2 demonstrates how various types of PHRs can be classified according to the above mentioned criteria. These criteria can affect different architectural requirements of PHRs to successfully perform designed functions and business rules discussed in past studies (Botts et al., 2011; Halamka et al., 2008; Hourcade et al., 2011; Jones et al., 2010; Kaelber et al., 2008; Pagliari et al., 2007; Simons et al., 2005; Tang et al., 2006).

Table 2. Classification of PHR architectures based on two infrastructural drivers
Infrastructural DriversMode of Data Access Management by Users
Connectivity CoverageUbiquitous Technology Baseline
PHR Architecture/Location of DataStorage DeviceConcomitant Device and Software Requirement for Data Access by UsersWeb-Based Hardware
  1. Note. Compared to other devices, standalone PHRs stored in a desktop personal computer, a compact disc or a laptop were not considered because of their inconvenience for data management (a compact disc) and accessibility (a PC and a laptop) at point-of-care.

Local

(e.g. standalone)

  • Data locally available
  • No Internet connectivity required
USB (Maloney & Wright, 2009; Wright & Sittig, 2007) & Other portable storage media (e.g. SD cards)

PHR software

USB or other designated interface

Computing device (e.g. a PC, a mobile phone, a PDA)

 
  • With portable computing devices (e.g. a laptop) but not a mobile, anytime anywhere
  • With a PC anytime
  • Locally available at point-of-care
Smartcard (ABC, 2011; Chaplin, 2007; Cross, 2008; Ward, 2003)

PHR software

Card reader interface

Computing device (e.g. a PC, a mobile phone, a PDA)

  • Currently not easy with portable computing devices (e.g. a mobile phone) anytime anywhere
  • With a card reader and a PC anytime
  • Locally available at point-of-care
Mobile Phone/PDA (Allone Health Group Inc., 2008; McClain & Thompson, 2010; Steele & Min, 2010)PHR software
  • With itself anytime anywhere
  • With a PC anytime
  • Locally available at point-of-care

Remote

(e.g. interconnected or tethered (Tang et al., 2006))

  • Continuous internet connectivity required
Web-based server (Dossia, My GroupHealth, My HealtheVet, Google Health, HealthVault, MyChart)

Web-browser

Internet connected computing device (e.g. a PC, a mobile phone, a PDA)

Remote web server (database, web applications, network, etc)
  • With internet connection via portable computing devices (e.g. a mobile phone) anytime anywhere
  • With an internet connection via PC anytime
  • Locally available at point-of-care with internet connection via computing devices
Proprietary application server—PING (Simons et al., 2005)

Specific client program to access a remote PHR (e.g. web browser plug-in)

Internet connected computing device (e.g. a PC, a mobile phone, a PDA)

Remote dedicated server (database, proprietary applications, network, etc)
Cloud-based server (Botts et al., 2011; Koufi et al., 2010)

Web-browser

Internet connected computing device (e.g. a PC, a mobile phone, a PDA)

Distributed web and data servers

Hybrid

(local and remote duplication)

  • Intermittent internet connectivity required
Local device (e.g. USB, Smartcard, mobile phone, a PDA) and remote server

Local PHR software and local computing device (e.g. PC, a mobile phone, a PDA) with associated devices (e.g. USB interface or a card reader)

local web browser and internet connected computing device (e.g. PC, a mobile phone, a PDA)

Remote web server (database, applications, network, etc)
  • With/without internet connection via portable computing devices anytime anywhere
  • With an internet connected PC anytime
  • Locally available at point-of-care with/without internet connection

The new classification in Table 2 examines seven types of PHRs mainly in terms of two dimensions, location of PHR data dependent on network connectivity (i.e. connectivity coverage) and its needed storage devices and software (ubiquitous technology baseline). The location of a PHR can affect the accessibility of health data by users and their availability to health professionals. Additionally, storage devices can also affect the location of where PHR data can be stored as it affects its data usability and timely accessibility at point-of-care (Maloney & Wright, 2009). The location of PHR data can be considered as:

  • Local PHRs—Data is predominantly stored on a USB (Universal Serial Bus) (Maloney & Wright, ), a smartcard (Chaplin, ) or a mobile device (McClain & Thompson, ). Patients can use such devices to store and maintain their local PHRs that could be classified as standalone (see Table ). The local PHR may be characterized by the fact that network connectivity is not required and its data is portable as it is stored within a portable storage device. However, it may require a specific architectural infrastructure depending on the type of devices utilized. For example, a PHR stored in a USB device, that is a USB-based PHR, requires a computing device such as a personal computer (PC) with a USB interface in order to access its data. Several local storage devices were not considered due to their inconvenience for data management and datedness, for example, a compact disc and accessibility such as a PC or a laptop.
  • Remote server-based PHRs—The PHRs are based on a web-based server (Tang et al., ), a proprietary application server (Simons et al., ) or cloud-based servers (Botts et al. ). Patients can use remote servers, such as a web-based online server possibly managed by a health care provider, to store and maintain their PHRs via an internet connection which could be classified as a tethered or interconnected PHR (see Table ). Under this type of architecture, PHRs may not guarantee patients with a real-time perpetual accessibility and availability of their health data. This is due to the fact that data access is highly dependent on whether a stable and continuous network connection can be provided by the community-wide network infrastructures and such networks' fault tolerance (Salfner, Lenk, & Malek, ) from, for example, communication disruptions. Cloud-based PHRs represent another form of remote server-based PHR under a cloud computing environment whose definition is still evolving (Horrigan, ; Mell & Grance, ; IBM, ). While it is an emerging technology, some cloud-based PHR architectures have been discussed and their architectures depend centrally on cloud infrastructure (Botts et al., ; Koufi et al., ). As such it has many of the same advantages and disadvantages of remote servers. The greatest disadvantage is the need for continuous and reliable connectivity between cloud servers and that connectivity between cloud servers and clients, for example, web browsers in mobile phones. In addition, cloud computing architectures includes less control of data and lack of local customization of applications (Osterhaus, ) with more concern about privacy and security due to dispersed and distributed PHR data (Rosenthal et al., ; Schweitzer, ). Extra advantages of cloud-based PHRs are greater fault-tolerance and resiliency, interoperability, flexibility of data access and sharing, data integration, and trusted collaboration (Fox et al., ; Koufi et al., ; Rosenthal et al., 2010; Shimrat, ).
  • Hybrid PHRs—As a cross between local and remote PHRs, such PHRs allow data to be duplicated on both a local storage device and a remote server. This PHR is likely to provide better accessibility to data and is likely to withstand unexpected system and infrastructural vulnerabilities like natural disasters, network or power failures.

With the above mentioned classifications, PHR functional capabilities and their infrastructural implications have been studied and analyzed in the following sections further reviewing the existing literature.

4. PHR Functional Capabilities

Functionality is a central evaluation criterion of PHRs (Detmer, Bloomrosen, Raymond, & Tang, 2008; Kaelber et al., 2008; Kim & Johnson, 2002; Krist & Woolf, 2011). This is due to the fact that a PHR is composed of various functions to assist patients and their health care professionals to improve the decision-making process and care. This section focuses on the functional capabilities and their key issues required for capture, integration, storage and use of a patient's health data distributed among health care providers. Functional requirements of PHRs such as access control, data sharing and integration, data exchange and information search (Detmer et al., 2008; Eichelberg et al., 2005; Kaelber et al., 2008; Krist & Woolf, 2011; Tang et al., 2006) may depend on a PHR's architectural design and its infrastructure, for example, web-based and online, standalone or hybrid. For instance, Asthma Kiosk used in the emergency department (Porter, Cai, Gribbones, Goldmann, & Kohane, 2004) required different architectural and functional design such as a form-based front-end user interface, when compared with other EHR integrated PHRs such as Dossia, My HealtheVet and MyChart.

A PHR's functional capabilities can also affect its adoption and use for health care by patients and other users while having healthcare implications such as improving the quality of care and safety, decision-making empowerment, patient-centered and continuous care, and reduction of healthcare cost (Demiris et al., 2008; Endsley et al., 2006; Jones et al., 2010; Luo et al., 2011; Ralston et al., 2007; Tang et al., 2006; Weingart et al., 2006; Yamin et al., 2011). Based upon an analysis of partial functionality descriptions in the literature we have introduced in this paper a comprehensive list of PHR functional capabilities in Table 3 below. Table 3 shows eleven PHR functional capabilities and in addition their key issues and requirements. However, PHR functional capabilities discussed in Table 3 may depend on different PHR architectures designed and selected for delivery of, for example, community-wide health care systems. To satisfy those eleven capabilities, it is ideal for PHRs to contain a patient's complete health data (Gearon, 2007; Markle Foundation, 2006), that integrates patient-entered data or automatically collected patient-specific health-related monitoring data, for example, using wireless sensor networks (Steele, Lo, Secombe, & Wong, 2009) with data retrieved from various sources such as the patient's health care provider or health insurance provider. To integrate and exchange data with health care providers, PHRs and their health systems may require an interoperable protocol and the standardization of data exchange and sharing (Detmer et al., 2008; Eichelberg et al., 2005; Tang et al., 2006).

Table 3. Functional capabilities and their key issues and requirements
Functional capabilitiesKey issues and requirements
Access control of health data including privacy and security
  • Who controls the access policy of health data in PHR? (e.g. Sujansky et al., 2010).
  • Responsibility for physical security and policies of the PHR
  • Technical mechanisms for achieving data security (e.g. Kaelber et al., 2008).
Health data integration with patient health records
  • Integration mechanisms and processes of distributed health data with PHR (e.g. Detmer et al., 2008; Tang et al., 2006).
  • Preservation of data consistency and integrity in PHR—synchronization mechanisms with connected health data providers.
  • Location of PHR for health data integration.
Interoperability and data exchange
  • Data exchange mechanisms and technologies between diverse and distributed health information systems and the PHR (e.g. Eichelberg et al., 2005; Tang et al., 2006).
  • Collaboration among health data providers to build interoperability of their systems (e.g. Detmer et al., 2008).
Data availability at the point-of-care, especially emergency
  • Mechanisms to provide accessibility and availability of PHR when emergency situations occur (e.g. Raisinghani & Young, 2008).
  • Definition and policy of disclosing data in emergency situations (e.g. Maloney & Wright, 2009).
Audit management
  • Accountability management of data access, management and exchange and policy changes (Gajanayake et al., 2011).
  • Complexity of audit trails (e.g. Wang et al., 2004).
Information sharing on demand for research or statistical purposes
  • Mechanisms and protocols of information (data) sharing with government or research institutes for research, health statistics or health planning (e.g. Mandl & Kohane, 2008; Steele & Lo, 2009).
Accessibility of information (knowledge) / Help for medical, health and computer readability / Health behavior management
  • External information access mechanisms and their interface such as medical knowledge base access and information searching (e.g. Halamka et al., 2008).
  • Mechanisms to provide and support an individual's readability of terms related to medicine, health and technology and their interface (e.g. Krist & Woolf, 2011).
  • Mechanisms to provide health behavior management to specific health group such as diabetes, chronic illness, etc. (e.g. Hourcade et al., 2011).
Secure communications
  • Provision for communication protocols with required parties such as health professionals or relevant communities (e.g. Gearon, 2007).
  • Mechanisms of application integration and its interface.
  • Integration mechanisms of email messages with PHR data.
Fault tolerance (Robust operation)
  • Requires application of systemic fault tolerance policies for a critical and stringent fault tolerance architecture from unexpected vulnerability such as severe weather, natural disasters, disruptions of electrical or communications networks, hacking as well as human errors (e.g. Salfner et al., 2010).
Data management, storage, sustainability, backup and recovery
  • Responsibility for data backup and recovery for data loss and data/system failure (e.g. Tang et al., 2006).
  • Responsibility for data management of various file types and choice for their interface.
  • Data should be sustainable for life-long access and use.
System upgrade / maintenance
  • Who is responsible for upgrade and maintenance of the PHR with integrated systems?
  • Who is responsible for maintenance costs?
  • Who is responsible for technical education and training?

With the complete health data stored in either a web-based or a standalone PHR, the PHR needs to be sustainable over a patient's lifetime to provide users with a continuously up-to-date version of their health record. Sustainability of the complete health data can be affected by various obstacles such as an obsolete system or lost data (Detmer et al., 2008; Maloney & Wright, 2009). It is important to ensure that data can be sustainable over a patient's lifetime as its capability to facilitate continuity of the information can help achieve continuity in a patient's health care (Haggerty et al., 2003). One way to achieve PHR sustainability is via a sustainable maintenance policy (Tang et al., 2006). Regular system maintenance and upgrade can provide seamless functional operations with a diverse range of health information systems at point-of-care while architectural infrastructures are evolving. Additionally, system backup and recovery may be an important maintenance procedure to undertake so that users are continuously provided with access to their health data as well as to minimize the impact caused by the occurrence of unexpected situations such as data loss (Diesburg & Wang, 2010). Other functionalities that are likely to provide benefits to health care services are: secure communications (Gearon, 2007; Wang et al., 2004), online appointment (Pratt et al., 2006; Yamin et al., 2011), external information access (Halamka et al., 2008), decision making (Detmer et al., 2008; Demiris et al., 2008) and assistance in using computers and understanding health-related terms (Krist & Woolf, 2011).

5. Comparison of Architectures: Advantages and Limitations

This section discusses five PHR architectures mentioned in Table 2 in terms of their advantages and limitations based on the eleven identified functional capabilities (Table 3) and the infrastructural dependencies.

5.1 USB or Other Portable Storage-based PHR

A portable storage device such as a USB flash memory or a SD (Secure Digital) card can provide data storage for a local PHR (Maloney & Wright, 2009; Wright & Sittig, 2007) and patients can conveniently carry the PHR while travelling domestically or overseas. If the device is not physically damaged, then the stored health data can be readily available and easily accessible with minimum infrastructural requirements, which is a PC with a USB interface or a designated card reader in the case of a SD card. Any PHR based on a portable storage device, without requiring network connectivity, can provide patients with control over the privacy and security of their health data via the use of a manufacturer-provided data encryption/decryption approach and the use of a password (Wright & Sittig, 2007). As it is important to provide emergency personnel with an access to a subset of a patient's PHR data, such information should be preselected and predefined by the patient rather than by device providers as a default function (Wright & Sittig, 2007) and should not be protected by any special software.

However, currently available portable storage devices themselves cannot be readily interconnected with other systems without concomitant devices (Maloney & Wright, 2009). Such a limitation can prevent its data from being synchronously integrated with other data sources which may require interoperable interfaces, protocols and standardization of data exchange between them. In order to maintain the continuity of care, the PHR may require to be sustained over the lifetime of an individual and this sustainability may depend on how its maintenance and upgrades are carried out. Moreover, an effective data recovery policy needs to be in place to ensure that all important data are backed-up and can be recovered when the system fails. As this type of PHR is local and standalone, an individual may be responsible to carry out the above mentioned processes to ensure the sustainability of their health data. However, system upgrade may not require much effort as the application can be upgraded automatically by the manufacturer. Nevertheless, the individual should regularly backup their health data in case unexpected situations arise, for example, loss or device / system failure, and the data / system recovery process can be performed by either the individual or the PHR manufacturer.

5.2 Smartcard-based PHR

A portable integrated circuit (IC) chip-based plastic card (smartcard) can either store an individual's health data physically or under a logical file system. Currently, a smartcard-based PHR has been implemented as the Health eCard (Chaplin, 2007; Cross, 2008), health smart card (Ward, 2003; ABC, 2011) or patient health cards (Hildebrand, Pharow, & Blobel, 2008). A smartcard-based PHR storing integrated health data may store the actual information regarding an individual, such as their demographic and personal health data as well as any important data that may be required during an emergency, for example, blood type, immunization history and known allergies (Ward, 2003). Alternatively, it may store the data indexes that point to the location of the patient's health data which are likely to be distributed across various health care providers (Cross, 2008). In the health care domain, the smartcard as a trusted portable data storage medium, which provides strong security and privacy, was mainly considered for health-related applications such as identification, authentication and data protection and confidentiality (Smart Card Alliance, 2003).

Systemic operation and scalability of a smartcard-based PHRs may require appropriate infrastructures adopted by all users such as a smartcard reader/burner, network connectivity or a USB interface (Chaplin, 2007) in order to access/manage its data. A smartcard-based PHR used as a physical data repository would not require network connectivity in order to facilitate data access (Ward, 2003). However, a network connection with other data sources should be an essential infrastructural requirement if it is used as a logical data repository (Cross, 2008) and there has been very little consistent infrastructure for smartcard systems in the United States (Ward, 2003). Like data access, a card burner is specially required to write health data to the smartcard (Chaplin, 2007; Ward, 2003). This can make it difficult, given current typical infrastructure deployment and low interoperability between existing smartcard systems (Ward, 2003), for individuals to update their health data due to its non-interactive data processing approach and limited application support (Smart Card Alliance, 2003). Such barriers are likely to make it harder for inappropriate changes to be made and therefore improving the reliability of the health data stored in the smartcard (Cross, 2008; Smart Card Alliance, 2003).

Data sharing with, for example, research institutions can also be restricted because the currently available smartcard-based PHRs cannot provide data sharing mechanisms via network connection (Chaplin, 2007; Cross, 2008). An individual user does not need much effort to maintain their health record stored in the smartcard (Ward, 2003). However, if the smartcard is lost or at fault, its unique identification mechanism may cause an individual to have difficulties in its data recovery even though backup data are available. For example, it may need complex recovery processes to recapture all fragments of health data from distributed data sources.

5.3 Mobile Device-based PHR

A mobile device such as a mobile phone (including smartphones) or a PDA (Personal Digital Assistant) with computing capability can be used as a local data repository for a mobile device-based PHR and/or as an access device to existing online PHRs via a wireless internet connection (Allone Health Group Inc., 2008; Keckley & Chung, 2010; McClain & Thompson, 2010; Sarasohn-Kahn, 2010; Steele & Min, 2010). Compared with other PHR architectures, the mobile device-based PHR can provide greatest portability, providing real time data access for individuals to access and manage their health data without a fixed network connection and concomitant devices anywhere and anytime (Allone Health Group Inc., 2008; Sarasohn-Kahn, 2010). The PHR may provide users with great control over its privacy and security, and dynamic and flexible access policies can also be applied according to the situation at point-of-care. For example, a patient can dynamically provide healthcare professionals with health data on demand by using the mobile device itself under an individual's control (Allone Health Group Inc., 2008; Steele & Min, 2010).

Mobile devices can offer convenient data exchange via either a physically wired or secure wireless connection. The emerging technology of Near Field Communication (NFC) (Jara, Zamora, & Skarmeta, 2011; Laakko, Leppanen, Lahteenmaki, & Nummiaho, 2008) can further support security, interoperability, and authentication for patient–clinician interactions between mobile-based PHRs and health records maintained by healthcare professionals. These advantages can also support efficient data integration and high data consistency among distributed health data. However, as wireless environments are unpredictable, non-trusted mobile entities can be involved and it may jeopardize the privacy and security of the health data (Steele & Min, 2010). Compared to other portable storage-based PHRs, the increasing capability to provide more dynamic data management or updates in real time may require more accurate authorship control about patient-entered data for reliance on their data by health professionals (Kim & Johnson, 2002). For data sharing with third parties, a mobile device-based PHR may have limitations if it cannot facilitate interconnections for data sharing with external parties such as the government (Keckley & Chung, 2010).

For system maintenance, the mobile device-based PHR can be automatically upgraded by manufactures but users may need to have more concerns over its fault-tolerant operation such as the stability of the PHR application, its computational capability and reliability of the wireless connection. In case of data backup and recovery, individuals can be responsible for its regular backups to minimize data loss and reduce the complexity involved when importing data from other data sources for its full recovery. Compared to smartcard-based PHRs, its backup and recovery process may be less complex. Finally, mobile device-based PHRs have the potential to more easily integrate with emerging health communication means, that may support greater health consumer engagement (Steele, 2011).

5.4 Remote Server-based PHR

We include the three remote server-based architectures from Table 2 here. This type of PHR requires an appropriate architectural infrastructure to facilitate secure and trusted interactions between users and various health data sources such that the delivery and management of data can be undertaken in a secure and private manner (Diesburg & Wang, 2010; Eichelberg et al., 2005). A remote server-based PHR can be distinguished into two architectures: a web-based PHR which requires a web browser to access its data, for example, Dossia, MyGroupHealth, My HealtheVet, Google Health, Health Vault and MyChart, and PHRs stored on a proprietary application server which require a dedicated client software to gain data access (Simons et al., 2005). Continuous availability of network connection and other appropriate infrastructures can ideally provide the most efficient and convenient integration and synchronous update of health data of the PHR with interconnected data sources in terms of physical integration (Detmer et al., 2008; Jones et al., 2010; Markle Foundation, 2003; Simons et al., 2005) such as Dossia, MyGroupHealth, My HealtheVet and MyChart or logical integration (Markle Foundation, 2003). As of today, most server-based PHRs are integrated and interconnected with systems used by specific health care providers such as hospitals or insurances, employers or third-parties (Simons et al., 2005; Porter et al., 2004), for example, Dossia, MyGroupHealth, My HealtheVet, Google Health, Health Vault and MyChart.

With portable devices providing wireless internet connections, users can also access and manage health data in real time but easy data update may require accurate authorship to ensure the reliability of the data so that they will be trusted by the health care professionals. When an emergency occurs, emergency access can depend on available policies applied by the providers, for example, health data predefined by a patient or broader access to emergency staff (Detmer et al., 2008; Kim & Johnson, 2002). The PHR can also provide a patient's control over the privacy and security of their health data but systemic privacy and security may greatly depend on the providers' privacy policies as an unknown or non-trusted online user can also access the servers with PHRs (Tang et al., 2006). Compared to the various standalone PHRs, web-based PHR applications can provide an immense improvement over the standardization of data exchange and representation (Eichelberg et al., 2005).

Individuals may not have to worry about the maintenance and upgrade of the PHR as it may be maintained by organizations. However, its ongoing costs such as development, upgrade and maintenance would be an issue for adoption by health care providers (Clarke & Meiris, 2006; Raisinghani & Young, 2008; Shah et al., 2008). In terms of data backup and recovery, the backup of health data from a remote server may depend on system capability but an individual may require technical help from the PHR manufacturer for data recovery. However, the major barriers that may hamper the adoption of this architecture would be the quality and speed of the ubiquitous telecommunication infrastructures (Perlin et al., 2004). Obviously, in order to provide continuous and robust online services, this architecture, which can have more vulnerabilities over other PHR architectures, may require greatest concern over the fault tolerance of complex infrastructures such as servers, internet connection, PHR applications and accessing computers, security breaches, system fault or device damage (Salfner et al., 2010). In this regard, this possible danger and weakness of remote server-based PHR architectures has not been fully addressed, given the criticality of the need to be able to always access health information in normal clinical situations or emergency situations.

5.4.1 Cloud-based PHR

As cloud-based PHRs represent another form of remote server-based PHR, it requires fault-tolerant and continuous network connectivity that would support reliable ubiquitous computing environments under which users and their healthcare providers can use and access their PHRs through various wired or wireless internet-connected computing devices such as mobile/smart phone, tablet, PC, laptop, etc. The cloud-based PHRs increase flexibility and agility of patient data access and, processing and storage through the cloud computing infrastructure (Shimrat, 2009) as is the case with other remote server-based PHRs. Unlike using dedicated servers provided and operated by healthcare providers, government, or authoritative third parties for remote server-based PHR access and services, cloud-based PHRs would use distributed, virtual and dispersed servers and storage under interconnected networks (IBM, 2009). Thus the distributed storage of an individual PHR would require more concern related to data security and individual's privacy (Schweitzer, 2011). Even though cloud-based PHR architectures have been discussed by Botts et al. (2011) and Koufi et al. (2010), this architecture based on the emerging technology would require more research for its application to PHR services in terms of the four deployment models discussed by NIST (Mell & Grance, 2009). For example, 1) dispersed and distributed healthcare providers would be interconnected under a cloud computing environment, or 2) individuals' virtual PHRs would be implemented under a cloud computing environment separate from existing healthcare providers outside of its cloud computing environment. In terms of both distinct architectural specifications, PHR functional and architectural requirements would depend on how to implement the cloud-based PHR architecture with current and potential infrastructure. Whatever architecture is utilized for an emerging cloud-based PHRs' solution, PHR functional capabilities discussed in Table 3 based on the existing architectures would be positively impacted by the systemic advantages of cloud computing, for example, data integration and exchange, interoperability, data availability, and scalability (Armbrust et al., 2010).

While the cloud-based PHR might potentially have variants that could potentially be characterized under the category of hybrid PHRs, the intrinsic feature of cloud-based systems is their use of remote servers in the cloud, and so such PHRs are best categorized as here, under the remote server-based PHR category.

5.5 Hybrid PHR

This PHR architecture, suggested by this paper, which allows an individual's health data to be duplicated on both a local and remote location, can provide the greatest availability of health data under any circumstances and flexible access, both local and online, to their health records. This hybrid architecture can complement limitations of both local and remote PHRs such as data integration and sharing, fault tolerance and ease of data recovery. For example, network connectivity is essential to this type of PHR but in contrast with a remote server-based PHR, any fault may not critically affect its data accessibility and availability. In case of a medical emergency, this type of PHR can provide different access methods to an individual's health data according to the situation (Kim & Johnson, 2002), for example, emergency staff can access the locally stored data if the patient is conscious; whereas in the case when the local copy is unavailable or the patient is unconscious, medical staff can retrieve the required data from data stored on a remote server.

This PHR architecture essentially requires appropriate policies to ensure the consistency and integrity of data stored in both local and remote PHRs and to achieve consistent secure access control for a user's health data in the two PHRs for protection of the user's privacy (Tang et al., 2006). Without data consistency and integrity between the local and remote PHRs, users cannot guarantee the reliability of their health data and any data inconsistency between the two data locations may result in critical medical errors which may have critical consequences for the user. Thus this PHR should require automated and robust synchronization mechanisms and secure data exchange protocols which require trusted connections with significant responsibility for provided data. In addition, more efforts and responsibility for system upgrade and maintenance of both PHRs would be required as each PHR may require its own data backup and recovery. For audit trails, users may need to trace data access and management of both PHRs. The hybrid PHR architecture may also require essential infrastructures such as network connectivity but can tolerate these not being continuous but rather intermittent. Furthermore, certain measures are also needed to ensure its interoperability and standardization of data exchange between both the local and remote side of the PHR.

5.6 Summary

With available technologies, the different approaches to PHRs can imply different architectural infrastructures such as network connectivity (i.e. connectivity coverage), location of PHR data, storage devices and concomitant software/hardware and reliability of infrastructure. PHR architectures may also have their own advantages and limitations in terms of the eleven functional capabilities identified in Section 4. This review article can act as a guide to inform the community-wide deployment of PHR architectures dependent on existing or planned infrastructures and the implications these hence have for PHR functional capabilities.

6. Conclusion

The widespread adoption of PHRs by individuals may provide significant benefits such as improving the quality of patient care and safety; empowering individuals with more information such that they are able to make more informed decisions over health-related matters; and provision of efficient and effective care by health care providers. However, their adoption and use may depend on various factors (Clarke & Meiris, 2006; Hourcade et al., 2011; Lober et al., 2006; Raisinghani & Young, 2008; Tang et al., 2006; Yamin et al., 2011) and one of the potential barriers to their widespread adoption would be requirements for the requisite community-wide infrastructure. We have described a novel classification approach for PHR architectures based on two infrastructural drivers—ubiquitous technology baseline and connectivity coverage—and discussed their infrastructural implications and dependencies in terms of eleven functional capabilities. These two drivers can affect the selection of PHR architectures as the usability, stability and reliability of PHRs greatly depends on the availability and reliability of its internet connection and hardware and software requirements. Moreover, the functional capabilities of each PHR architecture may also affect an individual's preference in relation to a PHR architecture such as its storage devices and location. Therefore, community- or nationwide infrastructure for PHRs may affect PHR architectural choices as each one of the architectures is defined by their functional capabilities. This review article provides a step towards better understanding these dependencies.

Ancillary