How Pulse works

A hospital is a real-time logistics system. Pulse closes the loop.

Pulse ingests the live signals a hospital already produces, predicts where bottlenecks will form hours ahead, and turns each prediction into a specific, explainable, human-gated action — then fans out the downstream work automatically. Below: the orchestration loop, a concrete example, the runtime that powers it, and the one color language every board speaks.

01 · The system

The closed orchestration loop

Signals flow into a canonical event bus, the optimization brain predicts and solves against them, ranked recommendations surface in the command center, a caregiver accepts or overrides, and one tap fans out into real work — which loops straight back into the bus as new signal. Every accepted action is measured, building a trust ledger over time.

closes the loop ↺ new state becomes new signal Hospital systems & signals EHR / ADT · RTLS · nurse call labs · monitors · EVS / transport the live feed that already exists Canonical Event Bus one normalized stream of snapshots + events live simulation today · real feed tomorrow Optimization Brain explainable weighted sums — factor × weight = contribution PREDICTORS admit prob · wait p50/p90 deterioration · accept-likelihood SOLVERS bed placement · backfill cascade capacity / surge · boarding forecast Recommendations & Alerts ranked by urgency × score explainable · SLA-routed to owners with auto-escalation ladders Command Center UI Mission Control · ER Flow · Beds & EVS · Staffing · Feed every screen ends in an action, not a number to stare at Caregiver decision — human-gated Accept ✓ or Override ↺ nothing auto-executes silently Fan-out assign bed ⇒ EVS job + transport + unit alert backfill ⇒ shift offer Outcome tracking proposed → accepted → executed → outcome measured against baseline Trust ledger boarding hours avoided agency shifts & moves avoided trust is earned, then proven ingest predict surface decide on accept
02 · In practice

One boarder, one tap, one closed loop

The same loop, traced through a single real event: an ED admit that becomes a boarder, the brain's best-fit clean bed, a charge-nurse accept, and the downstream work that fans out automatically — ending in measured boarding hours saved.

1

Admitted in the ED

An ADT admit event lands on the bus. The patient now needs an inpatient bed.

signal
2

Becomes a boarder

No bed yet — the clock starts. Boarding pressure climbs the urgency scale.

watch → urgent
3

Brain ranks best-fit bed

Solver scores every clean bed against hard + soft constraints — with a "why this bed" breakdown.

solve
4

Charge nurse accepts

One tap. Human-gated — the nurse can override to any ranked alternative instead.

accept ✓
5

Fan-out, automatically

Old bed vacated → EVS job + transport dispatched + receiving-unit alert raised in the feed.

downstream
6

Hours avoided, tallied

The boarding hours and moves saved post to the trust ledger — proven, not assumed.

measured
03 · Under the hood

The runtime — and why it's integration-shaped

Today a deterministic in-browser engine plays the hospital. But the boundary between the data source and the UI is the exact contract a real hospital feed would use — a live snapshot plus an event stream. That single design choice is what makes the simulation swappable.

Deterministic Sim Engine
engine.tick(world, dt, rng) returns a new WorldSnapshot each tick — advance clocks, fire stochastic events, apply reducers, recompute predictors, run the brain.
↓ commit once per tick
Zustand Store
The single live snapshot + sim controls (world, running, speed). This is the contract. A snapshot plus an event stream.
↓ fine-grained subscriptions
Selector hooks
useEdPatients · usePlacementQueue · useOpenGaps · useProposedRecs · useMetrics — each component reads only the slice it needs.
↓ render
React command center
'use client' islands — Mission Control, ER Flow, Beds & EVS, Staffing, Feed — dispatching user actions back through actions.ts.
Going live changes one layer. Swap the engine tick for a real SSE / WebSocket / FHIR-Subscription feed and nothing above the store changes — store, selectors, and every component stay exactly as they are.
04 · The language

One urgency scale, one acuity ramp

A single color language means a dirty-too-long bed, an SLA-at-risk wait, and a ratio breach all read identically across every board. It is deliberately the only saturated color in the product — so a separate sequential acuity ramp (ESI 1–5) never collides with it.

Clinical urgency scale

Status of any orchestrated item — every board speaks this.

ok stable — within target, no action needed
watch caution — drifting toward a threshold, keep an eye on it
urgent act now — SLA at risk, queue this for action
critical breached / unsafe — escalate immediately

ESI acuity ramp (1–5)

Patient acuity — a separate sequential scale, never urgency.

1
2
3
4
5
resuscitationemergenturgentless urgentnon-urgent

Two scales, two jobs: urgency tells you what to do next; acuity tells you how sick the patient is. Keeping them visually distinct is a safety decision, not a style one.

Pulse is a Next.js client-rendered command center over a deterministic in-browser simulation. Core docs: docs/ARCHITECTURE.md · docs/CONCEPT.md. The store contract is intentionally identical to what an ADT / HL7 / FHIR feed would push.