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

Hi everyone, my name is Anand Shankdar. I am an AI engineer at TRISA and I will be talking about automating oncology workflows from end to end. So at TRISA, we are automating various workflows in oncology. One of such workflows is prior authorizations where we file for authorizations for drugs for cancer patients. So I'll give a brief overview about the workflow before we move further in the call. 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 eligible for getting the drugs based on the amount that they have in insurance available with them. This is called eligibility and benefits verification. Next, we determine what all drugs for the patient require authorization. So a drug can... basically fall into one of the following pathways so one is NAR which is no auth required basically the drug does not require authorization another can be that the authorization has already happened for the drug for a time period which is called auth on file and the third is auth required which means that the authorization needs to be performed for this drug so yeah this is the workflow I was so although our bots run and perform these steps Finally a human review is required before submitting all these orders. I was tasked with the problem to run some of these orders without any sort of human touch directly towards submission. Which means I need to confidently identify which all orders can be proceeded without any human verification and then build the entire flow for them as well. So confidence is a key metric that we were working towards. So yeah, how we did this was using four agents namely EV agent, auth agent, necessity agent and submission agent. EV agent is for eligibility and business verification. So basically fetching the patient data and determining whether it is fine for moving forward. Auth agent determines the type of the status of the drug whether authorization is required or not and the necessity agent is the clinical brain of system of the system so for the cases where authorization is required we determine whether it has to be done on whether it is right for the patient based on his vitals or not and finally we move towards submission so 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 a scattered across dozens of portals apis and documents and it is difficult to find that information at one place so in order to in order to start with our pipeline we 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 pair sources and gives the output in a normalized uniform format which we can use for processing further and we also added a deterministic decision engine to flag the cases which would not move forward thus deterministically fixing some of the orders without any human in the loop so here's how it works so we have a coverage orchestrator which determines whether the patient will go for the api or the rpa path rpa is basically the automation we 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 if it is we move it further in the phn else we stop that right there now one of the problems we saw here was that if we have to build this then we will need to make custom integrations for different sort of portals which is not not a very scalable process but how we tackled it was that we used lms in the loop So first of all we made a huge repository of custom actions as well as popular actions that are required to build RPS. Then we built a LLM based config generation which performs these actions and builds the config for a portal to run on which reduces our development time significantly. And finally these automations are fragile so it may happen that they break during the run time. For this we have a self-healing loop which identifies these cases during production hours and then mitigates them. So thus preventing any sort of failures. So yeah that is the first step. Once we have done this we move further in our chin. So as we can see our diagram, the graph. The patient data is fetched, we perform the eligibility verification, we see if it is fine or not, if it failed we stop there, else we move forward. So yeah, moving forward, the next step was to see what all drugs require authorization. So if I have to remove humans from the loop, one simple case that I saw was that if a drug has already been authorized that is the authorization is on file or if the authorization is not required then we can partly solve the order that is that we do not need human oversight on that part of the order so yeah so as the first step we built a simple LLM extraction pipeline which takes in patients notes performs LLM's extraction and categorizes the drugs into these types the default being that authorization is required however uh yeah so we thought that they should would work but we face some issues here as well so one popular issue was that the nodes that we were using did not have enough data which means that it was performing some some errors uh also llm extraction is sort of an indeterministic process that means that whatever outputs we get from here cannot be blindly tested so we still need a human to review all these things it might improve the efficiency but it will not eliminate the human so in order to do so we thought that what if I add more evidence to it so if the LLM is saying that a drug is not no auth required then I have some information backing that, I can say that confidently or for the orthon file cases. So in order to do so, we leveraged two other data sources. So one was the authorization letters. So this was basically the previous information. So across the previous runs that a given patient has, they have authorization letters available, which shows that these drugs were actually authorized. Now instead of just having one source, I have two sources that give me the same information and wherever they conquer, I can say with confidence that this drug is already been authorized. Second is the NAR case, the no auth required case. So here 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 so we use that information to build a pair rule knowledge base which is basically a sql database which was made from portal checks as well as llm extractions so we use all this information we reconcile the evidence and we only extract the odd statuses with a higher confidence so if from this pipeline we get whether a drug does not require authorization or is already authorized we have a solid proof behind it and a higher confidence to say that this is the case and of course all of this is configurable so in order if some mishap happens we always have a plug over the cases so yeah Another 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 require authorization at all. The drugs are either not requiring authorization or are actually authorized from before. So this enabled us no touch on a certain set of orders that we had. Yeah. This slide gives a small overview on how we build the pair rule knowledge base for the NAR cases. So we had the documents which had this information on a time-wise scale. We built an LLM extraction which uses LLMs which 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 pair, this is how it will be treated for a period of time. Another thing is that we leverage some historical information. That is that we know that a certain organization treats this drug in a certain sort of way. So we stored that information and used that as well. Apart from this, we also use some regular portal checks to get this information. So yeah. Performing this 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. So now that we've solved for two types of drugs, let's move forward. So the next problem that we faced here was that some decisions do actually need clinical reasoning. So far the drugs that we shifted to no touch were the ones where the information was directly available or indirectly available by another source. But we did not need to perform any sort of reasoning over here or any sort of question answer. However, for the drugs that are actually auth required, we need to check whether the patient is actually eligible for them and also give sort of supportive evidence from where we are 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 and attaches confidence score to any answer. So we escalate only the ones that actually need a clinician. So we did a lot of work on this space. We actually have another publication here as well which I have mentioned. So how this agent works is that we have a new order and for every order we read three things. So we read the patient notes, we read the policy criteria. So the policy criteria is basically the criteria that needs to be met in order for this drug to be processed further. From this criteria, we query the patient medical graph which is a graph of biomarkers that are extracted for a patient and we determine what all biomarkers exist and what is the condition of this patient from here. And then we use this thing, this information and pass it to an LLM. to get an answered questionnaire with all the supportive and contradictory facts so yeah and 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 we keep that for human escalation so yeah this is the next step so after This medical necessity validation, we moved from the first step where we fetched the data, 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, got the cases where we can move that without any human intervention, and then we did the medical necessity evaluation. whatever was not met was also moved to repeat so yeah finally we assemble all this information and then we submit it back to the pairs so this is where our submission agent comes into place the submission agent is pretty much similar as the evvv agent we have customized integrations for every sort of pair that we have which is built using an LLM driven config as well as our repository of tools So yeah, this is the entire graph that we got through the entire journey. So the green part shows the cases that we are going without human touch. So whenever eligibility verification passes, then enough information is found to prevent the duck from going for further medical necessity evaluation, then this medical necessity evaluation and the submission. Finally, I'd like to mention that these drugs are also, although built initially for this case, are being used across multiple workflows. We have extended the functionality to a more general one where the medical necessity agent can answer questions specific to any sort of workflow for the patient. Similarly, for the other agents. As the conclusion, I would say the no-touch is growing on the share of every order. So we started with deterministic checks. Agents only for the rules that where what rules can't decide. We used multi-source of evidence to beat the single source of evidence to add confidence to our cases. We added self-healing in order to scale our RPS. And finally, we added the reasoning layer. in order to deal with the cases where actually authorization is required. So yeah, thanks for the, yeah, thanks for your time.

Can Oncology Workflows Run Without Human Touch?
At Risa, we automate healthcare workflows in oncology end-to-end using AI agents. We built four agents that work together  , each one handles a different step, then passes its output to the next. No human needed in between. The agents when combined are able to do the work of hundreds of medical workers a day. These agents are deployed across 20+ hospitals and supporting care for more than 100,000 patients.

Here is the overview of our agents:-
Ingestion Agent

Takes messy, unstructured medical documents, faxes, scanned PDFs, clinical notes and turns them into clean, structured data. AI models read each document, extract the key information (patient details, medications, diagnoses), and check against historical records to avoid duplicate work. If a patient has been seen before, the system already knows their history and skips redundant lookups.

EV Agent
Checks whether a patient's insurance is active and what their plan covers. Some insurers offer APIs; others only have web portals. The agent uses whichever method works calling APIs where available, and driving a browser through the portal where not. The result is always the same standardized output: what's covered, what the patient owes, and whether the plan is active.

Medical Reasoning Agent

The clinical brain of the system. It evaluates whether a proposed treatment is appropriate for a specific patient by checking their medical records against clinical guidelines and insurance coverage rules. It breaks complex guidelines into simple yes/no criteria, evaluates each one against the patient's data in parallel, and aggregates the results. A confidence score determines whether the case can proceed automatically or needs a human clinician to review it.

Submission Browser Agent

100+ browsers running in parallel on Kubernetes, each one filling out forms and submitting requests on insurance portals. Each insurer has a different website with different forms — the agent knows how to navigate all of them. For portals that ask clinical questions during submission, the agent calls the Medical Reasoning Agent in real-time to generate answers. At full capacity, the system handles thousands of submissions per hour

At Risa, we automate healthcare workflows in oncology end-to-end using AI agents. We built four agents that work together as a DAG , each one handles a different step, then passes its output to the next. No human needed in between. The agents when combined are able to do the work of hundreds of medical workers a day. These agents are deployed across 20+ hospitals and supporting care for more than 100,000 patients.

Here is the overview of our agents:-
Ingestion Agent

Takes messy, unstructured medical documents, faxes, scanned PDFs, clinical notes and turns them into clean, structured data. AI models read each document, extract the key information (patient details, medications, diagnoses), and check against historical records to avoid duplicate work. If a patient has been seen before, the system already knows their history and skips redundant lookups.

EV Agent
Checks whether a patient's insurance is active and what their plan covers. Some insurers offer APIs; others only have web portals. The agent uses whichever method works calling APIs where available, and driving a browser through the portal where not. The result is always the same standardized output: what's covered, what the patient owes, and whether the plan is active.

Medical Reasoning Agent

The clinical brain of the system. It evaluates whether a proposed treatment is appropriate for a specific patient by checking their medical records against clinical guidelines and insurance coverage rules. It breaks complex guidelines into simple yes/no criteria, evaluates each one against the patient's data in parallel, and aggregates the results. A confidence score determines whether the case can proceed automatically or needs a human clinician to review it.

Submission Browser Agent

100+ browsers running in parallel on Kubernetes, each one filling out forms and submitting requests on insurance portals. Each insurer has a different website with different forms — the agent knows how to navigate all of them. For portals that ask clinical questions during submission, the agent calls the Medical Reasoning Agent in real-time to generate answers. At full capacity, the system handles thousands of submissions per hour

Speakers:
- Anant Shankhdhar (Risa Labs): Anant Shankhdhar is an AI researcher and Machine Learning Engineer at Risa Labs whose work focuses on large language models, agentic AI, retrieval-augmented generation (RAG), multimodal AI, and document intelligence, combining research and industry experience from IIT Guwahati, Adobe Research, Walmart Global Tech, and healthcare AI to build production-scale intelligent systems.
  LinkedIn: https://www.linkedin.com/in/anantshankhdhar/
  GitHub: https://github.com/AnantShankhdhar