A hospital ward you can actually walk around, built to ask one question: does continuous glucose monitoring with telemetry help a nurse find deteriorating patients sooner than routine monitoring would - and what does it cost the rest of the shift?
Academic model - not clinical decision support. Every threshold and treatment pathway below is a simplified, configurable placeholder. It must not be used to inform patient care. What that means
Waiting for the simulator to start...
Academic model - not clinical decision support.
Bedside actions apply to the bed you are standing next to.
YouThe nurse you control. The tall white cap with the raised centre is unique to you.
Staff nurseA colleague on the ward. Plain white cap - the same family as yours, one step down.
Healthcare assistantNo cap, and carrying a tray. Helps with checks, point-of-care tests and discharge prep.
DoctorLong white coat and a stethoscope. Reviews, prescriptions and medical escalation.
SurgeonGreen scrub cap and mask. Reviews and discharge decisions for surgical patients.
Diabetes specialist nurseCap plus a shoulder bag strap. The specialist escalation route for glycaemic events.
Patient walkingA patient out of bed - arriving, transferring or going home - with a drip stand.
Empty bedMade up and free. A free bed can take the next admission from the queue.
Bed left unmadeThe patient is off the ward or walking. The bed is still theirs, so it is not free.
Nurse stationThe telemetry board. Standing here refreshes it for free; from elsewhere it costs a step.
Board alarmingThe monitor reddens while any alarm is unresolved.
Drug roomWhere treatments are drawn up.
Ward doorsAdmissions arrive here and discharges leave through it.
Occupied bedEach patient keeps one blanket colour for the whole shift, so you can follow them from bed to door.
Drawn on a patient's bed. Colour always means clinical state.
On telemetryThis patient is enrolled and their sensor is reporting.
Signal lostEnrolled, but the sensor has dropped out. It does NOT alarm - noticing is the point.
HypoglycaemiaGlucose below 3.9 mmol/L.
Severe hypoglycaemiaBelow 3.0 mmol/L. Left untreated this is what ends a shift badly.
HyperglycaemiaAbove 14.0 mmol/L, or above this patient's own threshold if one is set.
Falling fastA rapid downward trend, before any threshold is crossed.
Rising fastA rapid upward trend.
Point-of-care testA finger-prick reading. It is trusted over the sensor.
Treatment givenTreatment is in progress; glucose responds over the following half hour.
Ready for dischargeShown only once you have established it - the ward knows before you do.
Bed in reachThe bed a patient-directed key would act on.
Give it a few seconds, then press the green button. Best on a desktop or laptop with a keyboard. Open full screen Source code
Every treatment pathway, threshold and timing in this simulator is a simplified, configurable, guideline-inspired placeholder chosen to make the model behave plausibly. None of it is prescribing guidance or bedside instruction, and it must not be used to inform real patient care.
You are the nurse or shift coordinator on a 32-bed mixed medical and surgical ward. One shift is twelve hours; every decision takes five minutes. A telemetry dashboard at the nurse station shows glucose for the patients wearing a sensor - when the sensor is working, which is not always, and it does not announce when it stops.
Meanwhile there are patients to assess for the monitoring programme, notes to read, consent to seek, discharges to chase, and an admissions queue building behind you. The interesting part is not any single decision; it is what you stop doing in order to do it.
Insulin regimen, capacity to consent, true glucose, whether a colleague is free - none of it is visible until you spend a step finding out. Even the glucose readings are a snapshot from the last time you checked the board, and they go stale.
Readings lag, drift and occasionally spike. A capillary test is the reference, and clinically significant alarms are meant to be confirmed before anyone is treated.
When a sensor drops out it raises no alarm at all. The only cue is data that stopped arriving - which somebody has to notice.
The reward function is deliberately lopsided. Preventing harm is worth an order of magnitude more than tidy paperwork or a short queue.
The shift is 144 steps of five minutes - twelve hours. At step 144 it ends, the panel says shift complete, and any key starts a fresh one on a new random seed. A shift can also end early, in one of two ways: the ward becomes unsafely overcrowded, or a patient comes to serious harm. The headline measure the model exists to report is the proportion of shifts that finish without one.
No - and it is worth being precise about that. What you are watching is a hand-written rule-based nurse: a fixed set of priorities - answer alarms, confirm with a capillary test, treat, escalate, keep beds moving. It reacts to what it can see, but it has not learned anything.
What the project actually provides is the environment: a Gymnasium-compatible partially observable Markov decision process that a reinforcement-learning agent can be trained against. The repository ships a worked PPO training script, but no trained policy - training runs are research work, not part of this demo. The rule-based nurse exists to be a fair, transparent comparator, not to be good at the job.
Nor is the outcome pre-determined. Every shift is a fresh draw: arrivals, physiology, sensor faults and staff availability are all stochastic. Re-running the same seed replays a shift exactly, which is what makes the telemetry-versus-routine comparison a matched one - but you cannot know in advance how a given shift will go.
The comparison built into the model is telemetry versus routine monitoring, not telemetry versus nothing. Every patient still receives routine capillary rounds and symptom recognition; monitoring is additive. The question is whether the alarm gets there first, and by how much it changes the shift.
Both arms run on matched random seeds, so they simulate the same ward. The measures are:
Across 60 matched shifts, among the patients actually wearing a sensor, about two thirds of hypoglycaemic episodes were picked up with telemetry against about a third without. That difference holds up. The apparent halving of detection time does not - only ten episodes were ever found in the comparator arm, and the uncertainty around that figure is far too wide to claim anything from it.
Reporting both is the point. It would have been easy, and wrong, to quote the timing on its own.
Measured across the whole ward, that difference nearly disappears - and that is the more interesting result. Only about one patient in seven meets the eligibility criteria, so a large improvement for a small group barely moves a ward-level average. A real study would need to be powered for the monitored cohort, and would have to decide whether a ward-level effect is the right thing to look for at all.
It is a simulation of a workflow model, so it cannot demonstrate clinical benefit. What it can do is show whether a mechanism plausibly produces one, and which assumptions that conclusion rests on - which is the useful thing to know before designing a real study.
Built alongside an MRes in Clinical Research at Imperial College
London, on the diabetes and obesity pathway. The full formal
specification - the POMDP definition, observation and action spaces,
transition dynamics and reward weights - is in the repository under
docs/POMDP.md.