When an AI Orders the Wrong Test: Saga Compensation in Clinical Workflows
When an AI Orders the Wrong Test: Saga Compensation in Clinical Workflows
Category: Healthcare & Life Sciences | Reading time: 5 min
The Incomplete Action Problem
An AI workflow in a clinical setting rarely consists of a single action. A lab order workflow might: verify patient identity, check for duplicate orders, check insurance eligibility, create the order in the EHR, notify the lab, and update the care plan. Six steps, each touching a different system.
What happens when step four succeeds but step five fails?
You have an order in the EHR with no lab notification. The lab doesn't know the test is coming. The patient waits. Nobody knows why. And the next time the workflow tries to re-run, it may create a duplicate order.
This is the incomplete action problem — the specific failure mode that multi-step AI workflows introduce. Traditional error handling (try/catch, retry logic) addresses simple failures. It doesn't address the problem of partially completed state spread across multiple systems.
The Saga Pattern: Rollback for Distributed Workflows
The saga pattern, borrowed from distributed systems, provides a systematic answer. Every step in a workflow registers a compensation function — the action that undoes it if a later step fails. When a failure occurs, the kernel runs compensation in reverse order (LIFO), cleanly unwinding the completed steps.
In Taos, this is built into the kernel:
# After each step succeeds, register its compensation
taos.register_compensation(
"verifyPatientIdentity",
compensate_fn=lambda: audit_log.mark_verification_voided(patient_id)
)
taos.register_compensation(
"createLabOrder",
compensate_fn=lambda: ehr.void_order(order_id)
)
taos.register_compensation(
"notifyLab",
compensate_fn=lambda: lab_system.cancel_notification(notification_id)
)
If updateCarePlan (step 6) fails, compensation runs in reverse:
- Undo
notifyLab→ cancel notification - Undo
createLabOrder→ void the EHR order - Undo
verifyPatientIdentity→ mark the verification audit event as voided
The result: no orphaned lab order, no duplicate risk, no silent partial state. The system is back to a clean baseline.
Clinical Scenarios Where This Matters
Scenario 1: Insurance Eligibility Failure
The workflow creates a lab order before checking insurance eligibility (wrong order — but let's say a bug introduced it). Eligibility check fails. Without compensation, there's an order in the EHR for a test that insurance won't cover. With compensation, the order is immediately voided and the patient's care team is notified that the workflow failed at the eligibility step.
Scenario 2: EHR System Unavailable
The lab notification step succeeds but the EHR write fails because the system is temporarily unavailable. Without compensation, the lab is expecting a sample with no matching order. With compensation, the lab notification is cancelled, the system waits for EHR availability, and the workflow retries from a clean state.
Scenario 3: Duplicate Order Detection
A downstream step detects that an identical order was placed 20 minutes ago by a different workflow instance (network retry caused double submission). The saga compensation for the current workflow voids the duplicate order and logs the detection.
The Audit Trail of a Compensated Workflow
When compensation runs, every step is recorded in the audit log — both the original action and the compensation:
[14:23:11] STEP_COMPLETED verifyPatientIdentity patient=P-88421
[14:23:12] STEP_COMPLETED checkDuplicateOrders result=no_duplicate
[14:23:13] STEP_COMPLETED checkInsuranceEligibility eligible=true
[14:23:14] STEP_COMPLETED createLabOrder order_id=ORD-9921
[14:23:15] STEP_FAILED notifyLab error=connection_timeout
[14:23:15] COMPENSATION_STARTED
[14:23:15] STEP_COMPENSATED createLabOrder action=order_voided
[14:23:15] STEP_COMPENSATED checkInsuranceEligibility action=audit_logged
[14:23:15] COMPENSATION_COMPLETED
The audit trail is complete — what happened, what failed, and exactly how the system recovered. When a clinician or compliance officer reviews a failed workflow, they have the full picture: not a mystery, not missing data, but a documented and clean recovery.
Is-Checkpoint: When Rollback Isn't Right
Not every step should be compensated automatically. Some clinical actions are intentionally irreversible:
- A lab sample that has already been processed
- A medication that has already been administered
- A notification that has already reached the patient
Taos supports is_checkpoint steps — steps where automatic compensation should halt and a human escalation should be triggered instead:
taos.register_compensation(
"administeredMedication",
compensate_fn=lambda: escalate_to_clinical_lead(
"Medication administered in failed workflow — manual review required"
),
is_checkpoint=True # Stops automated rollback here
)
When the saga reaches a checkpoint step during compensation, it stops and creates a human escalation. The clinical lead reviews, determines appropriate next steps, and the workflow is closed with a documented decision.
Designing Clinical Workflows for Compensation
The key discipline is this: before building a step, decide how to undo it. If the step cannot be undone (administered medication, processed sample), it becomes a checkpoint. If it can be undone (created order, sent notification), the compensation function is registered immediately after the step succeeds.
This discipline improves workflow design beyond just error handling. It forces engineers to think carefully about the state each step creates and what "clean" means if that state needs to be removed. It eliminates the implicit assumption that all steps always succeed.
Agent judgment, gated commits, and denial modes
The kernel can enforce a declared workflow (steps, compensations, checkpoints) while still letting an agent handle fuzzy reasoning — which test to prioritise, how to phrase a request, or how to recover from ambiguous input. The split is not “deterministic or agentic”; it is agent proposes and navigates, kernel authorises and commits side effects only when policy and registration rules allow.
Operationally, that means before durable resources are committed (a billable lab order, a notification that starts specimen handling), the facts policy needs — duplicate checks, insurance eligibility, identity verification — should already be on the wire as structured input to the step that commits, not merely implied by model prose.
A wording trap worth avoiding: in TAOS, soft denial is not shorthand for “insurance wasn’t checked yet.” It describes how a denial is surfaced (structured result that may reach agent-facing code paths in a mode suited to conversational follow-up). Hard denial is not shorthand for “the model disagreed with insurance”; it describes denials that must not be reinterpreted by the LLM — the right posture when policy says coverage is not cleared or the order must not proceed, independent of how insistently the agent keeps asking.
The Bottom Line
Multi-step AI workflows in clinical settings will fail. Networks go down, systems are unavailable, edge cases occur. The question is not whether failures happen — it's whether your system recovers cleanly or leaves behind a mess that clinicians have to untangle manually.
Saga compensation in the Taos kernel makes clean recovery automatic. Every step is undoable by design. Every failure produces a clean baseline and a complete audit record.
Your AI orders the right tests. And when something goes wrong, the system proves it by cleaning up after itself.
Tags: saga compensation, clinical workflows, healthcare AI, EHR integration, distributed workflows, AI safety