Taction Software®
Healthcare IT Glossary

What is Blue Button?
Blue Button 2.0 API

The idea started simply: give patients a button they can click to download their health data. What began as a download feature on a VA website has evolved into a full FHIR-based API that lets 65+ million Medicare beneficiaries authorize third-party apps to access four years of claims history, coverage information, and clinical data — setting the template for patient-controlled health data access across the entire U.S. healthcare system.

Definition of Blue ButtonHow Blue Button Works in HealthcareKey Blue Button Standards and SpecificationsImplementation ConsiderationsHow Taction Helps with Blue Button

Definition of Blue Button

Blue Button is a patient data access initiative originally launched by the U.S. Department of Veterans Affairs (VA) in 2010 and subsequently adopted and expanded by CMS into what is now known as Blue Button 2.0 — a production FHIR R4 API that allows Medicare beneficiaries to connect their claims and health data to applications of their choice.

The evolution of Blue Button tracks the broader evolution of patient data access in U.S. healthcare:

Blue Button 1.0 (2010): The VA launched a simple “Blue Button” feature on the MyHealtheVet portal — a download button that let veterans export their health data as a text file. The concept spread to CMS’s Medicare.gov portal and was adopted by health plans, pharmacies, and providers through the Blue Button Pledge initiative.

Blue Button 2.0 (2018): CMS launched a FHIR-based API that transformed Blue Button from a manual download into a standards-based, application-accessible data service. Blue Button 2.0 exposes Medicare Part A, Part B, and Part D claims data (up to four years of history), beneficiary demographics, and coverage information through FHIR resources — accessible by any authorized third-party application via OAuth 2.0 authorization.

Blue Button 2.0 became the proof-of-concept for CMS’s broader interoperability agenda. It demonstrated that FHIR-based patient access APIs could work at scale — serving millions of beneficiaries and hundreds of registered applications — and directly influenced the CMS Interoperability and Patient Access Final Rule, which extended similar API requirements to all CMS-regulated health plans.

In simple terms: Blue Button 2.0 is CMS’s FHIR API for Medicare — the live, production system that lets Medicare beneficiaries authorize apps to access their claims and health data, and the model for patient data access across all U.S. health plans.

How Blue Button Works in Healthcare

Blue Button 2.0 operates as a standard FHIR API with OAuth 2.0 authorization — following the same patterns that SMART on FHIR uses for EHR app integration.

Use cases for Blue Button data:

Health and wellness apps that help beneficiaries understand their care history and costs. Care coordination platforms that aggregate a patient’s claims across providers to identify gaps and duplications. Research platforms that use de-identified or consented claims data for epidemiological studies. Population health analytics that combine claims data with clinical data for comprehensive risk assessment. Financial planning tools that help beneficiaries estimate out-of-pocket costs and compare plan options.

App registration
Developers register their applications with the CMS Blue Button API developer portal. Registration provides a client ID and client secret, defines redirect URIs, and specifies the application’s purpose and data access needs. CMS reviews applications before granting production access.
Patient authorization
When a Medicare beneficiary wants to use a Blue Button-connected app, the app redirects them to Medicare.gov for authentication. The beneficiary logs in with their Medicare.gov credentials, reviews what data the app is requesting, and grants or denies authorization. This follows the standard OAuth 2.0 authorization code flow.
Data access via FHIR API
Once authorized, the app receives an access token and can query the Blue Button 2.0 FHIR endpoints for the beneficiary’s data. The API exposes three primary FHIR resource types:
Patient
— Beneficiary demographics (name, date of birth, address, Medicare identifier).
ExplanationOfBenefit (EOB)
— Claims data for Part A (inpatient), Part B (outpatient/physician), and Part D (prescription drug) services. Each EOB contains service dates, provider information, diagnosis codes (ICD-10), procedure codes (CPT/HCPCS), billed amounts, allowed amounts, and beneficiary cost-sharing.
Coverage
— Medicare plan enrollment information, including Part A, Part B, Part C (Medicare Advantage), and Part D coverage periods and plan identifiers.
Data scope and history
Blue Button 2.0 provides up to four years of historical claims data. For beneficiaries enrolled in Medicare Advantage (Part C), claims data is limited because MA plans process their own claims — only fee-for-service claims flow through CMS’s systems. This is a known limitation that CMS is addressing through the CMS Interoperability rules requiring MA plans to provide their own Patient Access APIs.

Key Blue Button Standards and Specifications

Legacy
FHIR R4 with CARIN IG
Blue Button 2.0 uses FHIR R4 and aligns with the CARIN Alliance Consumer Directed Payer Data Exchange (CARIN IG for Blue Button) implementation guide. The CARIN IG defines the FHIR profiles for ExplanationOfBenefit, Coverage, Patient, and related resources — standardizing how payer claims data is represented in FHIR. This same IG is now required for all CMS-regulated payer Patient Access APIs, making Blue Button 2.0 the reference implementation.
Legacy
OAuth 2.0 Authorization
Blue Button 2.0 uses OAuth 2.0 for patient authorization — the same protocol foundation that SMART on FHIR uses for EHR integration. Apps request specific scopes (patient/ExplanationOfBenefit.read, patient/Coverage.read, patient/Patient.read), and the authorization server grants access based on the beneficiary’s consent.
Legacy
CMS Interoperability Rules
The CMS Interoperability and Patient Access Final Rule extended the Blue Button model to all CMS-regulated payers — Medicare Advantage, Medicaid managed care, CHIP, and QHP issuers on the federal marketplace. These payers must implement FHIR-based Patient Access APIs that expose claims, encounters, clinical data (USCDI), and provider directory information — following the same CARIN IG and Da Vinci implementation guides that Blue Button 2.0 pioneered.
Legacy
Privacy and Security
Blue Button 2.0 operates under CMS’s privacy framework — beneficiaries must affirmatively authorize each app, and CMS provides transparency about what data is being shared. However, once data leaves CMS’s systems and enters a third-party app, HIPAA does not necessarily apply (third-party consumer apps are generally not HIPAA-covered entities). This creates a policy tension — beneficiaries have the right to share their data, but the privacy protections follow the data only if the receiving app voluntarily commits to privacy standards.
Building an Blue Button integration? Let’s talk.
Book a free call

Implementation Considerations

For developers building Blue Button-connected applications, and for payers implementing Patient Access APIs modeled on Blue Button.

Consent and transparency. Apps that access Blue Button data should clearly communicate to users what data is being accessed, how it will be used, and how it will be protected. Even though HIPAA may not apply to the app, FTC Act protections against unfair or deceptive practices do — and CMS monitors the Blue Button ecosystem for apps that mishandle beneficiary data.

Developer sandbox first
CMS provides a Blue Button 2.0 sandbox environment with synthetic data for development and testing. Build and test against the sandbox before applying for production access. The sandbox mirrors the production API’s behavior, FHIR resource structure, and OAuth flow.
ExplanationOfBenefit resource complexity
The EOB resource in Blue Button 2.0 is complex — it carries dense claims data with multiple adjudication lines, adjustment reasons, and payer-specific extensions. Parse carefully and map to your application’s data model with thorough testing. Not every field is populated for every claim type.
Medicare Advantage data gaps
For beneficiaries enrolled in Medicare Advantage plans, Blue Button 2.0 has limited claims data because MA plans adjudicate their own claims. Your app’s user experience should communicate this limitation clearly — beneficiaries may expect complete data and be confused when MA claims are missing.
Rate limiting and performance
Blue Button 2.0 enforces rate limits on API calls. For applications serving large user populations, implement caching, pagination handling, and background data synchronization rather than querying the API in real time on every user interaction.
Building payer Patient Access APIs
If you’re a health plan building a Patient Access API to comply with CMS interoperability rules, Blue Button 2.0 is your reference implementation. Use the CARIN IG for Blue Button profiles, implement OAuth 2.0 authorization, expose ExplanationOfBenefit, Coverage, and Patient resources, and test against the ONC and Da Vinci testing tools.

How Taction Helps with Blue Button

At Taction, our team builds Blue Button-connected applications and helps health plans implement Patient Access APIs modeled on the Blue Button architecture.

What we do:

Whether you’re building a Blue Button-connected app, implementing a payer Patient Access API, or integrating claims data into clinical workflows, our healthcare interoperability team delivers the FHIR expertise and payer domain knowledge these implementations require.

Blue Button app development
We build consumer and clinical applications that connect to CMS Blue Button 2.0, parsing ExplanationOfBenefit, Coverage, and Patient resources into actionable health and financial insights for Medicare beneficiaries.
Payer Patient Access API development
For health plans subject to CMS interoperability rules, we build FHIR-based Patient Access APIs conforming to the CARIN IG for Blue Button — exposing claims, coverage, and clinical data to beneficiary-authorized applications.
CARIN IG implementation
We implement CARIN Alliance Blue Button FHIR profiles for ExplanationOfBenefit, Coverage, Patient, and related resources — ensuring conformance with the implementation guide that CMS mandates.
OAuth 2.0 authorization
We build the authorization infrastructure that handles beneficiary consent, token management, scope enforcement, and audit logging for patient-facing data access APIs.
Claims data analytics
We build analytics platforms that aggregate Blue Button claims data with EHR clinical data for comprehensive patient profiles, care gap identification, and value-based care performance measurement.

Explore Related Terms

What is Patient Portal?What is HIE?

Ready to discuss your Blue Button project?

Schedule a free call

Ready to Discuss Your Project With Us?

Your email address will not be published. Required fields are marked *

What is 1 + 1 ?

What's Next?

Our expert reaches out shortly after receiving your request and analyzing your requirements.

If needed, we sign an NDA to protect your privacy.

We request additional information to better understand and analyze your project.

We schedule a call to discuss your project, goals. and priorities, and provide preliminary feedback.

If you're satisfied, we finalize the agreement and start your project.