The term Personal Health Record, or PHR, has taken on different meanings, depending on who is talking. Mostly, it refers to a patient portal, connected to a particular data source (such as a physician’s EHR, or a hospital’s system, or a health plan, or an employer), and populated by the data found in that source.The earliest versions of PHRs suffered from low levels of consumer adoption. About the only significant survivor of that “first generation” of PHRs is Microsoft’s Health Vault. The main reason for low adoption experience was largely because such products relied on patients to self-enter the data themselves, or set up the data connections through some sort of (often difficult and unsuccessful) connection that the patient had to undertake.The “second generation” of PHRs (which dominate the landscape now) are pre-populated by the data source they are tethered to. This has enjoyed more adoption than previous attempts, but still has its limitations. Clinical providers (doctors, and to a lesser extent, hospital systems) can enroll patients in their portal (their “PHR”) and encourage patients to use it within the settings of care (e.g., during a visit to the office). Such portals offer patients some important value – seeing their medications lists, lab test results, and ability to securely communicate with the office, including scheduling or rescheduling their upcoming visits.

Such an approach was a step forward when few providers had EHRs, so that such connectivity was a rare luxury that distinguished one provider from another. However, that has changed. Most physicians in the U.S. now use some form of EHR in their practice, and each one pushes outpatient portals. Except for those people seeking all their health care from a single integrated organization that uses a unified, enterprise EHR (e.g. Kaiser), most other people seek healthcare from a variety of clinicians, and each one uses a different system. From the patient’s perspective, this results in a myriad of logins that need to be kept track of, each one giving a single-source slice of insight into a segment of their overall health story. This is the limitation of the current stage of PHRs. If anything, it exposes the fragmented nature of health data to patients. Such fragmentation of data is a vexing dilemma on the provider side, and is a similarly confusing jumble from the consumer/patient side.

 What about adoption?
The current “second generation” of tethered PHRs has enjoyed more adoption than the prior “first generation” of disconnected products. Providers encourage signups when patients either visit their office or enroll with them (if that is the model) – Meaningful Use of EHRs encourage physicians to do this. And, depending on the value patients see in their PHR , and depending on how pro-active clinicians’ offices are in encouraging patients to use their portal, some subset of those people will actually visit their PHR. In fact, Stage 2 of Meaningful Use requires that at least 5% of a practice’s patients actually sign in and use their PHR at least once during the measure year.

Are these PHRs easy to use? In looking at the PHR portals offered by the various major vendors at the recent HIMSS conference, the sense I got was that most of these EHR-based patient portals looked very much like their “parent” EHRs. Same look, same feel, same navigation style – the good, the bad, and the ugly of it.

Mostly, the kinds of data exposed in these portals is what Meaningful Use has required: problem lists, medication lists, allergies, immunizations, lab results, visit summaries, and health education links. And the way these data items are presented are more clinician-familiar and not especially consumer-friendly.

Other tethered products
Besides physician EHRs, other patient portals have been rolled out from virtually all other elements in the healthcare ecosystem: insurance plans, employers, hospitals, etc. Adoption of these, however, is minimal. Why? The primary point of contact between consumers (when they become patients) is with their physicians, not their employer or their health plan. Where people look for their health information is their trusted physician relationship. What people expect when they query their health plan is benefit and claims payment information. And with their employers, mostly it is to check in on employee wellness programs (if they exist at work).

In addition, Meaningful Use encourages physicians to engage patients electronically, and so the physician-EHR-based PHR portal will be encouraged in the settings where one receives care. Such incentives don’t apply to health plans or employers.

Whence forward?
The “third generation” of PHRs is a technology currently in its infancy. These products would be consumer-facing PHRs that are independent of hosting EHRs, but can tether to them seamlessly. They act like the tethered “second generation” PHRs do, except they can connect with any and all EHRs that a given patient’s physicians use. In short, such products can become a unifying dashboard connecting all the participants in an individual’s health caregiving team, solving the interoperability challenges in the background. They would be products that consumers can sign up for directly, even share their enthusiasm socially and virally, so that anyone can sign up themselves (without having to wait to be given login credentials one-at-a-time by each physician’s practice).

Such a vision of a “universal PHR” sounds like a re-invention of the original “first generation” products. Why would the anemic adoption experience seen with the first generation be any different with this new concept? Two things have changed: (1) the first generation of PHRs came at a time when few physicians had EHRs in their practices, so the data sources were mainly hospitals, labs and health plans – this is no longer the case; (2) the issue of interoperability has evolved considerably, largely because of efforts of the ONC around Meaningful Use, as well as the emergence of Health Information Exchanges and the peer-to-peer communication protocols of the Direct project.

So, let’s say that we are able to successfully build a PHR product that consumers can sign up for themselves, has public areas that allow for the voluntary social sharing of successes with communities of like-interested people, and has private areas that are automatically populated by the EHR data sources that a given patient connects with – the doctors, hospitals and health plans that can supply all their data effortlessly (from the consumer’s perspective). Such a thing has yet to be built, but we can see it from here. How, then, can we create the kind of adoption enjoyed by consumer health e-commerce sites (with adoption in the millions of users, not just hundreds or thousands)?

It’s a circular dilemma – getting the critical mass of users for it to ignite and become viral. Rule of thumb: for something to become viral, it needs over a million users. The size of the network becomes a “community” value (Metcalf’s Law). However the product itself needs to have consumer-perceived value built into it in order to attract further growth. So how do we break in to this?

Different on-boarding approaches
There are several approaches to building an independent PHR that will catch the needed consumer adoption to ignite into a truly important phenomenon. Four general approaches seem to be emerging, which might be worthwhile reviewing here.

1. Build a PHR as one of several “nodes” on an interoperability platform. Connect hospitals, health plans, EHRs and a PHR onto a single connected platform. An example of this approach is InteliChart. This has potential, but still confines the PHR to the scope of the platform. Such an approach has the same dilemma of other HIEs – the value is determined by the number of subscribers to the HIE hub (the “platform”)
2. Build the PHR as an outgrowth of patient sign-ups for their insurance plan. If consumers are given insurance plan “smart cards” with a prompt to go online in order to activate the insurance card, there is an opportunity to create a PHR (initially filled by health plan data) that can dynamically be added to with each encounter, and can be an updated Past Medical History for doctors at the point of care (replacing the clipboard). An example of this approach is LifeNexus (by way of disclosure, I am helping them build their PHR). Such an approach, where the onramp to an independent PHR is from the payer side, may provide enough network effect to create viral spread if the enrollment is high enough and if the product allows for self-signup options down the road, as well as EHR connectivity in subsequent iterations.
3. Build a secure peer-to-peer healthcare provider platform, where doctors, hospitals, home health agencies, ACOs, and other such coordinated (but scattered) delivery networks exist, and then expand this connectivity platform to include patients. An example of this approach is GroupMD. By starting with patients who are served by a such a care delivery platform, this can evolve into an offering that rapidly becomes a self-service patient-driven (consumer-driven) independent PHR – one which can request connection from the patient side to the doctors on the peer-to-peer platform. In fact, patient requests can drive adoption of the provider platform (rather than the other way around). Authentication of the patient is key here, which (from what I have seen in talking with GroupMD) is a technology that has evolved to significant sophistication. There is considerable potential in building the “universal PHR” from the provider-side onramp. After all, patients look to their doctors first (not their health plans) for their trusted health information.
4. Build the independent PHR from scratch, and launch it as a consumer health e-commerce application. Connect with other consumer health web sites (which already enjoy enrollment in the tens of millions) and grow the PHR organically that way. Provide a mint.com-like way of connecting with EHRs from the consumer side. With this approach, there is no specific onramp from the payer side, nor from the healthcare provider side, but instead it comes from the consumer health e-commerce side. There is potential in this approach too, but that may take longer to gain traction.

Conclusions
Today, most “PHRs” are tethered to a given data source, such as a physician’s EHR. They look a lot like the EHRs that gave rise to them. Though an advance from the previous generation of disconnected PHRs, there is still the problem of “one EHR, one PHR” and the resulting chaos of too many logins. The next generation of independent, universal PHRs that can act as dashboards to all the different EHRs that a patient’s doctors use, is starting to emerge.

Several approaches are being tested as ways to get enough critical mass for an independent PHR to be successful. Some try to tie the PHR into a centralized hub – a PHR as a “node” in a health information exchange. Others try to onboard from the payer (health plan) side, and move to build a universal PHR from that incoming direction. Still others are looking to onboard from the provider side, expanding the peer-to-peer conversation out to the patient, and building a self-service, self-signup PHR from that direction. And still others are looking to build something “from scratch,” hooking in to consumer internet adoption (and thus from outside traditional healthcare altogether), connecting to EHRs from that direction.

Which approach (or approaches) will be successful remains to be tested in the marketplace. Regardless, it is exciting to see a general realization of what the next generation of PHRs needs to be. It is also exciting to watch the different ways of getting to that ultimate vision emerge and evolve. The next 6-12 months will be quite interesting indeed in this sector of the Health IT space.