In the same way that there has been tremendous evolution in value-based models in the past decade, the way in which we access and use health data has also gone through a sea change.
There has been an increased drive to standardization of both the representation of the data and the means by which we move that data around. The Centers for Medicare and Medicaid Services (CMS) introduced the Interoperability and Patient Access final rule in March of 2020. In it, the FHIR standard was adopted as the way forward. This is a standard that has been in the making since 2011, and builds on top of previous widely used standards, upgrading healthcare data representation and exchange to a modern, stateless, uniformly-addressable scheme that piggybacks on the RESTful architecture of the web. The adoption of FHIR by CMS was hot on the heels of the first normative release of FHIR in October 2019, in other words, the first version not considered to be a draft or a trial. This version benefits from the 8 years of increased adoption of the burgeoning standard by health systems and technology providers, not only in the US but globally as well.
The drive behind standardization has fairly evident reasons. As systems scale, fragmentation of both data representation and methods of exchange means increasing complexity. Basically, more things to think about and manage, when either adding or improving functionality at the individual component level and when interconnecting components, within and across organizations. This complexity in turn means increased risk of critical failures, in terms of ineffective implementation, security exposure, performance bottlenecks, to name a few possibilities. All of this ultimately means costs that get out of control, which feeds into a vicious cycle that gets us worse outcomes for patients, providers, and healthcare systems in general.
Which gets us back to CMS and setting a path forward, where all partners can benefit from the shared bases for how we craft messages, with common representations for patients and their history, and how we deliver those messages.
CMS has a few APIs available for different programs and use cases, as well openly queriable datasets, with a wealth of public information. Three APIs are of particular interest to providers and Direct Contracting Entities (DCEs) participating in the Global and Professional Direct Contracting (GPDC) program.
- Beneficiary Claims Data API (BCDA): allows ACOs, DCEs, and similar entities who are assigned beneficiaries to download data for those beneficiaries in bulk. The normal flow makes data available weekly, but there’s nothing preventing this from becoming more frequent in the future.
- Blue Button 2.0 API: this is the latest iteration of a program started in 2010 that enabled veterans in the VA and Medicare beneficiaries to download their health records either for personal use or for sharing with providers. Blue Button 2.0 introduced greater interoperability through FHIR adoption as well as OAuth 2.0 for beneficiaries to be able to directly give discrete access to their data to third-party applications, on the web or mobile.
- Data at the Point of Care API (DPC): DPC is a pilot program that also makes patient fee-for-service data available in FHIR format. The distinction is that, where BCDA is for entities in alternative payment models and Blue Button requires beneficiary interaction, DPC is meant to serve healthcare providers directly, to fill in gaps in history as they are seeing a patient.
The more immediately applicable API for GPDC is BCDA, as it is an alternative to the traditional (monthly) download of patient and claim data through Claim and Claim Line Feed files.
For those with a technical background, the Getting Started section for BCDA is a good place to begin to understand the possibilities. The BCDA team provides sandboxes of different sizes with synthetic data. Synthetic data models the live beneficiary data you would get when using the API, and allows you to develop against the API without access to a production API endpoint or dataset. These sandboxes range in size from 50 to 30,000 beneficiaries.
In my particular case, I wanted to get a good feel for how to work with this API using Python. I didn’t find any Python clients to consume FHIR data from the BCDA endpoints, so I built my own, following the instructions in the guide and also taking a look at the open-sourced BCDA API server.
It helps that CMS and the government have a strong commitment to open source and modern technical collaboration. I encourage you to read the Digital Services Playbook. It is meant to provide guiding principles for technological choices across the many US government’s departments. In particular, Play 13 calls for making websites, datasets, and services in general as open as possible. Hurray!
In the spirit of Play 13, Pearl Health has open sourced the starter client I built for BCDA. Take a look at our BCDA Quickstart GitHub project:
https://github.com/PearlHealth/bcda-quickstart
The project is more of a proof of concept than a production-grade client, and makes limited choices for working with the files outputted by the API. Some choices for an actual use of this client are left to your specific architecture’s details. For example, how/where to store the response data, and how to effectively use the timestamp of last retrieval to make sure you are downloading only incrementals and not the full dataset every time. See the README file of the project for more details. In particular, I want to call out the excellent FHIR Resources Python project. We all can get to better places faster if we share through open sourcing. Open sourcing for a wide variety of projects makes sense, because the real competitive advantages are in how you use data and the service you provide, and not on fencing in building blocks where there’s common understanding.
Lastly, I wanted to also encourage you to interact directly with CMS if you are using their APIs. All of the APIs mentioned here have Google groups where you can ask questions to CMS and to the respective communities of API users. You can find the Google groups in the pages linked above for the individual APIs. The folks at CMS are pretty responsive and asking questions is another way to make this public API better for all.
Interested in solving life-changing problems as part of a world-class engineering team? Check out our open opportunities or reach out directly.
