healthcare AI platforms
Prior authorization automation,
explained by people who run it.
A practitioner-grade field guide to prior authorization automation in 2026. Written by the team running one of the six commercially available platforms processing Medicare Fee-for-Service prior authorizations under the CMS WISeR Model. What the term actually means, how production systems are architected, the regulatory floor under it, and the architectural choices that determine whether automation is safe to deploy.
What prior authorization automation actually is.
Prior authorization automation is the use of software — historically rule engines, today AI agents grounded in clinical criteria — to issue, route, or recommend prior authorization decisions without manual case work for routine requests. In a well-architected system, automation handles eligibility, criteria matching, evidence assembly, and clean-affirmative determinations. Clinical denials are routed to human reviewers because auto-deny is not safe to automate.
The phrase is used loosely. Some vendors mean rule-based form-routing. Others mean LLM-driven case summarization. A few mean end-to-end agent decisioning with audit-grade traceability. The architecture matters; the words don't.
The market isn't asking for AI — it's mandating it.
Three regulatory anchors made prior authorization automation a 2026 priority for every payer. Together they create the first hard deadlines the industry has ever had for digital PA infrastructure.
| Mandate | Effective | What it requires |
|---|---|---|
| CMS-0057-F | January 1, 2027 | FHIR Prior Authorization APIs — CRD, DTR, PAS — for Medicare Advantage, Medicaid managed care, CHIP, and QHP issuers on FFEs. Public PA performance metrics already required since March 31, 2026. |
| CMS WISeR Model | 2026–2031 | Six-year Medicare Fee-for-Service PA pilot using AI alongside human clinical review. Six states. Six commercial platforms. The federal government's first commercial-AI-assisted PA pilot. |
| State gold-carding laws | Active in 12+ states | Texas (HB 3459), Michigan, and a growing list of states require PA exemptions for high-performing providers. Automation is the only way to administer gold-carding at scale. |
For a deeper read on CMS-0057-F implementation reality, see For Payers. For the live WISeR deployment, see WISeR Live Deployment.
Decomposed agents. Audit-grade evidence. Human review on every denial.
Production-grade prior authorization automation is not one big LLM. It's a collection of specialist agents, each fluent in one job, each individually testable, each citable in an audit. Here's the reference pattern.
-
Step 1 · Intake validation
An Intake Agent validates the incoming PA request — CPT/HCPCS codes against active code sets, ICD-10 against current versions, beneficiary identifiers against eligibility systems (HETS for Medicare). Bad inputs are returned to the submitter with a structured error code, not silently failed.
-
Step 2 · Eligibility
An Eligibility Agent verifies the beneficiary is enrolled, the requesting provider is enrolled and credentialed (PECOS for Medicare), and the service is within scope of coverage. Eligibility failures are deterministic outputs, not AI guesses.
-
Step 3 · Duplicate detection
A Duplicate Request Agent checks whether this exact case has been submitted before by this provider for this beneficiary in a defined lookback window. Duplicates are flagged before a clinical reviewer ever sees the case — a major source of waste in legacy PA workflows.
-
Step 4 · Criteria evaluation
A Criteria Agent evaluates the case against the applicable medical policy — NCD, LCD, payer medical policy, or commercial criteria like InterQual or MCG. Evaluation is structured: each criterion is decomposed into atomic clinical questions and answered with explicit evidence citations.
-
Step 5 · Evidence assembly
An Evidence Agent assembles the clinical evidence for the determination — medical record excerpts, imaging reports, lab results, prior treatment history. Evidence is bound to specific criteria and timestamped, so the audit packet can be regenerated months later.
-
Step 6 · Determination
For auto-affirmation — cases where the criteria are clearly met — an Auto-Affirm Agent issues the determination in seconds. For non-affirmation — cases that don't clearly meet criteria — the case routes through a Non-Affirm Research Agent to a human reviewer. This is non-negotiable. Auto-deny is architecturally prohibited.
-
Step 7 · Audit packet
For every decision, the system generates an audit packet: rule pack version, evidence chain, agent reasoning trace, human-review record (if applicable), and the regulatory citations that justified the determination. CMS-ready by construction, not by scramble.
For the patent-protected substrate that powers all seven agents above, see Aether One™ Architecture. For the marketplace where individual agents are sold standalone, see Aether One™ Agents.
Why auto-deny is architecturally prohibited.
Many vendors treat denial automation as a feature. Production-grade systems treat it as a contraindication. This is the most important architectural decision in prior authorization automation, and it gets the least attention.
Federal and state law require human review for medical-necessity denials.
The Centers for Medicare & Medicaid Services, multiple state insurance commissioners, and 2024 federal court rulings have established that medical-necessity denials require qualified human clinical judgment. An AI agent cannot legally issue a clinical denial that affects coverage.
The cost of a wrong denial is asymmetric.
A wrong auto-affirmation costs a payer some incremental medical spend. A wrong auto-denial costs a patient access to care — potentially with catastrophic clinical consequences, almost certainly with regulatory exposure. The math is asymmetric. So is the architecture.
Every denial gets re-examined.
Provider appeals, member appeals, state insurance department complaints, and federal audits all re-examine denial decisions. A denial that can't trace back to a named human reviewer with documented clinical reasoning is a regulatory finding waiting to happen.
Agent 871 routes every non-affirmation to human review.
In HIP One, every case the auto-affirmation agent doesn't clear goes through a Non-Affirm Research Agent (Agent 871) to a human reviewer. The agent prepares the case, summarizes the gap, surfaces the evidence. The human decides. The architecture cannot be configured to skip the human.
Buyer's questions, answered.
The questions that come up in every payer evaluation, every provider procurement, every CMS Innovation Center conversation. Short, citable answers.
What is prior authorization automation?
Prior authorization automation is the use of software — historically rule engines, today AI agents grounded in clinical criteria — to issue, route, or recommend prior authorization decisions without manual case work for routine requests. In a well-architected system, automation handles eligibility, criteria matching, evidence assembly, and clean-affirmative determinations; clinical denials are routed to human reviewers because auto-deny is not safe to automate.
Is prior authorization automation safe?
It depends on the architecture. Auto-affirmation (approving requests that clearly meet criteria) is safe and high-value. Auto-denial is not safe to automate and most defensible production systems prohibit it architecturally. HIP One enforces this invariant: clinical denials cannot be issued by an agent — they always route through a non-affirm research agent to a human reviewer. This is also the architecture CMS rewards under WISeR.
What does CMS-0057-F require for prior authorization?
CMS-0057-F mandates that impacted payers (Medicare Advantage, Medicaid managed care, CHIP, QHP issuers on FFEs) implement FHIR-based Prior Authorization APIs by January 1, 2027. The required APIs are CRD (Coverage Requirements Discovery), DTR (Documentation Templates and Rules), and PAS (Prior Authorization Support) — collectively the Da Vinci PA bundle. Public reporting of PA performance metrics began March 31, 2026.
What is a prior authorization agent?
A prior authorization agent is an AI software agent that handles a specific step in the PA workflow — eligibility checking, intake validation, duplicate request detection, criteria evaluation, evidence assembly, or auto-affirmation. Domain-decomposed agents are individually testable and individually citable in audit, which is why production-grade PA systems use multiple specialist agents rather than one monolithic LLM. Aether One™ Agents sells these as standalone marketplace products.
How is prior auth automation different from delegated UM?
Delegated UM moves prior authorization decision-making to a third party (a UM vendor, a TPA, a delegated medical group). Prior auth automation can replace or supplement delegated UM by bringing the decisioning back in-house with software that runs against the same evidence-based criteria a delegated reviewer would use. Many payers run both — using automation for high-volume routine requests and delegated UM for specialty care.
Is Genzeon Platforms live in CMS Medicare?
Yes. Genzeon Platforms is one of six commercially available platforms processing Medicare Fee-for-Service prior authorizations under the CMS WISeR Model since January 2026, working with Novitas Solutions in MAC JL (New Jersey). Production performance: 15,000+ authorizations processed, 100% compliance with the CMS 3-day turnaround time, zero auto-denials by architecture.
What is the CMS WISeR Model?
WISeR (Wasteful and Inappropriate Service Reduction) is a six-year CMS Innovation Center model running 2026–2031 that uses AI and machine learning, alongside human clinical review, to streamline prior authorization for select Medicare FFS items and services in six states (New Jersey, Ohio, Oklahoma, Texas, Arizona, Washington). It is the federal government's first commercial-AI-assisted PA pilot and the model most likely to inform broader Medicare PA policy.
What is gold-carding?
Gold-carding is a payer policy that exempts high-performing providers from prior authorization requirements based on their historical approval rates. A provider with a 95%+ approval rate on a given service category may receive a "gold card" that lets them bypass PA for that category for a defined period. Gold-carding is increasingly mandated by state law (Texas, Michigan, several others) and HIP One includes a gold-card management module.
Can I buy a single prior auth agent without licensing the full platform?
Yes. Aether One™ Agents lets you buy a single agent — Prior Auth Eligibility, Pre-Check, Duplicate Request, Intake, or Auto Approval — and drop it into the workflow you already operate. Single agents are available on Microsoft Azure Marketplace today, with AWS Marketplace, Google Cloud Marketplace, and Salesforce AppExchange in onboarding. Pricing is $100K–$300K per agent per year.
How long does prior authorization automation take to deploy?
Single-agent pilots on Microsoft Azure Marketplace typically deploy in 2–4 weeks. Full-platform HIP One deployments range from 12–24 weeks depending on integration scope (FHIR endpoints, EMR connections, payer-specific rule pack customization). Outcomes-based engagements under the WISeR model timeline shipped from contract signature to production go-live in approximately 6 months.
A platform built for the architectural realities.
Most prior authorization automation vendors picked one shape: a payer suite, an EMR widget, a clearinghouse plugin. Genzeon Platforms picked the substrate — the agent architecture that runs across deployment shapes, audiences, and procurement models.
| What you need | Where Genzeon Platforms delivers it |
|---|---|
| A full PA platform replacing an incumbent stack | HIP One — full Health Intelligence Platform license, $1.0–2.5M ACV |
| A single PA agent dropped into your existing workflow | Aether One™ Agents — marketplace SKUs from $100–300K per agent per year |
| A risk-shared outcomes engagement like the WISeR Model | Outcomes-based contracting available for any LOB where outcomes can be measured |
| Sovereign or on-prem deployment for government or high-security payer environments | Aether One™ Sovereign — weights, knowledge, and decisions stay in your perimeter |
| CMS-0057-F compliance ahead of the January 2027 deadline | HIP One supports the full Da Vinci PA bundle (CRD, DTR, PAS) production-ready today |
| Production proof in CMS Medicare | WISeR Live Deployment — 15K+ authorizations, 100% 3-day TAT compliance, January 2026 go-live |
| Auto-deny architecturally prohibited | Built into the substrate. Cannot be configured to skip human review on clinical denials. |
Go deeper.
Where to read more on the architecture, the deployment, the patents, and the regulatory program shaping this market.
HIP One — Health Intelligence Platform
The full PA, UM, medical review, payment integrity, and quality measurement platform. Live in CMS Medicare today.
Explore HIP One Live deploymentWISeR Live Deployment
Production performance, architecture, and program references for the live CMS Medicare PA deployment with Novitas Solutions in MAC JL.
See the deployment ArchitectureAether One™ — The Healthcare Brain
The patent-protected agentic substrate beneath HIP One. Decomposed agents, deterministic guardrails, audit-grade traceability.
Read the architecture MarketplaceAether One™ Agents
Buy a single PA agent — Eligibility, Pre-Check, Duplicate Request, Intake, Auto Approval — on Microsoft Azure Marketplace.
Browse the marketplace IPPatent Portfolio
10 patents filed across the Aether One™ substrate, including the auto-affirmation system that backs the live CMS WISeR deployment.
See the patent portfolio For PayersBuyer's view
For health plans replacing fragmented PA stacks: how HIP One automates PA decisions, streamlines medical review, and meets CMS-0057-F.
Read the payer viewProduction proof, on your workflow.
A 30–45 minute conversation with the team running prior authorization automation in CMS Medicare. We bring the rule packs, the architecture, and the audit packets. You bring the use case you want to test.