AI Medical Coding and Prior Auth Automation

The buyer problem: revenue cycle is still too slow, too manual, and too fragile

Health systems and vendors do not buy AI because it sounds smart. They buy it because prior authorizations stall care, coding queues back up, and every delay turns into labor cost or lost reimbursement. The old RCM stack was built for batch processing: a referral arrives, someone checks eligibility, someone else codes the chart, someone manually gathers supporting documentation, and another team chases payer-specific requirements. That model breaks when volume rises or payers keep changing rules.

Real-time automation changes the operating model. Instead of waiting for a human to touch every chart, the system reads intake data, extracts clinical signals, maps them to CPT/ICD-10/HCPCS logic, checks payer requirements, and routes only exceptions to staff. The goal is not to eliminate revenue cycle teams. It is to move them from transcription and lookup work into review, exception handling, and denial prevention.

What real-time AI actually does in medical coding and prior auth

The core stack has four layers. First, capture structured intake from portals, call center notes, faxes, PDFs, and EHR data. Second, run NLP and document understanding to extract entities like diagnosis, procedure, laterality, ordering physician, medical necessity language, and payer references. Third, apply rules and models to assign codes or determine authorization needs. Fourth, orchestrate the task queue so staff only review cases that fall below a confidence threshold or hit payer-specific exceptions.

That is where agentic AI gets useful. The agent is not “thinking” in the abstract; it is executing a sequence: identify missing fields, request supplemental data, compare against policy, draft the prior auth packet, and hand off for final sign-off when required. In practice, that means combining LLM-based extraction, deterministic rules, payer policy libraries, and audit logging. If you remove any one of those pieces, the system becomes hard to trust.

Three architecture patterns that work

1) Rules-first automation

This is the safest starting point. Use conventional workflow engines for payer rules, eligibility checks, code edits, and authorization prerequisites. Add AI only where it is good at extraction: reading notes, classifying documents, and identifying missing data. This is the right fit when the organization needs traceability, payer-by-payer specificity, and low implementation risk.

2) LLM-assisted workflow

This pattern is usually the fastest to production. The model reads a visit note, builds a structured summary, and proposes the relevant codes or auth packet sections. A human reviews the output before submission. It works well when the chart narrative matters, but the underlying business logic still needs deterministic controls.

3) Agentic orchestration

This is the emerging model for real-time operations. The agent is not a monolith; it is a process controller. It watches for intake events, inspects the chart, identifies missing clinical evidence, requests more data, populates forms, and retries after payer responses. The value is speed, but only if the system has strong guardrails, versioned prompts, and audit trails.

AST’s approach to RCM automation

AST builds these systems as integrated product teams, not isolated model experiments. When our team works on revenue cycle tooling, we design the workflow around the people who must live with the output: coders, auth specialists, revenue integrity teams, and compliance owners. That usually means shipping a narrow first use case, like prior auth packet assembly or coding suggestion for a single specialty, then expanding once the error profile is understood.

We’ve seen a consistent pattern across healthcare software builds: the first version fails because the team overestimates model certainty and underestimates payer variability. The fix is to treat payer rules as a living product, not a one-time integration. AST’s pod teams typically handle this by pairing backend, QA, and DevOps early, so every model update, rules change, and workflow adjustment is testable before it reaches production.

We also build for observability from the beginning: confidence scores, extraction accuracy by document type, denial reason clustering, turnaround time, and human override rates. Without that telemetry, “automation” becomes guesswork with a nicer interface. With it, you can see exactly which payer, code family, or specialty is inflating rework.

Where the buyer gets real ROI

The strongest ROI usually comes from the workflows with three traits: high volume, repetitive rules, and expensive delays. Prior auth for imaging, durable medical equipment, sleep medicine, oncology support services, and specialty referrals often fit this pattern. Coding assistance also pays off when documentation is dense and coders spend time searching for missing specificity rather than applying real judgment.

We have seen this in clinical software environments where operational throughput matters as much as clinical accuracy. AST currently supports 160+ respiratory care facilities through clinical software products, and the lesson is straightforward: if the workflow is slow, the software must reduce touches, not add another dashboard. Teams care less about “AI” and more about whether the request gets approved without a second pass.

A decision framework for building this correctly

1. Choose one workflow. Start with a narrow, measurable slice such as prior auth for one service line or coding support for one specialty.
2. Map every handoff. Document the exact sequence from intake to submission, including who touches the chart, which systems are involved, and where delays happen.
3. Decide the automation boundary. Use AI for extraction, summarization, and drafting; use deterministic logic for payer rules, thresholds, and submission controls.
4. Instrument outcomes. Track first-pass yield, manual touch rate, denial rate, turnaround time, and override reasons before scaling.
5. Hard-stop on exceptions. Route low-confidence cases to humans and keep the system from submitting incomplete or unsupported requests.

What leaders should ask before they buy

Do not ask whether the vendor uses AI. Ask how they test model drift, how they handle policy changes, how they version prompts and rules, and how they prove that automation lowers rework instead of moving it downstream. Ask whether their system can integrate with your intake sources, EHR, call center, document store, and clearinghouse without brittle custom scripts.

Also ask who owns the workflow after go-live. In healthcare, the best systems are never “done.” Payers change policies, specialties expand, and documentation formats shift. The product must be built to evolve with that reality.

AST builds RCM automation the way healthcare teams actually need it

We do not treat revenue cycle as a demo problem. We treat it as an operational system with failure modes, compliance constraints, and real dollar impact. That is why our team builds for throughput, traceability, and exception handling first. If the workflow cannot survive payer variation, it is not ready for production.