# Can Oncology Workflows Run Without Human Touch? - Anant Shankhdhar, Risa Labs

Anant Shankhdhar

AI Engineer World's Fair 2026

[Talk page](https://ai.engineer/talks/_cVfz88_j7A-oncology-workflows-run-without-human-touch) · [Video](https://www.youtube.com/watch?v=_cVfz88_j7A)

## Can Oncology Workflows Run Without Human Touch?

RISA’s oncology workflow combines deterministic coverage checks, corroborated authorization evidence, and clinical reasoning to identify which orders can proceed without human review.

### Which orders can proceed without review?

[0:12](https://www.youtube.com/watch?v=_cVfz88_j7A&t=12s)

An oncology practice receives an order for a patient’s cancer drugs. Before filing any necessary prior authorizations, it must verify the patient’s insurance eligibility and benefits, then determine the authorization status of each drug. Automating those steps does not automatically eliminate review: at RISA, bots already performed the work, but a human still checked orders before submission.

Each drug follows one of three pathways:

| Status | Meaning |
| --- | --- |
| No auth required (NAR) | The drug does not require prior authorization. |
| Auth on file | An existing authorization covers a defined period. |
| Auth required | Authorization must be obtained. |

Anant Shankhdhar’s task was to identify which orders could proceed directly toward submission without that final human verification, and then build the path that would carry them through. **The goal was selective no-touch processing, with confidence determining which cases qualified.**

![Flowchart showing order intake, eligibility and benefits, order determination, authorization status branches, write-back and document upload, and completion. A note describes moving human involvement toward exception handling.](https://ai.engineer/api/talk-essay-media/d6c7784c8879cf8aafb2515a76354e346488aa579281a0721bc6d2f2f3177fce)

The prior-auth lifecycle, from order intake through status routing and write-back.

### Normalize coverage before making decisions

[2:04](https://www.youtube.com/watch?v=_cVfz88_j7A&t=124s)

The workflow is divided among four agents, each responsible for a distinct decision or operation:

- **Eligibility and benefits verification (EV):** Fetch patient coverage information and determine whether the order can advance.
- **Authorization:** Determine whether each drug needs authorization or already has it.
- **Medical necessity:** Evaluate the clinical basis for drugs that require authorization.
- **Submission:** Send the assembled information to the payer.

This division separates insurance eligibility, authorization status, and clinical justification instead of asking one agent to decide everything at once.

The first obstacle is access to evidence. Insurance details are scattered across portals, APIs, and documents. RISA built a unified service that connects to different payer sources and returns a normalized result. A deterministic decision engine then uses that result to flag cases that cannot proceed.

The coverage path works in three steps:

1. A **coverage orchestrator** selects either an API integration or robotic process automation (RPA) for the relevant payer source.
2. The selected integration retrieves the information and produces a fixed coverage-result format.
3. The deterministic engine checks whether coverage is active. Passing cases advance; failed cases stop at this gate.

Normalization makes the downstream decision independent of how the information was retrieved. But it leaves another problem upstream: building a separate automation for every payer portal does not scale easily.

### Generate portal configurations from reusable actions

[4:40](https://www.youtube.com/watch?v=_cVfz88_j7A&t=280s)

To reduce the work of adding portals, RISA created a repository of common and custom RPA actions. An LLM-based configuration generator uses those actions to build the configuration for a particular portal. Shankhdhar reports that this significantly reduced development time, without giving a numerical benchmark. The reusable unit is the action; the portal-specific output is the configuration that combines those actions into an automation.

Generating an integration does not make it durable. Portal automations can break at runtime, so RISA also added a **self-healing loop** that identifies broken automations during production hours and attempts to mitigate them. Shankhdhar presents this as a way to prevent failures, rather than providing a measured reliability guarantee. Together, reusable actions, configuration generation, and runtime repair support the retrieval layer; the eligibility gate still determines whether the resulting case can advance.

![Coverage orchestrator connects to API and RPA paths, then a coverage result branching to active coverage or not eligible/error. Three cards below describe reusable actions, LLM-generated payer configurations, and self-healing.](https://ai.engineer/api/talk-essay-media/5536ff66da74fd5e92f96be304ef988b2f2ab5b38422ac12b611d2a93ab006c9)

Coverage verification routes through API or RPA paths to an active-coverage or flagged result.

### Why extracting a status was not enough

[5:53](https://www.youtube.com/watch?v=_cVfz88_j7A&t=353s)

After eligibility verification, the next opportunity was to resolve drugs that already had authorization or did not require it. Either status could remove human oversight from that part of an order. RISA initially built a simple extraction pipeline: read the patient’s notes, use an LLM to classify the drugs, and default to **authorization required**.

Two problems kept this pipeline from removing review. First, the notes sometimes lacked enough information, causing extraction errors. Second, LLM extraction was nondeterministic, so the resulting classifications could not be trusted blindly. It could make reviewers faster, but they still needed to check its work.

The next step was to change what supported the decision. If the model classified a drug as NAR or auth on file, the pipeline needed evidence backing that classification. **A status extracted from notes became a claim to corroborate before bypassing review.**

### Corroborate authorization status across sources

[7:47](https://www.youtube.com/watch?v=_cVfz88_j7A&t=467s)

For auth-on-file cases, previous patient workflows supplied an additional source: **authorization letters**. These recorded earlier authorizations for the patient’s drugs. Where the notes and letters agreed, the system had stronger support for treating a drug as already authorized than it had from notes alone.

For NAR cases, the additional evidence came from payer portals and documents describing which drugs did not require authorization during a given period. RISA combined portal checks and LLM extraction to populate a **payer-rule knowledge base**, implemented as a SQL database. These rules concern whether authorization is required; they are not a determination that a drug is uncovered.

The pipeline reconciles those sources with the extracted statuses. Agreement gives the system more confidence in a NAR or auth-on-file classification, while configurable controls let the team restrict affected cases if problems arise. Corroboration supports a decision to automate; it does not establish that every classification is correct.

This produced the first complete orders that could avoid manual authorization review. Resolving one drug removes work from part of an order. When every drug in an order is either corroborated NAR or already authorized, there is no remaining drug that needs a new authorization. The drug-level shortcut therefore becomes an order-level no-touch path.

### Keep payer rules tied to their applicable period

[9:59](https://www.youtube.com/watch?v=_cVfz88_j7A&t=599s)

The payer-rule database needs more than a permanent yes-or-no label for each drug. Its source documents describe rules over time. RISA uses configurable LLM extraction for different document types to obtain drug-wise constraints: which payer the rule concerns, how the drug is treated for authorization purposes, and the period during which that treatment applies.

Document extraction is supplemented by historical information about how a particular organization handles a drug, plus regular portal checks. These inputs feed the same knowledge base, giving authorization classification evidence beyond the patient’s notes.

![Diagram titled Building the Payer Rule Knowledge Base shows payer documents passing through an LLM into drug-wise constraints, with historical payer documents and regular portal checks also feeding the database.](https://ai.engineer/api/talk-essay-media/4819bf8cb0bf57ff42e2c588d438dc0397cb56e7b9c856b45e8bc75fd8b86bda)

Payer documents, historical information, and portal checks feed a drug-wise constraints database.

At this stage, the pipeline could reject or flag unverifiable cases at the eligibility gate, then use corroborated drug statuses to resolve a subset of the remaining orders. It had removed review from cases whose authorization status could be established from available information. The unresolved category was drugs that actually required authorization.

### Answer clinical questions with supporting and contradictory facts

[11:34](https://www.youtube.com/watch?v=_cVfz88_j7A&t=694s)

Drugs that require authorization introduce a different task. The earlier paths established an existing status from evidence; these cases need clinical reasoning about whether the patient meets the relevant requirements. They also need supporting evidence for the answers submitted to the payer. The **medical necessity agent** handles simple and complex patient-specific questions, attaches a confidence score to each answer, and escalates cases that need a clinician.

For each new order, the agent follows an evidence-to-answer sequence:

1. Read the patient’s notes and the policy criteria for processing the drug.
2. Use those criteria to query a **patient medical graph** containing extracted biomarkers.
3. Retrieve the relevant biomarkers and information about the patient’s condition.
4. Pass that information to an LLM to produce an answered questionnaire, including both supportive and contradictory facts.

The policy criteria direct retrieval toward the clinical questions that must be answered. Preserving contradictory facts also keeps the output from becoming only a collection of evidence in favor of authorization.

Cases advance when the agent has relevant information and can answer with sufficient confidence. When the evidence is insufficient, they remain for human escalation. The talk does not specify a confidence threshold or calibration method, so this is an architectural routing boundary rather than a reproducible numerical decision rule.

### Carry qualified cases through to submission

[13:51](https://www.youtube.com/watch?v=_cVfz88_j7A&t=831s)

The completed flow starts with patient data and eligibility verification, flags ineligible orders, and classifies the drugs in the remaining orders. Corroborated NAR and existing authorizations take the shortcut; drugs that need authorization undergo medical necessity evaluation. Cases that do not meet those requirements move to review. The system then assembles the information for submission to the payer.

The submission agent uses an integration approach similar to the EV agent: payer-specific integrations built from LLM-driven configurations and the shared repository of tools. The same strategy that retrieves information at the beginning of the workflow supports sending it back at the end.

The complete graph shows the selectively automated paths in green, alongside failure and review branches. Some drugs avoid medical necessity evaluation because their authorization status is already resolved; others reach submission after that evaluation. Human review remains an explicit outcome for cases that do not qualify for the automated path.

![Flowchart connects patient data fetching, eligibility verification, authorization determination, medical necessity, and submission. Green paths include no-auth-needed and already-authorized shortcuts; red branches show eligibility failure and review outcomes.](https://ai.engineer/api/talk-essay-media/837155798eb6fa4e78a3d4a97cb059e0396c2d7daa478c1de547e38b5c438aa2)

The complete pipeline shows authorization shortcuts, medical necessity evaluation, submission, and review branches.

### Extend the agents beyond prior authorization

[15:27](https://www.youtube.com/watch?v=_cVfz88_j7A&t=927s)

Although these agents were initially built for this authorization workflow, RISA has reused them across other workflows. The medical necessity agent, for example, has been generalized to answer patient-specific questions outside this original use case. The other agents have also been extended for broader use. Their responsibilities—retrieving coverage, establishing authorization status, answering clinical questions, and interacting with payers—provide reusable boundaries.

Shankhdhar reports that the share of orders handled without human touch is growing, without specifying a percentage or evaluation period. That expansion follows the order in which the system was built: deterministic checks first, multiple sources of evidence to strengthen authorization decisions, self-healing to support portal automation, and finally a reasoning layer for cases that truly require authorization. **Human review is removed where the workflow has enough evidence to proceed, while unresolved cases retain a route to review.**

## Resources

- [Multi-Agent System for Medical Necessity Justification](https://aclanthology.org/2024.bionlp-1.4/) — RISA researchers describe evidence retrieval, checklist judgments, and aggregation for medical necessity assessment.
- [RISA API Hub](https://www.risalabs.ai/risa-api-hub) — Public overview of RISA's workflow APIs with links to documentation and a sandbox.
- [UnitedHealthcare's 2026 Administrative Guide](https://ams-gateway.uhcprovider.com/content/dam/provider/docs/public/admin-guides/2026-UHC-Administrative-Guide.pdf) — Payer guidance covering authorization requirements, validity periods, coverage, and payment conditions.

## Slides

### Automating oncology workflows, end-to-end

RISA describes a pipeline that moves from patient data to payer submission, clearing routine prior-authorization cases without human touch and routing harder cases to clinical reasoning.

[0:04](https://www.youtube.com/watch?v=_cVfz88_j7A&t=4s) [Title slide describing prior authorization agents, with metrics for hospital sites, patients, agents, and submissions per hour.](https://assets.ai.engineer/sites/aiecode2025/sha256/06c8118f482a3ae1a13911a66bf37440d22ca3ddc419b6bf1bd10c49d7deb62b.webp)

Automating oncology workflows, end-to-end

AI AGENTS FOR PRIOR AUTHORIZATION

From patient data to payer submission — a pipeline of specialized agents that clears the routine cases with zero human touch, and routes the hard ones to clinical reasoning.

50+ HOSPITAL SITES
100K+ PATIENTS
4 AI AGENTS
1000s SUBMISSIONS / HR

RISA
ONCOLOGY OPERATIONS · AI

### The prior-auth lifecycle

Orders move from intake and eligibility checks through authorization status paths to write-back and completion. A human reviews orders before submission; the goal is to handle only exceptions.

[0:11](https://www.youtube.com/watch?v=_cVfz88_j7A&t=11s) [Flowchart tracing orders from intake and eligibility through determination, status paths, write-back, and completion.](https://assets.ai.engineer/sites/aiecode2025/sha256/7375ae6723e28fc9424747fcf33db12002e79ae2c317123a6e7c3315254c4714.webp)

RISA
ORIENTATION

THE BIG PICTURE
The prior-auth lifecycle

Orders arrive from each practice's group inbox. RISA pre-processes and pre-classifies them, a Document Annotator validates on the medonc-dashboard, and RPA bots write results back to OncoEMR — submitting to payer portals when needed.

STEP 1
Order Intake & Worklist

STEP 2
Eligibility & Benefits (EV / BV)

STEP 3
Order Determination & Processing

Status path
NAR · No auth required
Auth on file
Auth required → submit
Misc (PRMA, oral, POI)

STEP 4
Write-back + Doc Upload

✓ Mark completed

MENTAL MODEL
The bot works each order before a human arrives — the annotator starts from a pre-assigned status and mostly validates. The goal is to shrink the “human validates” surface toward “human exception-handles only.”

### One graph, four agents

Patient data flows through four agents for eligibility verification, authorization determination, medical necessity, and submission. The slide says cases escalate to a human when none of the agents can make the decision.

[2:02](https://www.youtube.com/watch?v=_cVfz88_j7A&t=122s) [A sequence from patient data fetching through eligibility verification, authorization determination, medical necessity, and submission.](https://assets.ai.engineer/sites/aiecode2025/sha256/bbba697b5eb84536ae61d45a97d684bfd866014e84f62807396950be4dd51603.webp)

RISA
THE WORKFLOW

THE DECISION GRAPH

Zoom in: one graph, four agents.

Inside Order Determination, every order runs the same directed graph. Each agent owns one decision — we only escalate to a human when none of them can. We'll build it up, node by node.

INPUT
Patient Data Fetching

EV AGENT
Eligibility Verification

AUTH AGENT
Auth Determination

NECESSITY AGENT
Medical Necessity

SUBMISSION AGENT
Submission

### Processing orders without a human in the loop

A unified service normalizes information from payer portals and APIs. A deterministic engine clears straightforward cases, while specialized agents handle the rest.

[3:30](https://www.youtube.com/watch?v=_cVfz88_j7A&t=210s) [Two panels describe scattered insurance information and an approach using a unified service, deterministic decisions, and specialized agents.](https://assets.ai.engineer/sites/aiecode2025/sha256/96704ccc55e3f390e3fb5d54f737d76fae5b49ef352cb39c1e42f28ff871ee86.webp)

RISA
THE PROBLEM

THE CHALLENGE
How do we process these orders without a human in the loop?

WHY IT'S HARD
Insurance details are scattered across dozens of payer portals and APIs, no single source of truth.

Coverage lapses and edge cases are common, and historically every order was reviewed by hand.

THE APPROACH
A unified service that connects to every payer source and normalizes what it finds.

A deterministic decision engine clears the clear-cut cases first specialized agents handle the rest.

### Eligibility & coverage verification

A coverage orchestrator selects an API or RPA path; active coverage proceeds to PA, while failures are flagged. Reusable actions, generated configs and self-healing help scale portal automation.

[3:52](https://www.youtube.com/watch?v=_cVfz88_j7A&t=232s) [Coverage orchestration routes through API or RPA to a coverage result, with active coverage proceeding and failures flagged. Three cards describe scaling the automation.](https://assets.ai.engineer/sites/aiecode2025/sha256/4ab0daa714ba85171ef8aa9113648e5ebfc4681d96af6c80b0aa1c2e50575348.webp)

RISA
01 · ELIGIBILITY

AGENT 01 — EV AGENT
Eligibility & coverage verification

Coverage Orchestrator → API path / RPA path → Coverage Result
Active coverage → proceed to PA
Not eligible / error → flagged

How do I scale this?

ACTION REPOSITORY
A library of reusable automation actions that already covers most payer portals.

LLM CONFIG GEN
Per-payer configs are generated by an LLM, so new portals onboard without bespoke code.

SELF-HEALING
When a portal shifts, the agent repairs its own flow — preventing production failures.

### Verify eligibility

Patient data moves to eligibility verification. Eligible patients proceed to prior authorization; failed eligibility stops the workflow and is flagged out of the pipeline.

[5:36](https://www.youtube.com/watch?v=_cVfz88_j7A&t=336s) [Patient data flows to eligibility verification; failed eligibility is flagged.](https://assets.ai.engineer/sites/aiecode2025/sha256/a033079607ef02c60861a454fd12b22e5e466562f2590cbbb3be2beb6f397a6f.webp)

Verify eligibility

RISA
BUILDING THE GRAPH — 1 / 4
THE WORKFLOW

Patient Data Fetching → Eligibility Verification
Eligibility Verification → Eligibility failed

Eligible patients proceed to prior auth — coverage failures are flagged out of the pipeline.

### Which drugs actually need auth?

An LLM classifies drugs from patient notes as requiring authorization, needing none, or already authorized. Missing details and uncertain extraction mean the results still need human review.

[5:53](https://www.youtube.com/watch?v=_cVfz88_j7A&t=353s) [Patient notes feed an extraction step that identifies authorization status; a callout explains gaps and uncertainty in the notes.](https://assets.ai.engineer/sites/aiecode2025/sha256/abed6a2ad0a241e3bd4bf8f745c18458ce2880d57411a33dc7b9e461cfd9a604.webp)

RISA
02 · AUTH STATUS

AGENT 02 — AUTH-ON-FILE
Which drugs actually need auth?

Patient notes → LLM extraction →
Auth required
No auth required
Auth on file

THE CATCH
Notes alone give us no confidence signal, and some drug statuses simply aren't written down. We can't go no-touch on extraction we can't trust.

Furthermore, details of the patient are scattered, a note might contain the information on drug statuses, but might miss out on other things such as number of visits. Some other documents contain information on what drugs does a payer not authorise.

### Confidence comes from combining evidence

Clinical notes, authorization letters and payer rules are reconciled to establish each drug’s auth status with confidence. Drugs needing no auth or already authorized can clear with zero human touch.

[7:49](https://www.youtube.com/watch?v=_cVfz88_j7A&t=469s) [Clinical notes, authorization letters, and payer rules are reconciled to produce drug authorization status with confidence.](https://assets.ai.engineer/sites/aiecode2025/sha256/5af8ca27f993d28c6ac0c8e21fe7139bfc094c5ba40c634f24659bbe910cc4ef.webp)

RISA
02 · AUTH STATUS

AGENT 02 — EVIDENCE RECONCILIATION
Confidence comes from combining evidence

Clinical notes
Auth letters
Payer-rule knowledge base
→ Reconcile evidence → Auth status per drug + confidence

THE PAYOFF
Drugs that need no auth — or are already authorized — clear with zero human touch. Missing evidence in one source is recovered from another.

HOW THE KB IS BUILT
payer docs → AI extraction → human review → versioned rules

### Determine auth status

After eligibility verification, the workflow determines each drug’s authorization status. Drugs needing no authorization or already authorized take no-touch shortcuts; the rest continue.

[9:58](https://www.youtube.com/watch?v=_cVfz88_j7A&t=598s) [The workflow adds authorization determination after eligibility, with no-auth-needed and already-authorized outcomes.](https://assets.ai.engineer/sites/aiecode2025/sha256/1c01739b69f42a10e3919ca525a33789687cc2ae9a9fd8552f9acd82ad53d694.webp)

Determine auth status

RISA
THE WORKFLOW
BUILDING THE GRAPH — 2 / 4

Patient Data Fetching
Eligibility Verification
Auth Determination
No auth needed
Already authorized
Eligibility failed

Each drug is routed — no auth needed and already-authorized are no-touch shortcuts; only the rest continue.

### Some decisions need clinical reasoning

After deterministic checks clear straightforward orders, drugs requiring authorization still need a patient-specific eligibility judgment and supporting evidence.

[11:32](https://www.youtube.com/watch?v=_cVfz88_j7A&t=692s) [Slide explains that assessing medical eligibility requires case-by-case clinical reasoning.](https://assets.ai.engineer/sites/aiecode2025/sha256/f44e51d6599ccdc49e7064ef7e63457408e42f9e1f8303aae63a6eeb17be51da.webp)

Some decisions need clinical reasoning.

THE HARD CASES

Deterministic rules clear the clear-cut orders. What remains hinges on whether a patient is medically eligible for the drug — case-by-case judgment that demands real medical knowledge and a strong reasoning layer.

RISA
03 · MEDICAL NECESSITY

### A reasoning layer for the long tail

The medical necessity agent combines policy criteria, patient notes, and a patient medical graph to answer clinical questions. It assigns confidence scores and escalates cases with insufficient information to a clinician.

[12:19](https://www.youtube.com/watch?v=_cVfz88_j7A&t=739s) [Diagram shows policy criteria, patient notes and a medical graph informing confidence reconciliation and an answered questionnaire.](https://assets.ai.engineer/sites/aiecode2025/sha256/3fcb43d6b0b3f986895991059ff50ebd11ffb8473a957e4835ffd14fe3cc0c06.webp)

A reasoning layer for the long tail

RISA
AGENT 03 — MEDICAL NECESSITY
03 · MEDICAL NECESSITY

PA order + questions
Reads policy criteria
Reads patient notes
Queries patient medical graph
Reconcile confidence
Answered questionnaire

It answers simple and complex clinical questions per patient, attaching a confidence score to every answer — so we only escalate the ones that truly need a clinician.

• Himanshu Gautam Pandey, Akhil Amod, and Shivang Kumar. 2024. Advancing Healthcare Automation: Multi-Agent System for Medical Necessity Justification. In Proceedings of the 23rd Workshop on Biomedical Natural Language Processing, pages 39–49, Bangkok, Thailand. Association for Computational Linguistics.

### Evaluate medical necessity

After eligibility and authorization checks, required drugs are evaluated against medical necessity criteria. Cases that meet the criteria continue; those that do not go to human review.

[13:49](https://www.youtube.com/watch?v=_cVfz88_j7A&t=829s) [Workflow adds medical necessity evaluation after authorization determination, with unmet criteria sent for review.](https://assets.ai.engineer/sites/aiecode2025/sha256/b08184f24e0856dd1ccc0dd1d33ffe21c34b6587cc70b2479647e5665eee49d8.webp)

Evaluate medical necessity

RISA
BUILDING THE GRAPH — 3 / 4
THE WORKFLOW

Patient Data Fetching → Eligibility Verification → Auth Determination → Medical Necessity

Eligibility failed
No auth needed
Already authorized
Not met → review

Required drugs are checked against necessity criteria — Met continues; Not Met is the only case that reaches a human.

### Assemble and submit

The submission agent assembles an approved PA using evidence gathered by upstream agents, then submits it through a portal. The outcome is either submission to the payer or review.

[14:30](https://www.youtube.com/watch?v=_cVfz88_j7A&t=870s) [Diagram shows an approved prior authorization assembled into a packet and submitted through a portal, with submission or review outcomes.](https://assets.ai.engineer/sites/aiecode2025/sha256/dff880f207c26331a3fbe073cdd869f35d4b580d7fd9212bf1379886571988d6.webp)

Assemble and submit

RISA
AGENT 04 — SUBMISSION
04 · SUBMISSION

Approved PA → Assemble submission packet → Submit via portal → Submitted to payer / Needs review

The packet is built from everything the upstream agents already gathered — the submission step inherits their evidence rather than re-deriving it.

### End-to-end, no human in the loop

The green path moves cases from eligibility through authorization and submission without human touch. Cases needing no new authorization can bypass medical necessity; failed checks and other exceptions go to review.

[14:55](https://www.youtube.com/watch?v=_cVfz88_j7A&t=895s) [Complete workflow highlights automated paths to submission and exception paths for review.](https://assets.ai.engineer/sites/aiecode2025/sha256/2727929f7c4d652f03426b3e302264595ab7c799d52f502f0abfdb940a28ed14.webp)

RISA
THE WORKFLOW

THE COMPLETE PIPELINE — 4 / 4

End-to-end, no human in the loop

No auth needed
Already authorized

Patient Data Fetching
Eligibility Verification
Auth Determination
Medical Necessity
Submission
Submitted to payer
Needs review

Eligibility failed
Not met → review

Green is the no-touch path — patient data to payer submission, fully automated. A human only ever sees the genuine exceptions.

### No-touch on a growing share of every order

Risa runs deterministic checks first and uses agents when rules cannot decide. Multiple evidence sources, self-healing automation, and clinical reasoning support a growing no-touch share of orders.

[15:55](https://www.youtube.com/watch?v=_cVfz88_j7A&t=955s) [Conclusion slide summarizing deterministic checks, multi-source evidence, self-healing automation, and a reasoning layer for clinical cases.](https://assets.ai.engineer/sites/aiecode2025/sha256/d8603d0dc8fde14dba23e526e93aaa065ede2177069decde17ab34b3f1398242.webp)

RISA
IMPACT

WHAT WE LEARNED

No-touch on a growing share of every order.

01 Deterministic checks first — agents only for what rules can't decide.
02 Multi-source evidence beats single-source confidence.
03 Self-healing automations survive constant portal drift.
04 A real reasoning layer handles the clinical long tail.

Thank you.
20+ HOSPITALS · 100K+ PATIENTS · 4 AGENTS

## Full transcript

[0:00](https://www.youtube.com/watch?v=_cVfz88_j7A&t=0s) Hi, everyone. Uh, my name is Anant Shankhdhar. I am an AI engineer at RISA, and I'll be talking about oncol-- automating oncology workflows from end to end.

[0:12](https://www.youtube.com/watch?v=_cVfz88_j7A&t=12s) So at RISA, we are automating various workflows in oncology. One of such workflows is prior authorizations, where we, uh, file for authorizations for drugs for cancer patients. So, uh, I'll give a brief overview about the workflow before we m-move further in the call.

[0:31](https://www.youtube.com/watch?v=_cVfz88_j7A&t=31s) So, the first step is that we intake the orders that we get on a daily basis. The second step is we verify whether the patient is actually very, uh, eligible for getting the drugs based on the amount that they have in insurance available with them.

[0:46](https://www.youtube.com/watch?v=_cVfz88_j7A&t=46s) This is called eligibility and benefits ve-verification. Uh, next, uh, we determine what all drugs in the-- for the patient require authorization. So, a drug can basically fall into one of the following pathways.

[1:02](https://www.youtube.com/watch?v=_cVfz88_j7A&t=62s) So one is NAR, which is no auth required. Basically, the drug does not re-require authorization. Another can be that the authorization has already happened for the drug for a time period, which is called auth on file.

[1:14](https://www.youtube.com/watch?v=_cVfz88_j7A&t=74s) And the third is auth required, which means that the authorization needs to be performed for this drug. So yeah, this is the workflow. Uh, I was, uh... So although our bots run, uh, and perform these steps, finally a human review is required, you know, before submitting all these orders.

[1:34](https://www.youtube.com/watch?v=_cVfz88_j7A&t=94s) I was ta, uh, tasked with the cha-- uh, with the problem to run, uh, some of these orders without any sort of human touch, uh,

[1:45](https://www.youtube.com/watch?v=_cVfz88_j7A&t=105s) directly towards submission, which means I need to, uh, confidently identify which all orders can be proceeded without any human verification and then build the entire flow for them as well.

[1:58](https://www.youtube.com/watch?v=_cVfz88_j7A&t=118s) So confidence is a key metric that we were working towards.

[2:04](https://www.youtube.com/watch?v=_cVfz88_j7A&t=124s) So yeah. Uh, how we did this was using four agents, uh, namely EV agent, auth agent, necessity agent, and submission agent. EV agent is for el-eligibility and benefits verification, so basically fetching the patient data and determining whether it is, uh, fine for moving forward.

[2:24](https://www.youtube.com/watch?v=_cVfz88_j7A&t=144s) Auth agent determines the, uh, ca-- type of the status of the drug, whether authorization is required or not. Uh, and the necessity agent is the clinical brain of syst-- of the system.

[2:36](https://www.youtube.com/watch?v=_cVfz88_j7A&t=156s) So for the cases where authorization is required, we determine whether it has to be done on-- whe-whether it is right for the patient based on his vitals or not.

[2:46](https://www.youtube.com/watch?v=_cVfz88_j7A&t=166s) And finally, we move towards submission. So, uh, starting with the first step, how do we do this without any human in the loop? So, one of the problems that we have here is that insurance details, insurance documents, everything is, uh, scattered across dozens of portals, APIs, and documents,

[3:09](https://www.youtube.com/watch?v=_cVfz88_j7A&t=189s) and it is difficult to find that information at one place. So in order, uh, to, in order to start with our pipeline, uh, we

[3:20](https://www.youtube.com/watch?v=_cVfz88_j7A&t=200s) need to get information from various portals as well as APIs. In order to do so, we built a unified service that connects to different payer sources and, uh, gives the output in a normalized uniform format, which we can use for da-- uh, processing further.

[3:38](https://www.youtube.com/watch?v=_cVfz88_j7A&t=218s) And we also added a de-deterministic decision engine to flag the cases which would not move forward, thus, uh, deterministically, uh, fixing some of the orders without any human in the loop.

[3:52](https://www.youtube.com/watch?v=_cVfz88_j7A&t=232s) So here's how it works. So we have a coverage orchestrator, which determines whether, uh, the patient will go for the API or the RPA path. RPA is basically the automation.

[4:02](https://www.youtube.com/watch?v=_cVfz88_j7A&t=242s) Uh, we, uh, perform the actions for the RPA or call the API and get the output in a fixed coverage result format, which we then pass to our deterministic engine to determine whether the coverage is active or not.

[4:19](https://www.youtube.com/watch?v=_cVfz88_j7A&t=259s) If it is, we move it fur-further in the chain, else we stop that right there. Now, one of the problems we saw here was that, uh, if we have to build this, then we will need to make custom integrations for different sorts of portals, which is not, not a very scalable, uh, process.

[4:40](https://www.youtube.com/watch?v=_cVfz88_j7A&t=280s) But how we tackled it was that we used LLMs in the roo-loop. So first of all, we made a huge repository of custom actions as well as popular actions that are required in, uh, to build RPAs.

[4:55](https://www.youtube.com/watch?v=_cVfz88_j7A&t=295s) Then we built a LLM-based config generation, which performs these actions and builds the config for a ca-- uh, for a portal to run on, uh, which, uh, fix-- which reduces our development time significantly.

[5:12](https://www.youtube.com/watch?v=_cVfz88_j7A&t=312s) And finally, uh, these, uh, automations are fragile, so it may happen that they break during the runtime. For this, we have a self-healing loop, which identifies these cases during production hours and then mitigates them, so tha-thus preventing any sort of failures.

[5:32](https://www.youtube.com/watch?v=_cVfz88_j7A&t=332s) So yeah, that is the first step. Uh, once we have done this, we move further in our chain. So as we can see our diagram, the graph, uh, the patient data is fetched.

[5:44](https://www.youtube.com/watch?v=_cVfz88_j7A&t=344s) We perform the eligibility verification. We see if it is fine or not. If it failed, we stop there, else we move forward.

[5:53](https://www.youtube.com/watch?v=_cVfz88_j7A&t=353s) So yeah. Moving forward, uh, the next step was that deta-- uh, was to see, uh, what all drugs require authorization. So if I have to

[6:08](https://www.youtube.com/watch?v=_cVfz88_j7A&t=368s) ... uh, remove humans from the loop, one simple case that I saw was that, uh, if a drug has already been authorized, uh, that is the authorization is on file, or if the authorization is not required, then we can partly solve the order.

[6:25](https://www.youtube.com/watch?v=_cVfz88_j7A&t=385s) That is, that we do not need human oversight on that part of the order.

[6:30](https://www.youtube.com/watch?v=_cVfz88_j7A&t=390s) Uh, so yeah. Uh, so as the first step, we built a simple LLM extraction pipeline, which takes in patients' notes, performs LLMs extraction, and categorizes the drugs into these types, the default being that authorization is required.

[6:47](https://www.youtube.com/watch?v=_cVfz88_j7A&t=407s) However, uh, yeah, so we thought that this should-- would work, but we faced some issues here as well. So one popular issue was that, uh, the n-notes that we were using did not have enough data, which means that it was performing some, some errors.

[7:07](https://www.youtube.com/watch?v=_cVfz88_j7A&t=427s) Uh, also, LLM, uh, extraction is sort of an indes-- uh, indeterministic process. That means that whatever outputs we get from here cannot be blindly trusted. So we still need a human to review all these things.

[7:24](https://www.youtube.com/watch?v=_cVfz88_j7A&t=444s) It might improve the efficiency, but it will not eliminate the human. So in order to do so, uh, we thought that what if I add more evidence to it?

[7:36](https://www.youtube.com/watch?v=_cVfz88_j7A&t=456s) So if the LLM is saying that a drug is no auth required, then I have some information backing that. I can say that confidently or for the auth on file cases.

[7:47](https://www.youtube.com/watch?v=_cVfz88_j7A&t=467s) In order-- Uh, yeah. So in order to do so, we aut-- we leveraged two other data sources. So one was the authorization letters. So this was basically the previous information.

[8:00](https://www.youtube.com/watch?v=_cVfz88_j7A&t=480s) So across the previous runs that a given patient has, they have authorization letters available, which shows that these drugs were actually authorized. So now, instead of just having one source, I have two sources that give me the same information, and wherever they concur, I can say with confidence that this drug has already been authorized.

[8:21](https://www.youtube.com/watch?v=_cVfz88_j7A&t=501s) Second is the NAR case, the no auth required case. So here, uh, we found some other resources wherein from the portals or from some documents, we could find out that on a monthly basis, which are the drugs that the payer does not work for, the insurance does not work for, basically.

[8:41](https://www.youtube.com/watch?v=_cVfz88_j7A&t=521s) So, uh, we use that information to build a payer rule knowledge base, which is basically a SQL database, uh, which was made from portal checks as well as LLM extractions.

[8:54](https://www.youtube.com/watch?v=_cVfz88_j7A&t=534s) So we us-use all this information, we reconcile the evidence, and we on-- extract the auth ca-- auth statuses with a higher confidence. So if from this pipeline, we get whether a drug is not authori-- not-- does not require authorization or is already authorized, we have a solid proof behind it, uh, and a higher confidence, uh, to say

[9:17](https://www.youtube.com/watch?v=_cVfz88_j7A&t=557s) that this is the case. And of course, all of this is configurable, so, uh, in order-- if some mishap happens, we always have a plug over the cases. So yeah.

[9:31](https://www.youtube.com/watch?v=_cVfz88_j7A&t=571s) Uh, another-- a good thing that happened from here is that we noticed that certain orders were completely eliminate-- we could eliminate certain orders completely from these two type of drugs, because it may happen that an order does not actually requi-require authorization at all.

[9:47](https://www.youtube.com/watch?v=_cVfz88_j7A&t=587s) The drugs are either n-uh, not requiring authorization or are actually authorized from before. So this enabled us no touch on a certain set of orders that we had.

[9:59](https://www.youtube.com/watch?v=_cVfz88_j7A&t=599s) Yeah. Uh, this slide gives a big, uh, small overview on how we build the payer rule knowledge base for the NAR cases. So, uh, we had the documents which had this information on a time-wise scale.

[10:14](https://www.youtube.com/watch?v=_cVfz88_j7A&t=614s) We built an L-LLM extraction, which uses LLMs, uh, which, uh, is configurable, so we can configure it on different types of documents, and we can perform the extraction, and we can get the drug wise constraint that for this payer, this is the ca-- this is how it will be treated for a period of time.

[10:36](https://www.youtube.com/watch?v=_cVfz88_j7A&t=636s) Another thing is that we leverage some historical information. That is, that we know that a certain organization, uh, treats this drug in a certain sort of way, so we store that information and us-use that as well.

[10:50](https://www.youtube.com/watch?v=_cVfz88_j7A&t=650s) Apart from this, we also use some regular portal checks to get this information.

[10:56](https://www.youtube.com/watch?v=_cVfz88_j7A&t=656s) So yeah. Uh, performing this movement moved our needle forward a bit. So now we had these deterministic checks along with our initial eligibility verification. So whatever were not verifiable were flagged out before, and whatever moved forward, we could determine these statuses for the drugs, and we were able to eliminate some of the orders from here.

[11:25](https://www.youtube.com/watch?v=_cVfz88_j7A&t=685s) So now that we've solved for two to- types of drugs, let's move forward.

[11:34](https://www.youtube.com/watch?v=_cVfz88_j7A&t=694s) So the next problem that we faced here was that some decisions do actually need clinical reasoning. So, so far, the drugs that we were, uh, we shifted to no touch were the ones where the information was di-directly available or indirectly available via another source.

[11:52](https://www.youtube.com/watch?v=_cVfz88_j7A&t=712s) But we did not need to perform any sort of reasoning over here or any sort of question answering. However, for the drugs that are actually auth required, we need to, uh, check whether the patient is actually eligible for them and also sup-- uh, give sort of supportive evidence from where we are answering this inform-- uh, we are

[12:15](https://www.youtube.com/watch?v=_cVfz88_j7A&t=735s) giving this information. So in order to do this, we built our third agent, which is the medical necessity agent. So the medical necessity agent answers simple and complex clinical questions per patient, uh, and attaches confidence score to any answer.

[12:32](https://www.youtube.com/watch?v=_cVfz88_j7A&t=752s) So we escalate only the ones that actually need a clinician. Uh, so we did a lot of work on this space. We actually have another-- uh, have a publication here as well, which I have mentioned.

[12:45](https://www.youtube.com/watch?v=_cVfz88_j7A&t=765s) So how this agent works is that, uh, we have a new order, and for every order, we read three things. So we read the patient notes, we read the policy criteria.

[12:56](https://www.youtube.com/watch?v=_cVfz88_j7A&t=776s) So the pol-- uh, policy criteria is basically the criteria that needs to be met in order for this drug to be processed further. Uh, we, uh... From this criteria, we query the patient medical graph, which is a graph of, uh, biomarkers that are extracted for a patient.

[13:14](https://www.youtube.com/watch?v=_cVfz88_j7A&t=794s) And we determine wha-what all biomarkers exist and what is the condition of this patient from here. And then we use this thing, these in-- this information and pass it to an LLM to get an answered que-questionnaire with all the supportive and contradictory facts.

[13:32](https://www.youtube.com/watch?v=_cVfz88_j7A&t=812s) So, uh, yeah. And, uh, if we have the relevant information or we are able to determine this with a higher confidence, we move this forward. And for the cases we do not have this enough information, uh, we move-- keep that for human escalation.

[13:51](https://www.youtube.com/watch?v=_cVfz88_j7A&t=831s) So yeah, uh, this is the next step. Uh, so after, uh, this medical, uh, ne-necessity validation, uh, we moved from, uh, f-the first step where we fetched the data.

[14:05](https://www.youtube.com/watch?v=_cVfz88_j7A&t=845s) We did the eligibility verification. We flagged the orders that were not eligible, moved the rest forward, extracted the no auth needed and already authorized letters, uh, got the, got, uh, the cases where we can move that without any human intervention, and then we did the medical necessity evaluation.

[14:26](https://www.youtube.com/watch?v=_cVfz88_j7A&t=866s) Uh, whatever was not met was also m-moved to review. So yeah. Finally, we assemble all this information, and then we submit it back to the payers.

[14:38](https://www.youtube.com/watch?v=_cVfz88_j7A&t=878s) So this is where our submission agent comes into place. The submission agent is pretty much similar as the EV agent. We have customized integrations for every sort of payer that we have, uh, which is built using an LLM-driven config as well as our repository of tools.

[14:57](https://www.youtube.com/watch?v=_cVfz88_j7A&t=897s) So yeah, this is the entire graph, uh, uh, that we got through the entire journey. Uh, so the green part shows the cases that we are going without human touch.

[15:08](https://www.youtube.com/watch?v=_cVfz88_j7A&t=908s) So whenever eligibility verification passes, uh, then, uh, en-enough information is found to not-- to prevent the drug from going for further medical ev-- necessity evaluation, then this, uh, medical necessity evaluation and the submission.

[15:27](https://www.youtube.com/watch?v=_cVfz88_j7A&t=927s) So yeah. Finally, I'd like to mention that, uh, these agents are also al-although built initially for this case, are being used across multiple workflows. Uh, we have extended the func-functionality to a more general one, uh, where the medical necessity agent can answer que-questions specific to any sort of workflow for the patient.

[15:52](https://www.youtube.com/watch?v=_cVfz88_j7A&t=952s) Uh, similarly for the other agents as well.

[15:56](https://www.youtube.com/watch?v=_cVfz88_j7A&t=956s) So yeah. Uh, as the conclusion, I would say the no touch is growing on the share of every order. Uh, so we started with deterministic checks, uh, agents only for the rules that-- where what rules can't decide.

[16:11](https://www.youtube.com/watch?v=_cVfz88_j7A&t=971s) Uh, we used multi-source of evidence, uh, to beat the single source of evidence to add confidence to our cases. Uh, we added self-healing in order to scale our RPAs.

[16:24](https://www.youtube.com/watch?v=_cVfz88_j7A&t=984s) And finally, we added the reasoning layer in order to deal with the cases where actually authri-- uh, auth-authorization is required. So yeah. Thanks for the, uh, yeah, thanks for your time.

[16:36](https://www.youtube.com/watch?v=_cVfz88_j7A&t=996s) Uh, yeah. Bye-bye.