A Patient-Centric Taxonomy for Personal Health Records (PHRs)

Abstract

Today, the nascent field of personal health records (PHRs) lacks a comprehensive taxonomy that encompasses the full range of PHRs currently in existence and what may be possible. The Center for Information Technology Leadership (CITL) has created a taxonomy that broadly defines a PHR as having both an infrastructure component, which allows for data viewing and sharing, and an application component, allowing for selfmanagement and information exchange. The taxonomy also accounts for different PHR architectures – provider, payer, third-party, or interoperable. This comprehensive taxonomy may help to define the field of PHRs and provide a framework for assessing PHR value.

Introduction

The personal health record (PHR) is a newcomer to healthcare. As a result, the definition of a PHR is still evolving. For some, it is strictly a tool to view one’s clinical data in a provider’s electronic health record (EHR). To others, it is a place to store one’s personal health and wellness data. And yet others are looking at PHRs as an enabler of patient-centered health care – a system to support a variety of functions designed to monitor and manage one’s health.

This paper describes CITL’s work developing a PHR taxonomy as part of a large value-based technology assessment of PHRs. In any emerging health information technology, a taxonomy is important to help conceptualize the field. CITL has a history of developing taxonomies for other emerging health information technologies^1–3. One of our goals in developing a PHR taxonomy is to structure our overall value assessment of PHRs. However, a well designed taxonomy can also aid in other research and public policy endeavors.

What is a PHR?

A PHR is commonly defined as a patient’s own medical record, which is either provided by a preexisting record, such as a provider’s EHR or a payer’s claims database, or manually entered by the patient or a patient proxy. PHRs are often discussed as a means to increasing patient involvement in healthcare⁴. Patient engagement is seen as crucial to six of the ten rules, proposed by the Institute of Medicine⁵, for improving healthcare quality⁶.

However, there is little consensus on what constitutes a PHR. The Markle Foundation describes a PHR as:

“...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.”⁷

The Markle Foundation⁸ has also proposed a framework for assessing PHRs along three dimensions: access medium (desktop-based PHRs, web-based programs, and portable devices); data (patient-sourced and professionally-sourced); and, functions (both the viewing and sharing of patient’s core health information and may include content or transactional functionality).

Others have proposed definitions of PHRs as well. Matthew Kim and Kevin Johnson⁹ envision PHRs as simply data repositories that store core health information from both providers and patients, and allow this information to be reviewed or sent to outside users. While this definition is more restrictive than the Markle Foundation’s, it is a good example of a common definition of a PHR as, essentially, a patient-controlled data repository.

Tang et al.¹⁰ envision PHRs as both the personal data and tools that allow the patient to manage their health more independently, such as remote monitoring for chronic disease management and related content to support patient decision making about their care.

In addition to these definitions, there are many other descriptions and examples of what constitutes a PHR such as¹¹: institutional/integrated delivery network provider portal; individual provider portal; untethered – universal serial bus (USB)-, desktop-, and personal data assistant (PDA)-based; populated from claims data; population oriented; condition oriented; service oriented; and health 2.0 sites.

Proposed Taxonomy

CITL’s taxonomy takes a different approach. Rather than starting with the data source or medium of the PHR, we describe PHRs starting from the perspective of the patient. A PHR is meant to empower the patient in their own healthcare. In order to do so, a PHR needs to provide the patient with not only the ability to view and act upon their data but also to interact with their healthcare providers, payers, and benefits managers. After a comprehensive literature review and consultation with our advisory board, we found a clear delineation between the functions and architecture of the various PHRs currently evolving in the marketplace.

For PHR functions, there was a clear delineation between infrastructure and application components of a PHR, as shown in Figure 1, to support multiple types of interactions with multiple parties and to decouple the data source from the application, which creates a more flexible and customizable system. The arrows represent the direction of data exchange.

Figure 1.

Representation of CITL PHR Taxonomy

The PHR infrastructure consists the functions that allow the patient to store and view their health information. It consists of two main components, information collection and information sharing. Information collection components are the functions of a PHR system that “pull” and aggregate data from multiple external data sources (e.g., payer, provider) and data types. Data types consist of clinical data (e.g., medications, labs, images), administrative data (e.g., claims, insurance), and self-entered data (e.g., over-the-counter medications, exercise and diet). Information sharing components are the functions of a PHR system that allow patients and external parties to view health information in a PHR, acting as a conduit between different data sources to bring data into and out of the PHR. The infrastructure component is protected by user authentication protocols, including both password-encryption of data, as well as application programming interfaces (APIs) through which external parties can view and access data in the PHR.

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 exchange data with others regarding their health and well being. The application components are divided into two categories: information selfmanagement and information exchange. Information self-management components are functions within a PHR system that enable patients to learn about, monitor, and/or manage their own health and the health of others (i.e., children, dependent adults). These functions use all types of data stored in the PHR, from blood pressure measurements to claims data to provider contact information. Information exchange components are functions within a PHR system that allow patients to engage in two-way data exchange transactions with others regarding their health or healthcare, such as e-visits. There are a nearly limitless cadre of functions that will empower patients to take control of their health and healthcare.

CITL defined the architectures using four dimensions: methods of data incorporation, types of data systems, number of data sources, and type of data exchange.

Methods of data incorporation are the means by which information of any kind is entered into a PHR – typically through either automatic, electronic population or through manual data entry. The source of data often determines the method of incorporation. There are three primary types of data sources: professionally-sourced, patient-sourced, and patientrekeyed. Professionally-sourced data consists of any clinical (e.g., provider, laboratory) or financial (e.g., payer, pharmacy) data provided by entities responsible for the delivery and administration of healthcare. These data are usually entered into PHRs automatically via data exchange between different types of healthcare information systems or interfaces between different applications. Patient-sourced data is any data entered by the patient that is not provided by a professional organization, such as a patient diary, over-the-counter medication lists, or medical device data. Patient-rekeyed data consists of any data that is provided to the patient by a professional source that is then typed into the PHR by the patient manually rather than uploaded electronically.

CITL used professionally-sourced data as the first dimension of its architecture taxonomy. Patientsourced data was considered to be available by all types of architectures, and was therefore not useful in distinguishing PHR architectures. Patient-rekeyed data was excluded as it significantly decreases value of the information in the PHR due to the possibility of data entry errors and the significant workload on patients.

For types of data systems, CITL considered three types of data systems within professionally-sourced data: clinical, administrative, and mixed. Clinical data is information from a healthcare provider’s electronic health record (EHR), such as problem lists, test results, current medications and appointment schedules. Administrative data is information from a payer organization’s data system, such as information found in evidence of benefit statements or claims on cost of care, diagnoses, procedure codes, encounter dates, and coverage information. Mixed data consists of a combination of these two data sources, creating a more complete and robust data set.

A PHR has either one or multiple data sources. A PHR with one data source considers a single connection to a data silo. A PHR with multiple data sources considers the connection to any number of systems and applications.

There are two types of data exchange between a PHR and other healthcare information systems, machineorganizable and machine-interpretable. Machineorganizable, or manual, data exchange is a situation where data is electronically sent from one organization to another but no standards are used to structure this transmission; this requires human involvement to import the data into the local data systems^12–13. In addition, the recipient of the data cannot update, correct, or otherwise respond to the originating system. An example of machineorganizable data exchange is the situation where the PHR system can import data from the physician’s EHR system yet patient’s notes and corrections on the PHR to the data cannot flow back to the EHR from the PHR. Another example is where a PHR system can send an electronic appointment request to a physician’s office practice management system (PMS) yet the PMS does not acknowledge nor confirms the appointment electronically, requiring the patient to manually key in the appointment into the PHR. Machine-interpretable, or automated, data exchange allows the PHR and any external data sources to exchange data electronically in both directions without manual intervention; this is enabled by data standards.

Discussion

CITL’s taxonomy provides advantages over existing PHR descriptions of definitions in a number of ways. First, the field of PHRs currently has many variations of what constitutes a PHR. The initial PHR was strictly a patient-accessed view into an EHR or data entered by the patient. A PHR application, sometimes referred to as a personal health application, can provide a patient with the ability to actively learn about and manage their healthcare and may or may not utilize the data from healthcare encounters. However, both are lacking in that they need each other in order to truly empower the patient and effectively manage their health and/or healthcare. Therefore, we only consider those applications that utilize information in the underlying data repository or its ability to interact with other healthcare entities as part of a PHR. The specific application or infrastructure functions that reside in a PHR do not define what a PHR is, only what it currently does. The PHR needs to be defined by something at a higher level, which we have provided here.

As an example, the largest PHR currently in existence is My HealtheVet (MHV), provided by the Veterans Administration. MHV provides a wide range of functions, from ordering prescription refills to storing personal notes. The patient’s own health record is the hardest part to access, and requires the patient to authentication themselves with their PHR in person. In addition, Microsoft’s HealthVault fits our definition of a PHR. It provides both the infrastructure functions and is in the beginning stages of adding application functions.

In addition, a taxonomy needs to have mutually exclusive categories to be effective in providing a framework for understanding the development and capabilities of an emerging technology. Our taxonomy focuses on the source of data provided and not the entity that ultimately provides the user interface to or facilitates the exchange of that data. For example, IDN-level data could be provided by the IDN itself or by an outside third party. Categorizing this hypothetical PHR as an IDN PHR would be misleading.

Finally, all previous definitions of PHRs started at the source of the data, rather than the patient. As a result, they have ignored the specific functionalities that PHRs must have to support data collection, aggregation, sharing, exchange, and management of health and wellness. The source of the data and functions most useful to patients is undoubtedly important in determining how to best design, build and finance PHRs. However, PHRs are ultimately about patient empowerment, and therefore a framework should start from this point. The data source may initially define the types of specific functions that the PHR can have (e.g., a providersourced PHR will not have information on choosing the appropriate healthcare coverage plan), but ultimately should not determine whether the patient has the tools to gather, share, self-manage, and exchange healthcare information.

Limitations

There are limitations to this approach. Our PHR taxonomy does not include the communications medium used for accessing a PHR; we only consider web-based approaches. The portable device medium was excluded from our analysis as research has found security issues with using USB drives¹⁴. The desktop-based PHR would require a patient to store their own data locally, yet to share that information electronically, they would have to either host a web server or carry around their data on a portable device. The web server approach would require back-ups and 24-hour connectivity, which is not cost effective nor necessarily desirable for an individual. The portable device transport of this data has essentially the same limitations as USB-based PHRs. Therefore, we believe the web-based approach to PHRs is and will be the preferred modality. In addition, the desktopbased PHR would have difficulties establishing that the data provided is accurate, leading to issue of acceptance by outside viewer such as physician.

Our taxonomy does not consider hybrids of these models. For example, an IDN could provide its own data as well as payer data. Since the types of data are mixed, it is not truly an aggregator model because some of its data already resides in the IDN outside of the PHR. While the interoperable PHR architecture would solve these problems, it is quite clear that the interim will consist of many of these hybrid PHRs. However, we believe that the basic functions of the PHR, as we have defined them, will not change substantially during the creation of such a hybrid.

In addition, there are legal implications for each type of PHR. HIPAA restrictions apply to data stored and provided by a healthcare entity and their business associates; it is unclear how these restrictions apply to a third-party or other aggregator models. We do not address these issues in our taxonomy, though the separate classifications used here could serve as a framework for drafting patient privacy legislation for PHRs by delineating the different types of PHRs and their relationship to the data they provide.

Conclusion

CITL’s is the first patient-centric taxonomy for PHRs. In looking at the specific functionalities that a PHR can have to support patients and their caregivers, a patient may better see how they will benefit from the PHR, which will help spur adoption. Our PHR framework provides a mechanism for defining and ascribing the costs and benefits of PHRs, both for today and in the future. We outline the key components that will ultimately determine the sources of possible value from PHRs, and to whom PHR value accrues.

Figure 2.

PHR Architecture Taxonomy