Building a Clinical Simulator in the Browser: The ACLSMED Development Story

Building clinical simulation software as a clinician-developer means you can't hide from the accuracy. Every decision about how patient state propagates, how rhythms respond to drugs, how the ventilator interacts with the cardiac monitor — a bedside nurse already knows what those should look like.

The ACLSMED Clinical Suite started as a constraint problem: how do you build a multi-device ACLS training environment that runs in a browser, requires no installation, handles real-time synchronized patient state across a cardiac monitor, an IV pump, and a ventilator — and is clinically accurate enough that a CSICU nurse doesn't wince using it?

Why browser-native?

The original constraint wasn't a technical preference — it was a distribution problem. Simulation software that requires IT approval, local installation, and Windows-specific builds doesn't make it into hands-on learning moments. Nurses who want to practice before a recertification exam don't want to download a 2GB package. Browser-native meant accepting certain constraints, but the tradeoffs are worth the distribution advantage.

The synchronized patient state problem

The hardest engineering problem in the ACLSMED suite isn't the cardiac monitor or the ventilator individually — it's the synchronized patient state across all three devices.

In a real ICU, the monitor, the ventilator, and the pump don't operate independently. The devices reflect and influence each other. Training on isolated devices teaches isolated skills — not the integrated clinical thinking that real management requires.

The solution: a single broadcastPatient() event architecture that propagates a unified patient state payload across every connected device simultaneously via the browser's BroadcastChannel API. When the scenario changes — rhythm, vitals, oxygen saturation, intubation status — one broadcast updates everything.

// Single source of truth — propagates to all devices
broadcastPatient({
  rhythm: 'vf',
  hr: 0, sbp: 0, dbp: 0,
  spo2: 72, etco2: 18, rr: 0,
  intubated: true,
  scenario: 'refractory-vf',
  cxrData: { filename: 'pulmonary-edema.png', label: '...' }
});

The chest X-ray that appears in the respiratory module, the waveforms on the cardiac monitor, the alarm state on the IV pump — all sourced from the same event. No synchronization drift. No device showing a different patient state than the others.

Clinical accuracy as a hard constraint

The clinical accuracy bar for simulation software is higher than for most software categories, because the failure mode is specific: a clinician trains on incorrect drug timing, incorrect waveform morphology, or incorrect physiological response — and carries that incorrect mental model into a real clinical event.

Every ACLS medication in the suite has a defined onset window, a defined hemodynamic response curve, and a defined interaction with the current rhythm. Amiodarone in VF doesn't immediately terminate the rhythm — it reduces recurrence probability after defibrillation. Atropine in a complete heart block doesn't produce the expected rate response. The simulator reflects both.

The 34-scenario architecture

The ACLSMED suite ships with 34 MegaCode scenarios, each built around a distinct patient identity, presenting rhythm, and clinical trajectory. The design decision behind 34 was deliberate: cover every major ACLS algorithm branch with enough variation to prevent pattern-matching to a specific case, but keep the library curated enough that educators can assign specific scenarios without sifting through noise.

Each scenario has a unique patient name drawn from 16 distinct heritages — a fidelity choice, not a diversity checkbox. Real codes happen to real people with real histories.

What the development timeline actually looked like