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.
Want to see the regulatory background, payer scorecard and vendor summary?
great comments. thank you.
Sorry if this is a obtuse question: it seems patients need to log in to their health plan portal to get their claims data (and per this report, get mixed results). My question is, can a patient instead get IAL2 verified and submit a request for their claims data without having to go through their plan portal? For clinical data this can be achieved without having to sign into the patient portal of the health system (Patient Request in Carequality, Individual Access in TEFCA). Is there an equivalent method for claims?