Patient Access API: CMS-9115 Gaps and What Changes in 2027

Reviewed September 2026. Requirements checked against CMS's Patient Access API FAQ (modified 1 September 2026) and the CMS-0057-F rule text on 25 September 2026.

The CMS Patient Access API is the FHIR API that Medicare Advantage, Medicaid, CHIP and federal-exchange plans have had to run since 1 July 2021 under CMS-9115-F, so members can send their claims and clinical data to any health app they choose. CMS-0057-F extends it: payers have reported usage metrics to CMS since March 2026, and from 1 January 2027 the API must also return prior authorization requests and decisions. Most payers built the first version years ago. It is live, it returns valid FHIR, and it often returns far less than the rule expects.

This guide covers what the Patient Access API must return today, exactly what CMS-0057-F adds, the implementation guides and versions, how member apps connect, the four gaps most implementations carry, and how to test your own endpoint the way an app would.

What the CMS Patient Access API must return today

The Patient Access API must make available the adjudicated claims, encounter data and clinical data a payer maintains, with dates of service from 1 January 2016, for current enrollees, through a FHIR API that any app the member chooses can use. That duty has applied to impacted payers since 1 July 2021 under CMS-9115-F.

CMS's FAQ settles four points that come up in every implementation.

• "Maintain" has a definition. A payer maintains data when it has access to it, control over it, and authority to make it available. If a payer holds no clinical data for a member, it does not have to share any.
• Clinical data includes lab results, mapped to USCDI data elements where the payer holds them as discrete data.
• PDFs and faxes do not have to be parsed. CMS does not require payers to go manually through large files that cannot be broken into data elements efficiently, although it encourages mapping whatever is held discretely.
• One API, not several portals. All claims, encounter and clinical data must be available through a FHIR API that meets the adopted standards; a payer can structure its systems as it likes behind that.

Provider remittances and enrollee cost-sharing are excluded. Dental and vision claims are not excluded by the rule; CMS notes that a payer following the suggested implementation guides "could be in compliance" and may move to newer guide versions that cover more claim types.

The Provider Directory API is a separate, public endpoint built on Plan-Net; it is not part of the member-authorized Patient Access flow.

What CMS-0057-F adds in 2026 and 2027

CMS-0057-F adds two things to the Patient Access API: annual usage metrics reported to CMS, first due by 31 March 2026 for calendar 2025, and prior authorization data in the API itself from 1 January 2027. Neither changes who must comply.

Prior authorization data from 1 January 2027

From 1 January 2027, the Patient Access API must return information about the member's prior authorization requests and decisions for items and services, excluding drugs. That includes the status, the relevant dates, the items and services and quantities approved, and the specific reason for a denial. The information must be available within one business day of a status change and kept available for at least a year after the last status change.

This is the addition most likely to come back empty. Authorizations often live in a utilization management system run by a vendor or a delegated review entity rather than in the payer's own data store, and nothing reaches the API unless someone builds the path. The PDex guide defines the prior authorization profile most payers will use; the same data also feeds the Provider Access and Payer-to-Payer APIs, so the extract is worth building once.

Usage metrics reported to CMS

Every year, impacted payers report two numbers to CMS for the previous calendar year: the total number of unique patients whose data went through the Patient Access API to a health app they chose, and the number whose data went more than once. The first report, covering 2025, was due by 31 March 2026. The data is aggregated and de-identified.

States report their managed care plans' figures within the Managed Care Program Annual Report, due no later than 180 days after each rating period closes, so plans should agree dates and formats with the state early. CMS's FAQ now notes that CMS-0062-P proposes changes to API usage reporting; those are proposals and do not change the current duty.

Usage metrics change the stakes of a thin API. A member who connects once, sees a near-empty history and never returns shows up in the second number. Onboarding friction and missing data are now visible in a figure CMS collects.

Implementation guides and versions

CMS recommends CARIN Blue Button for claims, PDex for clinical and prior authorization data, and the US Drug Formulary guide for formulary data, and lists versions 2.0.x and 2.1.0 of each on its standards page. Payers may move to newer versions ONC has approved, provided the member's access to data is not disrupted.

The flag means those versions were built on standards that expired on 1 January 2026 (USCDI v1, US Core 3.1.1 and SMART 1.0.0). The current baseline is US Core 6.1.0 and SMART App Launch 2.0.0. CARIN Blue Button profiles ExplanationOfBenefit by claim type: inpatient institutional, outpatient institutional, professional and non-clinician, pharmacy, and oral (dental). An API that returns only professional claims is missing most of a member's hospital history.

How member apps connect: SMART on FHIR standalone launch

Member apps connect through the SMART App Launch standalone flow: the member opens the app, the app discovers the payer's authorization endpoints, the member signs in and approves scopes, and the app receives a token bound to that member. Everything a payer does to slow that sequence down now shows in its usage metrics.

Discovery starts at the payer's .well-known/smart-configuration document. A minimal, read-only request for claims and clinical data looks like this:

GET https://payer.example.org/fhir/.well-known/smart-configuration

GET https://payer.example.org/auth/authorize
  ?response_type=code
  &client_id=member-app-123
  &redirect_uri=https://app.example.com/callback
  &scope=launch/patient openid fhirUser offline_access patient/ExplanationOfBenefit.rs patient/Coverage.rs patient/Patient.rs patient/Observation.rs
  &state=af0ifjsldkj
  &aud=https://payer.example.org/fhir
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

The token response carries a patient field that tells the app whose data it may read. Three payer-side choices decide whether members get that far:

• PKCE and public clients. Most member apps are public clients, so PKCE is the protection, and SMART App Launch 2.0.0 expects it.
• Refresh tokens. Without offline_access, the member signs in again every time the app refreshes, and most stop.
• App registration. A registration process that takes weeks, is undocumented or runs by email is visible to every developer who tries it, and public reviews of payer endpoints report exactly that: non-standard scopes, proprietary token methods and undocumented limits.

Patient Access and Blue Button are related but not the same. Blue Button 2.0 is CMS's own Patient Access implementation for people in Original Medicare; every impacted payer must run its own Patient Access API for its members, and both use CARIN Blue Button profiles.

Four gaps worth checking this quarter

Four gaps account for most thin Patient Access APIs: claims history that stops short, prior authorization data that is absent, clinical data that was never connected, and app onboarding that discourages use. Each is a data or process problem rather than an API one.

1. Claims history that stops short

The requirement reaches back to dates of service from 1 January 2016, not a recent window. Many implementations return whatever the operational claims store holds online, often a rolling period, because that was reachable without touching the data warehouse. The fix is an extract path to archived adjudicated claims, which is data engineering rather than API work.

2. Prior authorization data that is absent or empty

If authorizations live in a utilization management system operated by someone else, an empty array is what the API will return from 1 January 2027 unless the retrieval path exists. That is the delegated entity problem, and it has the longest lead time because it depends on contracts and connectivity with third parties.

3. Clinical data that was never connected

Where a payer holds clinical data as discrete elements, it belongs in the response as USCDI content. Payers often hold more than they assume: lab results from care management, assessments, and data gathered for risk adjustment. It is usually absent simply because nobody mapped it.

4. Authentication and app onboarding that discourages use

The rule anticipates third-party apps connecting on a member's behalf. Registration that is slow, undocumented or manual is a compliance concern rather than a security posture, and with usage now reported to CMS it shows up in the numbers.

How to test your Patient Access API

The fastest honest test is to take twenty real members with known histories and pull each one through your own API exactly as a third-party app would, then compare what comes back with what you know exists. Choose members with a chronic condition, a recent admission, a completed prior authorization and a dental or vision claim.

That exercise takes a couple of days, tends to end internal debate, and produces the artefact an evidence pack needs: a dated, reproducible test with findings and a remediation plan. Pair it with conformance runs. ONC's Inferno framework has test kits for SMART App Launch, US Core, CARIN Blue Button and PDex; CMS does not require Inferno results as part of an attestation, but the runs are strong evidence that the API behaves as the guides say. Because there is no certification to rely on, the duty is to test and monitor, and a thin API that was never re-examined is a weak position. Our CMS-0057-F testing guide covers the Inferno kits and sandboxes in more detail.

Sequencing the remediation

Measure first, then close the claims history gap, then build the prior authorization path, then connect clinical data. That order puts the most missing data and the longest lead time first.

1. Measure with the twenty-member exercise. Assumptions about your own data are usually generous.
2. Close the claims history gap. It is the largest volume of missing data and the most mechanical to fix.
3. Build the prior authorization path before 1 January 2027. It usually means contracts and connectivity with delegated entities, so start now, and reuse the extract for Provider Access and Payer-to-Payer.
4. Connect clinical data where you hold it as discrete elements. It improves the response for members and for the other APIs that share the same data.
5. Fix onboarding in parallel: publish the registration process, support PKCE and refresh tokens, and track time from registration to first successful pull.

Why this matters more under CMS-0057

CMS-0057 raises the stakes on the Patient Access API in three ways: the scope grew to include prior authorization data, usage is now counted and reported to CMS, and prior authorization performance is published every March where anyone can compare plans. An implementation that was arguably adequate in 2021 now has a new category of data to serve and more people looking at it.

The same data plane serves the rest of the rule. Provider Access and Payer-to-Payer share the claims, clinical and prior authorization extracts, so the work done here is not isolated. Our Provider Access and Payer-to-Payer guide covers those APIs, and the CMS-0057-F requirements page tracks deadlines and status.

Nirmitee builds and tests FHIR APIs for payers and health-tech platforms, including the SMART authorization layer and the claims and prior authorization extracts behind them. Our healthcare interoperability team runs readiness assessments, implementation guide builds and conformance testing; for the platform side see our healthcare software product engineering practice. Talk to our team.

Sources

• CMS Patient Access API FAQ (modified 1 September 2026)
• CMS APIs and relevant standards and implementation guides
• CMS-0057-F final rule, 89 FR 8758 (8 February 2024)
• CMS-9115-F final rule, 85 FR 25510 (1 May 2020)
• HL7 CARIN Blue Button, Da Vinci PDex and SMART App Launch
• FY 2027 IPPS/LTCH final rule, FR doc 2026-15833 (170.215 updates)
• Flexpa, State of the Payer Patient Access API (November 2025)
• ONC Inferno test kits