vidtheque.

read-only demo

Videos _cVfz88_j7A

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

index_state ready data_status ok

AI Engineer· published 2026-07-20· 0:16:41· en-US· indexed 2026-08-10 19:47

Open on YouTube

Scene timeline

  1. Shot 0, 0:00 to 0:12, 1 of 1 keyframes kept
  2. Shot 1, 0:12 to 0:40, 1 of 1 keyframes kept
  3. Shot 2, 0:40 to 1:07, 0 of 1 keyframes kept
  4. Shot 3, 1:07 to 1:35, 0 of 1 keyframes kept
  5. Shot 4, 1:35 to 2:02, 0 of 1 keyframes kept
  6. Shot 5, 2:02 to 2:48, 1 of 1 keyframes kept
  7. Shot 6, 2:48 to 3:20, 1 of 1 keyframes kept
  8. Shot 7, 3:20 to 3:52, 1 of 1 keyframes kept
  9. Shot 8, 3:52 to 4:18, 1 of 1 keyframes kept
  10. Shot 9, 4:18 to 4:44, 0 of 1 keyframes kept
  11. Shot 10, 4:44 to 5:10, 0 of 1 keyframes kept
  12. Shot 11, 5:10 to 5:36, 0 of 1 keyframes kept
  13. Shot 12, 5:36 to 5:54, 1 of 1 keyframes kept
  14. Shot 13, 5:54 to 6:23, 1 of 1 keyframes kept
  15. Shot 14, 6:23 to 6:52, 0 of 1 keyframes kept
  16. Shot 15, 6:52 to 7:21, 0 of 1 keyframes kept
  17. Shot 16, 7:21 to 7:50, 0 of 1 keyframes kept
  18. Shot 17, 7:50 to 8:17, 1 of 1 keyframes kept
  19. Shot 18, 8:17 to 8:45, 0 of 1 keyframes kept
  20. Shot 19, 8:45 to 9:13, 0 of 1 keyframes kept
  21. Shot 20, 9:13 to 9:41, 0 of 1 keyframes kept
  22. Shot 21, 9:41 to 10:09, 0 of 1 keyframes kept
  23. Shot 22, 10:09 to 10:37, 1 of 1 keyframes kept
  24. Shot 23, 10:37 to 11:04, 0 of 1 keyframes kept
  25. Shot 24, 11:04 to 11:32, 1 of 1 keyframes kept
  26. Shot 25, 11:32 to 12:20, 1 of 1 keyframes kept
  27. Shot 26, 12:20 to 12:50, 1 of 1 keyframes kept
  28. Shot 27, 12:50 to 13:20, 1 of 1 keyframes kept
  29. Shot 28, 13:20 to 13:50, 0 of 1 keyframes kept
  30. Shot 29, 13:50 to 14:31, 1 of 1 keyframes kept
  31. Shot 30, 14:31 to 14:56, 1 of 1 keyframes kept
  32. Shot 31, 14:56 to 15:28, 1 of 1 keyframes kept
  33. Shot 32, 15:28 to 15:56, 1 of 1 keyframes kept
  34. Shot 33, 15:56 to 16:40, 1 of 1 keyframes kept

34 shot(s).

keyframes kept every frame deduplicated

What was stored

cues
93
whisperx 93
chunks
30
from 93 cues
keyframes
19
kept of 34 captured
frames with text
19
337 lines read
chapters
0
from the source metadata
keyframe bytes
2.7 MB
word timings on 93 cues

Provenance

Each pipeline stage, its state and the model that produced it
stage state model started took
fetch done — 2026-08-10 04:12 1m 35s
stt done — 2026-08-10 04:13 16s
chunk done — 2026-08-10 04:14 0s
text_embed done — 2026-08-10 19:47 0s
keyframe done — 2026-08-10 04:14 45s
ocr done — 2026-08-10 04:14 12s
frame_embed done — 2026-08-10 19:47 4s

Frames, and what the machine read

  • 0:06 #0 done15 line(s)

    shot 0·sharpness 1529.2

    1. RISA1.00
    2. ONCOLOGY OPERATIONS·AI0.98
    3. AI AGENTS FOR PRIOR AUTHORIZATION0.98
    4. Automating oncology0.99
    5. workflows, end-to-end0.98
    6. From patient data to payer submission — a pipeline of specialized agents that0.99
    7. clears the routine cases with zero human touch, and routes the hard ones to1.00
    8. clinical reasoning.1.00
    9. 50+1.00
    10. 100K+1.00
    11. 1000s1.00
    12. HOSPITAL SITES1.00
    13. PATIENTS1.00
    14. AI AGENTS1.00
    15. SUBMISSIONS / HR0.97

  • 0:34 #1 done33 line(s)

    shot 1·sharpness 2028.8

    1. RISA1.00
    2. ORIENTATION1.00
    3. THE BIG PICTURE1.00
    4. The prior-auth lifecycle0.98
    5. Orders arrive from each practice's group inbox. RISA pre-processes and pre-classifies them, a Document Annotator validates on the0.99
    6. medonc-dashboard, and RPA bots write results back toOncoEMR — submitting to payer portals when needed.0.98
    7. NAR·No auth0.95
    8. required1.00
    9. 40.83
    10. Order Intake0.98
    11. & Worklist0.93
    12. STEP 11.00
    13. Benefits (EV / BV)0.96
    14. Eligibility&1.00
    15. STEP 21.00
    16. Order Determination1.00
    17. & Processing0.95
    18. STEP 31.00
    19. Status0.96
    20. path1.00
    21. Auth on file1.00
    22. Write-back +0.97
    23. Doc Upload1.00
    24. STEP 41.00
    25. completed1.00
    26. ✓ Mark0.92
    27. Auth required -0.95
    28. submit0.92
    29. Misc (PRMA,oral,0.93
    30. POI)1.00
    31. MENTAL MODEL0.98
    32. The bot works each order before a human arrives — the annotator starts from a pre-assigned status and mostly validates. The goal is to shrink0.99
    33. the "human validates" surface toward "human exception-handles only."0.98

  • 1:04 #2 skipped

    shot 2·duplicate of #1

  • 1:18 #3 skipped

    shot 3·duplicate of #1

  • 1:38 #4 skipped

    shot 4·duplicate of #1

  • 2:34 #5 done22 line(s)

    shot 5·sharpness 1034.3

    1. RISA1.00
    2. THE WORKFLOW1.00
    3. THE DECISION GRAPH1.00
    4. Zoom in: one graph, four agents.0.99
    5. Inside Order Determination, every order runs the same directed graph. Each agent owns one0.99
    6. decision — we only escalate to a human when none of them can. We'll build it up, node by0.98
    7. node.1.00
    8. INPUT1.00
    9. EV AGENT1.00
    10. AUTH AGENT1.00
    11. NECESSITY AGENT1.00
    12. SUBMISSION AGENT1.00
    13. 40.78
    14. Patient Data0.98
    15. Eligibility1.00
    16. Auth1.00
    17. Medical1.00
    18. Submission1.00
    19. Fetching1.00
    20. Verification1.00
    21. Determination1.00
    22. Necessity1.00

  • 3:01 #6 done17 line(s)

    shot 6·sharpness 2677.2

    1. RISA1.00
    2. THE PROBLEM1.00
    3. THE CHALLENGE1.00
    4. How do we process these orders without a0.99
    5. human in the loop?1.00
    6. 40.71
    7. WHY IT'S HARD1.00
    8. THE APPROACH1.00
    9. Insurance details are scattered across dozens of1.00
    10. A unified service that connects to every payer0.98
    11. payer portals and APls, no single source of truth.0.99
    12. source and normalizes what it finds.1.00
    13. A deterministic decision engine clears0.97
    14. Coverage lapses and edge cases are common, and1.00
    15. clear-cut cases first specialized agents ha1.00
    16. historically every order was reviewed by hand.0.99
    17. rest.1.00

  • 3:33 #7 done17 line(s)

    shot 7·sharpness 2721.9

    1. RISA1.00
    2. THE PROBLEM1.00
    3. THE CHALLENGE1.00
    4. How do we process these orders without a0.99
    5. human in the loop?1.00
    6. 40.73
    7. WHY IT'S HARD1.00
    8. THE APPROACH1.00
    9. Insurance details are scattered across dozens of1.00
    10. A unified service that connects to every payer0.98
    11. payer portals and APls, no single source of truth.0.99
    12. source and normalizes what it finds.1.00
    13. A deterministic decision engine clears the1.00
    14. Coverage lapses and edge cases are common, and1.00
    15. clear-cut cases first specialized agents handle the0.98
    16. historically every order was reviewed by hand.0.99
    17. rest.1.00

  • 4:00 #8 done25 line(s)

    shot 8·sharpness 1400.4

    1. RISA1.00
    2. 01·ELIGIBILITY1.00
    3. AGENT 01 - EV AGENT0.96
    4. Eligibility & coverage verification1.00
    5. Active coverage1.00
    6. API path1.00
    7. proceed to PA0.99
    8. Coverage1.00
    9. Coverage1.00
    10. Orchestrator1.00
    11. Result1.00
    12. RPA path0.99
    13. Not eligible / error1.00
    14. ¬ flagged0.91
    15. How do I scale this?0.98
    16. ACTION REPOSITORY0.98
    17. LLM CONFIG GEN1.00
    18. SELF-HEALING1.00
    19. A library of reusable automation actions that0.99
    20. Per-payer configs are generated by an1.00
    21. When a portal shifts, the agent repairs its0.99
    22. already covers most payer portals.1.00
    23. LLM, so new portals onboard without0.99
    24. own flow — preventing production failures.0.99
    25. bespoke code.0.99

  • 4:31 #9 skipped

    shot 9·duplicate of #8

  • 5:00 #10 skipped

    shot 10·duplicate of #8

  • 5:33 #11 skipped

    shot 11·duplicate of #8

  • 5:39 #12 done11 line(s)

    shot 12·sharpness 487.6

    1. RISA1.00
    2. THE WORKFLOW0.97
    3. BUILDING THE GRAPH - 1 / 40.97
    4. Verify eligibility1.00
    5. Patient Data1.00
    6. Eligibility1.00
    7. Fetching1.00
    8. Verification1.00
    9. Eligibility1.00
    10. failed1.00
    11. Eligible patients proceed to prior auth — coverage failures are flagged out of the pipeline.0.99

  • 6:00 #13 done15 line(s)

    shot 13·sharpness 2093.3

    1. RISA1.00
    2. 02·AUTH STATUS0.97
    3. AGENT 02- AUTH-ON-FILE0.98
    4. Which drugs actually need auth?0.99
    5. Auth required0.97
    6. Patientnotes1.00
    7. LLM extraction1.00
    8. No auth required0.98
    9. Auth on file0.98
    10. 40.95
    11. THE CATCH0.99
    12. Notes alone give us no confidence signal, and some drug statuses simply aren't written down. We can't go no-touch on1.00
    13. extraction we can't trust.1.00
    14. Furthermore, details of the patient are scattered, a note might contain the information on drug statuses, but might miss out on1.00
    15. other things such as number of visits. Some other documents contain information on what drugs does a payer not authorise.1.00

  • 6:35 #14 skipped

    shot 14·duplicate of #13

  • 7:03 #15 skipped

    shot 15·duplicate of #13

  • 7:30 #16 skipped

    shot 16·duplicate of #13

  • 7:53 #17 done18 line(s)

    shot 17·sharpness 1298.7

    1. RISA1.00
    2. 02· AUTH STATUS0.96
    3. AGENT 02 - EVIDENCE RECONCILIATION0.99
    4. Confidence comes from combining evidence0.98
    5. Clinical notes0.99
    6. Reconcile1.00
    7. Auth status per drug1.00
    8. Auth letters1.00
    9. evidence1.00
    10. + confidence1.00
    11. Payer-rule knowledge base0.99
    12. THE PAYOFF0.98
    13. HOW THE KB IS BUILT1.00
    14. Drugs that need no auth — or are already authorized — clear with0.99
    15. payer docs → AI extraction → human review →0.99
    16. zero human touch . Missing evidence in one source is recovered1.00
    17. versioned rules0.98
    18. from another.1.00

  • 8:34 #18 skipped

    shot 18·duplicate of #17

  • 9:02 #19 skipped

    shot 19·duplicate of #17

  • 9:32 #20 skipped

    shot 20·duplicate of #17

  • 9:49 #21 skipped

    shot 21·duplicate of #17

  • 10:33 #22 done15 line(s)

    shot 22·sharpness 737.4

    1. RISA1.00
    2. 02· AUTH STATUS0.96
    3. AGENT 02 - EVIDENCE RECONCILIATION0.98
    4. Building the Payer Rule Knowledge Base1.00
    5. Payer Wise Documents0.99
    6. LLM1.00
    7. Drug Wise Contraints1.00
    8. containing drug wise1.00
    9. (DB)1.00
    10. rules1.00
    11. HistoricalPayer Wise1.00
    12. Documents containing1.00
    13. drug wise rules1.00
    14. Regular Portal Checks0.99
    15. data1.00

  • 10:45 #23 skipped

    shot 23·duplicate of #22

Transcript

93 cues· 2,261 words· 12,456 chars

  1. 0:00 Hi everyone, my name is Anand Shankdar.
  2. 0:03 I am an AI engineer at RISA and I will be talking about automating oncology workflows from end to end.
  3. 0:12 So at Reesa, we are automating various workflows in oncology.
  4. 0:16 One of such workflows is prior authorizations where we file for authorizations for drugs for cancer patients.
  5. 0:25 So I'll give a brief overview about the workflow before we move further in the call.
  6. 0:31 So the first step is that we intake the orders that we get on a daily basis.
  7. 0:36 The second step is we verify whether the patient is actually very eligible for getting the drugs based on the amount that they have in insurance available with them.
  8. 0:46 This is called eligibility and benefits verification.
  9. 0:50 next we determine what all drugs in the 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
  10. 1:21 So yeah, this is the workflow.
  11. 1:25 So although our bots run and perform these steps, finally a human review is required before submitting all these orders.
  12. 1:34 I was tasked with the problem to run some of these orders without any sort of human touch directly towards submission.
  13. 1:47 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 so confidence is a key metric that we were working towards
  14. 2:04 So yeah, how we did this was using four agents, namely EV agent, auth agent, necessity agent and submission agent.
  15. 2:13 EV agent is for eligibility and business verification.
  16. 2:17 So basically fetching the patient data and determining whether it is fine for moving forward.
  17. 2:24 Auth agent determines the type of the status of the drug, whether authorization is required or not.
  18. 2:32 And the necessity agent is the clinical brain of the system.
  19. 2:35 So for the cases where authorization is required, we determine whether it has to be done or whether it is right for the patient based on his vitals or not.
  20. 2:46 And finally we move towards submission.
  21. 2:50 So starting with the first step, how do we do this without any human in the loop?
  22. 2:56 So one of the problems that we have here is that insurance details, insurance documents, everything is scattered across dozens of portals, APIs and documents.
  23. 3:09 And it is difficult to find that information at one place.
  24. 3:13 So in order to start with our pipeline, we
  25. 3:20 need to get information from various portals as well as APIs.
  26. 3:25 In order to do so, we built a unified service that connects to different peer sources and gives the output in a normalized uniform format, which we can use for processing further.
  27. 3:38 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.
  28. 3:51 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
  29. 4:13 which we then pass to our deterministic engine to determine whether the coverage is active or not if it is we move it for further in the phn else we stop that right there
  30. 4:24 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 a very scalable process.
  31. 4:40 But how we tackled it was that we used LLMs in the loop.
  32. 4:45 So first of all we made a huge repository of custom actions as well as popular actions that are required to build RPS.
  33. 4:55 Then we built a LLM based config generation which performs these actions and builds the config for a portal.
  34. 5:05 to run on which reduces our development time significantly and finally these 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 that thus preventing any sort of failures so yeah that is the first step
  35. 5:35 Once we have done this, we move further in our chain.
  36. 5:39 So as we can see our diagram, the graph, the patient data is fetched.
  37. 5:44 We perform the eligibility verification.
  38. 5:47 We see if it is fine or not.
  39. 5:49 If it failed, we stop there.
  40. 5:51 Else we move forward.
  41. 5:53 so yeah moving forward the next step was that 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
  42. 6:22 then we can partly solve the order that is that we do not need human oversight on that part of the order.
  43. 6:33 So as the first step we built a simple LLM extraction pipeline which takes in patients notes, performs LLM extraction and categorizes the drugs into these types.
  44. 6:44 The default being that authorization is required.
  45. 6:47 however 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
  46. 7:09 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
  47. 7:29 So in order to do so, we thought that what if I add more evidence to it.
  48. 7:36 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 auth on file cases.
  49. 7:49 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
  50. 8:08 so 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 north 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

Open at this second