The Centers for Medicare and Medicaid Services on Monday held its first White House hackathon. The topic: Blue Button 2.0.

Ahead of the event, I spoke with two technologists, one from CMS and one from the United States Digital Service (which worked with the agency to develop the Blue Button API). 

Mark Scrimshire is CMS Blue Button Innovator and a developer evangelist. Kelly Taylor is a product manager at the United States Digital Service. They discussed the momentum that CMS has picked up recently in the developer sandbox, the ideal example of what Verily is doing with the API and what they hope other developers do with the tools moving forward.

Q: The White House hackathon is about Blue Button 2.0 – where is Blue Button now?

Scrimshire: When (CMS Administrator) Seema Verma announced the sandbox at HIMSS18 we thought we’d get 20-30 people but we came away with more than 200 developers registered – and it’s still growing. We didn’t try to create something unique to CMS. The resource was meant to be friendly and familiar to the payer industry and, in fact, there are four or five payers that have taken it and are using to do things like send data to analytics vendors. We deliver the API, documentation, implementation guide, sample apps, code samples, there’s a support forum on Google.

Taylor: It’s four months old and now we have more than 700 developers in the sandbox, apps in production. That tells states and Medicare Advantage plans that this is totally doable and there’s product market fit, developers want this.

"The challenge is always getting the data – so the big opportunity is CMS setting an example for the rest of the industry."

Mark Scrimshire, CMS Blue Button Innovator

Q: What are some of the most successful apps using the API today?

Taylor: The research projects so far – Google Verily’s Project Baseline is a perfect example. Research participants contribute all sorts of health data, it’s very in-depth, they can connect their Medicare data as one piece of the longitudinal puzzle. It’s the exact use case we envisioned when we set out to do this. A lot of startups are working on PHR apps, payers and EHR companies are in the sandbox experimenting with the API so they can understand what it looks like. From pop health to research projects, to people thinking about doing things with Amazon Echo, to health systems to stealth startups, it’s been fun to see the interest in this.

Scrimshire: Consumer-directed exchange is part of the wider application happening with Blue Button. Using the OAUTH 2.0 protocol allows a patient to authorize an app or service without giving away a password, and FHIR makes it easier for developers to find the data because it’s in JSON format so they can use standards to carry out their work. 

"The larger our developer ecosystem, the better for everyone, the more diversity we have, the more people asking hard questions, the stronger the product becomes."

Kelly Taylor, U.S. Digital Service

Q: With the recent push to attract more developers, what are you hoping they achieve? 

Scrimshire: Because my interest has been on patient empowerment for years, I’m engaging in conversations with payers and asking what is the relationship you want to have with your members in this interoperable world? Should you be finding preventative services members are eligible for? Should payers be publishing to their members the results of benefit or eligibility checks for services the member is after? Another thing that would be great to see is a single Medicaid implementation of Blue Button and not 50 different Medicaid implementations. 

Taylor: As a Blue Button product manager for the last year, I want to see more developers get their apps into production. I’m looking to better understand their blocks, friction and collect ideas for the roadmap.

Q: What’s one thing about Blue Button that developers might not know but should really be aware of?

Scrimshire: The Blue Button API is in a unique position because only a small fraction of care is happening in the doctor’s office or hospital, lots of care is delivered at home or in the community. Because a patient is enacting their HIPAA right of access, Blue Button is the only API that would enable a covered entity to share data with a community or faith-based organization that may be active in the community. If a hospital made available the FHIR information using Blue Button methodology a patient could share lab tests with the community organization that helps take care of them at home. Those organizations don’t necessarily have funding or infrastructure to become a Business Associate or covered entity. With Blue Button, they don’t have to become a covered entity. I’m trying to get this idea out there to get innovators and entrepreneurs to think about how to make healthcare better. Putting the patient in control makes sense.

Q: Last question: What’s next?

Taylor: One of the things I noticed is that there’s a community of early adopters and thought leaders around FHIR that understand the direction of everything and are driving the industry forward, and then there’s a massive gap and then everybody else in healthcare. So the idea is bringing healthcare decision makers, software engineers closer to understanding the FHIR data format and why that’s important. The larger our developer ecosystem, the better for everyone, the more diversity we have, the more people asking hard questions, the stronger the product becomes.

Scrimshire: I just want to see it really grow and flourish, ultimately it’s about seeing those apps in the hands of people, whether it’s working with Alexa or doing cool stuff with smartphones. We’re really just scratching the surface of what’s possible. The challenge is always getting the data – so the big opportunity is CMS setting an example for the rest of the industry. The more that causes other organizations to make this API available with relevant information for their members, the better in empowering consumers to manage their own health. 

Twitter: SullyHIT
Email the writer: tom.sullivan@himssmedia.com