medOS ultra
AI AgentsOperationsCapacity & disruption agent

Operations

Capacity & disruption agent

Sense a capacity breach in the twin, model the recovery, act only on your approval.

The Capacity & disruption agent watches occupancy, queues and flow across the hospital, and when the HORUS digital twin projects a breach it drafts a recovery plan — defer electives, open surge beds, reroute admissions — with each option scored by a live discrete-event + Monte-Carlo simulation before anything moves. It is safe by construction: every plan is a recommendation that a charge nurse, bed manager or duty officer accepts, edits or rejects, and on accept it executes through the same bed-board and queue workflows staff already use. It runs on the Operational plane only — it reasons over flow and capacity, never a patient chart.

Recommender-firstHuman sign-offPlane-isolatedOn-box AI option
horus — decision twin · initiative workbench
DemandCapacityWorkforceSupplyReimb.QualityCompliance7 agents · DES + Monte-Carlo

Open step-down unit (12→10 beds, budget-capped)

optimized

Renegotiate NHSO scheme — denial rate 18%→9%

4 sign-offs pending

In-source blood supply — 3 scenario runs

decided

HITL gate · 4 sign-offs release optimized → decided

COO ✓Service Lead ✓Finance ✓Clinical Director…

What it senses

The signals it watches for you

It reads across the systems you already run — on the medOS event substrate — and surfaces the issue while there is still time to act.

Occupancy bands

Ward and unit occupancy against surge thresholds — flagged as a band is crossed, before gate-level disruption sets in.

Bed state machine

The bed board's live status transitions (occupied / cleaning / blocked / pending-discharge) and turnover lag per ward.

Department queues

department_queues depth and wait by dept type — ER boarding, admission-pending, transfer-incoming — as the leading edge of a breach.

OR & elective schedule

The OR list and elective bookings whose downstream beds the twin can free by deferring.

Twin demand projection

The HORUS demand agent's DES arrival forecast (Poisson, calibrated on real history) for the next shift and day.

Admission & transfer flow

Inbound admission requests and inter-ward transfer requests competing for the same constrained beds.

What it proposes

Drafted work, never an autonomous act

Each item lands in the Acknowledgement Inbox with its reasoning and a confidence score. Nothing is sent, charged or changed until a human accepts.

proposalconf 0.84

Open surge capacity

Twin projects Med-Surg 4E at 104% by 22:00 — open 6 surge beds in the step-down annex; P50 occupancy falls to 91%, boarding clears in ~40 min.

AcceptEditReject
proposalconf 0.79

Defer a block of electives

Defer 3 of tomorrow's 11 elective ORs (lowest-acuity, non-time-critical) to free 3 ward beds; recovery plan holds occupancy under the surge band across P10–P90.

AcceptEditReject
proposalconf 0.81

Reroute incoming admissions

Route the next 4 stable medical admissions from 4E to 3W (currently 78%); simulated ER boarding wait drops from ~95 min to ~30 min.

AcceptEditReject
proposalconf 0.76

Stage discharge-ready patients

Flag 5 pending-discharge beds for early turnover and prioritise cleaning; nets ~3 usable beds by 18:00 with P50 confidence the breach is averted.

AcceptEditReject

The loop

Sense → propose → approve → execute

01

Sense

Reads occupancy bands, the bed state machine, department_queues and the twin's demand forecast to detect a projected capacity breach before it bites.

02

Propose

Drafts a multi-lever recovery plan — surge beds, elective deferrals, admission reroutes — and scores each option with a live DES + Monte-Carlo twin run (P10/P50/P90).

03

Approve

The plan lands in the Acknowledgement Inbox for a bed manager or duty officer; they accept, edit or reject, and that disposition is the training signal.

04

Execute

On accept, the agent calls the same bed-board, queue-transition and admission-routing endpoints staff use — no shadow write path, one funnel into the systems of record.

Capabilities

What it can do

Twin-driven surge response

Reads breach signals straight from the HORUS capacity agent and assembles a multi-lever recovery plan — surge beds, deferrals, reroutes — rather than a single blunt action.

Quantified by Monte-Carlo

Every option is scored by the twin's discrete-event simulation across P10/P50/P90 outcome bands, so you see the expected effect and its spread, not an LLM's guess.

Bed & OR optimisation

Balances ward occupancy and elective throughput together — finding the deferrals and reroutes that relieve the constraint with the least disruption to scheduled care.

Re-accommodation playbooks

Drafts concrete patient-movement plans — which admissions reroute where, which beds open, in what order — ready to hand to the bed board on accept.

Leading-edge detection

Surfaces the problem while there is still time to act: a band crossing or a queue trend, projected forward by the twin, not an after-the-fact alarm.

Budget- and rule-aware

Honours rule-row constraints — staffed-bed caps, ward limits, surge ceilings — so a proposal of 12 beds is pruned to the 10 you can actually staff.

Decision-trace recommendations

Each plan carries its full reasoning, the twin run it was scored on, and a confidence score — auditable and reviewable before anyone signs.

Not a black box

Why it is safe to run

Autonomy without guardrails is a liability in a hospital. These are the constraints that make this agent safe to put to work.

Operational plane only

Scoped to the Operational data plane at the database grant level. It reasons over beds, queues and flow — it literally cannot read a patient chart.

Recommender-first, human gate

Every recovery plan is a proposal. Opening surge beds, deferring an OR or rerouting an admission only happens after a named human accepts — no capacity move runs hands-free.

Quantified, not asserted

Proposals are scored by the HORUS twin's discrete-event simulation, not an LLM hunch. You see the modelled effect and its P10–P90 spread before you sign.

Audited per decision

Each plan is logged with its full reasoning trace, the twin run it cites and a named agent identity — every proposal and disposition is attributable.

Data plane

Runs on the Operational data plane, isolated at the database grant level — it reads beds, queues and flow but is structurally unable to read a patient chart.

Operating characteristics

What changes when it runs

24/7

Always-on flow watch

Monitors occupancy and queues every shift, including nights and weekends

Pre-breach

Acts before the gate jams

Surfaces the recovery while there is still time, not after boarding starts

P10–P90

Every plan simulated

Monte-Carlo bands on each option, not a single point estimate

0 autonomous moves

No bed opens itself

Capacity changes require human accept — by design, not policy

Works on your stack

Reads and writes where you already work

On accept, it calls the very same endpoints your staff use — no shadow write path, no second source of truth.

HORUS digital twin (demand + capacity agents)twin_metric_* calibration RPCsBed board + bed state machinedepartment_queues read modelqueue-transition workflow endpointsAdmission & transfer request routingOR / elective scheduling listAcknowledgement Inbox

Questions

Frequently asked

Can it open beds or defer surgery on its own?

No. It drafts the plan and scores it; opening surge beds, deferring an OR or rerouting an admission only executes after a named human accepts. No capacity move ever runs hands-free — that is enforced by design, not policy.

Where do its numbers come from — is it just an LLM guessing?

No. Every option is scored by the HORUS digital twin's discrete-event + Monte-Carlo simulation, calibrated on your real bed logs and arrival history. You see modelled P10/P50/P90 outcomes, not a language-model hunch.

Does it read patient charts?

No. It runs on the Operational plane, isolated at the database grant level. It reasons over occupancy, queues and flow — it cannot read clinical records at all.

How does it learn?

From you. Every accept, edit and reject on a proposed recovery plan is the training signal — over time it proposes the levers your bed managers actually choose, in the order they prefer.

When it executes, does it create a parallel system?

No. On accept it calls the same bed-board, queue-transition and admission-routing endpoints your staff use. There is one funnel into the systems of record and no shadow write path to reconcile.

Can the simulation and inference run on our own hardware?

Yes. The twin runs on your infrastructure and any LLM narration can run on-box via Ollama, so operational data and PHI can stay in the building — air-gapped deployments are supported.

Put Capacity & disruption agent on your floor

See it draft real work against your own workflows — every action under human sign-off.

Ask Anything