What is a FHIR prior authorization API, and what do providers need to do before January 2027?

For most of the last three decades, prior authorization ran on fax machines and hold music. A coordinator pulled the clinical record, filled out a payer-specific form, faxed it into a queue, and waited. Sometimes the decision came back in two days. Sometimes it took two weeks. Sometimes the fax was never confirmed and the whole thing started over. That world is ending, and a federal rule is setting the date.

By January 1, 2027, the largest government-regulated payers in the country have to expose standardized digital connections that let your practice submit a prior authorization request, see exactly what documentation is required, and receive a decision electronically. The technology behind that shift is called a FHIR prior authorization API. If you run a specialty practice, an FQHC, or a PE-backed group, you do not need to build it. But you do need to understand it, because the practices that prepare will spend a fraction of the time on authorizations that unprepared practices still burn today.

This guide explains what the FHIR prior authorization API is in plain language, what the CMS-0057-F rule requires and when, and what you should be doing right now to get ready.

The short version

• A FHIR prior authorization API is the electronic connection that lets your practice check requirements, submit, and receive a decision without fax or per-payer portal logins.
• Under CMS-0057-F, impacted payers must run these APIs by January 1, 2027, and have owed 7-day standard and 72-hour urgent decisions since January 1, 2026.
• Self-funded employer plans under ERISA are exempt, so plan for a mixed environment and a workflow that handles both modernized and legacy payers.

What is a FHIR prior authorization API?

FHIR stands for Fast Healthcare Interoperability Resources. It is a shared technical standard for how healthcare systems exchange data, maintained by the standards body HL7. Think of it as a common language that an EHR and a payer's system can both speak, so they can pass structured information back and forth without a human re-keying it.

A FHIR prior authorization API is the specific connection a payer builds so that a provider's system can do four things electronically: check whether a service needs authorization, see the exact documentation the payer wants, submit the request with that documentation attached, and receive the decision back in a structured, trackable form. No fax. No portal login for every payer. No guessing about what the reviewer needs.

The point is not the acronym. The point is that the back-and-forth that currently eats hours of coordinator time becomes a structured electronic exchange that automation can run on top of.

What does CMS-0057-F require by January 1, 2027?

CMS-0057-F is the formal name for the CMS Interoperability and Prior Authorization Final Rule, finalized in January 2024. It applies to a defined set of government-regulated payers: Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid and CHIP managed care plans, and qualified health plan issuers on the federally facilitated exchanges. It does not apply to most employer-sponsored commercial plans, which sit under ERISA. That carve-out matters, and we come back to it below.

The rule lands in two waves.

Effective January 1, 2026, impacted payers must already be doing several things. They must return decisions within 7 calendar days for standard requests and 72 hours for expedited requests. They must give a specific reason for every denial. And they must begin collecting prior authorization metrics, with the first public report of those metrics, covering calendar year 2025, due by March 31, 2026. These operational requirements are in effect now.

Effective January 1, 2027, the same payers must have the FHIR-based APIs live in production. CMS-0057-F requires four: the Prior Authorization API, the Patient Access API, the Provider Access API, and the Payer-to-Payer API. The Prior Authorization API is the one that changes your day. CMS estimates the rule will save roughly 15 billion dollars over ten years as authorization moves off paper.

What changes for providers day to day?

Today, a prior authorization is a manual chase. Under the rule, three things change at the point of care.

First, you can see authorization requirements before you submit. The API can tell your system whether a given service needs authorization for that patient's plan, which removes the most common source of wasted effort: submitting a request for something that did not need one, or skipping one that did.

Second, you can submit from inside your existing workflow with the documentation the payer specifies, rather than discovering what was missing after a denial.

Third, you can track status electronically and receive a structured decision, with a specific reason if it is denied. That single change, specific machine-readable denial reasons, is what makes automated appeals and faster resubmission possible.

The honest caveat: the rule does not require payers to make real-time approval decisions. Many requests will still route to a clinical reviewer. What the rule removes is the administrative friction around the review, not the review itself.

What must payers build, and what must you prepare for?

It helps to separate the two jobs. Payers carry the heavy technical lift. Providers carry a readiness and workflow job.

Source for timeframes, reporting dates, and API deadline: CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) and the CMS Prior Authorization API FAQ.

Your job is not to build any of this. Your job is to make sure your systems and your team can use it when payers turn it on, and to stop spending money preparing for a process that is about to change underneath you.

How do you assess whether your EHR is ready?

Your EHR vendor sits between you and these APIs. Ask your vendor four direct questions.

Will the system support electronic prior authorization submission through the payer FHIR APIs, and on what timeline relative to January 2027? Will it surface authorization requirements at the point of order, before a request is submitted? Will it ingest structured decisions and specific denial reasons into the chart and worklist, rather than dropping them into a fax inbox? And what does it cost, because some vendors will treat this as a premium module rather than a standard capability.

If your vendor cannot answer clearly, that is useful information. It tells you where a connected automation layer that already operates on these standards can carry the workflow your EHR will not.

A readiness checklist by organization type

Specialty practices should map their highest-volume authorized procedures to the payers that cover their patients, identify which of those payers are in scope for CMS-0057-F, and flag the commercial and ERISA volume that will not be covered so expectations stay realistic.

FQHCs and community health centers, with heavy Medicaid and managed care mix, are squarely in the rule's scope. The readiness move is to confirm which of your managed care organizations are building to the 2027 deadline and to centralize authorization tracking now, rather than running it out of spreadsheets per site.

PE-backed and multi-location groups should standardize the readiness assessment across the portfolio. The trap is letting each site assess its own EHR and payers in isolation. The leverage is one playbook, one vendor question set, one tracking layer across every location.

“We treated the 2027 deadline as a reason to stop patching our old authorization process and rebuild it. The practices that wait until payers flip the switch will spend 2027 reacting. We would rather spend it ahead.”

Where this fits, and where it does not

A FHIR-based approach to prior authorization is the right foundation when most of your authorized volume sits with government-regulated payers, when you are tired of fax-driven chases, and when you want a workflow that holds up across multiple sites. Specialty groups with high imaging and procedure volume, FQHCs with Medicaid-heavy panels, and PE-backed portfolios standardizing operations all benefit early.

It is a weaker lever, on its own, if the bulk of your authorizations run through self-funded employer plans that sit outside the rule. Those plans are not required to build these APIs, so a meaningful share of your volume may still run the old way for a while. The realistic plan is a hybrid: lean on the APIs where they exist and keep an automation layer that can handle the payers that have not modernized. That mixed reality is exactly why a connected layer that works across both matters more than any single payer's timeline.

How Linear Health operates within this framework

Linear Health automates prior authorization across the full workflow: checking whether a service needs authorization, assembling the documentation a payer requires, submitting the request, tracking status, and routing specific denial reasons into a worklist for fast resubmission or appeal. Where payer FHIR APIs are live, the platform uses them. Where they are not, it carries the same workflow across portals and fax so your team is not stuck waiting for every payer to catch up. The result our customers see is up to 80 percent less manual time spent per authorization.

This is the practical reading of CMS-0057-F. The rule gives the industry a common rail. The advantage goes to the practices that are ready to run on it the day it opens. For the broader regulatory picture, see our guide to the CMS prior authorization rule for 2026.

Frequently asked questions

Does my EHR need to support FHIR prior authorization by 2027?

The rule places the API obligation on payers, not on your EHR. But to use those APIs without re-keying data by hand, your EHR or a connected automation layer needs to send and receive through them. Ask your vendor directly about their timeline, and plan for a connected layer if the answer is vague.

What happens if my payer is not FHIR-ready by January 2027?

The deadline applies to impacted government-regulated payers. Self-funded employer plans under ERISA are not covered and may not build these APIs at all. Expect a mixed environment for a while, and keep a workflow that can handle both modernized and legacy payers.

Can I still submit prior authorization by fax after January 2027?

In most cases yes, fax does not become illegal. But payers in scope must offer the electronic path, and the practices that adopt it will move faster than those that stay on fax. The question is competitive efficiency, not permission.

Which payers does CMS-0057-F apply to?

Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid and CHIP managed care plans, and qualified health plan issuers on the federally facilitated exchanges. It does not apply to most employer-sponsored commercial plans.

What is the difference between the four APIs in the rule?

The Prior Authorization API handles the authorization workflow. The Patient Access API gives patients access to their own data. The Provider Access API lets providers retrieve member data for treatment. The Payer-to-Payer API moves a member's history between plans when they switch. For day-to-day authorization work, the Prior Authorization API is the one that matters most.