everythingpossible - Fotolia
Healthcare APIs get a new trial run for Medicare claims
Blue Button 2.0 is a new healthcare API aimed at making sense of Medicare claims. Developed by the U.S. Digital Service at HHS, the API is in 500 developer hands so far.
In the ongoing battle to make healthcare data ubiquitous, the U.S. Digital Service for the Department of Health and Human Services has developed a new API, Blue Button 2.0, aimed at sharing Medicare claims information.
Blue Button 2.0 is part of an API-first strategy within HHS' Centers for Medicare and Medicaid Services, and it comes at a time when a number of major companies, including Apple, have embraced the potential of healthcare APIs. APIs are the building blocks of applications and make it easier for developers to create software that can easily share information in a standardized way. Like Apple's Health Records API, Blue Button 2.0 is based on a widely accepted healthcare API standard known as Fast Healthcare Interoperability Resources, or FHIR.
Blue Button 2.0 is the API gateway to 53 million Medicare beneficiaries, including comprehensive part A, B and D data. "We're starting to recognize that claims data has value in understanding the places a person has been in the healthcare ecosystem," said Shannon Sartin, executive director of the U.S. Digital Service at HHS.
"But the problem is, how do you take a document that is mostly codes with very high-level information that's not digestible and make it useful for a nonhealth-savvy individual? You want a third-party app to add value to that information," Sartin said.
So, her team was asked to work on this problem. And out of their work, Blue Button 2.0 was born.
More than 500 developers have signed on
To date, over 500 developers are working with the new API to develop applications that bring claims data to consumers, providers, hospitals and, ultimately, into an EHR, Sartin said. But while there is a lot of interest, Sartin said this is just the first step when it comes to healthcare APIs.
"The government does not build products super well, and it does not do the marketing engagement necessary to get someone interested in using it," she said. "We're taking a different approach, acting as evangelists, and we're spending time growing the community."
And while a large number of developers are experimenting with Blue Button 2.0, Sartin's group will be heavily vetting to eventually get to a much smaller number that will release applications due to privacy concerns around the claims data.
Looking for a user-friendly approach
Shannon Sartinexecutive director of the U.S. Digital Service at HHS
In theory, the applications will make it easier for a Medicare consumer to let third parties access their claims information and then, in turn, make that data meaningful and actionable. But Arielle Trzcinski, senior analyst serving application development and delivery at Forrester Research, said she is concerned Blue Button 2.0 isn't pushing the efforts around healthcare APIs far enough.
"Claims information is not the full picture," she said. "If we're truly making EHR records portable and something the consumer can own, you have to have beneficiaries download their medical information. That's great, but how are they going to share it? What's interesting about the Apple effort as a consumer is that you're able to share that information with another provider. And it's easy, because it's all on your phone. I haven't seen from Medicare yet how they might do it in the same user-friendly way."
Sartin acknowledged Blue Button 2.0 takes aim at just a part of the bigger problem.
"My team is focused just on CMS and healthcare in a very narrow way. We recognize there are broader data and healthcare issues," she said.
But when it comes to the world of healthcare APIs, it's important to take that first step. And it's also important to remember the complexity of the job ahead, something Sartin said her team -- top-notch developers from private industry who chose government service to help -- realized after they jumped in to the world of healthcare APIs.
"We have engineers who've not worked in healthcare who thought the FHIR standard was overly complex," she said. "But when you start to dig in to the complexity of health data, you recognize sharing health data with each doctor means something different. This is not as seamless as with banks that can standardize on numbers. There, a one is a one. But in health terminology, a one can mean 10 different things. You can't normalize it. Having an outside perspective forces the health community to question it all."