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

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.