Prior authorization APIs are coming. Build for the years in between

Every prior authorization pitch deck now has a slide about FHIR. The slide is not wrong. Federal rulemaking is pushing payers toward machine-readable prior auth, and within a few years a real share of your requests will move over an API instead of a web portal. The useful question for anyone automating today is narrower: what do you build now that is still worth owning when that happens, and what are you going to do about the fax machine in the meantime?

The direction of travel is clear. The timeline is not yours

CMS finalized an interoperability and prior authorization rule in 2024 (CMS-0057-F). The parts that matter operationally are these: impacted payers must stand up a FHIR-based prior authorization API, must return decisions inside defined windows rather than whenever they get to it, must give a specific reason when they deny, and must publish prior auth metrics. The API requirement lands later than the timeline and transparency requirements, which is deliberate. Check the current rule text before you plan around any specific date, because compliance dates in this space have moved before and enforcement discretion is a real thing.

Two exclusions matter more than most people notice. The rule applies to particular payer types: Medicare Advantage organizations, Medicaid and CHIP programs and their managed care plans, and qualified health plan issuers on the federally facilitated exchanges. Self-funded commercial plans under ERISA are not in that list. And the prior authorization API requirement is scoped to items and services, not drugs covered under the plan. So the two categories that generate the most friction in a lot of practices, commercial coverage and specialty drugs, are the least affected.

Before you form an opinion, do the arithmetic. Pull twelve months of authorization volume, bucket it by payer line of business, and calculate what percentage of your requests are even in scope. For a hospital-based specialty group the in-scope share is often a minority of volume. That number, not the industry narrative, is what should size your API work.

The technical direction is also settled enough to plan against. The HL7 Da Vinci implementation guides split the problem into three: Coverage Requirements Discovery answers "does this need authorization at all," Documentation Templates and Rules gathers the payer-specific documentation, and Prior Authorization Support submits the request and carries the response. Learn that three-way split. It maps cleanly onto how you should organize your own system regardless of transport.

Why the portal and the fax outlive the mandate

A mandate creates a channel. It does not create adoption, parity, or good behavior. Four reasons the document-and-portal reality persists well past any compliance date:

• Delegated entities. A large share of authorizations for imaging, cardiology, musculoskeletal, and oncology never touch the payer directly. They route to a benefit management vendor operating under the payer's contract, with its own portal, its own clinical criteria, and its own timeline for building anything.
• Uneven conformance. Early API implementations tend to cover the easy codes first. The requests you most want automated are the ones with dense clinical criteria, and those are the last to get good API support.
• Your EHR's queue. Even where the payer endpoint exists, consuming it means an integration project inside your vendor's roadmap, not yours.
• The commercial book. If half your volume sits with plans outside the rule's scope, half your volume stays exactly as manual as it is today.

Plan to run multiple channels concurrently for years. Not as a transition state you tolerate, as the actual architecture.

Build the request object, not the channel

The single design decision that determines whether your 2026 automation survives to 2029 is this: model the authorization request once, internally, and treat every channel as an adapter at the edge.

The canonical object holds patient and coverage identifiers, the requested service with procedure and diagnosis codes, place of service, units and date range, ordering and rendering providers, facility, and an evidence bundle: the specific clinical facts that justify the request, each with a pointer back to where it came from in the chart. Everything downstream is rendering. A portal adapter fills form fields with it. A fax adapter renders a PDF cover sheet from it. An EDI adapter maps it to an X12 278. A FHIR adapter maps it to a PAS bundle.

That last mapping is the part people miss. Da Vinci PAS is not a replacement data model. At the payer edge it maps to the same X12 278 transaction the industry has had for decades. The reason 278 never took over was never the envelope, it was that a bare 278 could not carry clinical documentation, so payers kept asking for records anyway. FHIR fixes the attachment problem, not the underlying semantics. Which means the field-level work you do now to structure a request correctly is not throwaway. Only the transport changes.

Concretely: if your automation today is a script that knows how to drive one payer's portal, you have built nothing durable. If it is a request builder plus a thin portal driver, you have built most of the API future already.

The durable work is documentation, not transport

An API tells you a decision faster. It does not decide which clinical facts justify this service under this payer's policy, and it does not find those facts in a 400-page chart. That gap is the entire job, and no rulemaking closes it.

So the asset worth building is a policy corpus. One row per payer, plan, procedure code, and effective date. Each row records whether authorization is required, the clinical criteria that must be met, the specific evidence that satisfies each criterion, and a citation to the policy document and version it came from. Maintain it like code, with dated versions, because payers revise policy quarterly and a denial six months from now will hinge on which version was in force.

Then build extraction against it. For a given request, the agent's job is to locate each required fact in the chart and cite it: this note, this date, this line. Provenance is not a nice-to-have. It is what makes the output reviewable in seconds instead of minutes, and it is the same substrate your denials and appeals work runs on when a request comes back adverse. When denial reasons become more structured, as the rule pushes them to, an appeal agent that already knows which criterion you asserted and where you sourced it can act on that reason code immediately. This is the shape of the work we describe in more detail on our prior authorization automation page.

What to build in the next ninety days

In order, and none of these depend on any payer shipping anything:

• Instrument the manual process. Touch time per request, first-pass approval rate segmented by payer and procedure code, rework rate, peer-to-peer rate, days to decision. Most teams cannot produce these today. You cannot evaluate an agent without them, and the per-payer approval data is also what qualifies you for gold-carding programs when payers offer them.
• Assemble a golden set. Two to three hundred closed cases with known outcomes, weighted toward your highest-volume and highest-denial codes. Include the ugly ones. A clean sample produces a clean demo and a bad agent.
• Write the evaluation harness before the agent. Score extraction accuracy per criterion, not per case. Per-case pass rates hide which criterion the model keeps missing.
• Run in shadow mode. The agent processes real requests beside your team, producing output nobody acts on, until its accuracy on the golden set and on live volume are both defensible. IDC put the share of AI proofs-of-concept that never reach production at 88% in 2025. Shadow mode is the cheapest insurance against joining that number, and it is the spine of our delivery methodology.

Size the prize with arithmetic you can check yourself. Requests per month, times average minutes of staff time per request, divided by 60, gives monthly hours. Compare that to your actual staffing. If the answer is under one full-time equivalent, an agent is probably not your best next investment.

When the API makes your agent unnecessary

Three honest cases where you should not build this.

If your payer mix is concentrated in three plans, your code set is small, and those payers already expose a working endpoint, write the integration. Deterministic code beats a model on a solved problem, and the maintenance burden is a tenth as large.

If your denials are driven by coverage exclusions rather than documentation gaps, automation gets you denied faster. Sample fifty denials and classify them first. Missing evidence is an automation problem. Not a covered benefit is a contracting or ordering problem, and the fix belongs upstream at the point of order.

And if nobody owns the policy corpus after go-live, do not start. An authorization agent decays the moment payer criteria change, and criteria change constantly. That ongoing ownership is the actual product. Everything else is a demo. If you want a straight read on which of these describes you, that is what the healthcare engagements we run start with.