Prior Authorization Automation with ADK: a Payer Reference Architecture

Ask an AI Overview how a health plan should automate prior authorization and you get a confident answer about "AI-powered prior auth" that skips the only two things that scope the project: the regulation that makes it urgent, and the FHIR implementation guide that makes it interoperable. Without those two, "automate prior auth" is a slogan, not a project.

Prior authorization is the most visible friction point in U.S. healthcare administration. A provider requests approval for a service, the payer reviews it against coverage policy and medical-necessity criteria, and in the gap a patient waits — often for days, sometimes for two weeks. The work is real, the rules are codified, most of the volume is routine: exactly what an agent is built for. But "build an agent for prior auth" is not a specification. This reference architecture is — written for the payer engineering and product team scoping their first agent against a real regulatory deadline. It names CMS-0057-F as the procurement event, maps the Da Vinci Prior Authorization Support (PAS) FHIR implementation guide onto a working Agent Development Kit (ADK) v1.0 tool inventory, and treats the human-in-the-loop pattern — ToolConfirmation for medical-director review — as part of the canonical architecture, not an afterthought.

1. Why prior authorization is the CMS interoperability rule's center of gravity

The Centers for Medicare & Medicaid Services has spent several rulemaking cycles pushing U.S. healthcare toward standardized, API-based data exchange. Earlier rules targeted patient access and provider directories. The current one targets the single workflow providers and patients complain about most: prior authorization.

That focus is not arbitrary. Prior authorization sits at the intersection of three things CMS cares about — administrative cost, care delays, and data that does not move. A request travels by fax or payer portal, lands in a manual review queue, and the decision travels back the same way; the provider's EHR and the payer's utilization-management system never speak directly. Every other interoperability problem is a data-access problem; prior authorization is a transaction problem, and transactions are where standardized APIs change the economics most. So when a payer asks "where do we start with agents," prior authorization is the honest answer: high-volume, rule-bound, regulatorily mandated to modernize, and painful enough that the business case writes itself.

2. The current-state pain: faxes, portals, manual review, 14-day turnarounds

The workflow as it runs today at a typical regional payer: a provider's staff initiates a request — often by fax, often through a payer-specific portal they log into separately for every plan. It lands in the intake queue as an unstructured document or a form. A coordinator checks eligibility and benefits. A nurse reviewer pulls the clinical documentation, locates the applicable medical-necessity criteria, and assesses whether the request meets them. Routine cases that clearly meet criteria still wait behind everything else. Ambiguous, high-cost, or clinically complex cases go to a medical director. The decision — approved, denied, or pended — travels back to the provider, again by fax or portal.

Three costs compound:

1. Cycle time. Standard turnarounds run in days; the worst cases stretch toward two weeks. The patient waits the entire time.
2. Clinical hours spent on retrieval. Nurse reviewers and medical directors are scarce and expensive, and a large share of their time goes to assembling the case — finding the notes, the criteria, the prior history — not judging it.
3. No structured data. Because the request arrived as a fax or a form, there is nothing clean to analyze, audit, or learn from afterward.

3. What the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) actually requires

CMS-0057-F turns this from a nice-to-have into a dated project. The rule directs impacted payers — Medicare Advantage organizations, Medicaid and CHIP programs, and Qualified Health Plan issuers on the federal exchanges — to stand up a set of FHIR-based APIs. The ones that matter here:

• A Prior Authorization API. Payers must implement an API that supports the prior authorization process end to end — letting providers query whether a service requires prior authorization and what documentation is needed, submit the request, and receive the decision through a standardized FHIR interface rather than a fax or a proprietary portal.
• Decision timeframes and reason requirements. The rule shortens certain decision timeframes and requires payers to give a specific reason on a denial, so providers know what to fix or appeal.
• Provider Access, Patient Access, and Payer-to-Payer APIs. The same rule modernizes the surrounding data flows, so the Prior Authorization API is not an island.

The most important thing to understand: the rule mandates the APIs and the decision discipline. It does not mandate AI. You can comply using a standards-based API and an entirely human review process behind it. But the effective dates are what create the build window — once you are standing up a Prior Authorization API anyway, putting an agent behind it to do the assembly work is the obvious next move, and the timeline is what gets it funded.

Always verify the current effective dates and the exact set of impacted payers against the CMS-0057-F final rule page before scoping a timeline — CMS has adjusted compliance dates across the interoperability rulemaking, and your project plan should anchor to the source, not a secondary summary.

4. Where automation can take latency from days to hours — or minutes for routine cases

Map where the time goes today against where an agent removes it:

The realistic outcome is two-tier. Routine cases — clearly meets published criteria, member with clean eligibility — can move from days to minutes, because every slow step in that path is assembly the agent does well. Exception cases — high-cost, clinically ambiguous, or criteria-edge — still take human time, but the human starts from an assembled case file, so even those compress from days toward hours. The target is not "the agent decides everything faster." It is "the agent clears the routine bulk and hands the clinician the hard ones already framed." That distinction drives every design decision below.

5. Reference architecture: intake to decision

The canonical shape is a five-stage pipeline. A FHIR request enters through the Prior Authorization API; one ADK agent orchestrates all five stages; a FHIR response — approved, denied, or pended — exits the same way. The agent runs stages 1 through 4 itself. Stage 5 is where authority splits: routine determinations the agent drafts and returns, high-risk determinations it routes to a medical director through ToolConfirmation.

Walk the five stages:

1. Intake. The request arrives as a FHIR resource through the Prior Authorization API the rule requires — no fax to OCR, the standard largely solves the structuring problem. The agent's job here is validation: a well-formed request, for a service this payer covers, with the data elements the determination needs.
2. Eligibility check. Confirm the member's coverage is active and the service falls within the benefit — a fast, deterministic tool call. A failed check short-circuits the flow; there is no point assembling a case file for an inactive member.
3. Coverage determination. Does this specific service, for this plan, require prior authorization at all? Plans differ; the answer is a policy lookup. This is what the rule's "does this need prior auth" provider query maps to.
4. Medical-necessity review. The substantive stage. The agent retrieves the clinical documentation, locates the applicable medical-necessity criteria, and assesses the request against them. Routine cases get a drafted determination with the criteria cited inline; anything high-risk, the agent assembles the case file and stops.
5. Decision. Routine cases: the drafted determination returns through the PA API as a FHIR response. High-risk cases: the agent invokes ToolConfirmation, which pauses execution and routes the assembled case file to a medical director, who issues the determination. Either way, the response carries a reason, satisfying the rule's reason requirement.

The agent orchestrates all five stages but does not decide all five — stages 1 through 3 are deterministic checks, stage 4 is assessment, and stage 5 is where authority splits between the agent (routine) and a human (high-risk).

6. Da Vinci PAS: the FHIR implementation guide alignment

CMS-0057-F says "implement a FHIR-based Prior Authorization API." It does not, by itself, tell you the exact resource shapes and operations. The Da Vinci Prior Authorization Support (PAS) implementation guide does — a HL7 FHIR implementation guide, developed by the Da Vinci Project, that specifies how prior authorization requests and responses are represented and exchanged. PAS is the connective tissue between two worlds that predate FHIR and are not going away:

• The FHIR world the rule and the providers' EHRs speak.
• The X12 world — specifically the X12 278 transaction set for health care services review (request and response) — that payer claims and utilization-management systems have used for decades.

PAS defines the FHIR profiles for the request bundle and the response, and the mapping to and from X12 278, so a provider can submit a FHIR request and the payer's existing infrastructure can still process the underlying 278. For an agent architecture, that mapping does specific work: PAS gives you a published contract for every boundary the agent touches. The agent reads a PAS-conformant request and emits a PAS-conformant response — including generating the X12 278 where the payer's downstream systems expect it. You are not designing the agent's I/O shapes; the implementation guide already did.

Read the Da Vinci PAS implementation guide directly when scoping the tool inventory; its operations are what the next section's tools map onto. PAS is one option for the data exchange rather than a statutory mandate in itself — but it is the implementation guide the ecosystem has converged on, and building to it means building to something providers' EHRs are already targeting.

7. The ADK agent design: tool inventory

This is where the architecture becomes code. The agent is a single ADK LlmAgent with a focused tool inventory that maps directly onto the PAS operations above. The four tools it needs:

1. Eligibility lookup — checks member coverage and benefit status against the payer's eligibility system. Deterministic, fast, called first.
2. Policy retrieval — returns the plan's coverage policy for a given service: does it require prior authorization, and under what conditions.
3. Clinical guideline parsing — retrieves the applicable medical-necessity criteria and the member's clinical documentation, and structures them so the agent can assess one against the other.
4. X12 278 generation — produces the X12 278 health care services review transaction and reads the response, so the determination flows into the payer's existing utilization-management infrastructure through the channel it already understands.

The agent definition:

# agents/prior_auth/agent.py
from google.adk.agents import LlmAgent
from google.adk.tools import FunctionTool, ToolConfirmation
 
from .tools import (
    check_member_eligibility,
    retrieve_coverage_policy,
    parse_clinical_guidelines,
    generate_x12_278,
    route_to_medical_director,  # high-risk path — see section 10
)
 
 
prior_auth_agent = LlmAgent(
    name="prior_authorization_agent",
    model="gemini-2.0-pro",
    instruction=(
        "You process prior authorization requests for a health plan. "
        "For every request, in order: confirm member eligibility, "
        "retrieve the coverage policy, and — if prior authorization is "
        "required — parse the applicable medical-necessity criteria and "
        "assess the request against them.\n\n"
        "For a ROUTINE request that clearly meets published criteria, "
        "draft the determination, cite every criterion you applied, and "
        "generate the X12 278 response.\n\n"
        "For a HIGH-RISK request — high-cost service, ambiguous clinical "
        "picture, a criteria edge, or a likely denial — do NOT issue a "
        "determination. Assemble the case file and route it to a medical "
        "director for review. You never finalize a denial yourself."
    ),
    tools=[
        FunctionTool(check_member_eligibility),
        FunctionTool(retrieve_coverage_policy),
        FunctionTool(parse_clinical_guidelines),
        FunctionTool(generate_x12_278),
        FunctionTool(
            route_to_medical_director,
            require_confirmation=ToolConfirmation(
                # the medical-director review gate — section 10
            ),
        ),
    ],
)

Two design notes matter. First, the tool inventory is small on purpose — four well-defined tools, each a real system of record and a real PAS operation. Every tool is a surface the eval set has to cover and the audit trail has to record, so resist adding any the workflow does not require. Second, the model carries the assessment, the tools carry the facts. parse_clinical_guidelines returns the criteria and the documentation; the model reasons about whether one meets the other. That division keeps the agent auditable — the inputs to every judgment are explicit tool outputs, not knowledge baked into the prompt. For the foundations of structuring an agent and its tools this way, our code-first ADK guide is the reference; this article applies that grounding to the payer workflow.

8. Memory Bank for member-specific prior-auth history

A prior authorization request is rarely the member's first. The same member has had prior requests — some approved, some denied, some for related services. A chatbot starts every conversation cold. An agent should not.

That is what Memory Bank is for: the managed memory service on Gemini Enterprise Agent Platform that gives an agent persistent, member-scoped recall across sessions. For the prior-auth agent it carries forward:

• The member's prior authorization decisions and their rationales.
• Related prior requests — a physical-therapy request reads differently when the agent can see the member's prior imaging authorization for the same condition.
• Documentation the member or provider has already supplied, so the agent does not re-request what it already has.

The point is sharper than "memory is nice." Member-scoped persistence is the line between a chatbot and an agent. A system that re-asks for context it should already hold is doing intake theater; a system that opens a request already knowing the member's authorization history is doing the reviewer's job. Memory Bank is why "we built a prior-auth chatbot" and "we built a prior-auth agent" are not the same project.

9. Model Armor for PHI redaction in clinical-narrative inputs

The clinical documentation the agent reads is dense with protected health information. Some of it the determination genuinely needs; some is incidental and should never reach the model's context unredacted. That gate is Model Armor — the screening layer on Gemini Enterprise Agent Platform that inspects content moving in and out of the model and can detect and redact sensitive data, including PHI. In this architecture it sits on the inputs flowing from the parse_clinical_guidelines tool into the model's context: it screens the clinical narrative before it becomes model context, so PHI incidental to the assessment is redacted at the gateway, not relied on to be ignored downstream.

One scoping line the architecture cannot skip. Whether and how a given Google Cloud service can be used for PHI under a Business Associate Agreement (BAA) is governed by Google's list of HIPAA-eligible services, and that list moves. Designing the PHI flow and confirming the specific services in scope against Google's current covered-products list at the time you build is a compliance exercise in its own right. Our HIPAA-compliant agents reference architecture works through it in detail — the services in scope, the qualifier the claim language requires, what is and is not BAA-eligible — and any prior-auth build should be read alongside it rather than treating "Model Armor handles PHI" as a closed answer.

10. The human-in-the-loop step: ToolConfirmation for medical-director review

Full automation of prior authorization is not a hard target. It is the wrong one. A medical-necessity determination on a high-risk case is a clinical judgment with real consequences for a patient — and an architecture that lets an agent issue one has not solved a hard problem, it has built a liability. The clinician belongs in that decision path by construction, not by policy memo. That construction is what separates a payer architecture you can put in front of a regulator from a demo.

ADK's mechanism is ToolConfirmation. A tool can be marked as requiring confirmation: when the agent calls it, execution pauses, the call and its assembled context are surfaced to a human, and the agent proceeds only on the human's response. The prior-auth agent's route_to_medical_director tool is gated this way — so when the agent assesses a request as high-risk, calling that tool does not silently dispatch a determination, it stops the agent and hands a medical director the assembled case file.

What "high-risk" means is a policy decision the payer makes and the agent's instruction encodes — typically some combination of:

• High-cost services above a dollar threshold the plan sets.
• Requests where the clinical picture is ambiguous against the criteria.
• Criteria-edge cases the eval set has flagged as historically contested.
• Any case trending toward a denial.

That last point deserves emphasis. A denial is an action with appeal rights and clinical stakes, and the agent does not have the authority to issue one. The agent can assemble the case, surface that the criteria appear unmet, and route to the medical director — but the determination to deny is the clinician's, made on the assembled file. The agent's authority is bounded to drafting approvals on routine cases that clearly meet criteria; everything else is ToolConfirmation to a human.

This pattern — the agent assembles, the clinician decides, ToolConfirmation is the seam between them — is part of the canonical architecture, not an optional safety feature. It is the shape of our prior authorization blueprint: a six-week single-agent engagement where the agent walks the reviewer into review with the case file assembled and the determination drafted, and the named reviewer signs every one.

11. Audit trail: how Agent Registry satisfies the audit requirements

A payer cannot run an agent in a regulated decision workflow without being able to answer, for any past request: which agent acted, what it did, what it called, and which human finalized the determination. That is an audit requirement, and a Day-1 requirement, not a Phase 2 retrofit.

Agent Registry handles it natively. Every agent on Gemini Enterprise Agent Platform is registered with an identity, and its actions are recorded against that identity — the tool calls it made, the determinations it drafted, the ToolConfirmation handoffs to a medical director and which director responded. The audit trail is a property of the platform the agent runs on, not a logging system the team builds alongside it.

Why Day-1 and not later is structural. Defer it and you spend the back half of the project reconstructing what the agent did from application logs never designed to be an audit record — and in a regulated workflow, "we think the agent did X" is not an acceptable answer to an auditor. Inheriting the trail from the start means every request the agent has ever touched is accountable from the first one. Build it in at the foundation, the same way you build in the human-in-the-loop gate.

12. Deployment shape: an 8-week single-payer build vs. a 12-week multi-payer rollout

The architecture above is one agent for one plan. The realistic delivery shapes are two.

An 8-week single-payer build stands up the prior-auth agent for one health plan, against one set of coverage policies and one eligibility system:

• Weeks 1–2 — Discovery and inventory. Walk the current utilization-management workflow with the medical director and nurse reviewers. Inventory the coverage policies, the medical-necessity criteria sources, the eligibility system, the X12 278 integration point. Define "high-risk" as a written policy, and shape the eval set against decision quality from historical determinations.
• Weeks 3–5 — Agent and tool build. Build the ADK agent and the four tools against the real systems. Wire Memory Bank for member history and Model Armor on the clinical-narrative inputs. First eval pass against the historical corpus; tighten prompts and tool definitions against the results.
• Week 6 — Governance and the human-in-the-loop seam. Register the agent in Agent Registry. Wire ToolConfirmation on route_to_medical_director and test the pause-and-route flow with the actual reviewer pool. Confirm the audit trail captures what an auditor would ask for.
• Week 7 — Staging shadow run. Run the agent in shadow against live requests; compare its routine drafts and high-risk routing decisions to the human queue, and tune the eval set against any drift.
• Week 8 — Production cutover. Deploy behind the Prior Authorization API, clinician in the loop on every determination that warrants one. Hand the team the repo, the eval harness, and the runbook.

A 12-week multi-payer rollout is not "the 8-week build, longer." It is the single-payer build plus generalizing across plans: multiple coverage-policy libraries, multiple eligibility systems, the variation in what each plan classifies as requiring prior authorization, a "high-risk" policy that may differ per plan. The agent design does not change — same four tools — but the configuration surface, the eval corpus, and the integration count all multiply. Scope it as its own shape, not a schedule extension.

This audit-build-validate-ship rhythm is the same discipline behind our six-week pilot methodology — a healthcare workflow with a human-in-the-loop seam and an audit requirement runs slightly longer than a greenfield single-agent build, but the phases are the same. Once the prior-auth agent is in production, the natural next stage in the payer build sequence is claims processing as a multi-agent workflow, where this agent's determination becomes an input downstream. If your team is weighing prior auth against a different first agent, the full blueprint catalog and the platform overview lay out the other shapes and how the Build, Scale, Govern, and Optimize pillars fit around code your team owns.

If you are scoping this against a CMS-0057-F deadline and want a concrete read on which build shape fits your plan, talk to the healthcare practice.

13. FAQ