Four health systems just switched on real-time prior-auth checks inside Epic, four months before CMS forces every impacted payer to expose the same API. Here is the baseline that rule is being written against — every marketplace issuer in the country, plotted by how much it denies and how rarely anyone pushes back.
Ochsner, Froedtert ThedaCare Health, Denver Health and Summit Health went live this week with Epic’s FHIR-based Coverage Requirements Discovery API alongside UnitedHealthcare, Network Health and Aetna, with sixteen more payers in active testing. CMS-0057-F is the reason: since January 1 of this year, impacted payers have had to decide expedited requests in 72 hours and standard ones in 7 days, and give a specific reason for every denial. The Prior Authorization API itself stands up January 1, 2027.
Two of those three obligations are about latency. The third is about legibility — and legibility is where the existing system is weakest, because the appeal is supposed to be the check on a bad denial and almost nobody files one.
Each band is drawn proportional to the one above it. The last two are not visible at this scale, which is the point.
Each circle is one issuer. Horizontal position is share of claims denied. Vertical position is internal appeals filed per 10,000 denials, on a log scale because the range spans four orders of magnitude. Circle area is claims volume. Colour is what happened to the appeals that were filed.
One issuer is 59% of all appeals in the country. Oscar Insurance Company of Florida reports 221,043 internal appeals against 3.4 million denials — 651 per 10,000, roughly fifteen times the national rate, and 60% of every overturned appeal in the file. Drop it and the national appeal rate falls from 44 per 10,000 to 19 per 10,000. Either Oscar Florida’s members appeal fifteen times more readily than everyone else’s, or Oscar Florida counts something as an appeal that its competitors do not. The PUF cannot tell you which, and no downstream analysis of this file that does not name the issue is trustworthy.
The denial reasons do not partition. CMS collects ten denial-reason categories at plan level. Summed across every individual QHP they come to 75.7 million against a plan-level denial total of 52.4 million — 145%. Claims are being counted in more than one bucket, or the buckets are being filled inconsistently, or both. And the single largest bucket is the one labelled Other.
The API is the part everyone is building for and the smaller half of the rule. A coverage-requirements lookup answers does this need prior auth before the order is signed — genuinely useful, and the Da Vinci CRD, DTR and PAS implementation guides are public HL7 specs with public reference servers, so you can stand one up this weekend on synthetic data with no payer contract and no BAA. But the requirement that actually changes the numbers on this page is the specific-denial-reason mandate, because a denial you can read is a denial you can appeal, and 0.44% is what happens when you cannot read them. If you are building here, the differentiated product is not the lookup. It is the structured, machine-readable denial reason and the appeal it makes possible.
This is the individual ACA marketplace only — not Medicare Advantage, not Medicaid managed care, not commercial group. It is claims denial data, which is post-service adjudication, not prior authorization denial data; the two are related but not the same decision, and CMS-0057-F governs the latter. Claims and appeals figures are issuer-level self-reports and the appeal counts cover the issuer’s reported book, so appeals-per-denial is a ratio of two issuer-reported quantities and not a matched cohort. The plan year is 2023, the most recent year in the 2025 Transparency PUF; the reporting lag is a real limitation and means none of this reflects the January 2026 timeline requirements. Nine issuers with fewer than 20,000 claims are excluded from the scatter — between them they account for 78,896 claims, under 0.02% of the total. Because the reason categories overlap, every percentage in the bar chart is a share of the denial total, not a share of a partition. Anything that looks like a trend here should be checked against the sample-size slider before you repeat it.