A Cost Model for Personal Health Records (PHRs)

Abstract

Personal health records (PHRs) are a rapidly expanding area in medical informatics due to the belief that they may improve healthcare delivery and control costs of care. To truly understand the full potential value of a technology, a cost analysis is critical. However, little evidence exists on the value potential of PHRs, and a cost model for PHRs does not currently exist in the literature.

This paper presents a sample cost model for PHR systems, which include PHR infrastructure and applications. We used this model to examine the costs of provider-tethered, payer-tethered, third-party, and interoperable PHRs. Our model projects that on a perperson basis, third-party PHRs will be the most expensive followed by interoperable PHRs, and then provider-tethered PHRs and payer-tethered PHRs are the least expensive. Data interfaces are a major cost driver, thus these findings underscore the need for standards development and use in the implementation of PHR systems.

Introduction

A key factor in assessing the value of health information technologies is to determine the costs of these systems. PHRs are a rapidly evolving set of healthcare technologies with several alternative approaches in the nascent PHR marketplace. No published cost models currently exist for PHRs. As part of a larger study to estimate the potential value of PHR systems, the Center for Information Technology Leadership (CITL) developed a sample PHR cost model. This model assumes that there is an underlying PHR infrastructure that can host any number of PHR applications. In this paper we present preliminary findings from our PHR cost model and provide cost estimates for four different approaches (provider-tethered, payer-tethered, third-party, and interoperable) to offering PHR systems.

Methods

CITL has a long history of building cost models to inform the value assessment of healthcare technologies. ^1–4 To develop our PHR cost model, we first clearly defined a PHR for our analysis. 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.”⁵

Using this definition, we conducted a literature review to see if any work had been published on PHR costs. The search did not yield any solid published estimates of PHR costs.

After surveying the literature and discussing the current state of PHR systems with experts, CITL designed a PHR cost model that includes two basic components: infrastructure for data storage and access, and applications that support different types of clinical and administrative functions. Accordingly, we developed approaches to estimate both initial and annual maintenance costs for PHR infrastructure and applications. The methodology developed for each element of our cost model is described in detail below.

Infrastructure Cost

We have defined a PHR infrastructure as the functions that allow a patient to store and view their health information. Infrastructure functions allow patients and external parties to view health information, that “pull” and aggregate data from multiple external data sources (payer, provider, pharmacy benefits manager etc.), as well as information from the patient and health monitoring devices. Some examples of PHR functions that rely solely on PHR infrastructure include sharing test information, creating complete medication lists, and supporting private and secure access to data and applications within the PHR.

Another feature of the infrastructure part of our cost model is embedded secure messaging (secure Internet email), which can come in several forms. Based on our literature review this feature was seen as an essential part of a PHR, and thus included in the infrastructure. For the purposes of this model, we envisioned messaging as a two part process. For incoming messages, users would first receive a message notification in their personal email notifying them that they have a message in their PHR “inbox”. After receiving this notification, users would login to their PHR over secured channels to retrieve and respond to the actual message. Similarly, users would need to be logged into their PHR in order to send messages to their providers over secured channels. The security embedded in the infrastructure provides the privacy and security for the messages. The infrastructure component required for this type of messaging is a message server. We assumed a message server would meet the following requirements:

• Accepts a user name and a message

• Looks up the user’s public email address using the PHR’s user management functions

• Sends the user a notification that a message is waiting, and asks the user to log into the PHR portal

• Stores the message in the user’s PHR mailbox

• Allows the portal to check if there is any message waiting for the user (when user logs in to the portal)

• Displays the message as requested by the user

• Allows the user to send messages to other users on this PHR system

For most of the other components of our PHR infrastructure, we adapted the regional health information organization (RHIO) cost model developed by the eHealth Initiative (eHI) ⁶. We used the eHI cost model estimates for some of our components because it aligned with our definition of PHR systems. The infrastructure components adapted using the eHI model approach included: data centers, client user authentication and authorization, Internet connectivity, user interfaces, user support, record matching services, and data storage.

We defined these components as follows. A data center is the physical space that houses the servers, network infrastructure, and related hardware and all other application infrastructure required for a PHR. Client user authentication and authorization includes user login security as well as access controls. Internet connectivity is the cost required for the PHR system to provide data exchange with healthcare stakeholders and web-based access to its users. User interfaces are the displays that a user sees when they login and navigate the site.

User support depends on the size of the PHR. User support consists of the help desk and on-going training provided to PHR users. In order to determine the cost of user support, CITL obtained an estimate of the number of user support contacts per user of a pre-existing PHR system.⁷

Since PHRs combine disparate sources (i.e., combining provider data from multiple EMRs, payers, labs, imaging centers), record matching services are needed. Any PHR will need interfaces to external applications to retrieve patient data located across disparate ancillary systems. Our analysis considered five types of interfaces (provider, payer, lab, radiology, and pharmacy). For provider-tethered and payer-tethered PHRs, these interfaces are minimal, estimated to be only 20% of the full cost of building an interface from the beginning because they are accessing their own data in an electronic format. For third-party PHRs, many interfaces are required because they do not have access to clinical or administrative data without interfacing to a provider or payer system. For interoperable PHRs, only one data interface would need to be created for each type of interface because all data and transactions are standardized between PHRs and other healthcare stakeholders (e.g., lab, pharmacy, payer, etc.).

This cost model considers the PHR data repository as the primary data storage for different PHR systems. The PHR data repository consists of all data entered by users, data from messaging, and pointers to the all primary data sources. Additionally, third-party and interoperable PHRs require additional storage capacity for clinical and administrative data. This repository is necessary since neither type of PHR is assumed to have access to healthcare data, unlike provider-tethered and payer-tethered PHRs, which have existing data warehouses. The data storage consists of the actual data as opposed to pointers to ensure constant access to the data.

Application Cost

A PHR application is any function within a PHR system that allows patients to learn about, monitor, manage their own health and the health of others, and to engage in two-way data exchange transactions with others regarding their health and well being. PHR applications for any healthcare or wellness activity are feasible, and may support clinical and administrative types of functions. For example, PHR systems could include a health maintenance function and an insurance verification function.

Purchasing costs of commercial PHR applications are not reported in the literature nor are they publicly available, typically because of proprietary pricing models and differences in scalability and volume pricing. Therefore, our cost model estimated the average cost of a proto-typical web-based PHR application using the development cost of representative clinical and administrative PHR applications. We interviewed health IT software system developers^8–10 to estimate costs for the PHR applications included in our model. The number of applications that could be included is large, however in our cost model we only modeled the development costs of one generalized PHR application. We realize that PHR systems will have multiple applications to support clinical and administrative functions whose development and maintenance costs may differ depending upon many factors (e.g. local labor costs, complexity of interface, expertise of development staff).

The development cost was derived from estimates of person months per application, assuming a cost of $100,000 per programmer¹¹ per year including benefits. Development costs included the cost to design, develop, build, and test the PHR application. We then assumed that management and support costs were equivalent to 100% of the development cost, and core knowledge management costs were also 100% of the development costs. Total application costs were a combination of these three cost categories.

Acquisition and Annual Costs

For both the application and infrastructure cost estimates, we projected the acquisition cost as well as the annual cost. Because IT investments often require a large initial investment it is important to distinguish the often significant differences between acquisition and annual costs. Annual costs include: operations and maintenance (O&M), user support, remote hosting of storage, and software licensing fees for matching services. In our model, we estimated that yearly annual costs would be approximately 20% of the acquisition cost for those components that did not already have an annual cost. This estimate is applied to both the application and infrastructure costs.

Architectures

We combined the components of our cost model to represent four different types PHR architectures: provider-tethered, payer-tethered, third-party, and interoperable PHRs. For each architecture we estimated costs for a single installation. For the first three architectures, we are not assuming interoperability between separate and distinct PHRs, i.e., a payer-tethered PHR is only for one payer and does not communicate with other payer-tethered PHRs. The interoperable PHR does not currently exist. However, because other analyses suggest that fully interoperable health data exchange stands to provide significant benefits, we decided to model the costs for this approach to PHR systems as well ³.

To compare costs across all architectures, we assumed a baseline user pool of 1,000,000 users per architecture. The general trend of which architectures are more or less costly is the same regardless of the size of the baseline user pool. We recognize that in real-world circumstances, different types of PHRs will be adopted by different sized user groups, which will in turn impact total PHR cost. However, using a similar population size allows us to drill down on the components that drive the costs of different PHR architectures.

Results

Infrastructure Costs

For our cost model, we developed one-time acquisition and on-going annual costs for all infrastructure components based on PHR architecture (Table 1). Significant cost drivers are highlighted in italics. The costs for these identified components are an order of magnitude greater than for other cost components. To understand the costs per user across architectures, we took the total cost and divided it by the 1,000,000 users per architecture. We then projected the estimated acquisition and annual cost per user by architecture.

Table 1.

PHR single installation total costs acquisition and annual costs by architecture.

	Provider -Tethered ($)		Payer-Tethered ($)		Third-Party ($)		Interoperable ($)
PHR Component	Acquisition	Annual	Acquisition	Annual	Acquisition	Annual	Acquisition	Annual
Clinical Data Repositories	$0	$0	$0	$0	$400,000	$100,000	$400,000	$100,000
Client User Authentication	$95,000	$14,000	$95,000	$14,000	$95,000	$14,000	$95,000	$14,000
Core Data User Interface	$450,000	$90,000	$450,000	$90,000	$450,000	$90,000	$450,000	$90,000
Data Center	$1,700,000	$930,000	$1,700,000	$930,000	$1,700,000	$930,000	$1,700,000	$930,000
Doctor Matching	$0	$0	$0	$0	$0	$57,000	$0	$57,000
Interfaces	$40,000	$8,000	$20,000	$4,000	$6,600,000,000	$1,300,000,000	$250,000	$50,000
Medication Matching	$0	$0	$0	$0	$0	$17,000	$0	$17,000
Network Connectivity	$0	$1,000	$0	$1,000	$0	$1,000	$0	$1,000
Patient Matching	$0	$0	$0	$0	$67,000	$125,000	$67,000	$130,000
PHR Data Repository	$0	$25,000	$0	$25,000	$0	$25,000	$0	$25,000
Results Answer Matching	$0	$0	$0	$0	$17,000	$15,000	$17,000	$15,000
Results Name Matching	$0	$0	$0	$0	$0	$460,000	$0	$460,000
User Support	$0	$2,700,000	$0	$2,700,000	$0	$2,700,000	$0	$2,700,000
Secure Messaging	$50,000	$10,000	$50,000	$10,000	$50,000	$10,000	$50,000	$10,000
Total Cost	$2,300,000	$3,800,000,	$2,300,000	$3,800,000,	$6,600,000,000	$1,300,000,000	$3,000,000	$4,600,000
Single Application Cost	$450,000	$90,000	$450,000	$90,000	$450,000	$90,000	$450,000	$90,000
Total Cost w/Application*	$2,800,000	$3,900,000	$2,800,000	$3,900,000	$6,600,000,000	$1,300,000,000	$3,400,000	$4,700,000
Cost per user**	$3	$4	$3	$4	$6,600	$1,300	$3	$5

^*Numbers may be off due to rounding

^**assuming one million users

Application Costs

Based on our approach, we estimated that the average software development cost for a proto-typical PHR application or service was $450,000. This was based on an estimated design, develop, build, and testing average cost of $150,000. This estimate was then multiplied by 300% for management and support costs, as well as core data development costs.

Discussion

Our PHR cost model provides an in-depth analysis and estimate of PHR costs. It models infrastructure and application costs, as well as acquisition and annual costs, for four different architectures. The components of our cost model can be combined in numerous ways to estimate the costs of various PHR business models.

Infrastructure

Our analysis of costs demonstrates that specific infrastructure components are the major drivers of costs for different architectures. The differentiating factors when user pools are similar across architectures are the interfaces, and the matching services.

Data interface costs vary the most across PHR architectures. These costs are minimized for providers and payers since they have access to pre-existing data warehouses and therefore have lower interface costs. This is not true for third-party PHRs, which have no data inherent for a PHR and must invest heavily in interfaces to obtain data. Also, the need to maintain numerous interfaces creates the significantly high cost in interfaces for third-party

PHRs. Though these costs are high it is important to note that third-party PHRs could feasibly support more types of applications across a larger population since they interface with many distributed data sources. For the purposes of this analysis we artificially created a comparison of one million users per architecture, however if a third-party PHR is only servicing one million members it is unlikely that it will connect to every single large provider group in the nation due to the high cost of interfaces.

For annual costs, user support accounts for the second highest cost across all PHR architectures. In this scenario, user support is equivalent across all architectures, but user support will most likely comprise a significant portion of annual costs among third-party and interoperable PHRs because of the larger number of patients that each installation of these systems is expected to support

Applications

The number of applications that can connect to the underlying infrastructure is potentially large, provided that the data types needed to enable a given application are accessible through the given infrastructure. For example, a variety of chronic disease management applications could connect to and share the same infrastructure.

Building to data standards enables data interoperability³, which in turn facilitates the free exchange of data and eases data processing. Our cost model considers the cost as equivalent whether applications are built to a data standard or not. The differences in building to a data standard versus not will impact the exchange and reusability of the data. Improved processing of data, and information exchange, is a result of using data standards in system design.

Software development and annual costs are scalable and this has important implications. For example, one smoking cessation application could be used for the entire nation or hundreds of different smoking cessation applications could be developed independently at hundreds of times the cost. However, the benefits derived from broad use of either a single or multiple smoking cessation applications would be the same.

For certain applications, the total application cost will include more than just the software creation cost. For example, a congestive heart failure (CHF) management application may require certain hardware devices (digital scales) to accompany the web application. The cost of these devices is generally no more than hundreds of dollars per patient. However, if many patients require these devices, the costs could significantly impact the total cost for a PHR application. The costs of these scales was included in our total cost model, but not included in the average application development cost.

Our analysis considers PHR infrastructure and applications as two distinct components in a PHR system, with the acquisition and annual infrastructure costs being significantly greater than the application costs. This analysis points to the value of developing a common PHR infrastructure based on interoperability standards upon which numerous PHR applications could be built. This approach would greatly reduce the costs of PHRs.

Architectures

In comparing the different PHR architectures (Table 1), it is interesting to note that the annual per person cost of an interoperable PHR is still higher than provider-tethered and payer-tethered PHRs because of the cost of a clinical data repository and the costs associated with collating multiple data sources using matching services. As expected, the third-party PHR is the most costly per person mainly because of the number of interfaces required to connect to disparate data sources. Though the third-party and interoperable architectures are more costly, they address data portability and the issue of a patient having multiple providers and health plans over their lifetime.

While all sponsors view PHRs as a means to empowering consumers and, hopefully, to controlling healthcare costs, the motivation for different PHR sponsors to enter this marketplace can be significantly different. For example, some companies moving into the PHR space, such as Microsoft and Google, view PHRs as a new line of business as well as means to “flatten the curve” on their enterprise’s own healthcare costs. Therefore, third-party business models and interests in the cost of PHRs will be different than providers and payers who already have significant costs invested in the healthcare system. Understanding the costs associated with each PHR architecture is imperative to assess PHR cost-benefit as well as the larger the business case for PHRs. This PHR cost model provides a tool for researchers, policy makers, PHR developers, and others to help assess PHR costs.

We recognize that an interoperable PHR is an idealized projection. However, it is important to understand the costs associated with this type of PHR because we believe it represents the optimal scenario for PHRs. Although the costs for interoperability are high research indicates that tremendous benefits will accrue from widespread adoption of data standards.³

Conclusion

Value-based models of health IT cost are an important part of understanding the costs of novel applications in healthcare. This understanding is critical for developing successful business models and understanding potential value. Because no cost models for PHRs currently exist, we believe this cost model will help define the PHR marketplace, explore PHR business models, and guide PHR investment decisions.