Nov 2024 State of the Payer Patient Access API Report

Introduction

Six months ago, we published our inaugural State of the Patient Access API report to help stakeholders understand the real-world implementation status of CMS-9115-F. The response was remarkable - payers and vendors alike engaged with the findings, leading to collaborative improvements in API implementations and testing processes. This second edition builds on that foundation with refined metrics, expanded coverage, and deeper insights into what makes a successful Patient Access API implementation.

Who is Flexpa?

Flexpa provides patient-consented claims records from every health plan through our comprehensive integration with payer FHIR endpoints. As the largest consumer of Patient Access APIs, many payers report we represent the majority of their API traffic. As such, we have unique visibility into the successes and challenges of these implementations. Flexpa has facilitated over 120,000 successful connections across 216 health plans, giving us unparalleled insight into what works and what doesn't in the Patient Access API ecosystem.

Our core offerings include:

• Full payer coverage: Maintaining the largest network of payer FHIR endpoints in the U.S.
• Digital consent management: Simplifying user onboarding with a drop-in digital consent flow that is tailored to support varied consent requirements.
• Records API: Providing instant and ongoing access to coverage, claims, and clinical records.

With these capabilities, Flexpa helps any organization accelerate patient onboarding, streamline clinical trial participation, eliminate manual claim submission, enhance benefit processing, personalize plan enrollment processes, and much more.

Schedule a demo to see how Flexpa's solutions can transform your healthcare data strategy.

Regulatory Updates

As we close out the Biden administration and look ahead at the future of Patient Access, a number of legislative and regulatory threads remain hanging:

• We continue to drive forward towards the changes to the Patient Access APIs via the CMS' Interoperability and Prior Authorization Final Rule (CMS-0057-F), which will add reporting requirements on API usage and expand the data available by including prior authorization information
• CMS-0057 will also add significantly more complicated API transactions such as the Payer-to-Payer API, Provider Access API, and Prior Authorization APIs to the mix. This will increase demand for mature FHIR servers, but also nuanced workflow software for the complexity of prior authorizations.
• The good faith estimates included in the No Surprises Act still need regulatory action by the CMS to outline the exact path ahead, but are expected to expand Patient Access APIs to include advanced explanation of benefits. Today’s API only includes adjudicated claims
• The ASTP’s new HTI-2 Proposed Rule has expanded their voluntary health technology certification program with criteria for payers, including certification of payer patient access APIs

However, while health technology largely has been bipartisan through prior administrations, the unpredictable nature of the upcoming Trump presidency creates uncertainty around implementation timelines and enforcement priorities. Historical precedent suggests the core technical standards and interoperability work will likely continue, but the pace and specifics of implementation - particularly around newer requirements like Prior Authorization APIs and Good Faith Estimates - may be subject to review and potential modification. In particular, prior conservative administrations have targeted the ASTP and the voluntary certification program as examples of government overreach. Healthcare organizations will need to balance maintaining compliance momentum with flexibility for potential regulatory adjustments.

Reflections on the Last Report

The publication of our May 2024 report catalyzed significant improvements across the ecosystem. Several payers and vendors became active testing partners, including HCSC, Humana, PacificSource, HMSA, BC Idaho, and IEHP on the payer side, and Fire.ly and HealthSamurai among vendors. This collaboration led to meaningful improvements in both API implementations and our testing methodologies.

Based on stakeholder feedback, we've refined our scoring framework to provide more granular insights into implementation quality. We've expanded our metrics to better capture the nuances of authorization flows, API reliability, and standards conformance.

This report represents the most comprehensive assessment of Patient Access APIs to date, analyzing over 488 endpoints across 28 vendors. To account for updates made by payers since May, this report assesses data from the last 6 months.

For payers and vendors reading this report, we welcome any and all questions or feedback you have in response to the report. We hope to continue building partnerships to tackle these challenges together.

Changes in this report

Here's a high-level overview of the metric changes between May and November 2024:

• Scoring Granularity: We added more granular scoring tiers across several metrics, particularly in authorization success rates and error rates, to better differentiate implementation quality.
• Category Weights: We rebalanced the total points across categories to place greater emphasis on authorization reliability and FHIR implementation quality, while maintaining the overall 100-point scale.
• New Metrics: We added several new metrics to evaluate previously unmeasured aspects of implementations, such as maximum authorization periods, eligibility error handling, and conformance to CARIN BB Implementation guidelines.
• Performance Metrics: We introduced more quantitative measurements around sync speeds and error rates to better capture actual user experience.

Now, onto the actual metrics. If you want to jump straight to the results, you can read our takeaways or directly download the results here.

Metrics Overview

Our scoring framework evaluates Patient Access API implementations across five key dimensions, with a total possible score of 100 points. Each dimension measures critical aspects of API functionality and user experience.

Compliance and Coverage (25 points)

The foundation of any Patient Access API implementation begins with core regulatory compliance and breadth of coverage. CMS 9115F had an initial deadline of July 1, 2021 (delayed from January 1 due to COVID), and we are now over 3 years past that deadline. This category evaluates both the basic availability of the API and how extensively it serves different patient populations.

Status (20 points)

Based on Flexpa's continuous monitoring of connection attempts and success rates, we assign each endpoint a status that reflects its real-world accessibility and functionality. This metric provides an objective measure of whether patients can actually access their data.

• 20 - User Validated: Patients have successfully completed the flow
• 12 - Live: Production access is enabled, but no patients have gone through the flow yet
• 8 - Broken: Production access is enabled, but users are currently unable to successfully complete the flow
• 4 - Applied: Flexpa has applied for sandbox or production access, but access has not been granted.
• 0 - Not Available: No documentation or developer portal has been found

Lines of Business Support (5 points)

While CMS only mandates certain lines of business provide API access, leading implementations extend access to all members regardless of plan type. This reduces patient confusion and support burden while increasing API utility.

• 5 - All lines of business supported
• 3 - All CMS-mandated + ACA off-exchange
• 1 - All CMS-mandated
• 0 - Partial CMS-mandated or None

Developer Experience (8 points)

A robust developer experience is crucial for successful third-party integration. This category evaluates the tools and documentation available to developers implementing against the API.

CapabilityStatement (3 points)

The CapabilityStatement is a FHIR resource that describes the functionality supported by a FHIR server, including available resources, operations, and search parameters. A complete and accurate CapabilityStatement allows applications to programmatically understand an endpoint's capabilities. This measure looks at whether a capability statement is available at the {baseURL}/metadata endpoint.

• 3 - Available and accurate
• 1 - Available but inaccurate
• 0 - Not available

Well-known SMART Configuration (3 points)

The well-known SMART configuration endpoint provides OAuth2 authorization endpoints and capabilities following the SMART App Launch Framework. This standardized discovery mechanism is critical for automated client configuration. This measure looks at whether a SMART configuration is available at {baseURL}/.well-known/smart-configuration.

• 3 - Available and accurate
• 1 - Available but inaccurate
• 0 - Not available

Sandbox Environment (2 points)

A sandbox environment allows developers to test their integration without using production credentials or real patient data. This significantly accelerates development and reduces the risk of issues affecting real patients.

• 2 - Available
• 0 - Not available

Authorization and Access (28 points)

The authorization flow is often the biggest barrier to patient access. This dimension evaluates both the technical implementation and user experience.

Access Token Expiry (4 points)

When an application receives an access token after successful authorization, the token expires after a set period requiring either re-authorization or refresh. Longer expiry periods reduce user friction while maintaining security, with 1-24 hours representing the optimal balance.

• 4 - 1-24 hours
• 3 - 30 minutes to 1 hour
• 2 - 10-30 minutes
• 0 - Less than 10 minutes or greater than 24 hours

Refresh Token availability (7 points)

Refresh tokens allow applications to maintain access without requiring user re-authorization. This critical feature dramatically improves user experience by enabling persistent access while maintaining security controls.

• 7 - Available
• 0 - Not available

Maximum Authorization Period (3 points)

The maximum time an application can maintain access through refresh token usage before requiring re-authorization. Longer periods reduce user friction while still ensuring periodic re-validation of access permissions.

• 3 - Greater than 1 year
• 2 - 6 months to 1 year
• 1 - Less than 6 months
• 0 - No information

Patient Launch Parameter (1 point)

A standardized SMART parameter that tells applications which patient's data they are authorized to access. This enables reliable patient context handling without requiring custom per-vendor implementations.

• 1 - Present
• 0 - Not present

Eligibility Errors Sent on Callback (2 points)

When a patient isn't eligible for API access (e.g., not on a CMS-mandated plan), the payer can either send a legible error back on the callback response (best scenario) or error in a non-transparent way to the requesting application (in login screen UI, pass auth but fail to fetch in the FHIR server). Returning structured errors immediately after login enables applications to provide clear guidance to users and reduce support burden.

• 2 - Yes
• 0 - No

Authorization Success Rate (8 points)

Measures the percentage of authorization attempts that successfully complete, from initial redirect through token receipt. This metric directly reflects the reliability and usability of the authorization flow for end users.

• 8 - 98-100%
• 7 - 95-98%
• 6 - 90-95%
• 5 - 85-90%
• 4 - 80-85%
• 3 - 70-80%
• 2 - 60-70%
• 1 - 50-60%
• 0 - Less than 50%

Authorization Speed (3 points)

Measures the total time a patient spends in the payer’s login screen. Fast completion times indicate a streamlined user experience with minimal friction in the payer’s authorization page.

Average time to complete authorization:

• 3 - Less than 1 minute
• 2 - 1-2 minutes
• 1 - 2-5 minutes
• 0 - More than 5 minutes

FHIR API Implementation (31 points)

The quality and completeness of the FHIR implementation determines the utility of the API for third-party applications. This category evaluates both technical reliability and data completeness.

FHIR API Error Rate (6 points)

Measures the percentage of API calls that result in errors during data retrieval. Lower error rates indicate more reliable implementations that require less retry logic and provide a better user experience.

• 6 - Less than 0.1% error rate
• 5 - 0.1-0.5% error rate
• 4 - 0.5-1% error rate
• 3 - 1-2% error rate
• 2 - 2-5% error rate
• 1 - 5-10% error rate
• 0 - Greater than 10% error rate

CARIN BB Resources (12 points)

The core CARIN Blue Button Implementation Guide resources represent the fundamental data types that health plans maintain:

• 6 - ExplanationOfBenefit: Claims data including services, costs, and payment details
• 4 - Coverage: Plan details including member ID, group ID, and coverage dates
• 2 - Patient: Basic demographic information essential for identity verification

Clinical Resources (6 points)

While payers primarily maintain administrative data, claims processing requires key clinical information. These USCDI resources can be derived from claims data and provide valuable clinical context:

• 1 - MedicationRequest: Prescription claims and pharmacy benefits
• 1 - Condition: Diagnoses from claims
• 1 - CareTeam: Providers involved in care
• 1 - Procedure: Services and interventions
• 2 - Other USCDI: Additional clinical data from provider interactions

Practitioner and Organization References (4 points)

FHIR resources often reference providers and organizations. The ability to resolve these references to full resources provides valuable context about who delivered care and where.

• 4 - Both Practitioner and Organization references can be resolved
• 2 - Either Practitioner or Organization references can be resolved
• 0 - Neither Practitioner nor Organization references can be resolved

$everything Support (1 point)

The FHIR $everything operation provides a standardized way to retrieve all of a patient's data in a single request. This simplifies client implementations and ensures complete data retrieval.

• 1 - Supported
• 0 - Not supported

Sync Speed (2 points)

Measures how quickly an application can retrieve a complete patient record. Faster sync times improve user experience and reduce application complexity.

• 2 - Median sync time of 10 seconds or less
• 1 - Median sync time of 30 seconds or less
• 0 - Median sync time above 30 seconds

CARIN Implementation Guide Conformance (8 points)

The CARIN Implementation Guide provides detailed technical guidance for implementing claims and payment data APIs. While full conformance validation is complex, implementations that reference CARIN profiles demonstrate commitment to standardization. We evaluate which version of the Implementation Guide is referenced, with higher scores for more recent versions.

Scoring is based on resources that follow:

• 8 - The latest CARIN implementation guide >= 2.0.0
• 6 - STU1 >= 1.1.0
• 4 - >= 0.1.0
• 0 - Resources do not conform to any CARIN implementation guide

Overall Results

Score Distribution across Payers

Below are the aggregated results from 488 endpoints, across several key metrics.

November 2024 Total Scores

Endpoint status

Available lines of business

Sandbox availability

Refresh token availability

Authorization success rate

EOB Resource availability

Eligibility errors on callback

Sync speed

CARIN Implementation Guide Profile

Opportunities Beyond Metrics

Coverage & Implementation Gaps

• Many payers have yet to implement Patient Access APIs despite consistent patient requests for access. When patients search for these payers in authorization flows, there's no clear indication of when or if access will become available.
• When APIs are implemented, they often deviate from OAuth standards by requiring custom headers, non-standard parameters, and proprietary scope definitions. This creates unnecessary complexity and reduces interoperability across the ecosystem.
• Payers rarely provide notifications about API updates or planned downtime. Without standardized communication channels, applications must react to disruptions after they affect patients rather than planning for them proactively.

Troubleshooting and Support Challenges

• When technical issues arise, troubleshooting timelines easily extend into months. Complex relationships between payers and their vendors often result in communication gaps and delayed resolution.
• Most implementations provide limited visibility into authorization failures, making it difficult to determine whether issues stem from technical problems or legitimate eligibility restrictions.
• Customer support teams frequently lack familiarity with Patient Access API functionality. When patients encounter issues, they're often redirected to general customer service representatives who have no context about the API or its requirements.

Authorization Experience Friction

• Many payers maintain separate authentication systems from their member portals. This causes confusion, frustration and distrust and forces patients to create duplicate credentials and manage multiple login workflows.
• Authorization interfaces, especially those managed by vendors, often lack basic usability elements like payer branding, password reset capabilities, or registration links. This creates confusion for patients who expect the same experience they have with their member portal.
• Some major vendors implement impractically short refresh periods - as short as 2 hours - and limited maximum authorization periods. This forces frequent re-authorization and creates unnecessary friction for patients.

Eligibility Verification Challenges

• Instead of returning structured eligibility errors through the OAuth callback, many payers only display these messages on their member portal UI. This prevents applications from providing clear guidance to users about their access status.
• Some vendors return valid access tokens for ineligible members but omit the patient identifier. This pattern requires extensive troubleshooting to differentiate between technical errors and legitimate eligibility issues.
• In other implementations, authorization succeeds but subsequent FHIR queries return empty bundles with no indication of whether this represents an eligibility issue or a technical problem.

Complex Eligibility Rules

• Patients must navigate intricate rules about exchange participation, Medicare Advantage status, and supplemental coverage to understand their access rights.
• The distinction between on-exchange and off-exchange plans, Medicare Advantage versus Medicare Advantage Supplement plans, and other nuances creates confusion for both patients and applications.
• These complex eligibility rules make it difficult for applications to clearly communicate access requirements and for patients to understand whether they should have API access to their data.

Payer Analysis

Download the full scorecard here.

Top Performing Payers

The highest scoring payers demonstrate excellence across all measurement dimensions:

1. Maryland Physicians Care (85 points, OneUp Health)
   • Perfect score in FHIR implementation (31/31)
   • Strong authorization capabilities
   • Comprehensive clinical resource support
2. Paramount Insurance Company (85 points, Health Samurai)
   • Excellent developer experience (8/8)
   • Strong authorization success rates
   • Complete CARIN BB implementation
3. UPMC Health (83 points, in-house solution)
   • Full coverage across lines of business
   • Robust developer tooling
   • Superior reference resolution

Most Improved Implementation

Health Care Service Corporation (HCSC), operating Blue Cross Blue Shield plans across Texas, Montana, Illinois, New Mexico, and Oklahoma, demonstrated the most dramatic improvement in the last six months. Their consolidated implementation shows:

Current Implementation Strengths:

• Strong FHIR API implementation (22/31 points)
  • Complete CARIN BB resource support
  • Full clinical resource suite including MedicationRequest, Condition, CareTeam, and Procedure
  • Comprehensive reference resolution
• Robust technical infrastructure
  • CapabilityStatement availability (3/3 points)
  • Well-managed access token handling
  • Sub-30 second sync speeds

This transformation is particularly notable as HCSC moved from having no functional Patient Access API to a robust implementation serving millions of members across five states. Their collaborative approach to troubleshooting and commitment to standards-based implementation now serves as a model for large payer groups implementing consolidated Patient Access APIs.

Vendor Analysis

Download the full scorecard here.

Top Vendor Overall: Health Samurai

Health Samurai (77 avg score, 3 implementations)

1. Highest average authorization success rates
2. All implementations scoring above 65 points
3. Ahead with a 15 point lead from #2

Vendor Implementation Patterns

Top large-scale Vendors (>20 implementations)

• SmileCDR (46 avg score, 26 implementations)
• Edifecs (40 avg score, 24 implementations)
• OneUp Health (34 avg score, 67 implementations)

Top mid-scale Vendors (10-20 implementations)

• Cognizant (34 avg score, 11 implementations)
• SAFHIR (23 avg score, 11 implementations)
• Epic (20 avg score, 14 implementations)

Top emerging Vendors (<10 implementations)

• Health Samurai (77 avg score, 3 implementations)
• Opala (61 avg score, 1 implementation)
• Intersystems (52 avg score, 5 implementations)

Conclusion

The Patient Access API landscape continues to mature, with notable improvements in both implementation quality and coverage. However, given that it has been nearly three years since the initial mandate went into effect, we need to be expecting more from the landscape. With CMS-0057 and TEFCA coming down the pipe, the delays seen implementing Patient Access APIs will be magnified if issues are not fixed. Significant opportunities remain to enhance the developer experience, streamline authorization flows, and expand resource availability. Success stories like HCSC demonstrate that with proper focus and collaboration, these challenges can be overcome effectively.

The next six months will be critical as more payers work to improve their implementations and new regulatory requirements come into effect. Future reports will continue to track these developments and highlight both progress and remaining opportunities in the ecosystem.

If your team is thinking about CMS 0057 already, so are we! We would love to work together on building this next layer of health data interoperability. If you have any questions on this report, reach out to us at interop@flexpa.com.

If you want to empower your healthcare data strategy, schedule a demo to see how Flexpa's solutions can transform your healthcare data strategy.