Electronic Health Reporter

Guest post by Tyler Hayes is co-founder and CEO of Prime, the personal social network for your health.

Despite numbers the VA and ONC have shared, Blue Button is effectively not being used. Consumers haven’t heard of it. Developers aren’t implementing it. It’s not blossoming into what it can and should be.

This is happening for several reasons. I’d like to share some brief thoughts on our industry’s relationship with Blue Button, why it lacks adoption, and its currently troubled future.

First, there’s its identity crisis.

Blue Button is not the same as Blue Button+. Blue Button+ is Blue Button on steroids. That’s a good thing. But Blue Button+ is really two things, which makes it more confusing. That’s a bad thing. Blue Button+ is really Blue Button+ Push and Blue Button+ Pull. I hear the former may be renamed to Blue Button+ Direct and the latter to Blue Button+ REST API. Thoughts on the names aside, this is again more room for confusion.

This confusion, just from these few terms, is turning developers off from adopting Blue Button. When developers are confused, you can guarantee consumers are confused. We’ve seen both first hand in non-trivial amounts. That’s very bad.

From this point forward, I’m going to refer to all of these as just one whole: Blue Button. To do otherwise is to descend into madness. This is how Blue Button should exist right now anyway.

Second: Fragmentation.

Even if Blue Button were to fix its identity crisis, it would still suffer from fragmentation of resources like documentation and community efforts.

BlueButton.js, for example, is a tremendous community effort to translate health records (CCDA and C32 XML files usually) into JSON blobs. This is not the best end goal but it is a great first step to creating one, consistent interface to manipulate data — JSON can be easily read client-side and server-side. And yet effectively no one knows about BlueButton.js, certainly not those who’d benefit most from its existence: app developers.

Fragmentation can be solved relatively easily. Simply move the resources into one place and then tell people about that place.

Third, replacement of strategy and execution with platitudes.

At the 2013 ONC Consumer Health IT Summit there was no shortage of mentions of problems in healthcare. And yet no real, current solutions were offered. Blue Button was offered as a hypothetical solution but, because of no announcements of progress on Blue Button itself, acted more as a placebo onto which people projected any number of as-yet-unsolved hopes and dreams.

Blue Button is just developed enough (in the engineering sense) that it’s easy to assume it will be successful, but not developed enough (in the business development sense) that it is actually being used. Success comes from use.

Back-patting is not innovation. Stating problems is not innovation. Innovation is iteration.

Blue Button is essentially a start up because it is young, its success carries a sense of urgency and it depends heavily on talented software developers. It should be run like a start up, or at least a company, not a committee-run government project.

Blue Button has a huge advantage unlike most start ups: it already has product-market fit. Consumers want their data (well, really they want to access it in other systems, like apps) and Blue Button solves that.

However, like most start ups, what Blue Button doesn’t have is customers. Customers come from sales. Sales come from a compelling, easy-to-understand, easy-to-use product. Blue Button is not those things. Without those things, Blue Button will not achieve critical sales or customers.

Fourth, lack of communication, lack of community.

In any organization, progress needs to be constantly and clearly expressed by leaders for stakeholders to remain confident and for employees and customers to continue buying into the vision.

Blue Button is no different. Blue Button’s leaders need to communicate much more often in order for a community to develop. Without participation from those individuals directly responsible for the success of Blue Button, why would any developer think it’s worth investing her time and effort?

Fifth, lack of understanding of the vendor + provider + patient relationship.

EHR vendors don’t care about patients. Patients are not their customers. (That doesn’t mean they don’t care about patients as people.) That is the rule, not the exception. Vendors care about their customers: healthcare providers.

But who is Blue Button really for? Who wants it? Patients, of course. And who cares about patients? Providers. So for Blue Button to achieve success, it needs providers to enable Blue Button. And for providers to enable Blue Button, their EHR vendors need to implement Blue Button. If patients don’t know about Blue Button they can’t reach a tipping point in convincing their providers to ask their vendors to add Blue Button. And providers/vendors can achieve Meaningful Use without Blue Button.

Sixth, lack of understanding of patients as people.

Patients don’t care about structured data. Standalone XML does not help patients.

Patients are people. People care about living a better life. If their data helps them accomplish that, great. People don’t want to do work, they want things to just work.

The way I see it, there are three possible ways forward.

First: Do nothing. Let Blue Button and Blue Button+ continue to co-exist and see where the chips fall. I would not recommend this for all reasons stated above.

Second: Deprecate Blue Button and make Blue Button+ the only real Blue Button. Change nothing else. This would relieve some confusion. And if the government pushed hard enough on getting vendors to adopt Blue Button it could work. This is how Microsoft works. And like Microsoft, I don’t see this happening without a large sales force and enterprise development model.

Third: Re-organize Blue Button efforts around one goal of solving one problem with one visionary product. Tactically, a few first steps:

* Deprecate Blue Button and Blue Button+ Push.

* Re-align efforts on adopting and enforcing Blue Button+ Pull. Everybody working towards the same goal.

* Consolidate all resources into one location. Create great documentation. Convince vendors that Blue Button is a 10x better solution for achieving Meaningful Use. Convince developers setup is trivial.

This could be accomplished using a functional (not divisional) company-like structure, and would in fact likely be easier this way. But that does not mean it couldn’t be done in the current committee structure. (If it can, so much the better.)

We’ve implemented Blue Button+ Push at Prime since day one because we believe Blue Button is a quantum leap in health record portability, if done right. Still, Push is a sub-optimal solution.

Consumers already log in to apps using Facebook, powered by OAuth. Blue Button+ Pull is based on OAuth. Why re-invent the wheel? Let consumers log into apps and services using Blue Button+ Pull. Developers know how to build it. Consumers know how to use it.

Just do it.