CMS-0057-F and the prior authorization API: what it requires, and where automation fits

The short answer

The CMS Interoperability and Prior Authorization final rule, CMS-0057-F, released on 17 January 2024, does three things builders need to know. From 1 January 2026, impacted payers must decide prior authorization requests within 72 hours for urgent requests and seven calendar days for standard ones, and must give a specific reason for every denial. From 1 January 2027, they must run a FHIR-based Prior Authorization API that tells providers what’s required, takes requests and returns decisions. And they must publish prior authorization metrics every year.¹

The rule’s policies don’t apply to prior authorization for drugs.¹ This post summarises CMS’s own fact sheet; it isn’t legal advice, and the rule text governs.

Who it applies to

The fact sheet lists the impacted payers: Medicare Advantage organisations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the federally facilitated exchanges.¹ The decision-time requirements exclude those QHP issuers.¹

If you’re a provider, a vendor serving payers, or building automation on either side, the APIs and deadlines shape what systems will be expected to exchange.

The timeline

The prior authorization API

From 1 January 2027, payers must build and maintain an API populated with their list of covered items and services that can:¹

1. Identify whether, and with what documentation, prior authorization is needed.
2. Support a prior authorization request and response.
3. Return an approval, a denial with a specific reason, or a request for more information.

The APIs are built on HL7 FHIR, with FHIR Release 4.0.1 among the required standards, and CMS strongly encourages three HL7 Da Vinci implementation guides: Coverage Requirements Discovery (CRD) STU 2.0.1, Documentation Templates and Rules (DTR) STU 2.0.0, and Prior Authorization Support (PAS) STU 2.0.1.¹

In practice, those three map onto the three steps above: discover whether authorisation is needed, gather the documentation, and submit and track the request.

Because it’s FHIR, the usual FHIR integrity questions apply. Requests that bundle several resources should use transactions where they must succeed or fail together, and clients should read each entry’s status in the response; our transaction vs batch post covers the rules.² Access should use narrow scopes; SMART v2 scopes can name exactly which interactions a client may use.³ Our scopes post has a worked example.

Specific denial reasons

From 2026, every denial needs a specific reason, regardless of how the request arrived.¹ For anyone automating any part of prior authorization, this is the requirement that most shapes system design.

A specific reason has to come from somewhere: a policy criterion that wasn’t met, a missing document, a code that isn’t covered. If any part of the decision path is automated, the system must be able to say which criterion produced the result, in words a provider can act on. “The model scored this request low” isn’t a reason. “The required documentation was not included”, naming the document, is.

That has a design consequence. Store the decision as structured data, criterion by criterion, with the evidence that met or missed each one, and generate the reason text from that structure. Then the same record answers the provider’s question, feeds the annual metrics, and lets an auditor trace any denial back to the rule that produced it. If the reason only ever existed as free text written after the fact, none of that is possible, and errors in the text can’t be caught by comparing it with the decision.

Where AI and agents fit

AI is being applied on both sides of prior authorization: helping providers assemble requests and documentation, and helping payers triage requests. The rule’s requirements suggest where the guardrails belong, whoever builds the automation:

Research on automated coding and on automation bias is relevant here. General-purpose models assign billing codes inconsistently, as our coding accuracy post shows, and people over-trust automated recommendations when checking is hard, as covered in automation bias and approvals. A denial reason drafted by a model and approved in two seconds is the combination to design against.

A checklist for builders

1. Map your use of the three Da Vinci guides (CRD, DTR, PAS) to the three API functions.¹
2. Record every request and response, with ids, versions and timestamps, so decision times can be measured from records.
3. Keep the criterion behind every denial in structured form, not only in free text.
4. Put a person on every denial, and record who and when.
5. Use narrow API scopes for any automated client.³
6. Read back what you wrote to the payer’s or your own FHIR server, and check each Bundle entry.²
7. Exclude drugs from flows built for this rule’s requirements; they’re outside its policies.¹

Nothing here is clinical; it’s about systems, timing and records. For the FHIR building blocks, see the FHIR glossary entry. To see approvals and checks on a real database in your browser, try the playground; to grade what an agent can reach on your machine, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.