Audiences AIHolding the slot
Pull up tomorrow's OR schedule at any hospital that runs one and look at a single line. A case sits at 07:30 in a named room with a surgeon attached. The scheduling system knows this case in exact detail: the procedure, the duration estimate, who follows it in the room. Ask the building a different question, whether the case is actually ready to consume the slot it is holding, and no system answers. Readiness gets decided the way it always has been, by a charge nurse or a surgical office working phones and worklists the afternoon before.
The list of things that can stand between scheduled and ready is long and unglamorous: an authorization still incomplete, a pre-op lab never drawn, a clinical clearance unresolved, a consent form missing, imaging that has not arrived, an implant or equipment question, a blood requirement, no ICU bed for afterward, a patient who cannot be reached, a transportation problem, a medication hold. Each blocker lives in its own module or its own inbox. On the schedule itself, every one of these cases looks identical to a case with nothing wrong.
The gap has a measurable cost. Studies of same-day elective cancellations keep tracing them to the same families of cause: resource constraints, patient status, scheduling and preparation problems. A cancelled first case cascades down the room for the rest of the day. Most of the blockers above are visible in data the hospital already holds, hours or days before the team scrubs. What is missing is a recorded decision: is this case ready, and if it is unready, is it worth saving before morning?
Seven states behind one schedule entry
This is the pattern our current research keeps finding: the schedule is accurate and readiness is nobody’s field. Whether case 482 can actually consume its slot gets worked out by hand, case by case, by whoever has the least slack that afternoon. The surgical version resolves into a small vocabulary. Examined against the record, a scheduled case sits in exactly one of seven readiness states.
| State | Reading |
|---|---|
| READY | nothing outstanding |
| ADMIN_BLOCKER_RECOVERABLE | paperwork an office can clear today |
| PATIENT_BLOCKER_RECOVERABLE | contact or transport, fixable by phone |
| RESOURCE_BLOCKER | equipment, implant, blood or bed |
| CLINICAL_REVIEW_REQUIRED | an unresolved clearance, routed to a clinician |
| LIKELY_CANCEL | history says it will not clear in time |
| INSUFFICIENT_EVIDENCE | the record cannot support a call |
Little of this needs new data. Epic's public integration documentation exposes surgical schedules, consent status, orders, labs and imaging over FHIR and HL7 interfaces, and Epic stays the system of record throughout: it runs the schedule, holds the chart and receives whatever happens next. The readiness logic would be a thin layer beside it, reading what is already recorded and computing the one field nothing currently computes.
The working output in our sketches is a card per case, produced the afternoon before. An illustrative one:
Case 482: not ready. Primary blocker: authorization incomplete. Secondary: consent. Both recoverable before 16:00 today. Owner: financial clearance and the surgical office. Do not release the slot yet.
The last line is the point. When a case looks shaky, a surgical office has two reflexes: release the slot early and lose the case, or hold it quietly and scramble when the gap surfaces at 06:00. The card replaces both with a timed hold that names its terms: these two blockers, this deadline, this owner. The states with recoverable in their names are where the money sits, because a cancellation prevented by a 15:00 phone call costs a phone call, while the same cancellation discovered at 06:45 costs the slot, the team's first hour and a patient who fasted for nothing. How often each state occurs, and what a save is worth, are quantities this investigation still has to establish.
Where the logic must stop
There is a version of this idea that drifts somewhere it must never go, and the drift would be gradual. This quarter the system flags an unsatisfied clearance; next quarter someone proposes it read the lab values itself and quietly downgrade the cases it considers fine. The disciplined version holds a hard line. The software never says a patient is medically safe for surgery; it says a clinical clearance requirement is unsatisfied and routes the case to a clinician qualified to resolve it. CLINICAL_REVIEW_REQUIRED is where the software's authority ends: it notices, it routes, and it stops.
FDA's CDS guidance is what makes the boundary consequential, and we read it as a favor, because it forces the scope question before any logic exists. The same discipline applies to timelines. Encoding readiness rules is small work, plausibly a week of it; a hospital go-live never is, because security review, EHR configuration and clinical governance take the time they take, and pretending otherwise would mark us as tourists. Procedure readiness is research territory for us, and Interpret and Triage remain the only systems available for pilot.
What the surgery investigation has settled is a design principle we now carry everywhere: draw the boundary before writing the logic. Decide the operational question completely, and hand the clinical question over intact, with an owner attached. A readiness system that knows precisely where its authority ends is one a hospital can trial without betting anything clinical on the outcome. That property gets designed in at the boundary, and it cannot be patched in afterward.
To see this way of deciding in a shipped product, start with Triage, our diagnostic system for manufacturing.