The Standard

Nine years ago, Blue Button started as an idea:

“Wouldn’t it be great if, as a patient, I could go to my doctor or health plan website and click a button and be able to take my health record with me…”

The Veterans Administration and the Centers for Medicare and Medicaid Services (CMS) should take credit for turning this idea into reality when they implemented website features for veterans and beneficiaries to download a text or PDF file containing a few years of their health history.  

In 2015, CMS set out on a journey to deliver a new version of Blue Button; this time as a data service. It has been my privilege to be invited into CMS to lead the design and building of what is now known as the Blue Button 2.0 API.

From the outset, the vision was to build a developer-friendly, standards-based API that put beneficiaries in control of with whom they shared their claims information. 

In a healthcare world where so much data flows about us, without us, Blue Button 2.0 is about putting the patient at the center and letting them choose. This then makes TRUST and TRANSPARENCY job one for developers, services and researchers wanting to use the API. No data flows without the explicit authorization of the consumer.

Empowering the Innovators

The important feature about Blue Button 2.0 is that it is a standards-based API. By using familiar, proven standards and technologies that can operate at internet scale, Blue Button 2.0 makes it easier for developers to focus on real innovations in usability, actionable insights, and to spend less time on the mechanics of acquiring and transforming data into usable content.

Blue Button 2.0 has stayed away from developing anything more than sample applications. The focus is on building and supporting the community that has developed around the API. 

As has been demonstrated by the HL7® FHIR® specification, the real power is not the specification or the APIs. The real power lies in the vibrant community that grows up around them.  In that respect, Blue Button continues to grow and is currently comprised of approximately 1,500 developers representing a who’s who of healthcare organizations. 

The number of applications applying for, and successfully being authorized to, access the production Blue Button 2.0 API has grown, as has the number of beneficiaries choosing to share their information. The growth, one year after launching at HIMSS’18, has been organic. Expect to see more beneficiary awareness of Blue Button and the application choices available as we enter our second year of operation.

Industry Impact

Blue Button 2.0 is having a much wider impact than just the Medicare Fee for Service beneficiary population. The production of a Blue Button 2.0 Implementation Guide based on FHIR Release 4 has galvanized health plans into action to look at how they can do the same. Under the auspices of the CARIN Alliance, a collaborative effort focused on advancing Consumer-Mediated Exchange, has begun to develop a version of the Blue Button 2.0 Implementation Guide based on the new Release 4 of HL7 FHIR. 

Just as importantly, the under-the-cover work that is being carried out around code & value sets and a common terminology to define source data fields is also being used to accelerate one of the HL7 Da Vinci Project use cases: electronic Payer Data Exchange (ePDx). The Da Vinci Project is focused on leveraging the FHIR specification to improve real-world interoperability between payers and providers.

There are numerous people involved in more than one of these initiatives where the ultimate objective is to improve interoperability in healthcare in order to deliver better, more efficient and effective care to patients.

Standards, Software and Open Source

The vibrant, global community that supports and refines the HL7 FHIR specification has driven the creation of open source solutions and reference implementations. These are rapidly turning into cloud-based services and commercial products that will in turn drive greater adoption of the specification and help to improve interoperability.

The Blue Button 2.0 project was built using open source software and tools in the cloud. Like many other initiatives in the FHIR world, the code is available on GitHub for anyone to pick up and use. 

API Proliferation: Discovery and Registration

We are at a tipping point as the number of API endpoints is set to explode. The current mechanisms for registering applications at each API endpoint are clunky and not scalable.  Now is the time for the industry to come together and address these issues of API endpoint discovery and a robust dynamic application registration mechanism for certified applications. 

If we solve this the right way, in a way that leverages the strengths of the internet, we can create a win-win-win scenario for developers, data holders and consumers.

If we want to empower consumers – the last untapped resource that can transform healthcare – we have to give them choices in how they share their data as well as give them and the data holders confidence in the applications available in a vibrant consumer-facing application ecosystem.

It has been uplifting to see numerous thought leaders across the industry recognize that we need to address these scalability roadblocks. It is also encouraging to see a willingness to come together to tackle the challenge. It is a challenge that I am confident we can solve.

Interested in learning more? Come to my session at the HL7 HIMSS booth (4849) on Wednesday, February 13 from 4:10 - 4:40 pm.