Under CMS-0057-F, impacted payers must have a FHIR Prior Authorization API live by January 1, 2027, built on the Da Vinci CRD, DTR and PAS guides. Decision deadlines (72 hours expedited, 7 days standard) already apply since January 2026. Payers or EHR vendors without a tested PAS endpoint have about seven weeks left.
Prior authorization has moved from a policy debate to an engineering deadline. Three rules now stack on top of each other: the 2024 CMS interoperability and prior authorization final rule, ONC's HTI-4 certification criteria for EHRs, and the FY 2027 IPPS rule that updated the implementation guide versions. A proposed 2026 rule would add drugs. This guide lays out the dates, the standards, the X12 278 question, and what a payer or EHR vendor actually has to build.
What does CMS-0057-F require, and by when?
It requires Medicare Advantage organizations, Medicaid and CHIP fee-for-service programs and managed care plans, and Qualified Health Plan issuers on the federal exchanges to answer prior authorization requests faster, explain denials, publish metrics, and stand up four FHIR APIs. Operational provisions started January 1, 2026; the APIs are generally due January 1, 2027.
From the CMS fact sheet and CMS's ePA rulemaking summary:
| Date | Requirement | Who |
|---|---|---|
| Jan 1, 2026 | Decisions within 72 hours (expedited) and 7 calendar days (standard); specific reason on every denial | MA, Medicaid, CHIP (timeframes do not apply to QHP issuers) |
| Mar 31, 2026 | First annual public prior authorization metrics | All impacted payers |
| Jan 1, 2027 | Prior Authorization API, Provider Access API, Payer-to-Payer API, Patient Access API with PA data | All impacted payers (exact dates vary by payer type) |
| CY 2027 | Electronic Prior Authorization measure optional for MIPS clinicians (10 bonus points) and hospitals | Providers using certified health IT |
| CY 2028 | Electronic Prior Authorization measure required for MIPS clinicians and for hospitals to be meaningful EHR users | Providers |
Drugs are excluded from CMS-0057-F. Most commercial and employer plans are not covered either, although 58 health insurers signed a voluntary pledge in June 2025 to standardize electronic prior authorization on FHIR APIs, according to the same CMS summary.
Which implementation guides should a Prior Authorization API use?
The required base is FHIR R4.0.1, US Core and SMART App Launch. On top of that, CMS recommends the three Da Vinci guides: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) and Prior Authorization Support (PAS). The current federally adopted versions are CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1.
The version story is messy, so here it is in order:
- CMS-0057-F (2024) recommended, but did not require, CRD, DTR and PAS. CMS's API standards page lists versions 2.0.1 and 2.1.0, and notes that the older US Core 3.1.1 and SMART 1.0.0 expired on January 1, 2026.
- HTI-4 (July 2025) created three ONC certification criteria for EHRs: 45 CFR 170.315(g)(31) for CRD, (g)(32) for DTR and (g)(33) for PAS.
- FY 2027 IPPS final rule (July 31, 2026) replaced the adopted versions with CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1, effective October 1, 2026, as ONC confirmed.
- CMS-0062-P (proposed April 2026) would make the recommended guides required for payers from October 1, 2027.
Practical advice: build to 2.2.x now. It is what certified EHRs must support for the 2027 measure, and it is where the payer requirement is heading.
How do CRD, DTR and PAS fit together?
CRD tells the provider, at order time, whether authorization is needed. DTR collects the documentation the payer needs, pre-filled from the chart. PAS submits the request and returns the decision. Together they replace the "call, fax, portal" loop with three API exchanges.
1. Coverage Requirements Discovery (CRD)
The EHR fires a CDS Hooks call (order-select, order-sign, appointment-book and similar) to the payer's CRD service. The payer answers with cards: "no auth needed," "auth required," or "documentation required, launch DTR." The engineering challenge is latency. The hook runs while a clinician is signing an order, so a slow payer service blocks the workflow. Budget for caching coverage rules and for clean timeouts that fall back to "unknown, check later."
2. Documentation Templates and Rules (DTR)
DTR delivers a FHIR Questionnaire with CQL logic. The provider's DTR app runs the CQL against the patient record to pre-fill answers, and a human completes the rest. The hard parts are CQL execution against real, messy US Core data, and deciding which answers a clinician must confirm rather than accept from auto-fill.
3. Prior Authorization Support (PAS)
PAS sends a FHIR Claim bundle with the QuestionnaireResponse and supporting resources, and receives a ClaimResponse. If the payer cannot decide immediately, the response is "pended," and the provider gets updates later through subscription or polling. Pended handling is where most pilots break: state machines, idempotent resubmission, and reconciling updates that arrive out of order.
Do you still need the X12 278 transaction?
Not inside a compliant FHIR prior authorization flow. In February 2024 HHS announced enforcement discretion: no HIPAA enforcement action against covered entities that skip X12 278 within a FHIR Prior Authorization API that meets CMS-0057-F. CMS says the discretion has no end date, but it covers only that path.
The details are on CMS's HIPAA transaction enforcement discretion FAQ and the February 28, 2024 letter. Two consequences for architecture:
- The original PAS design routed FHIR through an intermediary that translated to X12 278. Under the discretion, a payer can accept FHIR end to end. Many will still keep a 278 path for trading partners who are not on FHIR, so plan for both.
- CMS-0062-P proposes that HHS adopt FHIR for prior authorization HIPAA transactions in place of X12N 278, with a 24-month compliance window (36 months for small health plans) once finalized. That is proposed, not final, as of November 2026.
What should a payer build before January 2027?
A production CRD service, DTR content (Questionnaires and CQL) for every service that requires authorization, a PAS endpoint with pended-decision handling, SMART-based authorization for provider systems, and metrics reporting. Most payers will buy a platform for some of this; the rule-content work cannot be bought.
- Rule content is the real backlog. Every service on your authorization list needs coverage logic for CRD and a Questionnaire with CQL for DTR. That is clinical policy translated into code, and it needs clinical review.
- Decision clocks. The 72-hour and 7-day timers start when the request arrives. Your PAS system needs to track them per request and alert before breach.
- Denial reasons. Every denial needs a specific reason the provider can act on, carried in the ClaimResponse.
- Metrics. CMS-0062-P proposes adding counts alongside percentages and new API usage metrics, with 2027 data reported in 2028. Log every request and decision with timestamps from day one.
- Endpoint directory. CMS-0062-P would also require payers to report their API endpoints to CMS within 60 days of that rule taking effect.
What should an EHR vendor build?
A CDS Hooks client for CRD, a DTR app or native DTR support that runs CQL against your data, a PAS client with pended-response handling, and payer endpoint discovery. If your customers report MIPS or hospital Promoting Interoperability, you need certification to (g)(31), (g)(32) and (g)(33) on the 2.2 versions.
The 2027 measure is optional and requires at least one certified module; from 2028 it is required and needs all three, per CMS's summary. That gives EHR vendors a clear sequence: PAS first (it carries the bonus in 2027), then CRD and DTR. The difficult engineering is in DTR: running payer CQL safely against your data model, mapping to US Core when your internal model differs, and keeping a clinician in the loop on every auto-filled answer. Our EHR integration services page describes how we approach FHIR mapping on existing systems.
Where can AI help with prior authorization, and where should it stop?
AI is useful for drafting DTR answers from unstructured notes, summarizing clinical evidence for the reviewer, and routing pended requests. It should not issue denials. CMS's WISeR model in Original Medicare, which uses AI to support reviews in six states from 2026, states that non-payment recommendations are determined by licensed clinicians.
On the provider side, the value is in DTR: much of what a payer asks is buried in free-text notes that CQL cannot read. A model can propose answers with citations to the source note, and a clinician confirms. On the payer side, models can triage and summarize, but the WISeR model page is explicit that clinicians make non-payment determinations. Design every AI step so a person approves the outcome and the audit log shows the evidence. We describe the pattern in human-in-the-loop AI for regulated industries, and how to test it in LLM testing for regulated industries. Any model that sees the chart needs to sit inside your BAA chain; see HIPAA-compliant AI agents.
What is coming next: drugs and CMS-0062?
CMS-0062-P, proposed April 10, 2026, would extend electronic prior authorization to drugs from October 1, 2027: medical-benefit drugs through the Prior Authorization API, and pharmacy-benefit drugs through NCPDP SCRIPT, Formulary and Benefit, and Real-Time Prescription Benefit for certain payers. It is not final yet.
Per the CMS-0062-P fact sheet, it would also set drug decision timeframes (24 hours for Medicaid and CHIP; 72 hours standard and 24 hours expedited for QHP issuers) and bring QHP issuers under the 7-day and 72-hour non-drug timeframes. If you are designing a PAS system now, keep the request model general enough for drug requests, because retrofitting is harder than planning.
How BeevR builds this
We build FHIR integration and AI layers for health IT teams: CDS Hooks services, SMART on FHIR apps, DTR pre-fill with clinician confirmation, and the audit and metrics plumbing that regulators ask for. We run a multi-tenant EHR live across four US clinics at about 300 patients a day, so we have worked with real US Core data, not just test servers. BeevR signs a BAA as a business associate, and AI components can run inside your own AWS account under the AWS BAA.
We work in fixed-price phases, from $10K per phase, with a working demo every Friday, and you own the code and IP from day one. See healthcare AI agent development for scope, or book a 30-minute call to review your 2027 plan.