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

Continued from page 1

So, let me just give you a quick glance at the documentation, and then we'll get into the demo. So, I mentioned earlier, this API is really Blue Button pieces. It's the authentication piece, which we're using OAuth 2, and it's the API piece, which we're using, I mentioned, FHIR, and specifically for the healthcare geeks out listening to this, we're using the explanation of benefits FHIR resource, which really helps describe a claim, an insurance claim.

So, just kind of scrolling through here, just to give you a sense. So, that's what the API is made out of. So, let me give you once glance at what an explanation of benefits claim, the type of data here, and then we'll hop over to the demo.

So, everything that we do is really based on code sets and coding systems. So, you can imagine a lot of kind of key value pairs of which coding system it's coming from and what the value is. This is very common for healthcare data. An example of a coding system would be ICD-10, and you would see some value, like seven, and you knew that seven described, some type of condition.

The API has a lot of cost information, and a lot of, dates, and times that you visited, which provider you visited. These are the types of things that developers need to combine with the other data they have, whether it's genetic data, whether it's electronic health record data, whether it's clinical trial data, these are the types of use cases where developers would take insurance claims and combine it with other things that they're doing to build something for the patient.

David: So, there's sort of a standard vocabulary that they can access through the API as well to describe some of these activities, or ...

Kelly: That's right, and that's what the FHIR spec outlines. So, in FHIR they use terms like "bundle," "item," "entry," "extensions," so, I'll just kind of scroll through. You know, this is very healthcare specific, of course, as you can see.

All right, so, let me toggle over to one of the demos. This API, it is for a third party application developer to build something that ultimately benefits the patient, or the Medicare beneficiary, so—

David: So, let's stop. Just stop there for one second. What would incent a developer to build on this API? Is the developer working for a medical practice? Are they just trying to put an app out in the public domain that people would download and pay for? Like, who do you envision being, in the way of developers, the first adopters of this?

Kelly: That's a great question. A developer that would be interested in this is a developer that has Medicare beneficiaries as their end users. So, examples are a developer working on software for clinical trials, or a developer working on an EHR system, or a developer working on an app similar to Apple Health, where it'll, like, bring in all of your healthcare data, or a developer working on a home prescription drug delivery service.

All right, things like that where the more that the app, or the service, or the research project, or the clinical trial knows about the patient, or the user, more interesting things they can do to ultimately help that user. And that can take the form of helping the user understand their information, like, their insurance claims, or it can be much more sophisticated and incorporate this type of longitudinal patient data into prediction models and different machine learning techniques.

David: So, businesses can benefit from the data as well as individual patients, ultimately.

Kelly: Yeah.

David: Of course, if a business was benefiting from that, like, from a research perspective, there would be some requirements around it, I'm assuming, like you would have to anonymize the data, or maybe that's a part of the OAuth implementation here, which basically says, okay, for this user, this is available, and for this other type of user, only this other information is available.

Kelly: Yeah, a good example of something that wouldn't directly benefit the patient might be a research study, where the patient is choosing to [authenticate via OAuth] with the third party, and consent for that third party to use their data, and to share that data with the third party to help them with their research project. So, you can imagine a thousand patients donate their data to a project like Sync for Science, or Google's Project Baseline, these are a variety of companies that are leveraging Blue Button today, and that would be incorporated into the models that these companies are building trying to better understand peoples' health, and how to make everyone healthier.

David: Good objective. Okay. I interrupted the demo, so let's go on.

Kelly: Yeah, so, like I said, we launched at HIMSS a couple weeks ago, and there are a variety of companies that have participated in a developer preview that we've been running for several months. The company I'm showing you here is an example of a health data aggregator, and health systems, like the sample health system that you'll see here, that doesn't have their own software development team, would use a product like Human API to help coordinate this claims data coming into their system so they can benefit.

You see that a lot in healthcare, where providers and other companies in a healthcare ecosystem, they just don't have the engineers on staff, right?

David: Of course.

Kelly: There's a lot of middle men and software vendors here. So, what I wanted to show you is, really, the authentication flow.

So, this is an example of a beneficiary being in front of Starfleet Health. Oftentimes this is referred to as a patient portal, you may have experienced this if you've checked into an appointment, or scheduled an appointment online with your physician. And what you're seeing here is the patient has clicked to connect their Medicare account with this patient portal.

So, this is the first view of the OAuth 2 flow. The identity that we're using to support the OAuth 2 flow is MyMedicare.gov, which is a portal that all Medicare beneficiaries have access to, and have an account with. So, that's the identity source that we're leveraging here. And, so, you're seeing a sample username and password being entered here.

And then, once they're authenticated, they see the consent view, this approve access view, and this is telling them, that this third party is going to have access to this type of information. And, so, this gives them a chance to really understand what's happening, and go ahead and approve access.

David: This is the sort of thing that people click on never even looking at it, right? It's ... I mean, in many ways, this is in the news right now with what happened recently with Facebook. Like, the app said what it was going to take, and people clicked on it anyway. People blow through these things.

Kelly: Yep, exactly. So, that's something that we're very cognizant about. With each third party that we work with, one of the things that we've been very serious about here is our access to production data. So, each company goes through a vetting process that we have, and—

David: Oh, so, that's important. In other words, there is ... Before a developer gets access to the API, they have to go through a vetting process, and you have to approve them.

Kelly: Yeah.

David: Yeah, okay.

Kelly: That's exactly right. And, one of the things that happens here, too, is the beneficiary has looked at the terms of service and the privacy policy of whatever applications they're using. Now, of course, we're very concerned that oftentimes those privacy policies, and terms and conditions, and terms of service aren't read. We know that. So, we're doing as much as we can here to educate beneficiaries to make sure that everyone is a good actor in our system. Of course—

David: And theoretically, a Medicare patient who visits multiple doctors, multiple, hospitals, whatever, they're going to see this, like, five, six, maybe 10 times, right? So, they'll get ... They'll sort of get accustomed to the work flow, because the chances that a Medicare patient is just seeing one specialist is very low.

Kelly: Yeah, it's very interesting putting the patient in the middle of their healthcare, right? They'll have this experience in other things that they do as well. For example, they're ... When they log into their patient portal, some patient portals allow them to share their data with other providers.

It's very interesting to see, you know ... At CMS we talk here a lot about the changing demographics of the Medicare population. So, someone that's turning 65 today could have had an iPhone for the last 11 years, right? There's ... Seniors are becoming very digital. They're using apps now too ... like, FitBit, or 23andMe, and a variety of different technologies that, it's different now than it was a decade ago.

David: For sure, yeah.

Kelly: So, this is a good ... A small step forward to try and help them.

David: Okay.

Kelly: So, continuing on in the demo, they've now synced their data, and the next thing you'll see is some of their data flowing into this patient portal. And, again, this is ... I'm going to stop it here. This is an example app, a prototype, so if you look closely at the data it's all of our test data. One of the things that we offer our developers is we have a sandbox of 30,000 synthetic patients, which is a term we use in healthcare software development, where it mimics the real patient, but it's ... You can't re-identify it, and things like that.

So, you see here some of that data, and a typical use case is the third party app that's consuming the Blue Button API will draw some sort of timeline, like I mentioned a longitudinal patient view, and the timeline view is a common view for longitudinal patient data. So, the physician can look down the timeline and see, which medications the beneficiary has been prescribed, see other information that's coming from the electronic health record and, understand cost of things over time, different procedures that the patient, the beneficiary may have had at other providers outside of this EHR, which is really key for interoperability, and then make better decisions about their care.

So, that gives you an example of how a patient, or Medicare beneficiary, would [use] OAuth to grant consent, and then how the developer would then take that token and query the API to retrieve the claims data.

David: That's a really interesting point that you're making, particularly about the availability of certain data to a variety of stakeholders. So, like, if I break my leg, which, involves a visit to my primary care, the hospital, the orthopedic surgeon, the therapist --- if somebody said, "well, how much did it cost you to break your leg?" I wouldn't know the answer to that question, right? But I'm gathering, from this kind of functionality, you could figure out what the total is. You could figure out what the total bill was, and you can also figure out how much of it was covered by insurance. I mean, there's a whole bunch of data here that suddenly becomes available, queryable, if you want to call it that, and that could lead to other improvements and positive outcomes in the overall healthcare system.

Kelly: Exactly right, and that's typically referred to as the explanation of benefits. The benefits that you're receiving from your insurance provider, and that's the ... That's also the name of the FHIR resource that we are using to model this data, and give you an example of what the API specifically looks like.

You know, I mentioned before, entry and items, but this gives you a sense here of the type of data that you find within that Medicare claim. You know, who the care team was, how much did it cost, what the diagnosis was, when did it happen, and where. Things like that. And you can imagine putting the patient in the center of their healthcare. If they have that data with them, and they're able to share it with the different specialists and the provider, that's one way to achieve interoperability.

David: Right. In terms of looking further out into the future, do you envision that in order for certain healthcare providers to be able to work with Medicare, or for, certain doctors ... And I guess just the doctors, maybe the insurance companies, I don't know, but can you ... Will you require this? In other words will this sort of be, "okay, either (A) you're using the Blue Button API, or [B] I'm sorry, you don't get to come to the party?

How does that work moving forward, because my understanding is the Department of Health and Human Services ... I testified to the Department of Health and Human Services about API security about a year ago, and my understanding was they were trying desperately not to create a standard API that everybody had to comply with.

Kelly: Right. The more you write technical rules into regulation and policy, the more you risk boxing yourself into certain technologies.

David: Right.

Kelly: The ONC, the Office of the National Coordinator—

David: That's right, that's who I testified to, yeah.

Kelly: Yeah, so, that organization is right across the street. We spend a lot of time together. They work a lot with healthcare IT vendors. They talk a lot about open APIs, and all of this stuff that's driving healthcare interoperability forward from an industry perspective. One of the things that we do ... You know, I mentioned earlier, this is just for Center for Medicare and Medicaid, and just for our patient population, but we do open source everything that ... You know, of course, all government agencies do that, they open source the technologies they build. So, other payers, Medicare advantage plans, and others can take what we've done and build their own versions of Blue Button.

I mentioned the VA, and Department of Defense has a Blue Button, and other payers hooked on this. So, the more that we push the boundary with CMS in terms of providing better care for beneficiaries through putting them in the middle of their patient care and, hopefully others do the same.

David: So, just going back to the API, I imagine that it kind of works both directions, so you can, depending on the application you can query it, but you can also post updates to it.

Kelly: So, this API is read only.

David: Read only, okay.

Kelly: The claim information, it all flows into the system from the providers, so they're the ones that submit claims to Medicare. So, the doctor submits the claim, and we don't have a way to say, like, hey, I found a mistake in this claim, update it, yet.

David: Okay. Oh, yet. So, that's maybe a coming ability, to update certain records.

Kelly: It's a type of thing that developers ask us about a lot, so it's ... You know, it's been wonderful. We have a couple ... Like I mentioned, we have a couple hundred companies, big and small, healthcare, fitness, lifestyle, all sorts of industries that have been using the Blue Button prototype, and it's been awesome getting their feedback and the ideas.

David: Are you going to extend Blue Button to cover more of the FHIR domains than just the claims data?

Kelly: For CMS, their world is claims data, but we will continue to add as much of the claims data as we can to the API, to the explanation of benefit FHIR resource that we're exposing.

David: Okay.

Kelly: ... others, for example, EHR companies, they'll use other parts of the FHIR spec. I mentioned project ... I'm forgetting the name now.

Cyrus Sethna:Project Baseline?

Kelly: Project ... No, the FHIR spec.

Cyrus: Argonaut.

Kelly: Project Argonaut is the project that encompasses FHIR resources for EHR companies.

David: Because I can imagine that some of that part of the spec would have to involve APIs that you can write to, like, for example, I have the smart watch, and it's got my heart rate and all ... And, I could imagine wanting to contribute some of that data into my health record, right?

Kelly: Right, right, and, often times people refer to that as exogenous data. There's all sorts of interesting things happening with how this type of data could be used at the point of care. We could talk a lot about how a physician just sees, when they take your blood pressure and your heart rate, it's just that point in time versus seeing a trend that you could hand to them with your smart watch over time.

You know, what's fascinating about claims data is how large it is. So, for each beneficiary they could have hundreds, or thousands, of claims that come back from the last four years and beyond, so it's—

David: Sure, all the incidents, the medications, I mean, it all goes through ... Kelly: Yeah, it's a very big data set. Yeah, absolutely.

David: Okay, so for developers that are watching this video and would have an interest in learning more, where can they go?

Kelly: So, BlueButton.cms.gov, and I'm not sure when this comes on, but if you're in town next week we'll be at Health Datapalooza.

David: Okay, so, next week is the last week of April, 2018. We'll probably getting this up just in the middle of that, unfortunately, but I'm guessing you have one of those every year, so if you miss the 2018 one, you can always come back for future editions of that event, right?

Kelly: Absolutely, and on Blue Button.cms.gov is our developer documentation, ways you can try the API, and a Google Group that we're very active in, so you'll find engineers with rich experience in claims data and APIs answering your questions there as you get going.

David: And for other API providers that are looking at what you've done here and saying that's pretty clever, and they want to know how you built it, just, what systems are in your stack? What did you build it on?

Kelly: Sure, so, we have a Django front end, and, a lot of CMS is leveraging AWS, cloud computing in government is still cutting edge innovation. So, one of the funny things our team talks about all the time is if we're doing anything new here, we're making a mistake. So, every single thing that we did is very, just, standard, unremarkable, and the true breakthrough here is not necessarily the tech stack, but it's the, understanding how to have this consumer directed exchange to give people access to their data.

David: Okay, well, Kelly Taylor, a product manager with the US Digital Service, thanks very much for joining me today to put this video out, appreciate it.

Kelly: Thanks, David.

David: We've been speaking with Kelly Taylor, he's a product manager at the US Digital Service out of Washington, D.C., thanks very much for joining us. If you have comments or questions, be sure to throw them underneath the video, or on the article that it's embedded on on ProgrammableWeb.com. I'm David Berlind, the editor-in-chief of ProgrammableWeb, thanks for joining us.

David Berlind is the editor-in-chief of ProgrammableWeb.com. You can reach him at david.berlind@programmableweb.com. Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.
 

Comments (0)