The Prior Authorization API Is Still “Coming Soon.” The Compliance Deadline Isn’t.

Short answer: CMS-0057-F requires health plans to launch a Prior Authorization API by January 1, 2027. As of WEDI's most recent survey, a large share of payers are still early in that build, even as many announce broader prior-auth reform. For hospitals — especially rural and critical access hospitals in the Pacific Northwest running on thin margins — the deadline is on the payer, but the readiness to actually use the API the moment it goes live is not.

What does CMS-0057-F actually require, and by when?

CMS-0057-F requires impacted payers to implement four HL7 FHIR (Fast Healthcare Interoperability Resources) APIs — Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization — with compliance dates primarily beginning January 1, 2027. Operational provisions took effect earlier: 72-hour decision timeframes for urgent requests, seven days for standard requests, and annual public reporting of prior authorization metrics, effective January 1, 2026, with the first metrics publication due by March 31, 2026.

That distinction matters more than it sounds like it should. A payer can be fully compliant with the operational half of this rule right now — faster decisions, public metrics — without the API infrastructure existing yet. Those are two different requirements on two different timelines, and only one of them needs a working API behind it.

Why don't payer announcements about "less prior auth" mean the API is live?

2026 has brought a steady stream of health plan announcements: fewer procedures requiring review, gold-card-style programs that waive prior auth for provider groups with a clean track record, public commitments to cut administrative burden. Worth taking seriously — and a separate project from the one CMS-0057-F actually requires.

Somewhere in the legal fine print of one of the country's largest health plans sits a page listing what its interoperability APIs do. Patient Access API: built, documented, live. Payer-to-Payer API: built, documented, live. Provider Access API and Prior Authorization API — the two that matter most to a hospital trying to get a decision back electronically instead of through a portal — are both marked, in exactly two words: Coming soon. That's not a leak. It's their own page, viewed this month.

A payer can announce it's approving prior auth faster and cutting overall request volume, and still not have the electronic pipe built that's supposed to carry a decision back automatically. Both things can be true on the same page.

How ready are payers right now?

WEDI's most recent industry readiness survey, released at HIMSS26 in March 2026, shows real movement: the share of payers reporting they had not yet started work on the CMS-0057-F APIs fell from roughly 43% in late 2025 to 10% by February 2026. That's genuine progress.

The harder number sits underneath it. 35% of payers estimated they were 25% or less complete on the Patient Access API — generally considered the simplest of the four to build. Industry analyses consistently describe the Prior Authorization API as the most complex: it has to determine whether a service requires review, collect payer-specific documentation, accept a submission, and return a decision end-to-end, without a fax machine or a portal login anywhere in the chain.

Industry commentary on the same WEDI data — from Managed Healthcare Executive and other analysts — has started framing a risk window rather than just the deadline: payers that haven't engaged a vendor or committed internal engineering resources by Q3 2026 are increasingly described as being at material risk of missing the January 1, 2027 compliance date. That threshold is an industry benchmark, not a CMS requirement — and Q3 2026 isn't a future quarter to plan around. It's the one we're in.

Is every payer behind?

No — and that gap is the actual point. CMS has named a group of early adopters, including several major health plans that publicly committed to advance electronic prior authorization ahead of the minimum federal requirement, with roughly thirty organizations overall participating in CMS's e-prior-authorization initiative ahead of the 2027 deadline. That range — some plans already testing against live endpoints, others still marking core APIs "coming soon" with under half a year left — tells you this isn't a technical wall everyone is equally stuck behind. It's a resourcing and governance choice, made differently by different organizations, and it shows up on their own status pages either way.

What happens on the hospital side if the payer's API isn't live yet?

We wrote about this from the hospital side in our piece on CMS-0057-F's architecture problem: an API that exists on the payer side is useless to a hospital that can't consume it. The reverse is just as true, and gets talked about less. A hospital IT team that spends 2026 building a FHIR client to query a Prior Authorization API that has no live endpoint yet is building against a specification, not a system. That's harder to test, harder to validate field-by-field, and harder to catch mismatches in before January — when the payer's API finally does go live and there's no runway left to discover your side doesn't actually talk to it correctly.

For a rural or critical access hospital in the Pacific Northwest running a margin thin enough to lose sleep over, that's not an abstract integration risk. It's the same person doing this work in December who's also covering three other fires, on a team too small to have someone whose only job is watching a payer's release notes for the word "live."

Which is exactly the governance gap we described in our piece on AI governance in healthcare IT: adoption outrunning the structure that's supposed to hold it accountable. A "coming soon" label with no public date attached isn't a technical status. It's a governance signal — evidence that whatever internal deadline was supposed to force this build into existence either wasn't strict enough or wasn't enforced. The same question applies on the hospital side of the handshake: does your own integration work have a real internal deadline, or just a general intention to be ready "before January"?

What should a hospital do before January 2027?

You can't make a payer's API exist faster. What you can control is whether your own side is ready the moment it does: an EHR-side FHIR client built and tested against a sandbox now, not in December; SMART on FHIR authentication already sitting inside your identity system instead of bolted on per payer; a documented plan for the payers who miss January entirely, because some will, and your workflow can't fall over the first time one does.

That's the work that doesn't wait on anyone else's roadmap. It's also the work nobody notices you did right — until the payer's API finally ships and yours is the hospital that was actually ready to receive it.

Where does your team stand on that build today — waiting to see what payers ship, or already testing against what's been published so far?

Frequently Asked Questions