The State of Payer Patient Access APIs

A scorecard for payers, vendors, and developers to understand the CMS-9115 landscape

Are you more interested in results and less interested in background? Skip ahead to the “Payer Analysis” and “Vendor Analysis” sections to see who’s doing well and who has room to improve.

On May 1, 2020, the CMS published CMS-9115, the CMS Interoperability and Patient Access Rule, affecting Medicare Advantage, Medicaid, CHIP, and ACA payers nationwide. Inspired by the 21st Century Cures Act and the ONC’s Cures Rule (but not gifted any additional authority or mandate), it represented the first foray by the agency into roles it hadn’t necessarily assumed previously - steward of health plans’ technical modernization, promoter of payer-oriented API technologies, and creator of some of the larger insurer infrastructure changes in decades.

As previously commented on, the rule was and is not perfect by any means:

• Coverage: Although the CMS can effectively regulate most providers in the country as the country’s largest payer, they lack the same reach across all payers or plans in the country. Fully funded, self-funded, federal, military, and many other plan types fall outside the authority of the CMS, meaning that they do not have access today.

• Data reliability: The rule failed to concretely recommend or require certain implementation guides, leading to disparate implementations in terms of data. When some payers have Coverage or MedicationRequest, but not all, those resources can not be uniformly relied on.

• Data depth: Patients don’t just want data for data’s sake - they want data to solve their problems. Detailed coverage information, prior authorizations, and in-progress claims are all extremely powerful tools in solving problems for patients - navigating care, unlocking novel treatments, or predicting costs. These concepts were omitted from this first rule, although future rules such as the CMS Interoperability and Prior Authorization Final Rule or the implementation of the No Surprises Act may address some of those gaps.

However, the rule is laudable as a first step towards empowering the patient to direct claims and other payer data to the applications of their choosing.

This rule foundationally underpins Flexpa’s mission to be the world’s easiest way to safely and securely access claims data. As the compliance date, July 1st, 2021, came into effect for payers to make available the Patient Access APIs detailed in the rule, we began our journey to connect to the available payers and allow patients to control their data and direct it to the applications of their choice.

Our coverage, the most comprehensive available today, covers 88.73% of lives on plans regulated by the CMS - 152,113,089 in total.

Access is not uniform across the country. Compliance and activation are variable by state, ranging from 43.82% to 100% depending on location, which you can explore more here.

We have pushed hard and knocked on every door to make this happen, battling through telephone tag, incomplete documentation, and broken APIs. There are myriad technical challenges scaling across all payers and plans: old TLS versions, incorrect FHIR implementations, and even failures to use HTTP properly. Beyond that, the operational obstacles to getting live were numerous, ranging from invalid developer support emails all the way to complete non-compliance.

Having explored the contours of the ceiling of the CMS rule, this report will catalogue the landscape of Patient Access APIs and score various implementations. We hope that it will be useful to a variety of stakeholders:

• Patients: The Patient Access API doesn’t work without patients, obviously. The API’s main intent is to enable them to access novel care, choose the right plans and providers, and manage their healthcare costs.

  • By giving a reference resource, we can raise awareness of what payers are available and how patients can use their data.

• Payers: As detailed in the recent CMS Prior Authorization Rule, non-compliance or prohibitively difficult patient access experiences can lead to patients reporting dissatisfaction to the CMS, state agencies, and other entities, negatively affecting reimbursement.

  • By baselining the status quo and giving perspective into the features for not only full compliance but also superlative implementation of payer patient access, we hope payers can understand where they stand and how to improve to better serve their members. The complaint of lack of adoption is generally a function of flaws in implementation. Patient usage is directly correlated with implementations that offer straightforward authorization processes and reliable FHIR APIs.

• FHIR server vendors: The payer market for FHIR servers has nearly saturated at this point aside from the Medicaid FFS state agencies, but still remains fairly fragmented and dynamic. We still see payers switching vendors with a new layer of FHIR-oriented regulation, putting strain on lower-end solutions, and expect that the market will continue to consolidate.

  • By highlighting strengths and weaknesses across vendors, the report offers FHIR vendors an impartial view of how they stand in the market and how they might improve to take advantage of future market consolidation.

• Third-party applications: For dozens of these payers, we were (and often still are) the first application to move to production.

  • By opening the door and smoothing out processes, support, and technical hiccups, we hope and expect many more to follow. The rule’s value is only realized with a large ecosystem of applications, and these APIs only get better with robust usage by disparate entities.

• Regulators: The CMS has made the rule but often may lack detailed insight into the API's real-world status.

  • By making this report available, the CMS should be able to improve any future rule-making in this space. Additionally, they may reach out to different payers about their compliance, given the date has long passed.

• Legislators: The CMS stitched together authority for this rule from a wide range of pre-existing laws, including the Social Security Act, the Affordable Care Act, and more. However, it does not have the authority to make this capability available to all Americans.

  • By showing the ceiling of the rule today, legislators at the federal level can pass the laws necessary to further empower the CMS to enforce compliance and start the tri-agency work to expand coverage to all plan types (as commercial regulation would require the collaboration of the CMS, the Department of Labor, and the Department of Treasury). Similarly, state legislators can follow the lead of California and Tennessee, who have expanded coverage in their states to all lines of business.

---

Regulatory Summary

While CMS-9115 was the original mandate to provide Patient Access APIs, there has been continued traction at both the federal and state levels to expand the data available via the API and the patients that have access to it:

• California Senate Bill 1419 (SB-1419): Signed into law in September 2022, this state bill expanded requirements for the Patient Access APIs to all health plans that operate in the state, meaning that patients on commercial plans would be covered. Originally slated to go into effect on January 1, 2024, it was pushed back a year after successful payer lobbying efforts.

• CMS Interoperability and Prior Authorization Final Rule (CMS-0057): A long-delayed follow-on to CMS-9115, it requires plans to make available a number of new APIs (Payer-to-Payer, Provider Access, and Prior Authorization). However, it notably expands the data available via the existing Patient Access API, requiring that medical prior authorization details are available. It also finalizes specific FHIR implementation guides as required, such as OpenID Connect and SMART. As shown later in this report, most payers are not compliant with these today. This rule will be required as of January 1, 2027.

• Tennessee Senate Bill 2012 (SB-2012): Similar to SB-1419, this bill has a section that requires health insurance entities to establish and maintain specific APIs (Application Programming Interfaces) to facilitate access to health information for patients and providers. These include patient access, provider directory, and payer-to-payer exchange APIs. Passed unanimously on April 25, 2025, it points to federal compliance dates, meaning that expansion to commercial and other previously unregulated plan types should be included by payers once signed by the governor.

• No Surprises Act (H.R.3630): This law establishes new consumer protections from unexpected medical bills. The NSA includes requirements for providers to send Good Faith Estimates (GFEs) to payers, who must then provide advanced explanations of benefits to patients. While the specific provisions related to GFE and AEOB have not been finalized, the industry seems to be converging around the DaVinci Patient Cost Transparency Implementation Guide, as the CMS notes here. This means that in-progress EOBs will be added to the Patient Access API once the rule is rolled out.

In summary, federal rules will expand data types to include expanded clinical content, prior authorization information, and advanced explanation of benefits, while state-based laws expand coverage regionally to all lines of business. While these federal and state initiatives are exciting in terms of expanding data and coverage, the main regulatory gap still remains the access gap: all Americans should be able to access their health plan data via API and direct it to the applications of their choosing. The state-by-state expansion of coverage, while beneficial on that front, significantly adds to payer burden and results in higher failure rates due to inappropriately implemented eligibility rules. As noted earlier, we hope to see a tri-agency federal rule to address this need.

---

Measuring Compliance and Beyond

When thinking about the metrics and measures of what a successful Patient Access API implementation looks like, we identified four main areas of focus:

• Compliance and coverage: The most important factor is just whether the capability is available to patients.

  • Does the plan even have an API?

  • Does it work end-to-end?

  • Does it cover the regulated population?

  • Does it go beyond the bare minimum and cover all plan types?

• General developer experience: The process of getting an application approved and live varies dramatically across payers. This section measures the use of best practices to enable a superlative developer experience and reduce the payer's support burden.

  • Does the payer have documentation and a developer portal?

  • Does the payer offer a Well-known SMART configuration?

  • Does the payer offer a CapabilityStatement?

• Authorization and access: The first step in the Patient Access API is the member granting access. This section measures the use of recommended standards and best practices for the authorization flow

  • Does it follow SMART conventions?

  • Does it have a reasonable access period?

  • Does it allow for refreshing?

• FHIR API: The CMS rule said the following data must “at a minimum, make available adjudicated claims (including provider remittances and enrollee cost-sharing); encounters with capitated providers; and clinical data, including laboratory results (when maintained by the impacted payer).” This section details whether payers do so.

  • Resources defined in the CARIN Blue Button Implementation Guide include Patient, Coverage, and ExplanationOfBenefit. There is no excuse for payers to not have these available, given they are core to their business.

  • USCDI that can logically be derived from claims, such as MedicationRequest, Condition, Procedure, and CareTeam. These should be present for all payers but often are not.

  • Resources defined in USCDI that cannot be derived from claims, such as DiagnosticReport, Observation, and DocumentReference. These are rarer and only present if the payer engages in robust data exchange with providers.

  • The $everything operation is a powerful tool for applications that want to rapidly and reliably retrieve all data for a patient.

  • The speed of data synchronization is ultimately a great metric for understanding whether applications can efficiently access all the data a patient may need.

---

Metrics

This section fully details all objective measurements based on Flexpa usage that we used in calculating payer scores.

General (60)

Status (40 points): The most important facet of the patient access APIs is whether or not a patient can get through the flow and access their data. The status metric measures where payers are on that journey.

• Validated (40 points): Production access is enabled, and patients can successfully complete the flow.

• Live (20 points): Production access is enabled, but patients have not been able to go through the flow successfully.

• Applied (10 points): While documentation or a developer portal was found, production access has not been enabled.

• Not Available (0 points): No documentation or developer portal could be found.

Patient Volume (3 points): Patient volume is a clear indicator that a payer’s implementation is reliable and does not have artificial blockers to access, such as hidden opt-in provisions in the member portal.

• Weekly/daily patient volume: 3

• Monthly patient volume: 2

• Volume greater than 0: 1

• No patients: 0

Patient Support Requests (3 points): Flexpa receives patient support requests when patients run into technical and operational challenges accessing their data. This metric measures the volume of support requests by payer. UnitedHealthcare leads this list, with nearly 100 unique covered patients unable to access their data.

• Greater than 20 unique patient support requests: 0

• Between 10 and 20 unique patient support requests: 1

• Between 1 and 10 unique patient support requests: 2

• No patient support requests: 3

Support for all Lines of Business (10 points): A simple measure of whether or not the payer’s implementation includes access beyond the compliance floor and allows all patients to access their data. This increases patient satisfaction and reduces payer support burden, in that inappropriately implemented eligibility rules are one of the top reasons for patient support requests.

General developer experience (7)

Developer Portal (2 points): A developer portal that includes provisioning and managing application credentials allows for safer, more secure integration with patient access APIs, but many payers have only rudimentary documentation pages or no guidance at all.

• Full (2): The payer implementation includes a developer portal for the management of API secrets.

• Docs only (1): The payer implementation only includes developer documentation.

• None (0): The payer implementation does not include a portal or documentation.

Well-known SMART configuration (2 points): The SMART implementation guide (required by the CMS when CMS-0057 applies) defines a discovery document for applications to understand the details of the authorization configuration. This eases developer burden, allowing for programmatic configuration of authorization. In lieu of this, authorization details are manually described in the documentation, which is often outdated or lacking sufficient information, or are conveyed only via email communication.

• Yes (2)

• No (0)

CapabilityStatement (3 points): The SMART implementation guide defines that FHIR servers should make a CapabilityStatement available. While SMART is transitioning from putting authorization details into the CapabilityStatement to instead using a Well Known SMART configuration, the CapabilityStatement resource is extremely valuable to developers to know what resources and search parameters are supported. In lieu of this, FHIR server details are manually described in documentation, which is often outdated or lacking sufficient information, or are conveyed only via email communication.

• Yes (3)

• No (0)

Authorization and Access (20)

Length of access token expiry (2 points): An access token is granted after a patient authorizes access. This token is used for subsequent FHIR API calls. When access tokens are granted, the authorization server returns the expiry period in the expires_in parameter. The expiry period is important as access tokens should not be valid forever for security purposes but also should be valid for long enough that applications can retrieve a patient’s data.

• Less than 10 minutes (0)

• Less than an hour (1)

• Less than 24 hours (2)

• Greater than 24 hours (0)

Presence of refresh token (15 points): Refresh tokens are issued to enable sessions to last longer than the validity period of an access token. This balances security (ensures access is by the approved application) while minimizing the patient burden of reauthorizing. Refresh tokens are the most important feature to increase member adoption, as lack of persistent access is an extreme dissatisfier for patients.

• Refresh token (15)

• No refresh token (0)

Presence of refresh expiry period (1): Similar to how the authorization server returns the expiry period in the expires_in parameter, many authorization servers return the refresh token expiry period in either the refresh_expires_in parameter (Keycloack servers), the refresh_token_expires_in parameter (Microsoft) or the exp claim of the refresh token. In lieu of this, refresh expiry periods are manually described in documentation or calculated by brute force.

• Presence of a refresh expiry period attribute (1)

• No refresh token expiry period (0)

Presence of patient launch parameter (2): The patient launch context parameter tells the app which patient's data it is authorized to access, while the fhirUser claim in the ID Token tells the app which user approved the launch. Payers deviate from this standard commonly, with applications today needing to handle over 21 unique custom locations or methods to ascertain and pull the right patient. The inclusion of the patient launch context parameter is defined in SMART and allows the application to understand the right patient to access in an interoperable fashion.

• Presence of the patient launch context parameter (1)

• No patient launch context parameter (0)

FHIR API (20)

The CMS Patient Access Rule stated this about what data should be available to patients:

Specifically, we are requiring that the Patient Access API must, at a minimum, make available adjudicated claims (including provider remittances and enrollee cost-sharing); encounters with capitated providers; and clinical data, including laboratory results (when maintained by the impacted payer). Data must be made available no later than one (1) business day after a claim is adjudicated or encounter data are received. 

This has been commonly interpreted to mean that payers should make available the resources of the CARIN Blue Button Implementation Guide (Patient, Coverage, and ExplanationOfBenefit), as well as core clinical resources (defined in USCDI version 1), as well as

CARIN BB resources (8 points): The CARIN Blue Button resources are the core data types that all payers produce by virtue of providing health insurance to patients - coverage and claims. As such, they are commonly shown in member portals and should be universally available regardless of payer operations. They are also the most unique data that a payer can equip their members with to enable better care.

• Patient (1): This resource is table stakes and required to understand key demographics.

• Coverage (2): This resource contains basic information about the member’s plan, such as plan name, member ID, group ID, and key dates.

• EOB (5): This resource is the most valuable to a member, containing key information about claims and the associated payment, as well as the responsibility that patients may have

Clinical resources (5 points):

• MedicationRequest, Condition, CareTeam, Procedure (4): While payers’ main focus is administrative data generated from financial processes, those processes do include key clinical data as exhaust. In order to process a claim, clinical information like diagnoses, medications, procedures, and a patient’s providers is required. As a result, all payers should be able to generate the four USCDI resources associated with those data types.

• Others (1): Other clinical data may be aggregated as part of data exchange programs with providers, such as quality measure submissions. This data is less consistently available (generally, only payers with mature value-based programs have robust clinical data like lab results, notes, and vitals).

$everything support (1): The FHIR $everything operation is intended to provide a patient with access to their entire record (e.g. "Blue Button"). It is a simple, developer friendly way to pull all of a patient’s data.

• $everything support (1)

• No $everything support (0)

Sync Speed (3): API availability is only the first step in providing patient access to their data. This measure looks at the performance of the API in terms of how it ranks relative to other payers’ APIs in the speed of synchronizing full patient records.

• Median sync time of 10 seconds or less: 3

• Median sync time of 30 seconds or less: 2

• Median sync time of 60 seconds or less: 1

• Median sync time above 60 seconds: 0

Future metrics

We had a number of other metrics we considered but chose not to include, either due to insufficient data collection or relative immaturity of the metric:

• Validation of the CapabilityStatement and Well Known SMART configuration: Real usage of the APIs has shown that the listed capabilities are not always matched to reality. Similarly, the listed capabilities in Well-Known SMART configurations often differed from reality, with the authorization experience not having supported scopes or capabilities. While we have the data in terms of the CapabilityStatements and patient volume, creating a metric that expressed accuracy proved challenging for this iteration.

• Maximum authorization period: The payer imposed an upper bound on the time period for which a user can keep an application in an authorized state despite continuously refreshing an access token prior to its refresh expiry. While this is sometimes the same as the refresh token expiry period, it often differs in that some payers issue new refresh tokens on refresh, allowing a patient’s authorization to be extended longer than the expiry period. Given that this information is not available programmatically or via most developer portals and can only be ascertained manually, we did not have comprehensive data here.

• Sandbox and/or production test patient availability: Without a method to test in advance of a real member going through the authorization flow, applications cannot verify that the functionality works end-to-end and are forced to have members try repeatedly as errors are identified and resolved. Sandbox environments are better than nothing but often differ significantly in configuration and settings. Production test patients are preferable but rarer. While we have this information, we were not able to compile it for this iteration.

• FHIR API error rate: Errors on data retrieval varied quite a bit in volume and type. While we were able to baseline this metric, we were not able to normalize it for different payer characteristics in a simple and straightforward fashion.

In future iterations, we’d like to implement these and other measures to continue to highlight where payers are doing well and can improve, so let us know anything else you think might be valuable.

---

Payer Analysis

Implementing the scoring algorithm, we have a few clear examples of payers with exemplar implementations. While each has small areas of improvement, they have put in the effort to be successful and geared their APIs towards optimal patient and developer experiences.

• Anthem/Elevance: 95

• Humana: 94

• UPMC Health: 93

• Capital District Physicians' Health Plan (CDPHP): 92

• CountyCare Health Plan: 92

• State of Kentucky: 92

• State of Nevada: 92

• Healthfirst: 91

• Kaiser Permanente: 91

• Maryland Physicians Care: 91

• State of Georgia: 91

• Centers for Medicare & Medicaid Services (CMS): 90

• Community Health Group: 90

• L.A. Care Health Plan: 90

These plans have reliable implementations with significant patient volume due to the availability of refresh tokens, full coverage across all lines of business, and superlative developer experiences.

Overall, this class of payer implementation is a distinct minority. Less than 25% of payers scored above 70:

Looking at just payers with over 100,000 lives, the breakdown is slightly better but still shows that most of the industry has significant room to improve:

Examining our lowest scoring tier of payers that are not yet compliant with the rule, the bulk of notable size are a number of state Medicaid agencies. Medicaid FFS agencies typically have elongated cycles for implementation compared to private plans in order to process new CMS rules, allocate budget, and issue request for proposals.

• State of Arizona

• State of Colorado

• State of Illinois

• State of Indiana

• State of Massachusetts

• State of Mississippi

• State of New York

• State of North Carolina

• State of Pennsylvania

• State of Texas

In terms of the private payers in this tier, the largest of note are a number of BCBS plans run by HCSC. To date, no CARIN application, Flexpa or otherwise, has successfully had a patient complete authorization and FHIR data retrieval:

• Blue Cross Blue Shield of Oklahoma (8)

• Blue Cross Blue Shield of Illinois (7)

• Blue Cross Blue Shield of Montana (7)

• Blue Cross Blue Shield of New Mexico (7)

• Blue Cross Blue Shield of Texas (6)

• Blue Cross Blue Shield of North Dakota (4)

The adverse effect of non-compliance by both state Medicaid FFS and HCSC (which are heavily involved in state Medicaid) mangaged care is that Medicaid populations have the least access of any regulated plan type today.

The full payer-by-payer breakdown is included below, with metric-by-metric scores for all payers:

If you are a payer and would like to work together to improve your score, please reach out. Likewise, if you believe any information is incorrect or out-of-date, please let us know.

---

Vendor Analysis

As noted earlier, the market for payer FHIR server implementations is quite fragmented. Many payers choose to build using open-source tools like HAPI FHIR, commercial options like Smile Digital Health or Firely, or cloud FHIR servers such as Microsoft FHIR Server for Azure, AWS Healthlake, or Google Healthcare Cloud.

Other payers chose off-the-shelf managed services, where each payer worked to load data but largely handed off operations to their vendor. Major vendors in this category include:

• 1Up Health (60 payers): Our highest-ranked vendor, with many payers in the 80-90 range, but one that suffers from high rates of patient support requests due to a largely broken identity-proofing experience.

• Edifecs (33 payers): A largely reliable vendor with strong support. However, most payers do not link their member portal identity provider, so patients are forced to re-register. Additionally, developer portal implementations often lack test patients or full configuration details. As a result, scores range from 18 (Aspire Health Plan) up to 90 (LA Care)

• Cognizant (11 payers): Based on Microsoft Azure behind the scenes, it is sufficient for basic exchange, but the developer portals are inconsistently available, authorization is frequently a problem due to unique nuances of the Azure IDP, and the FHIR implementation does not expose all expected resources.

• SAFHIR OnyxOS (10 payers): Based on Microsoft Azure behind the scenes, it suffers from similar problems to Cognizant, but with superlative developer support. Live payers usually score in the 70-80 range.

Smaller managed service vendors include:

• Healthtrio (7 payers): A popular solution for payer member portals, Healthtrio's authorization experience benefits from its innate IDP integration. However, its FHIR implementations to date have not included USCDI resources.

• HealthLX (5 payers): A newer entrant using Smile CDR under the hood, they have grown rapidly and helped plans achieve compliance quickly, with scores in the 75-80 range.

• Abacus Insights (6 payers): This is a competent and polished vendor with good developer experience. However, once live, scores will be in the 75-80 range as no clinical data is made available.

• Innovaccer (5 payers): A mature developer platform that suffers from non-responsive application activation processes and inconsistent authorization experiences. To date, no patients have been able to successfully navigate this and retrieve their data.

• Interopstation (4 payers): This is a largely deficient solution that rarely works during or after patient authorization. Support processes for developers and patients are non-existent, meaning that most patients are unable to access their data.

• Health Samurai (3 payers): A polished FHIR server and developer experience with limited payer adoption. Supported payers have production test users and retrieve USCDI data elements successfully.

• Inovalon (2 payers): Another mature developer platform that has been blocked by non-responsive application activation processes.

Certain types of payers gravitate towards particular vendors:

• Conduent (4 payers): A vendor with claims processing and other products tailored for Medicaid, they have been able to serve a number of their existing customers’ FHIR server needs.

• Similarly, 1Up Health has had success with state Medicaid agencies through their partnership with Gainwell Health.

• Many payviders using Epic as their EHR have opted to use that vendor for their CMS compliance. While their implementation is largely straightforward and polished, they do not make the Coverage resource available today.

With Change Healthcare's exit from the CMS Patient Access market in December 2023, a number of payers were and still are switching to new vendors, with 1Up Health, HealthLX, and Edifecs gaining market share as a result.

The full vendor summary, including the highest score for the vendor for each metric, can be found here:

If you are a vendor and would like to improve your scores together, please let us know. Likewise, if you believe any information is incorrect or out-of-date, please let us know.

---

---

Conclusion

Overall, payers and their vendors can reduce their support burden, increase member adoption, and improve their patient and developer experiences with some easy and straightforward changes:

• Ensure patients can complete the flow end-to-end: The main barrier for so many payers is still ensuring patients can complete the flow end-to-end. Payers should fix broken identity checking, remove barriers like hidden opt-ins, and ensure that data is available immediately after a member’s authorization. Flexpa has members waiting for most major plans, so please let us know how we can assist.

• Refresh token: Supporting long-lived access reduces patient burden of reauthorization. For that reason, the ONC has required this functionality for equivalent provider-hosted patient access APIs. Payers can drastically improve their member satisfaction and API usage by implementing this feature.

  • Furthermore, 53 payers today list support for refreshing in their well-known SMART configurations (through the offline_access scope or the permission_offline capability) but do not issue a refresh token in practice.

• Support for all lines of business: Only 6 payers have voluntarily made their patient access API available to all their members.

• Implementation of all CARIN resources: Patient, Coverage, and ExplanationOfBenefit are byproducts of claims processing and should be included by all payers

• Implementation of most common USCDI resources: MedicationRequest, Condition, Procedure, and CareTeam are derived from claims processing and should be present for all payers.

We’re excited to release this first version of the state of payer patient access APIs and improve it as an artifact for the industry going forward, so please reach out with feedback, questions, or ideas.