The CMS Patient Access API is a federal mandate that requires Medicare Advantage, Medicaid, CHIP, and qualified health plan issuers on the federal exchange to give patients electronic access to their claims, encounter, and clinical data through third-party applications built on FHIR standards. Since its phased rollout began under the CMS Interoperability and Patient Access final rule (CMS-9115-F), it has reshaped how payers expose data, and how healthcare vendors build products that consume it.

For vendors integrating with EHR systems like EPIC, understanding the Patient Access API matters because the same HL7 FHIR R4 standard underpins both payer-side compliance and the SMART on FHIR apps that connect to clinical workflows. If you're building or planning an integration that touches patient health data across payers and providers, the technical and regulatory requirements overlap significantly.

This article breaks down what the CMS Patient Access API requires, how FHIR powers it, what compliance looks like in practice, and where it intersects with broader interoperability efforts. At VectorCare, we build no-code SMART on FHIR applications for EPIC integration, so we work with these standards daily. Here, we're sharing what healthcare vendors need to know to stay informed and technically aligned with the direction CMS is pushing the industry.

What the CMS Patient Access API is

The CMS Patient Access API is a data-sharing requirement established under the CMS Interoperability and Patient Access final rule (CMS-9115-F), published by the Centers for Medicare & Medicaid Services in May 2020. At its core, the rule requires covered payers to expose patient health information through a standardized API so that patients can pull their own data into any third-party application they choose. The goal is to give patients real ownership of their health records rather than forcing them to log into separate payer portals with limited, often clunky, export options.

This rule shifts control of health data from institutions to patients, making portable, machine-readable records a baseline expectation rather than a premium feature.

The rule behind the requirement

CMS-9115-F sits under the 21st Century Cures Act, which directed federal agencies to eliminate information blocking and push interoperability across the healthcare system. The Patient Access API is one of several APIs the rule introduced, alongside the Provider Directory API and the Payer-to-Payer Data Exchange. Each of these mandates uses HL7 FHIR R4 as the technical foundation, meaning payers must structure and serve data in a format that modern applications can parse without custom translation layers built on top.

How it fits into the interoperability landscape

For healthcare vendors, the cms patient access api represents a meaningful shift in how patient data moves across the ecosystem. When a patient authorizes a third-party app, that app can retrieve claims history, clinical information, and formulary data directly from the payer using a standardized FHIR endpoint. This matters for vendors building tools that need a longitudinal view of a patient's health, because payer data regularly fills gaps that provider EHR records miss, especially for patients receiving care across multiple health systems or provider organizations.

Who must comply and key compliance dates

The cms patient access api applies to a specific set of payer types defined in CMS-9115-F. Not every insurance plan falls under the mandate, so knowing whether your organization or your target customer is in scope matters before you begin any technical planning.

Covered payer types

CMS applies the Patient Access API requirement to the following plan types:

• Medicare Advantage organizations
• Medicaid fee-for-service programs
• CHIP fee-for-service programs
• Medicaid managed care plans and CHIP managed care entities
• Qualified health plan (QHP) issuers on the federally facilitated exchange

Traditional Medicare (Parts A and B administered directly by CMS) and most commercial employer-sponsored plans fall outside the scope of this rule.

Compliance deadlines

Most covered payers faced an original compliance date of July 1, 2021, following a delay from the initial January 1, 2021 deadline tied to the COVID-19 public health emergency. QHP issuers on the federal exchange operated under a separately adjusted timeline that CMS tracked in parallel.

Missing these deadlines carries real consequences: CMS can flag non-compliant plans during audits and factor compliance into program participation determinations.

Ongoing compliance is not a one-time task. CMS expects payers to maintain functioning API endpoints, respond to patient authorization requests, and keep their implementation current with updated FHIR implementation guides.

What data payers must make available

The cms patient access api mandates that covered payers expose three primary categories of patient data through their FHIR endpoints. Knowing what falls within scope helps you build applications that use payer data effectively without making assumptions about what's actually available.

Claims and encounter data

Payers must provide adjudicated claims data going back at least one year from the patient's enrollment date. This data covers the financial and procedural record of care, including:

• Service dates and procedure codes
• Diagnosis codes (ICD-10)
• Cost-sharing details such as copays and deductibles
• Provider information tied to each claim

This claims history is particularly valuable for applications that need a longitudinal view of a patient's care across multiple providers and health systems.

Clinical and formulary data

Beyond claims, payers must expose clinical data elements aligned with the USCDI standard, including lab results, clinical notes, and care plan details they receive from providers. The depth of this data varies depending on what payers actually collect from providers during the adjudication process.

Your applications can also pull formulary data, covering drug tiers, cost-sharing rules, and coverage restrictions. This gives you the ability to surface medication cost and coverage details to patients at the point of care without requiring a separate data source.

Technical requirements: FHIR, SMART, and security

The cms patient access api requires payers to implement their endpoints using HL7 FHIR R4, the version CMS mandates across all covered plan types. This is the same specification underpinning SMART on FHIR apps that integrate with EHR systems like EPIC, which means the data formats and API patterns you encounter on the payer side translate directly to provider-side integrations.

Authorization and SMART on FHIR

Payers must use OAuth 2.0 as the authorization framework and align with the SMART on FHIR specification for patient-facing access. When a patient grants a third-party app permission to pull their data, that app receives an access token scoped to specific FHIR resources, giving patients direct control over what each application can see and retrieve.

Aligning your app with SMART on FHIR authorization from the start means you avoid rebuilding your auth layer when you later connect to provider-side EPIC endpoints.

Security baseline

Payers must enforce TLS 1.2 or higher across all API connections and structure their resources according to the FHIR US Core Implementation Guide. Your application also needs to handle token expiration, refresh flows, and revocation properly to maintain a secure, uninterrupted connection throughout each patient session without exposing sensitive health data during handoffs.

How to implement and maintain compliance

Implementing the cms patient access api requirements starts with selecting FHIR server infrastructure that supports HL7 FHIR R4 natively and can handle patient authorization flows at scale. Whether you're a payer building your own endpoint or a vendor consuming payer data, your foundational infrastructure choices affect every downstream integration decision you make.

Start with the right FHIR implementation guide

Your first concrete step is adopting the FHIR US Core Implementation Guide, which defines the specific resource profiles, search parameters, and data elements CMS expects payers to expose. Map your existing data sources to these profiles early in the project so data gaps surface before you reach testing or certification rather than after.

Catching data mapping issues during implementation costs far less to resolve than discovering them mid-audit or during third-party app certification.

Build ongoing monitoring into your process

Compliance does not end at go-live. You need to monitor your API endpoints continuously for uptime, token handling errors, and version changes to the underlying FHIR implementation guide as CMS refines its requirements.

Schedule regular audits of your authorization flows, review your OAuth scoping rules, and keep your technical documentation current. Patients and third-party applications expect reliable, accurate data access without disruption, and CMS evaluates ongoing performance, not just initial implementation.

Key takeaways

The cms patient access api sets a clear technical and regulatory baseline: covered payers must expose adjudicated claims, clinical data, and formulary information through HL7 FHIR R4 endpoints secured with OAuth 2.0 and SMART on FHIR authorization. If you build healthcare vendor applications that touch patient data, these standards directly shape the API patterns, data formats, and auth flows your product needs to support.

Compliance is not a one-time implementation. You need ongoing monitoring, version tracking, and regular audits of your authorization flows to stay current as CMS refines its requirements. The same FHIR foundation powering payer-side compliance also drives SMART on FHIR integrations with EHR systems like EPIC, which means aligning your architecture early saves you significant rebuild work later.

Ready to build a SMART on FHIR application that connects directly into clinical workflows? Explore VectorCare's no-code EPIC integration platform and go from concept to a listed app in weeks.