• organization of information


  1. Top of page
  2. Abstract
  3. 1. Introduction
  4. 2. Existing Architectural Classifications
  5. 3. PHR Classification Based on Architecture and Infrastructure Interdependence
  6. 4. PHR Functional Capabilities
  7. 5. Comparison of Architectures: Advantages and Limitations
  8. 6. Conclusion
  9. References

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

  1. Top of page
  2. Abstract
  3. 1. Introduction
  4. 2. Existing Architectural Classifications
  5. 3. PHR Classification Based on Architecture and Infrastructure Interdependence
  6. 4. PHR Functional Capabilities
  7. 5. Comparison of Architectures: Advantages and Limitations
  8. 6. Conclusion
  9. References

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

  1. Top of page
  2. Abstract
  3. 1. Introduction
  4. 2. Existing Architectural Classifications
  5. 3. PHR Classification Based on Architecture and Infrastructure Interdependence
  6. 4. PHR Functional Capabilities
  7. 5. Comparison of Architectures: Advantages and Limitations
  8. 6. Conclusion
  9. References

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 (, MyGroupHealth ( and My HealtheVet ( 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 ( can be classified as an independent web-based PHR, and HealthVault ( as an interconnected web-based PHR. There are also web-based PHRs that are integrated with EHRs, for example, MyChart (, My HealtheVet, and MyGroupHealth.

Table 1. Existing classifications of PHRs
Connectivity Type (Tang et al., 2006)Standalone
  • Individual creation of PHRs, not connected with other systems
  • PHRs connected to various health care systems
  • 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
  • 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
  • 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

  1. Top of page
  2. Abstract
  3. 1. Introduction
  4. 2. Existing Architectural Classifications
  5. 3. PHR Classification Based on Architecture and Infrastructure Interdependence
  6. 4. PHR Functional Capabilities
  7. 5. Comparison of Architectures: Advantages and Limitations
  8. 6. Conclusion
  9. References

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.


(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


(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)


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)


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

Distributed web and data servers


(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, 2009), a smartcard (Chaplin, 2007) or a mobile device (McClain & Thompson, 2010). Patients can use such devices to store and maintain their local PHRs that could be classified as standalone (see Table 1). 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., 2006), a proprietary application server (Simons et al., 2005) or cloud-based servers (Botts et al. 2011). 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 1). 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, 2010) 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, 2008; Mell & Grance, 2009; IBM, 2009). 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., 2011; Koufi et al., 2010). 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, 2010) with more concern about privacy and security due to dispersed and distributed PHR data (Rosenthal et al., 2010; Schweitzer, 2011). 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., 2011; Koufi et al., 2010; Rosenthal et al., 2010; Shimrat, 2009).
  • 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

  1. Top of page
  2. Abstract
  3. 1. Introduction
  4. 2. Existing Architectural Classifications
  5. 3. PHR Classification Based on Architecture and Infrastructure Interdependence
  6. 4. PHR Functional Capabilities
  7. 5. Comparison of Architectures: Advantages and Limitations
  8. 6. Conclusion
  9. References

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

  1. Top of page
  2. Abstract
  3. 1. Introduction
  4. 2. Existing Architectural Classifications
  5. 3. PHR Classification Based on Architecture and Infrastructure Interdependence
  6. 4. PHR Functional Capabilities
  7. 5. Comparison of Architectures: Advantages and Limitations
  8. 6. Conclusion
  9. References

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

  1. Top of page
  2. Abstract
  3. 1. Introduction
  4. 2. Existing Architectural Classifications
  5. 3. PHR Classification Based on Architecture and Infrastructure Interdependence
  6. 4. PHR Functional Capabilities
  7. 5. Comparison of Architectures: Advantages and Limitations
  8. 6. Conclusion
  9. References

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.


  1. Top of page
  2. Abstract
  3. 1. Introduction
  4. 2. Existing Architectural Classifications
  5. 3. PHR Classification Based on Architecture and Infrastructure Interdependence
  6. 4. PHR Functional Capabilities
  7. 5. Comparison of Architectures: Advantages and Limitations
  8. 6. Conclusion
  9. References
  • ABC (Australian Broadcasting Corporation). (2011). Smartcards to give patients records control. Retrieved October 12, 2011, from
  • AHIMA e-HIM Personal Health Record Work Group. (2005). The role of the personal health record in the EHR. Journal of American Health Information Management Association, 76(7), 64A64D.
  • Allone Health Group Inc. (2008). AllOne health group(SM) first to launch personal health records for mobile phones to health plans. Retrieved September 20, 2011, from
  • Archer, N., Fevrier-Thomas, U., Lokker, C., McKibbon, K.A., & Strauss, S.E. (2011). Personal health records: a scoping review. Journal of the American Medical Informatics Association, 18(4), 515522.
  • Armbrust, M., Fox, A., Griffith, R., Joseph, A.D., Katz, R., Konwinski, A., et al. (2010). A view of cloud computing. Communications of the ACM, 53(4), 5058.
  • Botts, N.E., Horan, T.A., & Thoms, B.P. (2011). HealthATM: personal health cyberinfrastructure for underserved populations. American Journal of Preventive Medicine, 40(5S2), S115S122.
  • Bourgeois, F.C., Taylor, P.L., Emans, S.J., Nigrin, D.J., & Mandl, K.D. (2008). Whose personal control? creating private, personally controlled health records for pediatric and adolescent patients. Journal of the American Medical Informatics Association, 15(6), 737743.
  • Brennan, P.F., Downs, S., & Casper, G. (2010). Project HealthDesign: rethinking the power and potential of personal health records. Journal of Biomedical Informatics, 43(5S1), S3-S5.
  • Chaplin, S. (2007). The health eCard: the way ahead for medical records? Prescriber, 5, 2829.
    Direct Link:
  • Choemprayong, S., Oh, S., & Sheble, L. (2006). Interface for the personal pregnancy health records (PregHeR) system: facets in time. Proceedings of AMIA Annual Symposium (p. 885). AMIA.
  • Clarke, J.L., & Meiris, D.C. (2006). Electronic personal health records come of age. American Journal of Medical Quality, 21(3), 5s-15s.
  • Cross, M. (2008). Wallet or web? British Medical Journal, 336(7645), 637638.
  • Demiris, G., Afrin, L.B., Speedie, S., Courtney, K.L., Sondhi, M., Vimarlund, V., et al. (2008). Patient-centered applications: use of information technology to promote disease management and wellness. Journal of the American Medical Informatics Association, 15(1), 813.
  • Detmer, D., Bloomrosen, M., Raymond, B., & Tang, P. (2008). Integrated personal health records: Transformative tools for consumer-centric care. BMC Medical Informatics and Decision Making, 8(1), 45.
  • Diesburg, S.M., & Wang, A.A. (2010). A survey of confidential data storage and deletion methods. ACM Computing Surveys, 43(1), 137.
  • DoHA (Department of Health and Ageing). (2011). Personally controlled electronic health records. Retrieved September 20, 2011, from
  • Dossia. (2011).
  • Eichelberg, M., Aden, T., Riesmeier, J., Dogac, A., & Laleci, G.B. (2005). A survey and analysis of electronic healthcare record standards. ACM Computing Surveys, 37(4), 277315.
  • Endsley, S., Kibbe, D.C., Linares, A., & Colorafi, K. (2006). An introduction to personal health records. Family Practice Management, 13(5), 5762.
  • Fong, E.N., & Goldfine A.H. (1989). Special publication 500-167: Information management directions: the integration challenge. NIST. Retrieved September 20, 2011, from
  • Fox, R., James, C., & Manfred, H. (2011). Creating a virtual personal health record using mashups. IEEE Computer, 15(4), 2330.
  • Fuji, K.T., Galt, K.A., & Serocca, A.B. (2008). Personal health record use by patients as perceived by ambulatory care physicians in Nebraska and South Dakota: a cross-sectional study. Perspectives in Health Information Management, 5(15), 116.
  • Gajanayake, R., Iannella, R., & Sahama, T. (2011). Sharing with care: An information accountability perspective. IEEE Internet Computing, 15(4), 3138.
  • Gearon, C.J. (2007). Perspectives on the future of personal health records. California HealthCare Foundation. Retrieved September 20, 2011, from
  • Goldberg, L., Lide, B., Lowry, S., Massett, H.A., O'Connell, T., Preece, J., et al. (2011). Usability and accessibility in consumer health informatics: current trends and future challenges. American Journal of Preventive Medicine, 40(5S2), S187-S197.
  • Google Health. (2010).
  • Haggerty, J.L., Reid, R.J., Freeman, G.K., Starfieldn, B.H., Adair, C.E., & McKendry, R. (2003). Continuity of care: a multidisciplinary review. British Medical Journal, 327(7425), 12191221.
  • Halamka, J.D., Mandl, K.D., & Tang, P.C. (2008). Early experiences with personal health records. Journal of the American Medical Informatics Association, 15(1), 17.
  • Hasan, S.O., & Rotenstreich, S. (2008). An organizational framework of personal health records for social networks. In H. R. Arabnia , M. Q. Yang , & J. Y. Yang (Eds.) Proceedings of International Conference on Bioinformatics & Computational Biology (BIOCOMP 2008) (pp. 568572). Las Vegas, NE:CSREA Press.
  • Haux, R. (2006). Health information systems—past, present, future. International Journal of Medical Informatics, 75(3–4), 268281.
  • HealthVault. (2011).
  • Hildebrand, C., Pharow, P., & Blobel, B. (2008). The role of patients and their health cards in integrated ehealth environments. Studies in Health Technology and Informatics, 136, 629634.
  • Horrigan, J.B. (2008). Use of cloud computing applications and services. The Pew internet & American life project. Retrieved December 6, 2011, from
  • Hourcade, J., Chrischilles, E., Gryzlak, B., Hanson, B., Dunbar, D., Eichmann, D., et al. (2011). Design lessons for older adult personal health records software from older adults. In C. Stephanidis (Ed.) Proceedings of the 6th international conference on Universal access in human-computer interaction: users diversity—Part II (UAHCI'11) (pp. 176185). Berlin/Heidelberg: Springer.
  • IBM. (2009). Cloud computing white paper. IBM point of view: security and cloud computing. Retrieved December 6, 2011, from
  • Jara, A.J., Zamora, M.A., & Skarmeta, A.F. (2011). An internet of things—based personal device for diabetes therapy management in ambient assisted living (AAL). Personal and Ubiquitous Computing, 15(4), 431440.
  • Johnson, D., Kaelber, D., Pan, E.C., Bu, D., Shah, S., Hook, J.M., et al. (2007). A framework and approach for assessing the value of personal health records (PHRs). Proceedings of AMIA Annual Symposium (pp. 374378). AMIA.
  • Jones, D., Shipman, J.P., Plaut, D.A., & Selden, C.R. (2010). Characteristics of personal health records: findings of the medical library association/national library of medicine joint electronic personal health record task force. Journal of the Medical Library Association, 98(3), 243249.
  • Kaelber, D.C., Jha, A.K., Johnston, D., Middleton, B., & Bates, D.W. (2008). A research agenda for personal health records (PHRs). Journal of the American Medical Informatics Association, 15(6), 729736.
  • Kaelber, D., & Pan, E.C. (2008). The value of personal health record (PHR) systems. Proceedings of AMIA Annual Symposium (pp. 343347). AMIA.
  • Keckley, P.H., & Chung, B. (2010). The mobile personal health record: technology-enabled self-care. Washington D.C, Deloitte Center for Health Solutions.
  • Kim, M.I., & Johnson, K.B. (2002). Personal health records: evaluation of functionality and utility. Journal of the American Medical Informatics Association, 9(2), 171180.
  • Koufi, V., Malamateniou, F., & Vassilacopoulos, G. (2010). Ubiquitous access to cloud emergency medical services. Proceedings of the 10th IEEE International Conference on Information Technology and Applications in Biomedicine (ITAB) (pp. 14). Corfu: IEEE.
  • Krist, A.H., & Woolf, S.H. (2011). A vision for patient-centered health information systems. Journal of the American Medical Association, 305(3), 300301.
  • Laakko, T., Leppänen, J., Lähteenmäki, J., & Nummiaho, A. (2008). Mobile health and wellness application framework. Methods of Information in Medicine, 47(3), 217222.
  • Lafky, D.B., & Horan, T.A. (2011). Personal health records. Health Informatics Journal, 17(1), 6371.
  • Liu, P., & Chetal A. (2005). Trust-based secure information sharing between federal government agencies. Journal of the American Society for Information Science and Technology, 56(3), 283298.
  • Lobach, D.F., Willis, J.M., Macri, J.M., Simo, J., & Anstrom, K.J. (2006). Perceptions of Medicaid beneficiaries regarding the usefulness of accessing personal health information and services through a patient internet portal. In Proceeding of AMIA Annual Symposium. 509513.
  • Lober, W.B., Zierler, B., Herbaugh, A., Shinstrom, S.E., Stolyar, A., Kim, E.H., et al. (2006). Barriers to the use of a personal health record by an elderly population. Proceedings of AMIA Annual Symposium (pp. 514518). AMIA.
  • Luo G, Tang C, & Thomas S.B. (2011). Intelligent personal health record: Experience and open issues. Journal of Medical Systems, 118.
  • Maloney, F.L., & Wright, A. (2009). USB-based personal health records: an analysis of features and functionality. International Journal of Medical Informatics, 79(2), 97111.
  • Mandl, K.D., & Kohane, I.S. (2008). Tectonic shifts in the health information economy. The New England Journal of Medicine, 358(16), 17321737.
  • Markle Foundation. (2003). Connecting for health a public-private collaborative. Retrieved September 21, 2009, from
  • Markle Foundation. (2006). Connecting Americans to their health care: a common framework for networked personal health information. Retrieved September 20, 2011, from
  • McClain, I., & Thompson, E. (2010). The use of cell phone technology provides teens more control and independence and healthcare cost savings in the management of chronic disease. Perspectives Health Information Management. 7(Fall), 1g.
  • Mell, P., & Grance, T. (2009). The NIST definition of cloud computing. NIST. Retrieved December 6, 2011, from
  • MyChart. (2011).
  • MyGroupHealth. (2011).
  • My HealtheVet. (2011).
  • Osterhaus, L.C. (2010). Cloud computing and health information. University of Iowa. Retrieved December 6, 2011, from
  • Pagliari, C., Detmer, D., & Singleton, P. (2007). Potential of electronic personal health records. British Medical Journal, 335(7615), 330333.
  • Perlin, J.B., Kolodner, R.M., & Rosswell, R.H. (2004). The veterans health administration: quality value, accountability, and information as transforming strategies for patient-centered care. American Journal of Managed Care, 10(11), 828836.
  • Porter, S.C., Cai, Z., Gribbones, W., Goldmann, D.A., & Kohane, I.S. (2004). The asthma kiosk: a patient-centered technology for collaborative decision support in the emergency department. Journal of the American Medical Informatics Association, 11(6), 458467.
  • Pratt, W., Unruh, K., Civan, A., & Skeels, M. (2006). Personal health information management. Communications of the ACM, 49(1), 5155.
  • Raisinghani, M.S., & Young E. (2008). Personal health records: key adoption issues and implications for management. International Journal of Electronic Healthcare, 4(1), 6777.
  • Ralston, J.D., Carrell, D., Reid, R., Anderson, M., Moran, M., & Hereford, J. (2007). Patient web services integrated with a shared medical record: patient use and satisfaction. Journal of the American Medical Informatics Association, 14(6), 798806.
  • Rosenthal, A., Mork, P., Li, M.H., Stanford, J., Koester, D., & Reynolds, P. (2010). Cloud computing: A new business paradigm for biomedical information sharing. Journal of Biomedical Informatics, 43(2), 342353.
  • Salfner, F., Lenk, M., & Malek, M. (2010). A survey of online failure prediction methods. ACM Computing Surveys, 42(3), 142.
  • Shah, S., Kaelber, D.C., Vincent, A., Pan, E.C., Johnston, D., & Middleton, B. (2008). A cost model for personal health records (PHRs). Proceedings of AMIA Annual Symposium (pp. 657661). AMIA.
  • Sarasohn-Kahn, J. (2010). How smartphones are changing health care for consumers and providers. California Healthcare Foundations. Retrieved December 6, 2011, from
  • Schweitzer, E.J. (2011). Reconciliation of the cloud computing model with US federal electronic health record regulations. Journal of the American Medical Informatics Association, Advance online publication. doi:10.1136/amiajnl-2011-000162.
  • Shimrat, O. (2009). Cloud computing and healthcare. San Diego Retrieved December 6, 2011, from
  • Simborg, D.W. (2009). The limits of free speech: the PHR problem. Journal of the American Medical Informatics Association, 6(3), 282283.
  • Simons, W.W., Mandl, K.D., & Kohane, I.S. (2005). The PING personally controlled electronic medical record system: technical architecture. Journal of the American Medical Informatics Association, 12(1), 4754.
  • Smart Card Alliance. (2003). HIPAA compliance and smart cards: solutions to privacy and security requirements. Retrieved September 20, 2011, from
  • Steele, R. (2011). Social media, mobile devices and sensors: categorizing new techniques for health communication. Proceedings of the 5th International Conference on Sensing Technology (ICST 2011) (pp. 187192). Palmerston North, New Zealand: IEEE.
  • Steele, R., Gardner, W., Chandra, D., & Dillon, T.S. (2007). Framework and prototype for a secure XML-based electronic health records system. International Journal of Electronic Healthcare, 3(2), 151174.
  • Steele, R., & Lo. A. (2009). Future personal health records as a foundation for computational health. Computational Science and Its Applications—ICCSA 2009, Lecture Notes in Computer Science, Volume 5593/2009 (pp. 719733). Springer-Verlag.
  • Steele, R., Lo. A., Secombe, C., & Wong, Y.K. (2009). Elderly persons' perception and acceptance of using wireless sensor networks to assist healthcare. International Journal of Medical Informatics, 78(12), 788801.
  • Steele, R., & Min, K. (2010). HealthPass: Fine-grained access control to portable personal health records. Proceedings of the 24th IEEE International Conference on Advanced Information Networking and Applications (AINA) (pp. 10121019). Perth: IEEE.
  • Steinbrook, R. (2008). Personally controlled online health data—the next big thing in medical care? The New England Journal of Medicine, 358(16), 16531656.
  • Sujansky, W.V., Faus, S.A., Stone, E., & Brennan, P.F. (2010). A method to implement fine-grained access control for personal health records through standard relational database queries. Journal of Biomedical Informatics, 43(5S1), S46-S50.
  • Tang, P.C., Ash, J.S., Bates, D.W., Overhage, J.M., & Sands, D.Z. (2006). Personal health records: definitions, benefits, and strategies for overcoming barriers to adoption. Journal of the American Medical Informatics Association, 13(2), 121126.
  • Wang, M., Lau, C., Matsen, F.A., III, & Kim, Y. (2004). Personal health information management system and its application in referral management. IEEE Transactions on Information Technology in Biomedicine, 8(3), 287297.
  • Ward, S.R. (2003). Health smart cards: merging technology and medical information. Medical Reference Services Quarterly, 22(1), 5765.
  • Weingart, S.N., Rind, D., Tofias, Z., & Sands, D.Z. (2006). Who uses the patient internet portal? The PatientSite experience. Journal of the American Medical Informatics Association, 13(1), 9195.
  • Wright, A., & Sittig, D.F. (2007). Encryption characteristics of two USB-based personal health records devices. Journal of the American Medical Informatics Association, 14(4), 397399.
  • Yamin, C.K., Emani, S., Deborah H.W., Lipsitz, S.R., Karson, A.S., Wald, J.S., et al. (2011). The digital divide in adoption and use of a personal health record. Archives of Internal Medicine, 171(6), 568574.
  • Zeng, K., Bodenreider, O., & Nelson, S.J. (2008). Design and implementation of a personal medication record—MyMedicationList. Proceedings of AMIA Annual Symposium (pp. 844848). AMIA.