What the CMS Patient Access API requires from US health plans, the FHIR profiles it uses (CARIN Blue Button, US Core), how an app registers and authorizes, and where the data can live with consent.
The CMS Patient Access API is the FHIR R4 API that US health plans regulated by CMS must offer so their members can pull their own claims and clinical data into any app they choose. It uses US Core, CARIN Blue Button and SMART App Launch with OAuth 2.0; your app registers with each payer, asks the member to sign in and consent, and then reads the data as FHIR resources.
Who has to offer it
The CMS Interoperability and Patient Access final rule (CMS-9115-F, 2020) requires a Patient Access API from:
Medicare Advantage organizations;
state Medicaid and CHIP fee-for-service programs and their managed care plans;
qualified health plan issuers on the federally facilitated exchanges.
Original Medicare offers the same kind of access through its own Blue Button 2.0 API. Hospitals and physicians are not covered by this rule; their patient-facing APIs come from the ONC certification rules behind the Cures Act.
The later Interoperability and Prior Authorization final rule (CMS-0057-F, 2024) extends the Patient Access API with prior authorization information and adds Provider Access, Payer-to-Payer and Prior Authorization APIs, with most API requirements due from January 2027.
What data comes back
Data
FHIR profiles
Typical resources
Claims and encounters (adjudicated)
CARIN Consumer Directed Payer Data Exchange (CARIN Blue Button)
Plans must make data available back to January 1, 2016 for current members. Coverage, formats and freshness vary by plan, so always read each plan's capability statement (/metadata) and SMART configuration (/.well-known/smart-configuration).
How an app connects
Register with each payer. Most plans run a developer portal where you register a client, describe your app and agree to their terms. Plans may ask about your privacy policy; they cannot block an app for reasons other than a security risk to their systems.
Discover the endpoints. Read /.well-known/smart-configuration for the authorization and token endpoints and the scopes the plan supports.
Authorize the member. Use the SMART App Launch standalone flow with PKCE: the member signs in at the plan and approves scopes such as patient/ExplanationOfBenefit.read (SMART v1) or patient/ExplanationOfBenefit.rs (SMART v2).
Read the data. Call the FHIR API with the access token, page through results (Bundle.link with next) and keep the refresh token only as long as the member wants the connection.
Where Anpheros fits
The Patient Access API gives your app read access to one plan. Anpheros Platform is where that data can live next to everything else a person brings: lab results from other labs, wearable data, documents and notes, in one FHIR R4 record per person, with provenance on every write and access only by the person's consent.
Map ExplanationOfBenefit lines to the person's timeline and keep the original resource for audit.
Record where each item came from (Provenance with the plan as source), so a later read by a clinician shows it was claims data, not a clinical note.
Let the person revoke the plan connection and the data sharing separately.
Anpheros is hosted in the EU. A US data region and a HIPAA business associate agreement (BAA) are available on request for production customers; production for US patient data starts only after the BAA is signed. Build and test on the free sandbox with synthetic patients.
Frequently asked questions
What is the CMS Patient Access API?
A FHIR R4 API that CMS-regulated payers (Medicare Advantage, Medicaid, CHIP and federal exchange plans) must provide so members can share their claims and clinical data with the app of their choice, using SMART App Launch and OAuth 2.0.
Which FHIR implementation guides does it use?
CARIN Blue Button for claims (ExplanationOfBenefit), US Core for clinical data, Da Vinci PDex US Drug Formulary for formularies and SMART App Launch for authorization.
Can a health plan refuse to connect my app?
Only to protect its own systems from a security risk, assessed with objective criteria. It may ask whether your app has a privacy policy and inform members about it, but it cannot judge which apps members should use.
Does Anpheros connect to payers for me?
No. Your app connects to each payer with the member's authorization; Anpheros stores what the person chooses to keep, with consent and provenance, and gives other apps access only when the person agrees.
