What is this report?
Flexpa's State of the Payer Patient Access API Report assesses the current implementation of Payer Patient Access APIs across the healthcare ecosystem. These APIs are federally mandated (CMS 9115-F) as part of broader healthcare interoperability efforts led by CMS and ONC.
This report provides a snapshot of the current state of healthcare data interoperability, highlighting both progress and challenges. We emphasize real-world impact measurements because patient-mediated access delivers value beyond mere compliance, and we aim to build a broader coalition of champions who share this vision.
Patient-mediated access to claims data can:
- Empower hyper-specific chronic condition management
- Power bill negotiation and claims substantiation
- Personalize plan selection, benefits utilization, administration, and cost savings
- Eliminate chart chasing
- Accelerate participant selection in life sciences
With CMS 0057 (Payer-to-Payer Data Exchange) on the horizon, payers have a significant opportunity to leverage their interoperability investments. A strong foundation with the Patient Access APIs will position payers advantageously for efficient payer-to-payer exchange implementation.
Metric Changes
Based on feedback from our previous reports, we've made two significant changes to our evaluation framework:
1️⃣ Big change 1: Separate Vendor Metrics
We now use distinct metrics for vendors versus payers:
- Vendor metrics include only the relevant subset of payer metrics
- Vendor scores use the median of their payer implementations rather than average
- Only vendors with Live production implementations are evaluated
Payer metrics are denoted by 🪪 and total to 100 points.
Vendor metrics are denoted by 💼 and total to 70 points.
2️⃣ Big change 2: Stakeholder-Centered Framework
There is not enough education on the real world impact of these APIs. Without an understanding of the impact, we can't make the nuanced implementation decisions that are necessary in a well functioning and thought out system. We've restructured our scoring to focus on the primary stakeholders of interoperability:
- Ecosystem Experience - Coverage Strength
- Patient Experience - Authorization Flow
- Developer Experience - FHIR API
This approach recognizes that successful implementation requires coordination across organizational units that often operate independently. When these units don't effectively collaborate, issues arise: FHIR configuration errors can prevent eligible members from accessing data, system upgrades can invalidate patient identifiers, and developers like Flexpa must manage user confusion without visibility into these internal changes.
Metrics Overview
All scores are calculated based on the last 6 months of data to account for recent improvements. Health plans covering fewer than 500 lives have been filtered out of the report.
Ecosystem Experience - Coverage Strength (20 points)
The value of Payer Patient APIs depends on network participation to ensure all members can access their data. This foundation becomes even more critical with the upcoming CMS 0057 implementation.
Status (10 points) 🪪
- Definition:
- Whether the API is available or not
- Scoring:
- Live: 10 points
- Implementing: 5 points
- Not available: 0 points
- Why it matters:
- The fundamental prerequisite for patient data access—no availability means no access regardless of other factors
- How it's calculated:
- Measured based on our continuous monitoring of member connection attempts
- Live: Endpoints with configured client credentials where the organization status is Live, User Validated, Inferred Validated, or Broken
- Implementing: Endpoints in active implementation phase, with organization status of Unavailable but Planned, Applied, or Ready to Configure
- Not available: Endpoints without established contact, with other organization status designations
Sandbox Environment (6 points) 🪪 💼
- Definition:
- Availability of a test environment for developers
- Scoring:
- Available: 6 points
- Not available: 0 points
- Why it matters:
- Enables developers to test integrations before production, reducing errors and accelerating time-to-market for patient-facing applications
- How it's calculated:
- Verification of test endpoint availability for the endpoint, organization, or vendor
CapabilityStatement (2 points) 🪪 💼
- Definition:
- Availability of an accurate FHIR capability statement
- Scoring:
- Available: 2 points
- Not available: 0 points
- Why it matters:
- Provides crucial technical documentation that enables automated discovery and efficient integration of available resources
- How it's calculated:
- Fetched from baseURL/metadata; presence of capability statement is verified without evaluating content correctness
Well-known SMART Configuration (2 points) 🪪 💼
- Definition:
- Availability of .well-known/smart-configuration for automated discovery
- Scoring:
- Available: 2 points
- Not available: 0 points
- Why it matters:
- Enables standardized OAuth flows and automated endpoint discovery, simplifying integration for developers and providing consistent patient experiences; crucial for upcoming Payer-to-Payer authorization through UDAP
- How it's calculated:
- Fetched from baseURL/.well-known/smart-configuration; presence is verified without evaluating content correctness
Patient Experience - Authorization (45 points)
Adoption fundamentally depends on patients successfully using the solution. The Patient Access API should provide a digital interface for users to obtain and share their records easily. A smooth experience begins with straightforward consent and authorization processes.
While these metrics provide quantitative measures, we also address qualitative improvement areas later in the report.
Authorization Success Rate (14 points) 🪪 💼
- Definition:
- Measures rate of successful authorization attempts
- Scoring:
- 95-100%: 14 points
- 90-95%: 12 points
- 80-90%: 10 points
- 70-80%: 8 points
- 50-70%: 4 points
- Less than 50%: 0 points
- Not enough data: 0 points
- Why it matters:
- Directly measures how many patients can successfully connect—the front door of Patient Access API usefulness
- How it's calculated:
- Percentage of live mode patient authorizations with state of Authorized, Exchanged, or Revoked out of all attempts (excluding BOUNCED state)
- No artificial weighting or minimum thresholds applied to avoid excluding well-performing endpoints
Refresh Token Behavior (10 points) 🪪 💼
- Definition:
- Determines whether long-term access without re-authorization is possible
- Scoring:
- Available for 1+ years: 10 points
- Available for 6 months to 1 year: 6 points
- Available for 3 months to 6 months: 4 points
- Available for < 3 months: 2 points
- Available, max auth unknown: 2 points
- Not available: 0 points
- Why it matters:
- Eliminates the need for patients to repeatedly log in, providing seamless ongoing access to their health data for care coordination
- How it's calculated:
- Verification of refresh capability and maximum authorization period
Inactive Member Data Availability (8 points) 🪪
- Definition:
- Does the payer allow inactive members access to their data?
- Scoring:
- Available indefinitely: 8 points
- Available for 5+ years: 6 points
- Available for 2-5 years: 4 points
- Available for 1-2 years: 2 points
- Available for <1 year or unknown duration: 1 point
- Not available or unknown: 0 points
- Why it matters:
- Ensures continuity of care when patients change plans or coverage lapses, maintaining their full health history
- How it's calculated:
- Based on direct payer communications, stored as endpoint configuration for inactive member access and associated period (in seconds)
Requires Additional Member Portal Opt-In (6 points) 🪪
- Definition:
- Whether members must log into their member portals to create an account or opt-in
- Scoring:
- Not required: 6 points
- Required: 0 points
- Why it matters:
- Additional opt-in requirements create significant dropoff; when a member receives an error during connection, they often abandon the process rather than navigating to a separate portal
- How it's calculated:
- Information gathered through payer communications and member troubleshooting, stored as endpoint configuration
Eligibility Errors Sent on Callback (4 points) 🪪 💼
- Definition:
- Whether structured error messages are returned when access is denied
- Scoring:
- Yes: 4 points
- Unknown: 2 points
- No: 0 points
- Why it matters:
- Provides clear feedback when access is denied, helping patients understand why they can't connect and what steps to take
- How it's calculated:
- Based on query_ineligible responses on callback from live mode patient authorizations
- Endpoints without recorded error states receive 2 points
Lines of Business Support (3 points) 🪪
- Definition:
- Measures how broadly the API is available across plan types
- Scoring:
- All LOBs offered are supported: 3 points
- Only CMS-mandated of offered are supported: 2 points
- All LOBs are CMS and are supported: 2 points
- None supported (not connected): 0 points
- Why it matters:
- Determines how many members can actually use the API; broader support means more inclusive access. Complex eligibility rules increase the likelihood of configuration errors, leading to member confusion and troubleshooting challenges
- How it's calculated:
- Assessment of plans supported via API versus CMS mandates, considering both the LOBs the health plan offers and which subset is API-supported
Developer Experience - FHIR API (35 points)
Developers build these integrations to deliver valuable services to members. Their success depends on reliable data delivery conforming to Implementation Guides, allowing them to focus on service development rather than troubleshooting data inputs.
FHIR API Resource Request Success Rate (10 points) 🪪 💼
- Definition:
- How often FHIR API requests succeed
- Scoring:
- 99%: 10 points
- 95-99%: 8 points
- 90-95%: 6 points
- 80-90%: 5 points
- 70-80%: 3 points
- 50-70%: 1 point
- <50%: 0 points
- Why it matters:
- Directly impacts reliability and thoroughness of data access and determines whether applications can consistently serve patient needs
- How it's calculated:
- Percentage of live mode FHIR proxy requests with 200 status codes where extract step is everything, individual, pagination, or retry (reference resolutions evaluated separately)
Reference Resolution Success Rate (5 points) 🪪 💼
- Definition:
- Whether references in resources are resolvable
- Scoring:
- 95% of references resolvable: 5 points
- 80-95% resolvable: 4 points
- 60-80% resolvable: 3 points
- 40-60% resolvable: 2 points
- 20-40% resolvable: 1 point
- <20% resolvable: 0 points
- No references: 0 points
- Why it matters:
- Ensures complete data context by connecting related information like providers and organizations, enabling meaningful analysis
- How it's calculated:
- Percentage of live mode FHIR proxy requests with 200 status codes where extract step is reference resolution
Carin BB Core Resource Availability (6 points) 🪪
- Definition:
- Evaluates availability of required claims resources (scores summed)
- Scoring:
- ExplanationOfBenefit: 3 points
- Coverage: 2 points
- Patient: 1 point
- None: 0 points
- Why it matters:
- Determines whether the required foundational claims resources are available for cost transparency and care coordination use cases
- How it's calculated:
- Based on live mode FHIR proxy requests for specific resources with 200 responses
Clinical Resources (4 points) 🪪
- Definition:
- Assesses presence of key clinical FHIR resources (scores summed)
- Scoring:
- 4 other clinical resources: 4 points
- 3 other clinical resources: 3 points
- 2 other clinical resources: 2 points
- 1 other clinical resource: 1 point
- 0 other clinical resources: 0 points
- Why it matters:
- Enables use cases that require clinical context beyond claims data, expanding the utility of patient data access
- How it's calculated:
- Based on live mode FHIR proxy requests for specific resources with 200 responses
Sync Speed (5 points) 🪪 💼
- Definition:
- Measures time to retrieve all patient data
- Scoring:
- Median completion < 1 second: 5 points
- Median completion < 5 seconds: 4 points
- Median completion < 10 seconds: 3 points
- Median completion < 30 seconds: 2 points
- Median completion <= 60 seconds: 1 point
- Median completion > 60 seconds: 0 points
- Why it matters:
- Determines whether real-time use cases are possible and directly impacts patient wait times for accessing their data
- How it's calculated:
- Median duration between sync job creation and completion in live mode
$everything Support (3 points) 🪪 💼
- Definition:
- Indicates support for the $everything operation
- Scoring:
- Supported with proper pagination: 3 points
- Supported but limited functionality: 1 point
- Not supported: 0 points
- Why it matters:
- Enables efficient single-request data retrieval, reducing complexity and improving performance for applications
- How it's calculated:
- Based on live mode FHIR proxy requests where extract step was everything
Developer Portal Availability (2 points) 🪪 💼
- Definition:
- Measures whether configuration details or client credentials were obtained from a developer portal
- Scoring:
- Available: 2 points
- Not available but communicate via email: 1 point
- Unknown: 0 points
- Why it matters:
- Enables self-service access to implementation resources, reducing barriers to entry for developers and accelerating ecosystem growth
- How it's calculated:
- Based on recorded developer portal URL for the endpoint
Results
352 payers with implementations across 30 vendors were evaluated for this report. Top scoring payers and vendors are below and you can download the full report here.
Top Payers
Our highest scoring payer implementation received 82 points out of 100, with two payers tied for the third highest score.
- Centers for Medicare & Medicaid Services - 82/100*
- Health Plan of San Joaquin - 78/100
- Anthem - 73/100
- Santa Clara Family Health Plan - 73/100
Top Vendors
Vendor scores are calculated based on the median score across their payers' metrics with two caveats. One, only the subset of metrics that has been denoted by 💼 above are evaluated as relevant to vendors. Two, only the payers who have live production endpoints are evaluated.
Our highest scoring vendor received 31 points out of a possible 70.
- Care Evolution - 31/70
- Health Samurai - 30/70
- 1Up Health - 26/70
Shoutouts
- Blue Shield of California
- For making all lines of business available through their Patient Access API ahead of (and despite) the extended regulatory requirements.
- Centene
- For testing updates to their FHIR base URL over a month in advance of the changes being put into production.
- Centers for Medicare & Medicaid Services
- For proactively soliciting feedback from the developer community both through a live Zoom call as well as asynchronously through surveys.
- Cigna
- For not only proactively discussing migration changes to prevent disruptions, but thoroughly reviewing all changes big and small to ensure updates would not break developer implementations.
- Hawaii Medical Services Association
- For their successful migration to a cloud solution and their forward thinking efforts to do so in service of enhancing the system's functionality, performance, and scalability.
- HealthLX
- For encouraging production test users across all payer endpoints to perform end to end testing
- Independence Blue Cross
- For increasing FHIR server rate limits from 10 requests per 3 seconds to 500 per 3 seconds, which will significantly improve performance and reduce errors.
Qualitative Insights & Opportunities
Ecosystem Experience Challenges
- Implementation Timeline Challenges: Many payers face extended delays when implementing record uploads. The separation between API construction and data upload often creates multi-month delays, leaving partially functional APIs that can't properly serve members.
- Strategic Vision Gaps: Some organizations view these APIs solely as compliance requirements rather than strategic assets. This mindset limits investment and hinders the development of robust, user-friendly implementations.
- System Coordination Failures: Poor communication between identity providers (IDPs) and FHIR vendors creates cascading failures. For example, when FHIR vendors change identifiers without notifying IDPs, all refresh tokens can become invalidated, forcing users to manually reconnect and frustrating both users and developers.
Patient Experience Opportunities
- Trust-Building Features: Consistent branding across authentication endpoints helps build patient trust. Users are more likely to complete authorization when they recognize familiar branding elements like logos and color themes.
- Credential Consistency: Patients expect to use the same credentials they use for member portals. Authentication systems requiring separate credentials create confusion and abandonment.
- Streamlined Registration: When a user doesn't have an existing online account and creates one, immediate data access eliminates frustrating wait times. Systems requiring a delay for data upload then reauthentication create significant patient drop-off.
- Clear Communication: When patients encounter errors, clear instructions and alternative paths are essential. Generic error messages without actionable guidance lead to abandonment.
Developer Experience Pain Points
- Troubleshooting Barriers: The most common challenge we as developers face is the "It's working on my end" response from payers, which fails to address underlying issues and provides no actionable next step.
- Approval Process Friction: Many payers require individual member approval for third-party connections, but explain the process poorly to members. Requests often go unanswered because they're framed as administrative tasks rather than beneficial services.
- Developer Contact Gaps: Vendors who manage payer endpoints but require payer approval without the ability to provide payer contact information is a frustrating roadblock. Similarly, payers reference vendor relationships without sharing vendor names for direct troubleshooting. This creates circular communication challenges.
- Lack of Notification: Simple operational matters like client credential rotation often lack proper notification. Developers face extended troubleshooting cycles only to discover a key rotation occurred without notification. Better portal visibility or automated notifications would eliminate these preventable disruptions.
How Flexpa Can Help
Flexpa is a consent management system that connects patient-consented claims data from every health plan. At Flexpa, we specialize in building the connective tissue between payers and the growing ecosystem of healthcare applications, ensuring that patient-consented claims data can be adopted widely for the benefit of patients.
Due to our vast experience connecting to, troubleshooting with, and advising health plans on their interoperability projects, Flexpa can help you:
- Comply with upcoming CMS 0057 requirements on both network access and consent management. Two essential capabilities to reap the business value from these efforts.
- Test your CMS 9115F or 0057 implementations end-to-end in development or production environments. Whether you're still in development and testing incrementally, or have the full service built out and just want to make sure there have been no breaking changes, we're here to help.
- Send you error logs from observed real patient usage for authentication, token exchange, or FHIR API errors encountered.
- Something else? Let's chat.
Contact Flexpa to learn how your organization can make the most of CMS-9115-F—and prepare for CMS-0057. Learn more about how we support payers or schedule a demo.
Let's make your API work for you—and for the members you serve.
*May 20 2025 update: We discovered and fixed two scoring errors in our CMS implementation evaluation, resulting in an updated ranking.
