Blue Button 2.0

Interoperability in healthcare has been a top buzzword in the industry for a while now. It’s the ability for distinct healthcare information systems and devices to seamlessly exchange and interpret health-related data.

This techno-functional enabler for healthcare ecosystems is being used to solve pressing health data availability issues, and pave the way for better delivery of care and patient outcomes.

Along with EMR/EHR records (that carry a patient’s health records, including diagnoses, tests, prescriptions, etc.), health insurance and claims data is hugely valuable in the endeavor for healthcare interoperability.

Combined data can provide additional insights and information surrounding a patient’s medical history. It does so in terms of appointments, procedures, and treatments used, as well as aspects like the number of readmissions or expenses incurred to address particular health conditions.

There are many use cases for health insurance data in healthcare and research. Now there’s a handy tool that can help application developers or healthcare interoperability implementers access a reliable data warehouse of claims (with permission from the beneficiary): Blue Button 2.0.

What Is Blue Button 2.0?

Blue Button is a secure interoperability tool to fetch and use claims data for a number of healthcare and health application use cases. It’s an Application Programming Interface (API) that allows Medicare beneficiaries to share their claims data with 3rd-party apps. And, it’s an open-source initiative by the CMS (Centers for Medicare and Medicaid Services).

Blue Button 2.0 uses HL7/FHIR and OAuth2.0 standards for beneficiary data and authorization. It allows developers to build integration mechanisms for their applications to access more than four years of Medicare Part A, B, and D data. It does this for 53 million+ Medicare beneficiaries.

For the beneficiary to access data with Blue Button 2.0, they must provide explicit authorization to the requesting system/application. MyMedicare.gov controls all beneficiary identification and authorization.

How Does Blue Button 2.0 Provide Value?

When integrated with applications for use-cases of relevance, Blue Button 2.0 offers value to providers, caregivers, researchers, payors, or beneficiaries (nearly every type of stakeholder or player in the healthcare and medical research space).

Here are some ideas on how to leverage Blue Button 2.0 for your next interoperability or healthcare project:

• Blue Button 2.0 provides a variety of data about a beneficiary’s health, including the type of Medicare plan, prescriptions, and primary care treatments, as well as cost. Nearly 1,300 fields from the CMS claims data warehouse are mapped to FHIR across the core resources of Patient, Coverage, and Explanation of Benefits.
• The mapped records include

• Beneficiary Enrollment Record
• Carrier Claims
• Durable Medical Equipment
• Home Health Agency Claims
• Hospice Claims
• Inpatient and Outpatient Claims
• Part D Events
• Skilled Nursing Facility Claims

How Does Blue Button 2.0 Work?

Blue Button 2.0 leverages coding systems specific to Medicare billing and other standard and recognized coding systems. There’s a lot that can be done with a useful interoperability tool like the Blue Button 2.0 API. Whether it’s:

• Making your app easier for patients to use by pre-filling data that’s relevant to them,
• Giving them a consolidated, unified view of their health history, or even,
• Spinning up interesting and insightful health dashboards so they remain engaged in the process of their health care.

Researchers can also use the wealth of the CMS claims data warehouse to fetch and gather insights from datasets of interest.

These are some of Blue Button 2.0’s features:

• The Explanation of Benefits (also called as Episode of Care) carries the bulk of the beneficiary data. The API response can include several thousand lines.
• The Patient resource contains the beneficiary’s demographics and other administrative, non-medical information – including contact information.
• The Coverage resource consists of the beneficiary’s insurance plan information.
• CMS says it updates the Medicare Part A and B claims data weekly and the Part D data monthly. Developers are encouraged to have their applications run jobs to refresh the data that they use on a daily basis. They should do this while also adhering to the usage limits defined in the API’s Terms of Use.
• It’s important to note that the API doesn’t share information such as the date of birth,SSN, and HICN. These security measures prevent worries for beneficiaries when they authorize applications to access their claims data. The applications should also provide an adequate explanation so patients clearly understand what data will be accessed and how it will be used.
• The system requesting claims information may need to access large volumes of data via the API. To improve performance, developers are given the option to turn on compression for specific content types. When turned on, the compression is applied when the payload exceeds 1kB in size. This is a helpful feature that can lessen the chance of a system being plagued by slow responses or poor user experience.
• To help developers when testing their applications with the API, CMS offers a synthetic data set to test against. This means that API calls will return near-real-world values and provide a fair idea of whether the application can meet the objectives that it’s been designed for.
• Developers can also access the full synthetic data set – another useful feature to understand the types of data available, their co-relations, and how to better design an application.
• It’s possible that beneficiaries could initially grant and later choose to revoke access to their claims data. This can be performed via the MyMedicare.gov website. In these cases, the application will show that access has been revoked, and the user interface will tell the beneficiary how their data is being used.
• CMS must approve all Blue Button API applications before going live. They require that certain conditions be met by the organization launching the app, as well as information about, and a demonstration of, the developed app. This process usually takes a couple of weeks and could involve calls and meetings with the CMS Blue Button API Team. It also means agreeing to the Terms of Use and accepting a future audit. This is a part of the Production API access renewal process for app version updates or to keep in sync with the evolution of the Blue Button API itself.

Need More Information?

This was a quick overview of the Blue Button 2.0 API and its features, and there’s more that we’d be happy to share.

Get started on your Blue Button 2.0 project today and reap the benefits of using this super-useful API! Get in touch with Boston Technology Corporation to learn more or to explore deeper aspects of implementation for the unique needs of your project or organization.