Risa Labs combines four agents to automate oncology prior authorizations from intake through payer submission.
2
Deterministic checks and evidence from multiple sources let the system handle eligibility, no-authorization, and authorization-on-file cases without review.
3
A medical necessity agent answers clinical questions with supporting evidence and confidence scores, escalating cases when the available information is insufficient.
Summary
Anant Shankhdhar describes Risa Labs' attempt to remove human review from parts of oncology prior authorization. The workflow starts by collecting patient and insurance information from documents, payer portals, and APIs. An eligibility agent normalizes that information and stops cases that cannot proceed. The system then identifies drugs that need authorization, using prior authorization letters, payer rules, historical data, portal checks, and LLM extraction to increase confidence in no-authorization and authorization-on-file decisions. For cases that require clinical judgment, a medical necessity agent compares patient notes and a policy's criteria with a patient medical graph of biomarkers. It returns supporting and contradictory facts with a confidence score, while sending uncertain cases to a clinician. A submission agent completes payer-specific forms through custom integrations. Shankhdhar is direct about the boundary: automation grows by handling cases with sufficient evidence, while ambiguous clinical cases remain in human review.
Prior authorization is a chain of separate decisions
The workflow begins with daily order intake, followed by eligibility and benefits verification. The system then determines whether each drug is no authorization required, already authorized through an authorization-on-file status, or authorization required. Before this project, bots performed these steps but a person reviewed the orders before submission. Shankhdhar's task was to identify orders that could proceed directly to submission and build the full flow for them. He says confidence was the metric guiding this work.
A unified coverage service hides the differences between payer sources
Insurance information is spread across payer portals, APIs, and documents. Risa Labs built a service that connects to these sources and returns a normalized coverage result. A coverage orchestrator chooses an API path when an insurer provides an API and an RPA path when the information is available through a portal. A deterministic decision engine checks whether coverage is active. Cases that fail stop immediately, while passing cases continue through the workflow. This gives later agents a consistent input rather than separate logic for every source.
LLM-generated portal configurations reduce custom integration work
Payer portals require different integrations, which Shankhdhar describes as difficult to scale manually. Risa Labs created a repository of custom and commonly used actions for building browser automations. An LLM-based configuration generator combines those actions into a configuration for a particular portal. Because browser automations can break during production runs, the system also has a self-healing loop that identifies failures and mitigates them. The goal is to reduce development work while keeping payer-specific automations running.
Single-source drug extraction is too uncertain for no-touch decisions
An initial LLM extraction pipeline read patient notes and classified drugs as no authorization required, authorization on file, or authorization required. The notes often lacked enough information, and the extraction process was nondeterministic. That meant its output could improve efficiency but could not remove human review by itself. Shankhdhar changed the design by adding evidence from authorization letters and payer-specific rules. The system treats a drug status with greater confidence when independent sources agree.
A payer rule knowledge base combines documents, history, and portal checks
For no-authorization cases, Risa Labs built a payer rule knowledge base in a SQL database. Configurable LLM extraction reads documents that describe drug-specific constraints over time. The system also stores historical information about how an organization treats a drug and performs regular checks on payer portals. These sources are reconciled before the system extracts an authorization status. Shankhdhar says this produced proof strong enough to remove some orders from human review, especially when drugs were already authorized or did not require authorization.
Medical necessity requires patient-specific clinical reasoning
Cases marked authorization required need more than a directly available rule. The medical necessity agent reads the patient notes and the policy criteria for the drug. It queries a patient medical graph containing extracted biomarkers, then passes the relevant information to an LLM. The answer includes supporting and contradictory facts, along with a confidence score. Cases with enough relevant information continue automatically. Cases where the evidence is insufficient are kept for human escalation. The agent therefore narrows clinical review instead of treating every LLM answer as final.
The submission agent completes the payer-specific final step
After eligibility, drug-status checks, and medical necessity validation, the system assembles the information and submits it to the payer. The submission agent uses customized integrations for each payer. Like the eligibility and benefits workflow, these integrations use an LLM-driven configuration system and a repository of tools. In Shankhdhar's graph, the no-touch path includes passing eligibility, having enough information to continue clinical evaluation, passing medical necessity checks, and completing submission. Failed or uncertain cases move to review.
The agents are being reused beyond prior authorization
Although the agents were first built for oncology prior authorization, Risa Labs extended them to other workflows. The medical necessity agent can answer questions specific to a different workflow for the same patient, and Shankhdhar says the other agents have also been generalized. His design pattern is to start with deterministic checks, use agents where rules cannot decide, add multiple sources of evidence, use self-healing for browser automation, and reserve human review for cases that require clinical reasoning or lack enough information.
"We use all this information, we reconcile the evidence, and we only extract the auth statuses with a higher confidence."08:58
Who should watch
You build healthcare workflow automation and need to combine payer APIs, browser portals, documents, and clinical data.
Your team is deciding which healthcare decisions can be automated safely and which cases need clinician review.
You want a concrete example of using confidence, evidence reconciliation, and deterministic gates around LLM-based clinical reasoning.
