Patient Access API (CMS-9115-F)

Patient Access API (CMS-9115-F)

The Patient Access API is the foundational interoperability obligation under CMS-9115-F (Interoperability and Patient Access Final Rule, 2020). It requires covered payers to implement a FHIR R4 API that allows a patient — through a third-party application of their choice — to retrieve their own health data. Compliance was required by July 1, 2021.

This is existing regulation, not upcoming. Payers that were in scope in 2021 should already have compliant implementations. This article documents the technical requirements, data scope, and the relationship to subsequent rules (CMS-0057-F).

For the broader CMS interoperability picture, see CMS Interoperability Rules. For the provider-initiated equivalent (CMS-0057-F, 2027), see Provider Access API.

Who is covered

CMS-9115-F applies to the following payer types:

Payer typeNotes
Medicare Advantage (MA) organizationsCMS-regulated plans
State Medicaid fee-for-service (FFS) programsState agencies operating Medicaid directly
Children’s Health Insurance Program (CHIP)FFS programs
Qualified Health Plan (QHP) issuers on Federally Facilitated Exchanges (FFEs)Marketplace plans

Not covered: Commercial/employer-sponsored group health plans, fee-for-service Medicare (CMS operates Blue Button 2.0 directly for beneficiaries), Medicaid managed care organizations (separately regulated, subject to CMS rules but with different timelines).

This is an important boundary. A commercial insurer offering employer-sponsored plans is not subject to CMS-9115-F’s Patient Access API requirement for those lines of business. If the same insurer also offers MA plans, the MA line is subject to the rule.

What the API must provide

The Patient Access API must give patients access to the following data categories:

Claims and encounter data

Adjudicated claims data, represented using CARIN Blue Button Implementation Guide profiles on the FHIR ExplanationOfBenefit resource. CARIN Blue Button defines four EOB profile types:

CARIN EOB profileClaim type
Inpatient InstitutionalHospital inpatient stays
Outpatient InstitutionalHospital outpatient services
Professional/Non-ClinicianPhysician and other professional services
PharmacyPrescription drug claims

Each profile maps payer claims data fields to FHIR elements. For example, the professional EOB includes diagnosis codes, procedure codes, servicing provider NPI, allowed and paid amounts, and adjudication status.

Clinical data

Clinical information the payer holds, represented using US Core FHIR profiles. This includes:

  • Conditions (US Core Condition)
  • Observations and laboratory results (US Core Observation)
  • Procedures (US Core Procedure)
  • Medications and dispense records
  • Allergies and intolerances
  • Immunizations

The scope of clinical data available from a payer is typically derived from claims data — not from direct clinical records (payers don’t maintain EHRs). A diagnosis code on a claim becomes a Condition resource; a procedure code becomes a Procedure resource.

Coverage information

The patient’s current and historical coverage, represented as FHIR Coverage resources. This tells an app what plan the patient is on, the member ID, the payer, and coverage period.

Prior authorization data (added by CMS-0057-F)

Prior authorization data was not required in the original CMS-9115-F Patient Access API. CMS-0057-F (2024) added the requirement that PA data — including denial reasons — must be included in Patient Access API responses. The compliance deadline for PA data in Patient Access is January 1, 2026.

Technical standard: SMART App Launch

The Patient Access API uses the SMART App Launch Framework with the OAuth2 authorization code grant (also called the authorization code flow). This is the patient-facing authentication model: the patient authenticates with the payer’s identity provider and explicitly consents to data access by the third-party app.

Authorization code flow

The sequence for a SMART-connected app retrieving patient data:

  1. App initiates — the patient opens a third-party health app and chooses to connect to their payer
  2. Redirect to payer authorization server — the app redirects the patient’s browser to the payer’s OAuth2 authorization endpoint, passing the requested scopes and a redirect URI
  3. Patient authenticates — the patient logs in to their payer account (portal credentials or similar)
  4. Patient consents — the authorization server presents a consent screen showing what data the app is requesting
  5. Authorization code issued — the payer redirects back to the app with an authorization code
  6. Token exchange — the app exchanges the authorization code for an access token (and optional refresh token) by calling the token endpoint
  7. API calls — the app calls the FHIR server using the access token in the Authorization: Bearer header
  8. Data returned — the payer’s FHIR server returns the requested resources

The token exchange step (step 6) looks like this:

POST /token HTTP/1.1
Host: payer.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTH_CODE_FROM_STEP_5
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
&client_id=my-health-app
&code_verifier=PKCE_VERIFIER

The payer’s token endpoint responds with:

{
  "access_token": "eyJhbGciOiJSUzI1NiJ9...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "patient/Patient.read patient/ExplanationOfBenefit.read patient/Coverage.read",
  "patient": "Patient/payer-member-id-123",
  "refresh_token": "8xLOxBtZp8"
}

The patient field in the token response is the SMART patient context — the app uses this value as the patient reference for all subsequent FHIR queries.

How this differs from Provider Access API

The Patient Access API uses the authorization code grant — the patient is present, authenticates, and consents. The Provider Access API (CMS-0057-F, January 2027) uses SMART Backend Services (client credentials) — no patient login, system-to-system, with provider organizational credentials. The two APIs serve different requesters and use different OAuth2 flows. See Provider Access API for the provider-initiated model.

CARIN Blue Button profiles in detail

CARIN Blue Button is a HL7 FHIR Implementation Guide developed by the CARIN Alliance that defines how payer claims data maps to FHIR resources. CMS-9115-F mandates CARIN Blue Button for claims data in the Patient Access API.

An ExplanationOfBenefit resource using CARIN Blue Button profiles represents a single adjudicated claim. A minimal example of a professional EOB:

{
  "resourceType": "ExplanationOfBenefit",
  "id": "eob-professional-001",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-ExplanationOfBenefit-Professional-NonClinician"
    ]
  },
  "status": "active",
  "type": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/claim-type",
      "code": "professional"
    }]
  },
  "use": "claim",
  "patient": { "reference": "Patient/payer-member-id-123" },
  "billablePeriod": {
    "start": "2024-08-15",
    "end": "2024-08-15"
  },
  "created": "2024-08-22",
  "insurer": { "reference": "Organization/payer-acme" },
  "provider": { "reference": "Organization/provider-clinic-456" },
  "outcome": "complete",
  "diagnosis": [{
    "sequence": 1,
    "diagnosisCodeableConcept": {
      "coding": [{
        "system": "http://hl7.org/fhir/sid/icd-10-cm",
        "code": "J06.9",
        "display": "Acute upper respiratory infection, unspecified"
      }]
    }
  }],
  "total": [
    {
      "category": {
        "coding": [{ "code": "submitted" }]
      },
      "amount": { "value": 185.00, "currency": "USD" }
    },
    {
      "category": {
        "coding": [{ "code": "benefit" }]
      },
      "amount": { "value": 148.00, "currency": "USD" }
    }
  ]
}

This is a stripped-down example. Production CARIN Blue Button EOBs include adjudication details, line-item services, rendering provider NPI, subscriber information, and additional claim-specific fields.

Provider Directory API

CMS-9115-F also requires covered payers to implement a Provider Directory API — a public-facing FHIR API that exposes the payer’s network directory (which providers participate in the plan). The technical standard is the Da Vinci PDex Plan Net Implementation Guide.

The Provider Directory API is patient-facing in the sense that it is unauthenticated (no patient login required) — anyone can query it to find in-network providers. It is separate from the Patient Access API but required by the same rule.

Plan Net profiles include: PlannetOrganization, PlannetPractitioner, PlannetPractitionerRole, PlannetLocation, PlannetNetwork, PlannetEndpoint.

Penalties for non-compliance

CMS-9115-F enforcement is primarily through public reporting. CMS can publicly report payers that are non-compliant, which creates reputational and market pressure. CMS can also refer persistent non-compliance to the appropriate federal or state agency.

Civil monetary penalties are available in statute but have been rarely invoked for Patient Access API non-compliance specifically. CMS’s enforcement posture has been more active with CMS-0057-F given the prior track record on CMS-9115-F compliance quality across the industry.

Relationship to CMS-0057-F (2024)

CMS-0057-F (Interoperability and Prior Authorization Final Rule) did not replace CMS-9115-F. It built on top of it.

AspectCMS-9115-F (2021)CMS-0057-F (added requirements)
Patient Access APIEstablished (claims, clinical, coverage)Adds prior authorization data (Jan 1, 2026)
Provider Directory APIEstablished (Plan Net IG)No change
Payer-to-PayerInitial requirementUpdated, expanded (Jan 1, 2027)
Provider Access APINot establishedNew requirement (Jan 1, 2027)
Prior Authorization APINot establishedNew requirement (Jan 1, 2026)

Payers must comply with all obligations under both rules. The Patient Access API established under CMS-9115-F continues to operate; CMS-0057-F layered additional data scope (prior auth) and new APIs (Provider Access, Prior Auth API) on top of it.

Implementation checklist

  • FHIR R4 endpoint live with SMART App Launch capability statement
  • Authorization code flow (PKCE required) operational
  • Patient portal credential used for SMART login
  • ExplanationOfBenefit resources conforming to CARIN Blue Button profiles (all four EOB types)
  • US Core profiles for clinical data (Condition, Observation, Procedure, etc.)
  • Coverage resource for current and historical coverage
  • Provider Directory API (Plan Net IG) publicly accessible
  • Patient context returned in token response (patient claim)
  • Prior authorization data included (compliance by January 1, 2026 under CMS-0057-F)

See also

Section: regulation Content Type: overview Audience: mixed
US
CMS
interoperability
Published: 17/02/2023 Modified: 07/12/2025 12 min read
Keywords: Patient Access API CMS-9115-F CARIN Blue Button SMART App Launch FHIR payer