US Digital Service Launches v2 of Blue Button API to Ease Flow of Medicare Data

Earlier this month, the US Digital Service (USDS) — a group that operates out of the White House — reached its second big milestone of 2018; it launched version 2.0 of the Blue Button APITrack this API. Earlier this year, the group published a framework that made it easier for federal government organizations to publish custom-built code as open source.

To find out more about the Blue Button API 2.0, I interviewed USDS product manager Kelly Taylor who spearheaded the initiative. The video, audio, and full-text transcript of that interview are embedded below. The basic premise of of the Blue Button API is promote the interoperability of Medicare claims data between different systems (for example, between a primary care provider and a hospital) such that the patient is central to that flow of information and the care for that patient is greatly improved when compared to the world of non-interoperable healthcare data.

It should be noted that Medicare claims data is just one part of the larger electronic healthcare data ecosystem (and a narrow part at that given that millions of Americans get their health insurance from somewhere else besides Medicare). Officially, it's a subset of the broader set of electronic healthcare record (EHR) data that needs to be interoperable across the healthcare industry. The all encompassing set of standards that covers Medicare claims data and other EHR groupings is known as FHIR (Fast Healthcare Interoperability Resources).

However, the efficacy of medicare claims data as a part of EHR ecosystem is not to be underestimated. Over 57 million Americans are insured through Medicare. Medicare claims data is also, in many ways, a direct reflection of the care that a patient is getting, who is providing that care, what medications have been prescribed, etc. So, once that data is flowing across healthcare providers with less friction (while at the same time becoming more immediately accessible to the patients themselves), there's a stronger likelihood that the patient will receive better care. When anonymized, the big data set from across all Medicare-insured patients can also flush-out medical discoveries that might not otherwise present themselves to medical researchers.

In fact, that sort of permission-based access to EHR data is largely what this version — version 2.0 — is about. As Taylor describes in the interview, this version is integrated with the Oauth standard in such a way that patients can more easily authorize who has access to their Medicare claims data. Taylor goes into significant detail about this and other benefits of version 2.0 and even does a demo of how that authentication workflow will look to the patient.

Here's the interview (the full text transcript appears below).

Video Interview of Kelly Taylor

Editor's Note: This and other original video content (interviews, demos, etc.) from ProgrammableWeb can also be found on ProgrammableWeb's YouTube Channel.

Audio-Only Version of Kelly Taylor

Editor's note: ProgrammableWeb has started a podcast called ProgrammableWeb's Developers Rock Podcast. To subscribe to the podcast with an iPhone, go to ProgrammableWeb's iTunes channel. To subscribe via Google Play Music, go to our Google Play Music channel. Or point your podcatcher to our SoundCloud RSS feed or tune into our station on SoundCloud.

Tune into the ProgrammableWeb Radio Podcast on Google Play Music  Tune into the ProgrammableWeb Radio Podcast on Apple iTunes  Tune into the ProgrammableWeb Radio Podcast on SoundCloud


Full Transcript of David Berlind's Interview with Kelly Taylor

David Berlind: Hi, I'm David Berlind, editor-in-chief of ProgrammableWeb, and we're here today to bring you another one of our great videos. Today my guest is Kelly Taylor. He's a product manager with the US Digital Service out of Washington, D.C., and today Kelly's going to be talking to us about version 2.0 of the Blue Button Initiative.

Kelly, thanks for being on the show today.

Kelly Taylor: Thanks, David. The US Digital Service is a group of technologists based here in Washington, D.C., designers, engineers, product managers, that come to DC for a three, six, or 12 month digital tour of duty. So, I am assigned to [the Department of] Health and Human Services , where I have been helping the Center for Medicare and Medicaid with the Blue Button API. The Blue Button is a symbol for a patient's right to access their own healthcare data. It's something that began in 2010, and for the last seven or eight years or so, Medicare patients have been able to download a text file of all of their Medicare insurance claims, and this is a great step forward for healthcare interoperability and so on. But imagine a patient prints out a 50-page, print out of a CSV file they downloaded with all the raw data. And, so, we started talking about how it's really the services, not just the raw data, that can ultimately benefit Medicare beneficiaries. So, we came up with the idea of building an API for Blue Button that combines OAuth plus a FHIR-based API. The FHIR is a healthcare data format, and—

David: That's spelled FHIR, is that correct?

Kelly: Yeah. And, so, those are the Blue Button pieces. So, what I'm about to show you is Blue Button 2.0. We announced this a couple of weeks ago at the big healthcare IT conference in Vegas called HIMSS, and we now have a couple hundred companies that are building with the Blue Button API, and several companies that have gone live now with the integration.

The important thing to remember here, especially with OAuth, too, is what policy dictates us being able to offer this API, CMS being able to offer this API to third party developers.

David: I'm sorry, CMS stands for?

Kelly: Center for Medicare and Medicaid.

David: Okay.

Kelly: And that's the office I'm sitting here in, a block from Capitol Hill here in Washington.

David: Okay.

Kelly: And there's a healthcare law that many people are probably familiar with called HIPAA, and a lot of software developers have to deal with HIPAA regulations and a lot of constraints around developing in this type of environment. And there's a provision in HIPAA that talks about a patient's right to their healthcare data, and how they're able to [give] consent for someone [a third party] to access that information.

So, that's what this is all based on, and that's the part that CMS really helped us figure out, whether or not we could build this API, and once we got the go-ahead to build it, that's where the US Digital Service paired up with our CMS colleagues on the policy side and built this.

David: Okay, I just want to stop you for one second, because you mention Medicare a few times. Because when I think about this idea of being able to download your own health data, that seems like something that every person in the world would want, let alone just Americans, but is this just restricted to those people who are in the Medicare system?

Kelly: That's a great question, and the answer is yes. The Blue Button API is for Medicare patients. There's about 57 million Americans on Medicare.

David: Okay.

Kelly: And the Blue Button Initiative, that's been around since 2010, it's a symbol for access to patient healthcare data. So, for example, the VA, the Veteran's Administration, has implemented their own version of Blue Button. Other large insurance companies have their own version of Blue Button. So, it's just really this thing that patients will see throughout, and it's really ... It's one small piece of trying to solve the overall healthcare interoperability problem, which is still, of course, unsolved.

The FHIR data format is a big part of that, where it's a consistent data format that lots of people are using now. So, there's a variety of initiatives, one's called Project Argonaut, that focuses on using the FHIR data format for electronic healthcare records systems. We're using a part of the FHIR spec that deals with insurance data, which I'll refer to a lot as "claims."

Yeah, so, that's what we're up to.

David: So, FHIR is, when you talk about it being a format, it's sort of like a broad format that, by what you just said, you're sort of implying, it covers quite a few domains. It covers healthcare data, covers insurance claims, things of that nature, and it's sort of a standard format, like sort of standard field names, standard field sizes, all that sort of stuff, and then—

Kelly: Yep.

David: ... in some ways, a standard that a lot of different systems providers, and, of course, Blue Button Initiative is complying with in part or in whole, is that what you're—

Kelly: You're exactly right.

David: Okay.

Kelly: Yeah, that was exactly it. [FHIR is] now on version three, with version four being worked on now. You know, there's working groups for each area of the FHIR spec. You may have seen the announcement from Apple, the new Apple Health app now integrates with a variety of healthcare systems, for example, Johns Hopkins, and they're using DSTU2, which is the second version of FHIR that deals a lot ... , covers a lot of EHR ... They call them resources, in the FHIR spec.

David: Wait, EHR, electronic health records, so this is the actual ... Where the health information, the last doctor's visit, that kind of thing, is being stored, right?

Kelly: That's exactly right.

David: Yeah, okay.

Kelly: And there's a concept in healthcare called a longitudinal patient record, and it is everything from when you go to the doctor and they take your blood pressure, to test results you have, to the ultimate insurance claim that's filed, and if your insurer is Medicare, that's where it's filed, and Medicare pays for it. And having that information all together into this longitudinal view is really what everyone in healthcare talks about as being the ultimate goal with interoperability. So, when you go to the doctor, no matter where you are, no matter which specialist or doctor you're going to, that doctor has a complete, view of all of your information and can make the best decision for you.

So, again, this is one small piece of the puzzle, and with what we're doing, this idea of consumer directed exchange of information, or patient directed exchange, the idea is one of the ways that interoperability in healthcare can be achieved is by putting the patient in control. When you look at health systems around the world, for example, in France, everyone has a card that they carry with them, and when they go to the doctor, it slots into the doctor's computer and has all of their information, and then they take it with them, so the patient is in control.

So, it really touches on a lot of that here with what we're doing.

David: Okay, very good. So, you have a demo you're going to show us, right? Or you're going to ... You've got something, like, exhibit A? Kelly: Exhibit A, so, let's take a look at the Blue Button website. David: Okay.

Kelly: For developers that are working with healthcare data, they can go to BlueButton.cms.gov to get started. This is a free API. At Blue Button.cms.gov we talk a little bit about — some of the things I just mentioned — why we're able to do the API, what it's all about.

The API encompasses, like I mentioned, 57 million Americans are covered under Medicare. We have about 53 million Americans available in this API. There's a term, part A, B, and D data, this is a way to describe Medicare data, and it talks about hospital visits, primary care doctor visits, durable medical equipment, prescription drugs, these are the types of claims, and types of healthcare data that you'll find in this API, and we make up to four years of data available for each beneficiary.

Continued on page 2. 

Be sure to read the next Healthcare article: ClearCare Launches Home Connect API for Home Care Solutions

 

Comments (0)