InsightsHealthcare
How to build a prior authorization agent that meets the CMS rules for 2026 and 2027
What CMS-0057-F requires in 2026 and 2027, who must review a denial, and how to build a prior authorization agent on Google Cloud with nurse approval.
- Written by
- CloudMagic engineering team
- Published
- Reading time
- 11 minutes
The short answer
Since January 1, 2026, Medicare Advantage, Medicaid and CHIP plans must decide urgent prior authorization requests within 72 hours and standard ones within seven days, every impacted payer must give a specific reason for a denial, and from January 1, 2027 payers must run a FHIR Prior Authorization API, with no delay announced. A provider-side agent gathers what the payer's policy asks for, flags what is missing and hands a complete packet to a nurse, who approves it before anything is sent. It never decides medical necessity: that stays with the payer, and in Medicare Advantage a physician or other appropriate health care professional must review a medical necessity denial before it is issued.
As of November 11, 2026. This is engineering guidance, not legal advice; check current rules with your counsel and compliance team.
CMS's prior authorization rule, CMS-0057-F, put deadlines and stated reasons on payer decisions in January 2026. In January 2027 it moves the request itself onto FHIR APIs. An incomplete packet now runs against a shorter clock on both sides.
Our examples come from a recorded demo for Wrenfield Health and Ashmere Health Plan, a made-up health system and insurer, on synthetic patients.
What does CMS-0057-F require, and from which date?
It requires impacted payers to decide prior authorization requests faster, explain every denial and publish their numbers from 2026, and to run FHIR APIs for prior authorization and data exchange from January 1, 2027. CMS published the rule on February 8, 2024 (89 FR 8758), and it took effect on April 8, 2024.
The impacted payers are Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and qualified health plan (QHP) issuers on the federally facilitated exchanges. Original Medicare and employer plans are not on that list, and drugs are excluded.
| Date | What applies | Who | Status |
|---|---|---|---|
| April 8, 2024 | CMS-0057-F takes effect | Impacted payers | Final |
| October 1, 2025 | ONC's HTI-4 adds EHR certification criteria for CRD, DTR and PAS | Health IT developers | Final |
| January 1, 2026 | Decisions within 72 hours (expedited) and seven calendar days (standard) | Medicare Advantage, Medicaid and CHIP; not QHP issuers | In force |
| January 1, 2026 | A specific reason with every denial, on any channel | All impacted payers | In force |
| March 31, 2026 | First public prior authorization metrics (2025 data), then every March 31 | All impacted payers | In force |
| January 1, 2027 | Prior Authorization, Provider Access and Payer-to-Payer APIs; prior authorization data in Patient Access | All impacted payers; Medicaid managed care by rating period, QHPs by plan year | Final; no delay announced |
| CY 2027 | Electronic Prior Authorization measure optional, with bonus points | Hospitals (FY 2027 IPPS rule) and MIPS clinicians (CY 2027 fee schedule rule) | Final |
| October 1, 2027 (proposed) | Drugs added, v2.2 Da Vinci guides required, QHPs held to seven days and 72 hours | Impacted payers | Proposed in CMS-0062-P |
| CY 2028 | Electronic Prior Authorization measure required | Hospitals and MIPS clinicians | Final |
The Prior Authorization API is what your agent will eventually talk to. Under 42 CFR 422.122 it must list the items and services that need authorization, identify the documentation the payer requires, accept the request, and answer approved, denied with a specific reason, or more information requested.
What changed in 2026, and is the January 2027 deadline still firm?
The decision clock and the denial-reason rule took effect on January 1, payers published their first metrics by March 31, and CMS proposed a follow-up rule in April. The January 1, 2027 date has not moved: CMS's electronic prior authorization page still says providers can request prior authorizations electronically beginning that day, and mentions no delay.
CMS counts the clock in calendar time, whether a request arrives by API, portal, fax or phone. KFF's analysis of 14 insurers' 2025 figures (August 13, 2026) found enrollment-weighted denial rates for standard requests of 12% in Medicare Advantage, 14% in Medicaid managed care and 18% on the ACA marketplace. In Medicare Advantage, 67% of appealed denials were overturned.
CMS-0062-P was published on April 14, 2026, and comments closed on June 15, 2026. It is not final, and every date in it is proposed. It would add drugs, require the Da Vinci guides CMS now only recommends (CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1), and hold QHP issuers to seven days and 72 hours, all from October 1, 2027 (proposed). HHS also proposes replacing the X12 278 with the Prior Authorization API as the HIPAA standard for prior authorization.
What does a prior authorization agent do for a health system, and what does it do for a health plan?
For a health system, it reads the payer's policy and the chart, flags what is missing and prepares a packet for a nurse to approve. For a health plan, the same pattern assembles the evidence on an incoming request for the clinical reviewer, who makes the call.
Physicians in the AMA's survey of 1,000, published May 18, 2026, reported about 40 prior authorizations and 13 hours of physician and staff time a week.
In our demo, Wrenfield Health has 14 total knee replacements booked for Monday, each needing approval from Ashmere Health Plan. Both organizations are invented and every patient is synthetic. The utilization management nurse asks which cases are ready, and the agent sorts all 14 and shows what each one is missing. One patient's outside therapy fax has the year typed wrong. The agent reconciles the year from the referral and the fax header, and keeps the typed value beside it for the nurse to check.
A packet reaches the payer through whatever route it accepts: its portal, fax, an X12 278 request through a clearinghouse, or its FHIR Prior Authorization API as those come online. We keep submission as a separate step, because payers move to their APIs on different dates.
Who must review a prior authorization denial, and can AI deny one?
The payer decides medical necessity, and in Medicare Advantage a qualified professional must review a medical necessity denial before it is issued, so an AI system cannot issue one on its own. For Medicare Advantage, 42 CFR 422.566(d) says that when a plan expects to issue a partly or fully adverse medical necessity decision, a physician or other appropriate health care professional with expertise appropriate to the services, holding a current and unrestricted license, must review it first.
The plan's decision must rest on the enrollee's medical history, physician recommendations and clinical notes (42 CFR 422.101). CMS's FAQ says the rule does not require real-time decisions, and that "other decisions will continue to necessitate review and evaluation by clinical reviewers." For Medicaid and marketplace plans, and under state law, ask counsel which review rules apply.
In the pledge CMS announced on June 23, 2025, insurers committed to having medical professionals review all clinical denials. CMS's WISeR model, which uses AI in Original Medicare in six states from 2026 to 2031, states: "All recommendations for non-payment are determined by appropriately licensed clinicians." In the AMA survey, only 24% of physicians agreed that medical necessity denials are reviewed by a licensed, qualified physician.
Our agent has no tool that approves, denies or submits anything. In the demo, a surgical scheduler asks it to override the X-ray window so a case can stay on Monday's list. The insurer's policy windows are checked in code, no tool can waive one for any role, and the request is logged. Nothing goes to Ashmere until a nurse approves it. In the demo, the approved packet is prepared for the team or an integration to submit, and the agent itself sends nothing.
What does a prior authorization agent look like on Google Cloud?
The chart sits in a FHIR R4 store on the Cloud Healthcare API in your own project, the payer's policy becomes rules that code checks, the agent runs on Gemini Enterprise with a few narrow tools, and every packet waits for a nurse. That is our demo's design, again for a made-up health system and insurer.
| Layer | In our demo |
|---|---|
| Chart | FHIR R4 store on the Cloud Healthcare API, read through FHIR search |
| Protected records | Security labels, excluded inside the search |
| Payer policy | Written as rules clause by clause, each version signed off by a person, every window checked in code |
| Outside faxes | Fields read once at intake from an allowed list; the year checked against the referral and fax header, the typed value kept |
| Agent | Gemini Enterprise, with a few narrow tools |
| Approval and audit | A nurse approves; every question, refusal and approval is logged |
Google lists the Cloud Healthcare API, Gemini Enterprise and Gemini Enterprise Agent Platform (formerly Vertex AI) among the products covered by its business associate agreement, and says HIPAA compliance is a shared responsibility, so getting your project's configuration right is your side of it. If your clinical data is not in your own project yet, that comes first; we have moved a clinical analytics platform with patient data before, as part of our data and analytics work.
How do you keep behavioral health and substance use records out of the agent's view?
Exclude them inside the FHIR store's search so they never leave the store, and give the agent only a count. A knee replacement packet does not need them, and a record the agent never receives cannot leak through an answer or a log.
In the demo, records labeled PSY, ETH and 42CFRPart2 are excluded by the store's own search, with one _security:not parameter per code. Our store read a comma-separated list of the three codes as no filter at all, and testing caught it. For one synthetic patient the agent reports 14 protected records held back and receives none. The Cloud Healthcare API can also enforce FHIR Consent resources that match on security labels.
The 42 CFR Part 2 final rule, with a compliance date of February 16, 2026, says a covered entity or business associate that receives records under a single consent for treatment, payment and health care operations does not have to segregate them. Keeping them away from the agent is a design choice, and we make it; a person allowed to read such a record adds it when a request needs it. Our post on keeping protected records out of an agent's reach has the full method.
How do you know the agent gets it right before it goes live?
Score it against an answer key written by the nurses who do the work, on past cases, several runs over, next to a prompt-only version on the same model. For a real build, that means replaying last quarter's prior authorizations against what the payers decided.
Our demo used 20 synthetic cases for the made-up health system and insurer, run four times. Our agent got all 20 right in every run, 480 of 480 criteria. A prompt-only version on the same Gemini model scored 19, 18, 18 and 18, and read 42 protected records in every run. It believed the mistyped fax year and marked that patient's packet not ready each time. These are synthetic test cases, not customer results. Our post on how we test an AI agent before launch explains the answer key and the go-live gates.
After launch, count how often packets come back with more information requested, one of the three answers the Prior Authorization API returns from 2027.
Should we build now or wait for Gemini for healthcare?
Start the groundwork now, because most of it carries over to whichever agent you run. Google announced Gemini for healthcare on November 10, 2026, in preview for Gemini Enterprise Standard and Plus customers. Google's Pre-GA terms say customers should not use preview offerings for personal or regulated data unless a written notice or Google documentation says otherwise, so get written confirmation before any patient data goes in.
The answer key from your past cases, access to the chart, signed-off payer rules, the protected-records filter and the approval step do not depend on the product choice. Run the same test set against each option and let the scores decide. Our post on getting ready for Gemini for healthcare covers the preview terms. When you have a workflow in mind, talk to an engineer.
Update log
- November 11, 2026: first published.
Frequently asked questions
Does the rule apply to marketplace plans?
Partly. QHP issuers on the federally facilitated exchanges must give denial reasons, publish metrics and run the 2027 APIs, but the 72-hour and seven-day timeframes do not apply to them. CMS-0062-P would add those from October 1, 2027, a proposed date.
Does it cover drugs?
No. CMS-0057-F covers medical items and services. CMS-0062-P proposes adding drugs from October 1, 2027 (proposed).
Do we still need X12 278?
HHS will not enforce the X12 278 requirement against payers running an all-FHIR Prior Authorization API, and CMS says an X12-only API cannot meet the rule's other requirements. Until each payer you work with has its FHIR API live, build a packet that can go out either way.
Which Da Vinci guide versions should we build to?
CMS recommends CRD, DTR and PAS but does not yet require them. HL7's current versions are CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1, published March 27, 2026. HTI-4 certification references version 2.0.1 of each, and CMS-0062-P would require the 2.2 versions from October 1, 2027 (proposed), so expect to support both for a while.
Can AI approve a request in real time?
CMS does not require real-time decisions and expects some to keep needing clinical reviewers. Our agent approves nothing; a nurse approves the packet and the payer decides.
Do Original Medicare and employer plans have to comply?
No. Neither is an impacted payer under CMS-0057-F, though Original Medicare has its own review programs, such as the WISeR model.
Sources
- CMS-0057-F final rule, 89 FR 8758, Federal Register
- CMS-0057-F fact sheet, CMS
- Prior authorization FAQ, CMS
- Electronic prior authorization overview, CMS
- X12 278 enforcement discretion FAQ, CMS
- CMS-0062-P overview, CMS
- CMS-0062-P proposed rule, Federal Register
- 42 CFR 422.122, eCFR
- 42 CFR 422.566, eCFR
- 42 CFR 422.101, eCFR
- 42 CFR 438.242, eCFR
- 45 CFR 156.223, eCFR
- FY 2027 IPPS final rule, Federal Register
- CY 2027 Physician Fee Schedule final rule, Federal Register
- HTI-4 overview and key dates, ASTP/ONC
- Da Vinci CRD history, HL7
- Da Vinci DTR history, HL7
- Da Vinci PAS history, HL7
- Prior authorization metrics analysis, KFF
- 2026 prior authorization physician survey, AMA
- Insurer pledge on prior authorization, CMS
- WISeR model, CMS
- 42 CFR Part 2 final rule, Federal Register
- FHIR in the Cloud Healthcare API, Google Cloud
- FHIR consent management, Google Cloud
- HIPAA compliance on Google Cloud, Google Cloud
- Gemini for healthcare launch, Google Cloud
- Pre-GA Offerings Terms, Google Cloud
- Prior authorization agent demo film, CloudMagic