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.
Our experts are ready to understand your business goals.
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.
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.
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.
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.
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.
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.
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.
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.
For developers building Blue Button-connected applications, and for payers implementing Patient Access APIs modeled on Blue Button.
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.
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.
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:
Explore related glossary terms:
Your email address will not be published. Required fields are marked *
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.