A year ago I wrote a blog post for HL7 about Blue Button 2.0 and FHIR. A lot has happened since then, so I wanted to take this opportunity to review the progress that has been made in the past twelve months.
In 2015 the journey to build Blue Button 2.0 started with a vision to build a “developer-friendly, standards-based API that put beneficiaries in control of whom they shared their claims information.” That vision still drives Blue Button 2.0 to this day.
But Blue Button 2.0 has grown into an eco-system. The core data in HL7 FHIR format has been used to help Accountable Care Organizations and Providers by making the data available for the beneficiaries they care for available in bulk via the Beneficiary Claims Data API (BCDA) and the Data at the Point of Care (DPC) projects respectively. The data is also being used in numerous health plan selection tools, including the Medicare Coverage Tool on Medicare.gov.
In February 2019 CMS also unveiled the Interoperability and Patient Access proposed rule. This triggered plenty of activity in the wider healthcare community since Blue Button 2.0 was cited as an example API in the proposed rule.
The HL7 Da Vinci Project adapted the Payer Data Exchange Implementation Guide to respond to the requirements laid out in the proposed rule while the CARIN Alliance, also now a HL7 Accelerator project set about creating a Blue Button 2.0 Implementation Guide for Commercial Payers that followed the CMS lead but utilized the Release 4 version of FHIR that is the current version of the specification.
By the end of 2019 these Implementation Guides had already been tested at multiple HL7 Connectathons.
In the summer, the CARIN Alliance announced their Blue Button 2.0 Implementation Guide and immediately received support from a broad spectrum of insurers and technology companies. NewWave is one of the organizations that has partnered with these health plans and technology companies to support the CARIN Blue Button specification. NewWave is especially proud to be partnered with Microsoft to build the SAFHIR platform in the Azure cloud to deliver a highly scalable Blue Button 2.0 service for health plans.
The future looks bright for patient access to their data. In October the momentum behind Electronic Medical Record systems providing API access reached a tipping point as health systems needed to be able to demonstrate the API capability before the end of 2019. There are now thousands more API endpoints where patient’s can connect their health information to third-party applications, like NewWave’s MyCareAI.
The proliferation of API endpoints creates a new challenge that NewWave has worked with other standard-setting organizations to solve. How do developer’s get their apps connected to these thousands of API endpoints in a scalable way? At the same time, how do consumers know which apps to trust?
Fortunately, work has been progressing to address these challenges. On the policy front The CARIN Alliance created a Code of Conduct for consumer-mediated exchange applications. While on the standards front a specification to support what we refer to as a “Community of Trust” through an enhancement to OAuth2.0’s Dynamic Client Registration Protocol (DCRP) – “Trusted DCRP” was published in one of the HL7 Da Vinci Implementation Guides. This is critically important work if we are to establish as a community to: a) enable consumers to evaluate the trust-worthiness of the applications they use and b) enable developer’s to get their trusted applications registered at the rapidly growing number of API endpoints while c) enabling data holders to have confidence in the apps that are connecting to their FHIR-based APIs.
We are stronger as a community
The power of the HL7 FHIR specification is the community that has created and tested the specification. As the specification enters a period of dynamic growth we will face many challenges.
- As already outlined above, the registering of applications needs to become a scalable process.
- As Implementation Guides proliferate, we risk seeing multiple ways of profiling the same resource, making implementation more complex.
The HL7 Da Vinci has already taken steps to profile frequently used FHIR resources once and leverage those profiles across multiple
Implementation Guides: We need to focus efforts to accomplish the same pragmatic approach for value sets and coding systems to enable clinical and claims information to be handled consistently without losing precision as data is transformed back and forth between different coding systems.
Now is the time to re-double our efforts to work as one community to solve these challenges. We are stronger together. If we fail to make this effort, we will find ourselves burdened with esoteric implementations of quasi-standards for years to come.
In the last decade we accomplished enormous strides in interoperability, but we’ve still only scratched the surface of what needs to be accomplished. However, all the tools are in play. We have a growing toolkit that comprises AI and machine learning, on-demand cloud capacity, standards-based open source software and a growing community of developers that are comfortable building new solutions using these tools.
The next decade is certain to be an exciting one. With data flowing through interoperability solutions, like NewWave’s SAFHIR, and the ability to apply AI, with tools like iQuartic, to turn the expanding mass of data into actionable information. We are looking at amazing opportunities to bend the cost curve in healthcare, deliver true value-based care where consumers are truly empowered through tools that enable them to participate actively in their own care and the care of those they care about.
By working together, supporting standards development, adopting standards-based solutions and deploying them to secure, privacy-protecting cloud platforms we will truly be “Solving for the Greater Good!”