Understanding the Patient Access API: Requirements, deadlines, benefits and trends

Updated February 27, 2026

Patients increasingly expect to use apps to view, download, and share their health information—not just clinical data, but also claims, coverage, and (soon) prior authorization status. For payers, the Patient Access API is the backbone that enables this. It started as a compliance obligation mandated in the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), but in practice it’s also a platform decision: if you make access reliable and easy to use, you unlock member experience improvements, lower servicing costs, and a cleaner data foundation for other mandated APIs.

But what does this API actually do, and where do payers come into this? In this blog, I’ll break down the key requirements, the benefits for payers, and some of the emerging trends in this space. 

Whether you’re focused on meeting regulatory requirements or want to explore new ways to engage with patients and streamline your operations, this is everything you need to know about the Patient Access API. 

What is the Patient Access API?

The Patient Access API allows patients to access their health and administrative information using health applications of their choice. This empowers patients to decide how, when, and with whom to share their information and make informed decisions about their care. 

The Patient Access API is part of the broader CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) that requires impacted payers to make claims, encounter, clinical, and prior-authorization data accessible to patients through a secure FHIR-based API. 

Who does this impact? 

• Medicare Advantage (MA) organizations 
• Medicaid managed care plans 
• Children’s Health Insurance Program (CHIP) managed care entities 
• State Medicaid and CHIP Fee-for-Service (FFS) programs 
• Qualified Health Plan (QHP) issuers on the Federally Facilitated Exchanges (FFEs) 

What data must be available?

At a minimum, payers must support standardized data sets using recognized implementation guides (IGs). In practice, most payer programs align to a combination of: 

• Claim details and encounters (see CPCDS & CARIN Blue Button)
• Clinical data including laboratory data (see USCDI & US Core and Da Vinci Payer Data Exchange)
• Plan Coverage and Formularies (US Drug Formulary) 
• Prior Authorization Decisions (Da Vinci Payer Data Exchange)

CMS-0057-F emphasizes timeliness and transparency. For example, prior authorization status information is expected to be available through the Patient Access API within one business day of the payer receiving an update.

What are the technical requirements?

From a technical standpoint, the Patient Access API is built on a few well-known standards:

• United States Core Data for Interoperability (USCDI) Version 1.0.0 and Version 3.0.0  
• Health Level Seven (HL7®) Fast Healthcare Interoperability Resources (FHIR®) Release 4.0.1 as the core technical standard. 
• The OAuth 2.0 standard for secure authorization, ensuring privacy and security. 
• The SMART on FHIR standard for authentication, allowing patients to securely authorize third-party apps to access their data. 

The hard part typically isn’t the HTTP endpoints—it’s data readiness (correct mappings, code systems, and member identity matching), operational reliability (uptime, performance, monitoring), and a frictionless authorization experience that members can actually complete.

Timeline: what’s already in force vs what’s new 

A common source of confusion is that “Patient Access API” gets used to refer to both the original requirements and the new CMS-0057-F expansions. Here’s a clearer way to think about it:

• Already in force since July 1, 2021: The Patient Access API requirement for claims/encounters and related data has been enforceable since July 1, 2021 for impacted payer types.
• New in 2026 – Usage metrics: Payers must collect Patient Access API usage metrics for calendar year 2025 and submit the first report to CMS by March 31, 2026, then annually by March 31 for the prior calendar year.
• New/expanded by 2027 (CMS-0057-F expansion): By January 1, 2027, payers must update the Patient Access API to include prior authorization information (excluding prior authorizations for drugs), in addition to meeting the broader set of mandated API requirements in CMS-0057-F.

Note: CMS-0057-F compliance dates vary slightly by program type (for example, some requirements are tied to plan years or rating periods). The dates above are a practical headline view; your compliance team should validate the precise applicability for each line of business.

Why this matters beyond compliance (especially for payers)

Compliance keeps you out of trouble. But a production-grade Patient Access API can also reduce costs and improve experience—if it’s implemented as a durable capability rather than a one-off project.

1. Boost member engagement: Giving members easy access to their health info helps them feel more in control, leading to higher satisfaction and engagement. When members can easily view their data, they’re able to make informed decisions about their health, which benefits everyone involved. 
2. Cost savings: With health data readily available, members are empowered to manage their health better by engaging in preventative care and monitoring health issues for early intervention. This reduces the need for costly hospitalizations and treatments for advanced diseases down the road. 
3. Improve efficiency and reduce admin work: Automating how payers, providers, and patients share data eliminates the need for manual processes. This saves time and resources, and improves care coordination, which ultimately leads to better health outcomes. 
4. Attract new members: By adopting the Patient Access API and technologies like SMART on FHIR, payers can offer innovative, member-focused services. In a competitive market, this helps them stand out from the crowd and attract new members. 

Patient Access API trends for 2026

Most payers already have an API endpoint. The differentiator is whether members and partners can successfully use it at scale. In 2026, strong implementations tend to focus on: 

1. Member authorization that works: short flows, clear explanations, and support processes for failed logins and identity proofing.
2. Operational reliability: monitoring, alerting, capacity planning, and clear SLAs—because an API that’s often down is functionally non-compliant.
3. Data completeness and consistency: stable mappings, meaningful coding, and predictable update frequency.
4. App onboarding strategy: a repeatable security and review process so you can safely support multiple apps without reinventing governance.
5. Preparing for prior auth transparency: make prior authorization status/decision data first-class in your API model well before the 2027 date.

You may also see more interest in profiles such as UDAP (Unified Data Access Profiles) to simplify client authentication and registration, and in TEFCA-related policy developments. These are not required for Patient Access API compliance today, but they influence how the market is thinking about scalable, trust-based access.

Transform compliance into opportunity 

The Patient Access API is more than just a regulatory requirement; it’s an opportunity for payers to improve member satisfaction, lower costs, and reduce admin burden.  

If you’re modernizing your Patient Access API (or preparing for the CMS-0057-F expansion), the work usually lands in three buckets:

• API readiness: FHIR R4 endpoints, SMART/OAuth patterns, security hardening, and conformance testing against the relevant IGs.
• Data readiness: mapping, terminology, and operational pipelines so claims, clinical, and prior auth data are available in the required formats and timelines.
• Governance and rollout: monitoring, reporting support for the March 31 submissions, and an app onboarding approach that your security and compliance teams can live with.

While implementing it might seem complicated, Firely Server makes the process easy by supporting all the mandatory requirements out-of-the-box. It’s the perfect solution for payers who want to comply with CMS regulations, improve their services, and stay ahead in a competitive market. 

If you’re ready to take the next step, visit our CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) documentation for a step-by-step guide on how to implement the Patient Access API. If you have any questions, reach out to our team.