Nov 2025 State of The Payer Patient Access API Report

What is this report?

Flexpa's State of the Payer Patient Access API Report assesses the current implementation of Payer Patient Access APIs mandated by CMS-9115-F.

Compliance alone isn't sufficient. Patient Access APIs must be usable, properly configured, and genuinely aligned with the HL7 FHIR R4 standard, not just technically compliant on paper. Payers must be responsive to patient inquiries, authentication errors, and service disruptions.

The patient experience and developer experience are two sides of the same coin. When developers encounter unclear error messages, undocumented customizations, or unresponsive support teams, those friction points directly translate to patients being denied access to their own health information. Both experiences must work in tandem.

With CMS-0057 (Payer-to-Payer Data Exchange) implementation deadline approaching on January 1, 2027, payers have a critical opportunity to leverage their existing interoperability investments. Both regulations mandate the same FHIR R4-based API structure and OAuth 2.0 authentication flows. Payers with robust Patient Access API implementations (including proper FHIR resource support, stable authentication, and responsive operations) will have a significant advantage in meeting the payer-to-payer exchange requirements.

This is Flexpa's November 2025 Edition, where we discuss what worked, what didn't, and how we've grown together with payers over the last six months.

Patient impact & demand

CMS initially required payers to implement these APIs by January 1, 2021. Nearly five years later, third-party apps expect compliance, but most importantly, patients are demanding access to their own data.

Our reports emphasize real-world impact measurements because patient-mediated access delivers value beyond mere compliance. Patient-mediated access to claims data can:

• Empower hyper-specific chronic condition management
• Personalize plan selection, benefits utilization, and cost savings
• Eliminate chart chasing
• Accelerate participant selection in life sciences

Before we dive into the report, we wanted to highlight some patient experiences to remind us who we're building these systems for:

Flexpa Usage

Since launch, Flexpa has connected to 433 payers and counting. The real-world usage of our platform demonstrates genuine patient demand for these capabilities:

• 428,000+ authorization attempts from patients seeking to connect their health data
• ~3,000 unique individuals successfully accessed their complete claims history through MyFlexpa
• 100M+ FHIR resources synced, representing the full scope of patient data from ExplanationOfBenefit to clinical resources

These numbers represent actual patient interactions with the interoperability ecosystem, not sandbox testing or vendor demonstrations.

With CMS mandated reporting starting soon, we wanted to take the opportunity with this report to also share usage stats per payer. As a third-party application we have a unique view of the full patient experience, in a way that payers and vendors themselves might not. We are happy to provide these usage reports on an ongoing basis to any payer who requests it. Just let us know at interop@flexpa.com.

Coverage Status

Flexpa's combined approach delivers industry-leading coverage across all major plan types. "Coverage" means we've successfully integrated with a payer's Patient Access API and can retrieve FHIR resources in production.

In total, we cover 94% of all U.S. CMS lives and 100% of VA lives through functional Patient Access APIs. That's over 165 million people. In addition to connecting to payers, Flexpa has also connected to medical record systems and national networks as part of our 3-in-1 Network.

State-level coverage varies primarily based on Medicaid managed care implementation patterns and regional commercial payer footprints. Over 70% of states have 97%+ coverage, while gaps in the remaining states typically stem from smaller regional payers or state Medicaid agencies that have delayed implementation.

Quantifying Patient Access

In addition to quantitative measures outline in the scorecard, we wanted to share some aggregate qualitative analysis on the current state of getting connected to this ecosystem. The numbers below represent real integration timelines, configuration complexity, and patient abandonment patterns, all crucial to the real usability of these APIs. These metrics illustrate the gap between regulatory compliance and practical usability.

The Road to Establishing Contact

Our coverage numbers tell a story of progress, but they obscure the months or years of outreach required to establish each connection. We've documented how long we've been attempting to reach unsupported payers. Some took over three years.

The barriers vary: some payers never respond to outreach attempts across multiple channels. Others respond but report their implementation isn't production-ready, often with no timeline for completion. Most concerning are payers who explicitly state they won't implement the Patient Access API, citing exemptions or interpretations of CMS-9115-F that appear inconsistent with the rule's plain language. Nearly five years post-deadline, "we're working on it" is no longer an acceptable answer.

Time to Production

For supported payers, we've tracked the duration from initial contact to production-ready implementation. This timeline matters for two audiences: developers planning integration efforts need realistic expectations, and payers approaching CMS-0057 implementation need to understand these cycles take months, not weeks.

Payers who proactively reach out, provide test credentials, and assign responsive technical contacts dramatically accelerate this timeline. Those who treat third-party integrators as adversaries rather than partners often remain in limbo for a year or more, all while their patients are effectively locked out of applications they want to use.

Customization Configurations

The HL7 FHIR R4 standard and the SMART App Launch Framework define clear specifications for API implementation. In practice, however, payers and their vendors have introduced significant variations that require custom engineering to accommodate. These deviations from standard patterns include:

• Custom OAuth 2.0 scopes beyond patient/*.read and launch/patient
• Non-standard token endpoint authentication methods
• Proprietary extensions to the authorization flow
• Inconsistent FHIR resource profiles and missing required elements
• Undocumented rate limiting and pagination behaviors
• Custom error response formats that don't follow FHIR OperationOutcome patterns

Below, we outline the percentage of payers requiring custom configurations or lacking support for specific parameters. We've made adjustments purely to expand payer support and ensure patients can actually access their data.

These customizations represent significant technical debt for the ecosystem. Every non-standard implementation increases the barrier to entry for new applications, reduces interoperability, and ultimately limits patient choice in how they access their health data.

What do we define as a custom configuration? Read the detailed methodology here.

Abandonment Reasons

Understanding why patients abandon the connection process is critical to fulfilling the spirit of the CMS-9115-F rule. The underlying causes are varied: payer-side authentication errors, undisclosed line-of-business restrictions, forgotten credentials, or patients without online portal accounts.

While Flexpa works to prevent avoidable abandonment through clear expectations in our consent flow, many barriers require payer action to resolve. We share granular abandonment data, including error codes, failure patterns, and affected patient volumes, with supported payers monthly. The response has been underwhelming. The prevailing mindset appears to be: "Our test patients work, the API is technically live, so we're compliant."

This perspective misses the regulatory intent. CMS-9115-F doesn't just require an API endpoint. It mandates that patients can "access all their claims and encounter information, including clinical data...through third-party applications of their choice." When a patient receives a generic error message with no recourse, that's not access, it's a compliance checkbox that fails in practice.

Payers have a regulatory obligation to maintain functional authentication systems, provide meaningful error messages, and respond to reported issues. Below, we highlight the most common abandonment reasons and their progression over time.

Scorecard Methodology

Our evaluation framework assesses both regulatory compliance and practical usability. As the industry matures, we're raising the bar beyond mere technical implementation. This report features three distinct sections:

• Usage statistics: We've included real-world usage data for each payer. These numbers represent actual patients attempting to access their health information, not synthetic test data. When a payer sees hundreds or thousands of authorization attempts, that's evidence of real demand. When they see high abandonment rates, that's a signal that something in their implementation is blocking patient access.

• Core Implementation Scorecard: Measures baseline requirements for a functional Patient Access API. This evaluates adherence to FHIR R4 specifications, SMART App Launch Framework compliance, proper OAuth 2.0 implementation, required FHIR resource support (ExplanationOfBenefit, Patient, Coverage), and basic operational stability. A score of 100 indicates meeting the minimum regulatory requirements of CMS-9115-F.

• Beyond Compliance Scorecard: Evaluates the quality of implementation from both patient and developer perspectives. This includes comprehensive FHIR resource coverage, clear error messaging, responsive support channels, proactive communication during migrations, and documented authentication flows. These factors determine whether an API is merely compliant or actually usable in production.

Results

We evaluated 493 payers with Patient Access API implementations across 30+ vendors. Each payer received scores for both Core Implementation (baseline regulatory compliance) and Beyond Compliance (patient and developer experience quality).

A note on reporting structure: This year's report breaks down results by individual payer rather than aggregating by vendor. We received feedback that vendor-level aggregations obscure important nuances—some vendors operate as managed services while others provide self-hosted solutions, and metrics like patient abandonment rates don't meaningfully aggregate across different payer implementations of the same vendor platform. If you're a vendor and would like a custom report showing your payers' results, contact us at interop@flexpa.com.

Top Payers

Our highest-scoring payers demonstrate excellence across both implementation and experience dimensions, meeting not just the letter of CMS-9115-F, but its spirit:

Core Implementation (100 max points)

1. Centers for Medicare & Medicaid Services - 92
2. VillageCareMAX - 91
3. UnitedHealthcare - 88
4. Tied for 4th and 5th places - 85
   • Central California Alliance for Health
   • Kaiser Foundation Health Plan of Hawaii

Beyond Compliance (40 max points)

1. Anthem - 35
2. Blue Shield of California - 31
3. CareSource - 30
4. Tied for 4th and 5th places - 28
   • Kaiser Permanents
   • Kaiser Foundation Health Plan of Washington
   • Kaiser Foundation Health Plan of Hawaii
   • Kaiser Foundation Health Plan of Colorado
   • Clover Health

Shoutouts

• CareSource

  • For providing comprehensive documentation throughout their migration process and maintaining consistently responsive support to ensure smooth implementation.

• Abacus Insights

  • For their exceptional responsiveness in quickly identifying and resolving technical issues, keeping integrations running smoothly.

• Blue Cross Blue Shield of Alabama

  • For proactively communicating their transition to a new FHIR vendor and working closely with the Flexpa team to ensure thorough end-to-end testing. Their rapid resolution of Patrius login screen issues minimized patient disruption.

• New Jersey DMAHS

  • For their commitment to improving infrastructure by transitioning to a new vendor, demonstrating dedication to enhanced patient access capabilities.

How Flexpa Can Help

We work directly with payers and vendors to accelerate Patient Access API implementation, validate FHIR compliance, and resolve production errors. Our experience integrating with 433+ payers provides unique visibility into what works and what doesn't.

For Payers

1. CMS-0057 Readiness: Leverage your Patient Access API infrastructure to meet payer-to-payer exchange requirements, including consent management, network directories, and API stability.

2. End-to-End Testing: Validate your implementation in development or production environments. We test OAuth flows, FHIR resource formatting, search parameters, pagination, and error handling for the full stack.

3. Production Error Monitoring: Receive detailed logs from real patient usage, including authentication failures, token exchange errors, FHIR validation issues, and abandonment patterns. We provide actionable data, not just "something broke."

4. Vendor Migration Support: Planning to switch FHIR vendors? We've helped payers navigate multiple vendor transitions. Our parallel testing can identify regressions before you cut over production traffic.

For Vendors

If you're building Patient Access API solutions, we can validate your implementation against real-world usage patterns and help identify edge cases before your clients encounter them in production.

Connectivity Transparency

In keeping with our commitment to transparency, Flexpa is restructuring our Endpoint Directory and publicly available payer statuses. To see all supported endpoints and their current status, visit our Endpoint Directory.

If you're a payer or vendor with questions about this report or interested in collaborating, email us at interop@flexpa.com.

---

Five years into the Patient Access API mandate, we're past the era of "effort credit" for incomplete implementations. Patients deserve functional access to their health data, developers need standardized APIs they can reliably build on, and payers must evolve beyond viewing compliance as a checklist exercise.

The infrastructure exists. The standard is clear. What's needed now is a shared commitment to making these systems work in practice, not just on paper. The patients quoted at the beginning of this report, and the millions they represent, are counting on it.