The Value of Personal Health Record (PHR) Systems

Abstract

Personal health records (PHRs) are a rapidly growing area of health information technology despite a lack of significant value-based assessment.

Here we present an assessment of the potential value of PHR systems, looking at both costs and benefits. We examine provider-tethered, payer-tethered, and third-party PHRs, as well as idealized interoperable PHRs. An analytical model was developed that considered eight PHR application and infrastructure functions. Our analysis projects the initial and annual costs and annual benefits of PHRs to the entire US over the next 10 years.

This PHR analysis shows that all forms of PHRs have initial net negative value. However, at the end of 10 years, steady state annual net value ranging from $13 billion to -$29 billion. Interoperable PHRs provide the most value, followed by third-party PHRs and payer-tethered PHRs also showing positive net value. Provider-tethered PHRs constantly demonstrating negative net value.

Introduction

Personal health records (PHRs) are gaining attention in the US healthcare system. A large variety of provider, payer, and third-party organizations, including organizations not traditionally involved in healthcare such as Google, are discussing, developing, and in some cases bringing to market various types of PHRs. These PHRs have a wide range of diverse architectures and functions, ranging from “stand-alone” PHRs that do not integrate with any other systems to “tethered” PHRs that provide a patient oriented view integrated with other electronic health information¹. There is also growing interest and excitement on the part of patient and patient organizations as to the potential for PHRs to improve healthcare.

With this background, however, the actual quantifiable value of PHRs has yet to be demonstrated. No published reports on PHRs have analyzed their value on a large scale or compared the value of different types of PHRs. Here we present a thorough value analysis of the potential value of PHRs to the US.

Methods

To assess the value of PHRs the Center for Information Technology Leadership (CITL) followed a four-step value assessment methodology that we have previously developed and used in several other assessments of emerging health information technologies^2–5. This four-step process includes:

1. Technology definition and data collection

2. Taxonomy definition and evidence framework

3. Evidence synthesis

4. Model development

1. Technology Definition and Data Collection. Although many definitions of PHRs exist, we used the Markle Foundation PHR description:

“The Personal Health Record (PHR) is an Internet-based set of tools that allows people to access and coordinate their lifelong health information and make appropriate parts of it available to those who need it.”⁶

We then completed a comprehensive literature review looking at the impact of PHRs. We identified 22 words or phrases related to PHRs and searched PubMed, Business Sources Complete, and ABI/Inform which yielded 493 references. The references were further reduced to 265 by limiting to peer-reviewed references in English over the last 10 years (1997–2007). Abstracts were obtained on the 265 references and two researchers reviewed each abstract and agreed upon 137 articles to be fully abstracted based on the relevance of the abstract.

2. Taxonomy definition and evidence framework. After the literature review, we developed a PHR taxonomy and evidence framework to organize our PHR value analysis.

Our PHR taxonomy is based on categorizing PHR functions on the information needed and how it is used within a PHR from the patient’s perspective. CITL envisions PHRs operating as PHR systems⁶ encompassing both infrastructure functions, defined as those functions that collect data and allow patients and external parties to view it, and application functions, defined as functions that allow patients to manage their own health and participate in two-way data exchanges (transactions) with health entities. Privacy and security features are also included in the PHR system and “surround” both infrastructure and application components.

Within in the PHR framework, which is described in more detail elsewhere⁷, we envisioned four PHR architectures, based on the primary source of data for the PHR, including provider-tethered, payer-tethered, third-party, and interoperable PHRs. Provider-tethered and payer-tethered (both linked only to healthcare data within their own organization’s information systems), and third-party PHRs all exist today, with interoperable PHRs representing a future type of PHR based on robust standards for electronic healthcare data exchange.

3. Evidence Synthesis. We used this PHR framework to organize and integrate data from the literature and experts to determine the value of PHRs. The evidence pointed to value clusters – general areas where PHRs have or could have value. From these value clusters, we identified PHR functions with potential value. We chose to model eight PHR functions that demonstrate the potential effects of a range of infrastructure and application functions, both for administrative and clinical purposes (Table 1). Within the PHR infrastructure, value was estimated for sharing complete medication lists in a PHR leading to a reduction in drug-drug interaction adverse drug events (ADEs) and for sharing complete test results in a PHR thereby avoiding of redundant tests. Within PHR applications, value was estimated for congestive heart failure (CHF) remote monitoring, smoking cessation management, appointment scheduling, pre-encounter questionnaires to collect administrative information for new patient encounters, medication renewals, and e-visits. The impact of these functions derived from reducing both administrative costs and healthcare utilization costs.

Table 1.

Representative PHR benefit functions categorized by application (A) functions or infrastructure (I) functions.

PHR Benefit Function	Type
Sharing Complete Medication Lists	I
Sharing Complete Test Results	I
Congestive Heart Failure (CHF) Remote Monitoring	A
Smoking Cessation Management	A
Appointment Scheduling	A
Medication Renewals	A
Pre-encounter Questionnaires	A
E-visits	A

4. Model Development: Next, we developed a computer model to integrate all of our cost and benefit evidence and extrapolate this information to the national level. Because our literature review yielded relatively little quantitative evidence regarding PHR costs and benefits, we augmented our literature derived model parameters with expert opinion and related evidence from non-PHR sources. Our model consisted of a PHR benefit model and a PHR cost model which were then combined to assess the net value of PHRs.

For our PHR benefit model, we recognize that a large number of PHR functions could exist in future PHRs, yet a very small number of existing PHR functions have any proven value today.

The eight benefit functions we choose to model based on the existing PHR literature have different value propositions based on PHR architecture (Table 2). In general, the value proposition of a given benefit function within a PHR architecture is dependent on the data available within that PHR architecture and the degree to which the PHR function allows automated data processing through the PHR. For example, with appointment scheduling, medication renewals, and pre-encounter questionnaires, we assumed that all PHR architectures would have secure messaging and so could support these activities through this tool. However, provider-tethered and interoperable PHRs could automatically integrate information from these secure messaging enabled administrative functions into their non-PHR scheduling, medication renewals, and pre-encounter questionnaires systems because of the known data structure standards in use in the provider-tethered and interoperable systems. This facility for automated processing of PHR data dramatically increases its value. Third-party and payer-tethered PHRs with these functions could only provide non-standardized data that would still require some manual processing, and so these functions in these architectures would be less valuable.

Table 2.

Relationship between PHR function and PHR architecture (− no value model, + value through manual data processing, ++ value through automatic data processing).

PHR Function	PHR Architecture
	Provider-Tethered	Payer-Tethered	Third-Party	Interop.
Sharing Complete Medication Lists3	−	−	−	++
Sharing Complete Test Results3	−	−	+	++
CHF Remote Management2	+	+	+	+
Smoking Cessation	+	+	+	+
Management2
Appointment Scheduling1	++	+	+	++
Medication Renewals1	++	+	+	++
Pre-encounter Questionnaires1	++	+	+	++
E-visits2	+	+	+	+

¹Administrative,

²Clinical and

³Infrastructure functions.

Clinical functions were either self-contained (CHF remote monitoring and smoking cessation) and required manual processing, or required review and action by a provider (e-visits). Therefore, the value proposition did not vary by PHR architecture because each architecture used data in the same way. For infrastructure benefits, we assumed automated processing of a complete medication list and automated processing of complete test results only in the interoperable PHR, with the ability to manually check PHR data for possible redundant tests in the third-party PHR.

For our PHR cost model, we determined a representative mean PHR application development cost of $450,000 per application, including: programmer costs to design, develop, build and test the application; management and support costs; and core knowledge management development costs. We also developed infrastructure cost models to build and implement each of the four PHR architectures. These infrastructure cost models were adapted from several sources^8–10. All costs included initial acquisition costs as well as annual costs. Primary differences in costs came from differences in interface costs and typical costs to implement at scale given the architecture (i.e. the typical number of patients that a single type of each PHR would be provided to).

For our national model, we determined the number of installations for each of the four types of PHR architectures needed to cover 80% of the US population (Table 3). Costs were projected over a 10-year period for installation, adoption, and use, with a normalized three-year installation rate and, five-year adoption rate. We assumed going from 0% PHR use in the first year to full use by 80% of the US population at end of year 10. All modeling was done using Analytica – a decision science modeling software package¹¹. Details of our cost model are described elsewhere¹².

Table 3.

Estimated number of unique PHR installations to cover 80% of the US population by PHR architecture.

PHR Architecture	Number of Installations to cover 80% of the US population (#)
Provider-Tethered	26,478 provider organizations13,14
Payer-Tethered	706 payers15
Third-Party	3 third-parties (Microsoft, Google, Dossia)
Interoperable	428 regions2,13,16

Results

Based on our PHR value model, the annual benefits of the PHR functions we modeled ranged from $9 million for complete medication lists to $7.9 billion for complete test results (Table 4).

Table 4.

Annual potential benefits by PHR function.

PHR Function	Annual Benefit by PHR Architecture ($, millions)
	Provider-Tethered	Payer-Tethered	Third-Party	Interop.
Sharing Complete Medication Lists	0	0	0	9
Sharing Complete Test Results	0	0	3,300	7,900
CHF Remote Monitoring	6,300	6,300	6,300	6,300
Smoking Cessation Management	1,040	1,040	1,040	1,040
Appointment Scheduling	170	71	71	170
Medication Renewals	1,100	490	490	1,100
Pre-encounter Questionnaires	72	18	18	82
E-visits	4,800	4,800	4,800	4,800
TOTAL	14,000	13,000	16,000	21,000

Application costs were less than infrastructure costs and initial acquisition costs were greater than annual costs both for single installations and for the 80% roll-out (Table 5). When combining application and infrastructure costs, third-party PHRs had the highest initial and annual costs for a single PHR installation, while provider-tethered PHRs had the highest initial and annual costs to provide PHRs for 80% of the US population.

Table 5.

Total initial (I) and annual (A) costs by PHR architecture for single installation and 80% roll-out.

PHR Architecture	Total costs for single installation ($, millions)		Total costs for 80% of US ($, billions)
	I	A	I	A
Provider-Tethered	2.8	1.2	130	43
Payer-Tethered	2.7	2.1	4.7	2.0
Third-Party	6,600	1,600	21	4.9
Interoperable	3.5	3.5	3.7	1.9

When we integrated the 10-year roll-out period into our analysis, all PHRs demonstrated initial net negative value (Figure 1). The interoperable PHR had the earliest break-even point, by the end of 3 years, followed by the payer-tethered and third-party PHRs by the end of year 4. Provider-tethered PHRs do not break-even point during the 10-year period. Table 6 shows the steady state net value and the minimum number of patients per PHR installation to obtain a steady state net positive value.

Figure 1.

Annual net value over 10-year roll-out period.

Table 6.

Annual steady state value PHR by architecture.

PHR Architecture	Steady State Net Value ($/yr, billion)	# of Users Per Single PHR Installation to Break Even
Provider-Tethered	−29	59,000
Payer-Tethered	11	62,000
Third-Party	11	47,000,000
Interoperable	19	52,000

Discussion

Our initial analysis presents the first assessment of the potential economic value of PHRs to the US. It demonstrates that although to implement any type of PHR throughout the US will require between $4 and $130 billion in initial capital and between $2 and $43 billion in annual support. These expenses, in most cases, will be recouped by the projected $13 to $21 billion in annual potential benefit.

In the cost analysis, each PHR architecture has a similar set of core components. Differences in PHR architecture costs lie in user support and data storage, which may vary for a single installation, due to variable number of users, but at the national level are equivalent since all PHR architectures serve the same national population. Differences in costs also lie with matching services, which are only required by third-party and interoperable PHRs, as well as the number of interfaces that are more numerous for these two types of PHRs. These differences stem from the assumption that these PHRs are not a source of healthcare data themselves, but must interfaced with primary data sources.

The third-party PHR has the highest single installation cost primarily because of the need to build numerous data interfaces to the multiple data sources needed to populate this PHR with data. However, the costs for a single installation are superseded in a national PHR roll-out because of the large number of provider and payer organizations that must each install their own PHR. Therefore, on the national level, third-party PHRs have very good economies of scale, although on a per-installation basis are the most costly, because of the larger number of people that a single third-party PHR is expected to be able to service.

This juxtaposition of the costs to build a single instance of a PHR system and the costs to roll out these systems nationally is also demonstrated through the interoperable PHR. Because this PHR is built around the assumption of interoperability data standards, the initial costs are much lower than third-party PHRs because a relatively small number of interfaces need to be developed and implemented to obtain access to a wide range of data. Also, this PHR is designed to take advantage of healthcare value exchanges in local medical markets, and thus the number of installations to cover the majority of the US population is less than for provider-tethered and payer-tethered PHRs. As with other analyses¹³, this analysis clearly points to the significant value of data standards for use with PHRs.

On the benefits side, even our eight PHR functions demonstrate tremendous potential value, and PHRs could have many more similar functions. There is a trade-off between application functions that are used more frequently and have a lower their impact per use, such as appointment scheduling, versus functions that may be use less frequently but have a higher impact per use, such as CHF remote monitoring. Our analysis also indicates that PHR infrastructure functions themselves could provide up to 1/3 of the value of PHRs and could by themselves cover many of the initial and ongoing costs of PHRs over an extended period.

E-visits, replacing face-to-face visits, have the potential to address a wide range of chronic and acute (non-emergent) healthcare issues, and therefore represent a large area of potential PHR benefit in our model. Because of the diversity of the care needs addressed by this PHR function, significant benefits might be realized using e-visits to replace face-to-face visits. However, the value of e-visits is very dependent on the costs associated with these visits. In our model, we assumed the current standard: that providers are not reimbursed for e-visits. We recognize that to provide value, providers need to offer e-visits, payers need to reimburse them, and the e-visits themselves need to use the provider’s time more efficiently and effectively. E-visits could also provide value to patients and employers by diminishing travel time and decreasing time lost from work. However, these are not direct costs to the healthcare system and were not estimated in our analysis.

Our model also illustrates the value of interoperability between PHRs and EHRs. Appointment scheduling, medication renewals, pre-appointment questionnaires, and sharing of complete test results were modeled in two ways. The first way modeled the data supporting these functions being provided electronically but still requiring manual processing. For example, a PHR appointment scheduling function sending a secure message to a provider’s office that then still needed to be manually entered into the provider’s appointment scheduling system. The second way envisioned data from PHR functions that allowed for automatic processing of the data from the PHR to the EHR, analogous to how several on-line services allow for direct scheduling of airline flights. Although the initial costs of building to a data standard structure are roughly the same as building to a unique, nonstandard data structure, the benefits of a totally standardized and automated PHR function are significantly greater than one that still requires some degree of manual data processing because of a unique, non-standard data structure.

One of the challenges we faced in modeling the value of PHRs, which our model clearly demonstrates, was to think of all of the constituencies involved in a PHR. Our analysis helps identify costs and benefits to payers and providers who currently bear direct healthcare costs. We recognize that many others, especially patients, but also employers and non-healthcare related corporations, may derive significant benefits from PHRs. Benefits may include improved convenience, quality of care, safety, communication, record keeping, and efficiency through the use of PHRs. However, the evidence for hard cost savings and value by these other groups, including patients, has not been demonstrated, and was not included in our model. Additionally, our 10-year installation, adoption, and use estimate may be overly optimistic and will vary by PHR architecture.

Conclusion

PHR systems, although costing billions of dollars to implement and maintain, with even a small set of functions, could provide significant net benefit to the US healthcare system through many billions of dollars in potential cost savings to the healthcare system. Keys to achieving this value include developing and adopting of standards electronic data exchange among PHRs, design of business models that align who is paying for and receiving the benefits from these systems, and deployment strategies that maximize the number of users per PHR installation.