Modal Dialog and Interrupt Handling in EHR Workflows

Modal Dialog and Interrupt Handling in EHR Workflows.

Modal dialogs and EHR automation failures under traditional smooth-path assumptions

Modal dialogs and other unexpected UI interrupts rank among the most disruptive obstacles a computer-use agent faces inside an EHR workflow, and how an agent handles them, whether it detects the interrupt, correctly identifies what kind it is, and recovers without losing its place, decides whether the automation survives contact with a real production environment or falls apart the moment a screen does something the script didn't expect. Most automation built for these systems assumes a clean path, where screen one leads to screen two, a form gets filled, a confirmation appears, and the task is done. That assumption does not hold in practice.

Production EHR environments throw session timeouts, unsaved-data warnings, authentication challenges, CAPTCHAs, multi-factor prompts, and browser security alerts into the middle of otherwise routine sequences, often with no warning and no consistent timing. HealthAdminBench, an arXiv paper from April 2026, documents just how rigid and unforgiving real payer portal workflows actually are. Agents working a prior authorization or claims task have to pull every document out of the EMR before they even think about opening a payer or fax portal, and the benchmark's own workflow guidance states the rule bluntly: never navigate back mid-form, because progress will be lost.

That instruction exists for a reason. A single unexpected popup, a session timeout, an unsaved-data warning, can wipe out an entire multi-step wizard form the moment it fires. Payer portals are notorious for exactly this kind of brittle, linear structure where backward navigation isn't just discouraged, it's destructive.

The stakes here aren't abstract. Interrupts happen, reliably and often. They will, reliably and often. Can the agent detect the interrupt, classify what it actually is, and recover the task state without quietly losing the work that already got done?

Computer-use agents and the interrupt risk of screen-level execution

A computer-use agent interacts with an application the way a person would: clicking, typing, navigating, reading whatever is rendered on the screen at each step. That's the whole architecture, and the reason it exists deserves examination. In production healthcare settings, a single patient scheduling interaction can touch three or four separate applications that share no APIs whatsoever blog.anyreach.ai keragon.com. According to research from Anyreach, the "API" connecting those systems has historically been a trained staff member who simply knows which button to click, in which order, across which piece of software blog.anyreach.ai. Computer-use agents exist to stand in for that knowledge.

That comes with a tradeoff. An API call returns structured data: clean, predictable, free of visual noise blog.anyreach.ai. A screen-operating agent gets none of that privilege. It sees the entire rendered UI, every modal, every overlay, every warning banner and dialog box that happens to sit on top of the workflow it's trying to execute.

HealthAdminBench gives some sense of scale here. The benchmark's taxonomy includes 292 form-completion subtasks, 200 task-resolution subtasks, and 149 document-handling subtasks, and each one represents a point where a dialog could fire and break the agent's state HealthAdminBench. Multiply that across the actual ecosystem an agent has to work inside: Epic, Cerner, Meditech, and Allscripts, all of which vendors like Automat describe operating visually rather than through structured integration, plus separate billing systems, insurance verification portals, pharmacy benefit tools, and referral management platforms, each with its own modal behavior and its own session logic.

The implication cuts both ways. The same architectural choice that lets a computer-use agent work across every system a staff member touches, without needing a custom integration for each one, is the exact feature that exposes it to every UI event that staff member would also run into. Broad reach and interrupt exposure are the same coin, not two separate problems.

The interrupt taxonomy: not all modal dialogs are the same problem

Lumping every popup into one bucket called "interrupt" misses what actually matters, because these are meaningfully different challenges wearing the same visual costume.

Session-state interrupts are the most time-sensitive. Timeout warnings fire mid-form and demand an immediate response to keep the session alive, while unsaved-data warnings appear the moment navigation is attempted before a save action completes. Both destroy progress if the agent doesn't act inside a narrow window.

Authentication interrupts are a separate animal entirely: multi-factor challenges dropped mid-workflow, CAPTCHA prompts that research from Automat and Anyreach shows appear especially often on payer portals that redesign every quarter and frequently bolt on new CAPTCHA layers after those redesigns, plus browser security alerts and certificate warnings that have nothing to do with the workflow itself and everything to do with the browser's own security posture.

Workflow-branching interrupts sit closer to the task logic. These are confirmation dialogs demanding a yes or no before anything continues, error messages from the EHR or portal that block forward motion until they're acknowledged or fixed, and payer portal wizard forms where attempting to go back is itself what triggers the interrupt.

And then there's a category that isn't really an interrupt in the technical sense at all: human-in-the-loop points, where the workflow is designed to require a person's approval, clarification, or course correction before the agent moves forward. A peer-reviewed paper published in BMC Medical Informatics and Decision Making in April 2026 frames this directly, arguing that agentic AI systems need to support asynchronous connections back to a human for exactly this purpose, and that this isn't an edge case bolted on as an afterthought, it's an architectural requirement.

Classification has to come before any response, because an agent that handles a session timeout the same way it handles a confirmation dialog will either lose the task state it was trying to protect or make a decision nobody authorized it to make. The correct recovery depends entirely on first getting the interrupt type right.

Why selector-based RPA collapses at the first unexpected dialog

Traditional RPA runs on fixed sequences: CSS selectors or UI element IDs, scripted ahead of time, executed in strict order. It's a reasonable approach when the screen behaves exactly as predicted. It is not a reasonable approach in a payer portal.

The moment a modal shows up that wasn't in the script, the selector the script expects gets blocked or buried behind the dialog. From there, the outcomes are all bad: the script times out waiting for an element that will never come into focus, it clicks the wrong element because the dialog changed the page's structure underneath it, or the task simply crashes.

Payer portals are practically engineered to expose this weakness. Automat's own research shows payer portals get redesigned on a quarterly basis, add CAPTCHAs without warning, and change authentication flows often enough that hardcoded selectors break on a predictable cycle. In healthcare specifically, that failure isn't cheap. HIPAA compliance means a failed automation can't just be restarted quietly, it requires investigation and documentation of what happened and why.

Goal-based agents handle this differently, and the change is structural rather than cosmetic. Research from TinyFish frames it this way: when a portal redesigns, the underlying goal, something like "find the prior authorization status for patient ID X," is still perfectly valid. A goal-oriented agent can go find the button even after it's moved, because it's reasoning about intent rather than matching a fixed selector. A selector-based script has no such flexibility; it simply breaks.

The damage compounds in ways that matter more in revenue cycle work than almost anywhere else. Most RCM operations run vast-horizon, repetitive workflows, batches of authorizations, waves of claims, and an unhandled interrupt in one instance doesn't stay contained. The OS-Marathon benchmark found that naive task decomposition doesn't solve this: errors from one subtask propagate straight into the next one. A single unhandled dialog early in a batch can quietly poison everything that follows.

Interrupt detection in a well-designed agent

Detection sounds like it should be trivial. Detection is not trivial. The agent's visual field shows whatever is currently rendered, but telling a modal dialog apart from a legitimate, expected workflow screen takes active interpretation, not passive observation.

One useful primitive is screen-state comparison. The agent keeps an internal model of what the next screen should look like given the current step in the workflow, and when the rendered screen diverges from that expectation, a new overlay appears, focus lands somewhere unexpected, the controls the workflow needs are suddenly unreachable, that divergence itself is the signal something has interrupted the flow.

Certain visual patterns make this easier in practice. Modal overlays tend to dim the background and center a dialog box with a narrow set of buttons, usually just confirm, cancel, or dismiss. Session timeouts often come with a countdown timer or explicit "your session will expire" language. CAPTCHAs show up as image grids or checkbox challenges, sometimes with an audio alternative. Error states tend to announce themselves with red borders, warning icons, or inline validation messages that block submission.

ReUseIt, a paper revised in January 2026 and published at IUI '26 in March of that year, builds a concept called the execution guard around exactly this idea. Reusable workflows incorporate condition checks: the agent evaluates the current screen state against what should follow the last action taken, and a mismatch triggers a fallback path instead of letting the agent barrel forward on a false assumption.

Not every model handles this equally well. Research from Fan and colleagues on hybrid GUI-MCP agents found that reasoning models are meaningfully better at interpreting ambiguous screen states than non-reasoning models keragon.com. A non-reasoning model faced with an unexpected UI element may ignore it, misidentify it, or falsely conclude the task is finished, while a reasoning model tends to recognize the anomaly for what it is and adjust course keragon.com.

When detection fails, the failure is quiet and dangerous rather than loud. The agent tries to interact with an element that's now sitting behind a modal, the click lands on the modal instead, and the workflow's actual state becomes undefined. Everything after that executes against the wrong assumption, and the agent has no idea the task already broke. In the section on how a well-designed agent detects that an interrupt has occurred, the discussion draws on Eliciting Tool Use and Managing Multimodal Context in Hybrid GUI-MCP Computer-Use Agents ([arxiv.org/pdf/2608.03327]).

Classifying the interrupt so the recovery action is correct

Detecting that something interrupted the flow only gets an agent halfway there. What it does next depends entirely on classifying that interrupt correctly, and getting this wrong in either direction causes real damage. An agent that reflexively clicks "Cancel" on every dialog will abandon confirmation prompts it should have accepted. One that reflexively clicks "OK" on everything will confirm data deletions and session resets it never should have approved.

Is it urgent, meaning does it expire on its own, the way a session timeout does, or will it simply wait, the way a confirmation dialog does? Is it reversible, or does responding the wrong way destroy work that can't be recovered? Does resolving it require human authority, an actual credential or clinical judgment the agent doesn't hold, or can the agent handle it on its own? And does its scope stop at the current step, or does it invalidate everything the workflow already accomplished upstream?

The Microsoft AI Red Team's taxonomy of agentic failure modes, published as a whitepaper in April 2025 and cited since as a reference point across multiple 2026 academic papers, offers a useful frame here. Interrupts that go unclassified, or get classified wrong, map directly onto several of the failure categories that taxonomy documents.

Some interrupts get correctly classified as belonging to a human, and that outcome shouldn't read as a failure of the agent. An authentication challenge that needs a credential the agent simply doesn't hold, or a clinical decision embedded partway through a workflow step, both call for a handoff. The BMC paper from April 2026 is explicit that agentic systems need to maintain connection integrity across long sequences of steps and support exactly this kind of asynchronous handoff for approval or clarification. That's the design working as intended, not the design falling short.

A useful parallel comes from outside the screen-agent world. Ellis and colleagues, in an August 2026 paper, studied interruption in clinical voice agents and identified three distinct types: recognitional, competitive, and transitional sub-unit HealthAdminBench keragon.com. What they found was that how the agent classified the overlap between speakers determined that clinically necessary information either survived the interruption or got lost in it HealthAdminBench keragon.com. The specifics don't transfer directly from voice to screen, but the structural lesson does: classification isn't a formality that happens after the real work, it's the step that decides what gets preserved and what doesn't.

Recovery strategies: restoring task state without losing what the workflow had already accomplished

Recovery has one real constraint: task state has to come back to a known-good point the workflow can safely resume from, not merely to whatever screen happened to precede the interrupt. Those are not the same thing, and treating them as interchangeable is where a lot of naive recovery logic falls apart.

Different interrupt types call for genuinely different responses. A session timeout needs an immediate reply to keep the session alive, followed by a check to confirm the form data actually survived before continuing, and if it didn't survive, the agent has to fall back to the last checkpoint before the form and re-run the data-gathering step. An unsaved-data warning should never just get dismissed; the right move is to pause, check that the in-progress data can still be saved, take that save action if one exists, and only then continue. A CAPTCHA calls for escalation to a human-in-the-loop checkpoint rather than an autonomous attempt to solve it, since autonomous CAPTCHA solving is unreliable and, in healthcare environments, potentially a compliance issue. A blocking error message needs to be classified by type, validation, authorization, or system-level, addressed at the root if that's within the agent's authority, and then resubmitted. A confirmation dialog can be resolved autonomously only when the required response is unambiguous given everything the workflow already knows; otherwise, it escalates too.

None of this works without checkpoints built into the workflow itself. Well-designed agents save task state at defined points, after documents are pulled from the EMR, after form data gets entered, after a portal submission goes through, so that recovery means resuming from the last valid checkpoint rather than starting the entire task over from zero. HealthAdminBench's own workflow guidance reflects exactly this structure: gather every document from the EMR first, treat the move to the payer portal as a second checkpoint, treat form submission and the resulting confirmation number as a third, and close the loop by returning to the EMR to record that confirmation.

ReUseIt takes this a step further with what it calls fallback action mechanisms. Its reusable workflows are built from both successful and failed prior attempts, and at each step where a failure was previously observed, a fallback action gets embedded ahead of time ReUseIt. The agent isn't scrambling to invent a response in the moment, it already has an alternative path ready to go. That approach alone raised success rates from 24.2% to 70.1% across fifteen tasks, which is a significant jump for what amounts to giving the agent a memory of its own past failures ReUseIt.

The propagation of errors still looms over all of this in repetitive, high-volume work. OS-Marathon's research on vast-horizon tasks, processing a batch of authorizations, working through a stack of claims, found that an interrupt left unrecovered in one instance bleeds errors into every instance that follows it. Recovery, in other words, can't just be scoped to the step where it happened. It has to be scoped to the entire instance, or the damage keeps spreading quietly through the batch. Good recovery, from the practice's point of view, looks almost boring: the workflow finishes on roughly the timeline a human operator would have hit, the interrupt gets logged somewhere staff can see it later, and nothing gets silently dropped.

Limits of interrupt handling in production healthcare environments

The honest answer is that interrupt handling remains an unsolved problem, not a solved one with rough edges. Benchmark numbers make that clear rather than reassuring. ReUseIt found that state-of-the-art agents working without any interrupt-recovery scaffolding managed only a 24.2% success rate on repetitive web tasks at baseline. Getting to 70.1% required goal-oriented agents equipped with execution guards, and that improvement depends on having prior execution data available to build fallback paths from in the first place ReUseIt. An agent walking into a brand-new payer portal with no history of failed attempts to learn from doesn't get that lift for free.

That's the real limit right now. Interrupt handling that works is interrupt handling that's been built from experience, from a record of what already went wrong once before. The gap between 24.2% and 70.1% isn't a gap in raw model capability so much as a gap in whether the system has been given the scaffolding, the checkpoints, the fallback paths, the classification logic, to use that capability well ReUseIt. Production healthcare environments generate that experience constantly, in payer portals that redesign every quarter, in EHR sessions that time out without warning, in CAPTCHA challenges that appear overnight. Closing the gap means building systems that accumulate and apply that experience methodically, rather than treating each new interrupt as a surprise to be handled from scratch. In the section on where current agents still struggle, the limits of interrupt handling in production healthcare environments are examined through SOURCE PAGES, what the pages behind the outline's links say.