Blue Button 2.0 Patient Access APIs Hero
Mark Lorenz


In this post:

  • Patient access workflow screenshots.
  • What is this Blue Button thing?
  • Day 33: They still suspect nothing.

In this article, I'll skip my usual Watchmen-style, parallel story ark thing and jump right into Blue Button 2.0. Blue Button is the protagonist, it can carry the narrative by itself.

What is Blue Button 2.0

CMS (Centers for Medicare and Medicaid Services) is awesome, and that's no 🧢. Best. Federal. Agency. Ever. These are the folks in the federal government that are responsible for administrative rule making around Medicare, Medicaid, and Affordable Care Act exchange plans. That means they're responsible for the CMS-9115-F Patient Access rule, and it's little brother: Blue Button 2.0

The cleverly named Blue Button (1.0) started life in 2010 as a blue button on the Department of Veterans Affairs (VA) website that would let vets download a consumer-readable PDF or text file of their medical records. CMS followed suit for Medicare beneficiaries.

In 2018 Blue Button 2.0 built on the original Blue Button, but with a focus on connecting 3rd party app/website developers through OAuth 2.0 and the HL7 FHIR standards. Now we're cooking with gas! (that's a FHIR joke 🙄). It works differently, but you can think of all this as for healthcare. You hook up your banking/health information and previously siloed information can be put to work for you.

Aside from nerds, who cares?

Where we're at now with patient access APIs is a lot like where cell phones were in the early 2000's. Lots of people had one, they were an important part of life- and what your phone could do was mostly decided by Nokia.

Before the 2008 launch of Apple's App Store, the apps (or "features" as we called them) that you could use on your cell phone were the ones the handset manufacturer decided to load on the device when it shipped. Nokia Snake was a world-wide phenomenon[1].

Then came the App Store and we got Angry Birds (which made $6.5MM in 2010 and $75.6MM in 2011![2]), Candy Crush, and many more.

The early 'naughties cell phone is today's healthcare data

Nokia Snake was the best game, conveniently, it was also the only game. [photo credit]

Access to healthcare data has just crossed the same inflection point. We now have our app store. We just need someone to give us the Angry Birds of healthcare.

Blue Button 2.0 and CMS-9115-F Patient Access APIs

Blue Button 2.0 has a lot in common with the CMS-9115-F Patient Access final rule, it's cited several times by CMS in their rule making process. So what's the difference between Blue Button 2.0 and the Patient Access rule? Basically two things:

1. Who's providing the authorization workflow.

Authorization Provider
Blue Button 2.0
CMS-9115-F website of patient's insurance plan

2. What patients are covered by the rule.

patient covered by blue button 2.0.

patient covered by CMS-9115-F patient access rule.

At this point, you're probably wondering… "Why make new rules? Why not use Blue Button 2.0 for everything?" CMS was asked this question during the rule making process, their answer was very laissez-faire: they believe that, "industry will do a better job of taking interoperability to the next level".

My opinion? Blue Button has a multi-year head start so it's not a fair comparison. But, having implemented Aetna, United/Optum, Cigna, Humana, and Blue Button 2.0- Blue Button is far and away the best documented and follows the standards very closely. The Blue Button 2.0 developer resources are incredibly good.

When I say over and over again "CMS is awesome", I mean it. It feels like this agency puts everything in the public domain. (Did you know that they publish the commissions paid to Medicare Advantage brokers for each plan they sell? Fascinating.) Anything you want to know about how healthcare works is probably stashed somewhere on the CMS website. This is why I catch feelings for CMS- they too live the HealthSouse mission.

The authorization workflow

Blue Button 2.0 has a very crisp authorization workflow.

blue button 2.0 authorization workflow.

What you need to know about authorizing

Not much really. It's basically an out-of-the-box OAuth 2.0 workflow that supports PKCE in the /authorization step. It does require the client_id and client_secret to get a token so you won't be able to do that step without a back-end service.

Aetna, Cigna, and Optum got this one better- client_secret isn't required for any of the steps.

Blue Button 2.0 issues a refresh token, that doesn't appear to expire. This is excellent, it means that patients can connect to an app that runs in the background serving them for as long as they like. Aetna, Cigna, and Optum have all put a 3 month limit on their refresh tokens.

The Explanation of Benefit (EOB)

I'm working on a proof-of-concept right now that leans heavily on the Blue Button 2.0 EOB. More to come in a separate article.

Wrapping up

As it turns out, for some 53 million Americans, the future of healthcare APIs was already here. However, only about 53,000 Medicare beneficiaries have used Blue Button and there's only 55 approved 3rd party applications (yes, CMS does have to approve the 3rd party applications, which is also a difference with CMS-9115-F).

I think what feels like low utilization to me, is largely due to Blue Button 2.0 hiding in plain sight. Go build something with it, ya'll!

blue button 2.0, hiding in plain sight.

One Click Retweet

Do you know someone with an Aetna Medicare Advantage plan? Please send them to the HealthSouse home page. We may also be able to save your friend some money.

Still here? Thanks for reading! You seem like a nice person, who should send me an email: Encouragement and criticism are both welcome!