When RIA front-desk staff request a patient estimate in Abbadox, the order round-trips through our
once-a-minute pipeline — eligibility, pricing, letter — and back out as an ORU. Usually that takes minutes.
Sometimes a patient waits three hours. This is why.
The flow is bimodal by design and by accident. By design: only a third of estimate
letters are truly on-demand — the rest are timed to the appointment and swept out nightly. By accident: the
on-demand ones ride the same once-a-minute batch as unrelated bulk work, so when a large eligibility or reprocess
job lands, every on-demand request in that batch waits for the whole thing to finish.
01 · The gap
A typical run is fine. The customer average is not.
Flow time = run start → the final "Generate and send ORMs" step. The median run finishes fast,
but a few pathological runs each carry hundreds of on-demand requests — so weighting by request (what a
customer actually feels) drags the 95th percentile from minutes to hours.
02 · Where customers land
Most are served in minutes; a slice is crushed.
Every on-demand request in the window, bucketed by how long its run took. The green mass is healthy;
the warm tail is the contamination — a small share of customers, but they wait 1–3+ hours.
03 · Day by day
The bad days are events, not a monthly clock.
Top strip: daily 95th-percentile flow time, colored by severity. Bars: on-demand requests per day,
split by how long they waited. Most days are entirely green. On a handful — here —
a bulk batch collapsed the flow and hundreds of on-demand patients waited over an hour.
04 · The mechanism
Big batches make long runs make many victims.
The twelve longest on-demand runs. Horizontal: how many eligibility inputs shared the batch. Vertical:
how long the run took. Bubble area: on-demand requests caught in it. A normal batch is ~60 inputs and clears in
minutes; these carried 2,000–12,000 and ran for the better part of an hour or more.
05 · The blocking step
Eligibility scales with batch size — and it runs before the letter.
CheckBenefits is the gate: AutoSendLetters can't fire until the whole batch's
eligibility completes. As the batch grows, so does the wait every request inherits.
The bottleneck rotates with batch size — LoadVisitBatch,
CalculateVisits, CheckBenefits, ReprocessChangedConfigurations all scale.
So the fix is not speeding up one step; it's keeping bulk eligibility / reprocess work out of the on-demand
batch (its own schedule or queue), so a front-desk request never shares a run with a 10,000-input job.