APIs or application programming interfaces have been the future of healthcare for some years now. It is undoubtedly true that – all things being equal – an increase in the use in APIs will make healthcare interoperability more affordable and efficient. Existing point-to-point interfaces that are the historic norm in healthcare (one can think of ADT or admission, discharge, and transfer interfaces or SIU or unsolicited scheduling interfaces) are costly and prone to significant scalability problems.

            In the provider community such challenges have made interoperability difficult; nevertheless, the challenge is even more daunting when it comes to exchanging data from health plans. Many health plans have methods to share claims or other data with providers, organizations representing providers such IPAs (independent practice associations), individual practices, and patients. The challenge, however, is that the data is often somewhat dated when it is received and nearly every payer uses a proprietary format. Claims data often comes in a series of delimited text files. A delimited text file could have each field separated by a comma, a tab, or another character such a pipe ( “|”). Additionally, there are often different files for different types of claims data such as membership files, pharmacy claims, etc. Organizations wishing to use such data must load it in batch.

            CMS – in its continuing drive to push for more efficient interoperability – released in 2018 an API that has access to over four years of Medicare Part A, B, and D data for more than fifty million Americans. The API is based on FHIR – fast healthcare interoperability resources – which is a standard developed to facilitate the exchange of healthcare data through APIs. In contrast to CCDAs, FHIR is discrete, not document-based. It is built around exposing specific discrete sets of healthcare data; in contrast, the CCDA standard is used to describe the creation of a specific document containing a significant quantity of clinical data (e.g., a summary of care after an inpatient visit). The API allows software developers to create beneficiary facing applications and for beneficiaries to grand an application access to up to four years of Medicare claims data. This data can provide information on a patient’s medical conditions, procedures performed, and medications dispensed. The Blue Button API is also extremely useful to research programs where the data on subjects can be largely pre-filled and researchers may be provided with additional data that will assist in exploring topics further. CMS is intending for the API to be used to better empower consumers to manage their health and to spur health information technology innovation.

            For developers, CMS has tried to make implementing the API as easy as possible. There is a specific website – https://bluebutton.cms.gov/developers/ – where developers can go to read through the API specifications, the data models, and guidelines for use. Moreover, there is information on accessing a CMS sandbox and accessing sample beneficiaries. There is a registration process for applications and CMS provides information on the website as well. 

            There are some points that developers and organizations must be aware of prior to beginning the development and planning the implementation of Blue Button API-based solutions. Access to the API is consent based – i.e., the beneficiary has to allow the application to access their records; moreover, the application must honor the beneficiary’s request to revoke consent. This is similar to how the Google API works. A developer requests access to a certain set of information and the continued access to that information can be managed from each individual’s Google account.

            The Blue Button API increases the ability for software developers to rapidly deploy software that empowers Medicare beneficiaries to take control of their healthcare by providing applications with access to their Medicare claims data. It is hoped that this project will serve as a catalyst for other health plans to develop APIs to enable more consumer empowerment in healthcare.

Categories: Healthcare IT


Your thoughts?