Thoughts on Blue Button: 6 Reasons Why It Lacks Adoption, and Its Troubled Future

Tyler Hayes
Tyler Hayes

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.

5 comments on “Thoughts on Blue Button: 6 Reasons Why It Lacks Adoption, and Its Troubled Future”

Hey everybody, my name is Tyler Hayes. I’m co-founder & CEO of Prime and writer of this guest post. I’ll be keeping an eye on the comments section tonight, tomorrow, and this weekend so feel free to post any and all questions or thoughts on the article, Blue Button, or otherwise.

Thanks for this post Tyler, its a great conversation to start. As you know I am on the Blue Button team at ONC though am responding in a personal rather than official capacity.

I agree with a lot of the points you bring up- especially the challenges of having to coordinate these efforts not just across ONC Divisions but across massive governmental agencies (ONC, VA, CMS) and the private/public sector, with some actors that we have more levers to use with to create change than others (EHR vendors for example, versus data holders like insurers or pharmacies). You can streamline leadership for the campaign but using policy levers and engaging in standards development work legally requires a bunch of people in the room and lack of unilateral decision making. But we can absolutely, and should, always do better.

One barrier that you don’t list is simply one of timing. People keep saying “nobody is doing Blue Button Direct”. Well, the regulation didn’t actually require EHR vendors to certify for the technology until right now, and providers have only just started attesting for using it. So its a bit unfair to say that its failed before its even been up and working within the EHRs for patients to use and developers like yourself to take advantage of. I think the next six months to a year will be a much more accurate indicator of its success.

There is definitely confusion around the branding of Blue Button right now. To be clear, Blue Button is a consumer brand and campaign for patient access to data. As you state, consumers don’t really care what’s under the hood technically, they care about what they are able to functionally achieve. Other than CMIOs and the like most providers feel the same way. We want people to hear Blue Button and know that means easy electronic access to their data.

The question of naming and the different flavors of Blue Button + for developers is a really important one, and I’d love to see a conversation develop here to help us make this better. To the extent that we are trying to get multiple data types/content to patients (clinical versus claims) and the timeline for our regulatory lever of Meaningful Use, its not feasible to tell everyone to use one content and transport standard. From the clinical standpoint, there is only one content standard, the consolidated CDA. From the transport standpoint, as you note there is both the Direct and RESTful API approach. The latter is what I am personally most interested in long term, as are most people in the developer community. But Direct is in place NOW and required for all MU certified EHR technology. There is literally nothing we can do to slip the REST transport method into certification requirements that will begin to impact industry on a timeline that makes sense for any startup, so we decided that its strategically foolish to throw all of our eggs in the REST basket and wait several more years for people to be able to access their data. I don’t like simplistic cop-outs like “government can make people do it”.

Though the MU lever is not immediately available to us, we are working hard to encourage the uptake of Blue Button REST in other ways and with data holders we have weaker regulatory authority over, such as through the REST Pilot workgroups. As you note most date holders and providers are not exactly making money off of giving people their data. I’ve been told point blank by some of these companies that unless its in regulation, its not happening. We need patients and developers to step up and put the pressure on their providers and data holders like pharmacies and insurers.

One of our team members is in the midst of updating the Implementation Guide, it will be great to get feedback when its finished soon. GitHub is the central place for all of the dev support tools you mention:

We’d love to hear suggestions on what other events and support tools would be most helpful to developers. Would regular implementation support calls help? More regular email outreach? The Blue Button team will be presenting at and attending mHealth, and there is a codeathon and shortened Dev Forum in the works for Boston in late January. It would be great to connect with you and any readers there. Our team is also ALWAYS willing to speak with developers who want to learn about or need help with Blue Button.

We’d love to hear suggestions on what other events and support tools would be most helpful to developers. Would regular implementation support calls help? More regular email outreach?

There are many examples of how to do developer outreach among tech companies. Some of the best that come to mind are Twilio, Dropbox, and GitHub.

I think the next six months to a year will be a much more accurate indicator of its success.

I think and hope so too.

Lots of thoughtful thoughts in here. Thanks for sharing them.

Write a Comment

Your email address will not be published. Required fields are marked *