Last Week I had the pleasure of attending the Partners for Interoperability event held by HL7 International at the Kaiser Center for Total Health in Washington DC. The event was aimed at C-level executives who have an interest in achieving interoperability through standards in the US, and was well attended by Pharma, providers, payers and vendors.

During the clinicians breakout the ever-present question of the personal health record arose. As I listened to the discussions for and against — the comparisons to the United Kingdom’s failed efforts; the history of the PHR in America and the European perspective — it became clear that the camps could be boiled down into two basic concepts that were diametrically opposed.

The first point of view was that nobody really needed a PHR until they were sick, and even then they were unlikely to sustain their use after the event unless they had a chronic condition.

I was the only person in the room who actually had routinely made use of a commercial package for any period of time, and even then my main use was to track prescriptions to ensure my providers mistakes were minimized.

In contrast, others felt that the main reason for the failure of the PHR was that the killer features had not yet been found, so consequently the market had no reason to seek out the software. Nobody advanced a list of said features, but it was apparent that data exchange was a key component of building the commercially successful PHR.

Data exchange is important because looking for a PHR is like looking for a buffalo on the plains — where you find one, you will find many, and the herd is more important than the single buffalo.

In my opinion, the PHR should have a broader conception than just a series of killer features in a single app.  It’s a collection of systems, not just one portal into an aggregated record, and the basis is a set of data distributed across a platform, not a view into a single EHR, nor a view into an aggregated set of EHRs. The most effective PHR is not one app; it’s the platform that allows for suites of apps to be built that share information about your health and provide actionable data that helps you manage your conditions.

FHIR will be the transport that links these apps into a coherent whole.

This perspective plays well in a generationally separated market where millennials have completely different expectations of a PHR than other groups such as seniors or baby boomers. Seniors often have caregiver children who would like to participate in their care and are reasonably technologically savvy. They typically have three or more concomitant conditions, and a complex raft of medications and procedures or appointments to track. Millennials tend to have considerably fewer health conditions and may prefer an uber style app that gets them in with a doctor at a known rate even using surge pricing if necessary.

In either case, my point is that generations have differing perspectives, and considerably different needs of their PHR that should be serviced by apps that are directly targeted at them. As they move through their lifetimes and the layers of health needs that come with aging, they may find themselves migrating throughout this app pool.

Today our healthcare data resides everywhere, and yet the majority of it is available to the patient nowhere.

The pull model of FHIR plus OAuth authentication provides the first real chance to liberate our data, the chance to “pull” down the walls that have surrounded it, and allow third parties to synthesize the basis of a real PHR.

To do this I believe we need patient registries. These would allow a system to publish that a patient has been to a given location and has data present at that FHIR access point (with the patient’s consent).  Apps could then simply pull from a known registry to find all the data repositories, and filter to find the data that they really need, rather than asking the patient to input an interminable list of institutions each time they start using a new app. The registry itself would simply be serving a bundle of FHIR resources, and would be protected by OAuth.

Without registries FHIR interfaces are discoverable only through manual configuration; a simple, but tedious process if we want a rich ecosystem of apps; each of which must be setup by the patient and/or their caregivers.

Who would operate these registries?  This is a perfect use case for initiatives such as the Sequoia project, Commonwell, or even HIEs who could monetize the service by charging app makers a small per-patient fee to  join the FHIR discovery network.

If this model can be implemented, the future for the virtual PHR is bright, and in time we may find providers asking patients to pull up various apps to share their data during an office visit, and even allowing them access to the data from those apps as FHIR bundles that their system could consume with the patient providing authorization as needed.

Perhaps then the visit could return to being a conversation about my health rather than a frustrating exercise in data entry.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s