Skip to main content

Public Roadmap

Free. Forever. For everyone. πŸš‘ That's not a tagline β€” it's a promise.

TrainingMonitor.App is built by EMS educators, for EMS educators β€” and this roadmap is our public commitment to the community that trains tomorrow's paramedics.

Here's what you'll find:

  • πŸ“‹ Planned β€” features we're committed to building

  • ⚑ In Progress β€” what's actively being developed right now

  • βœ… Completed β€” everything we've already shipped

We believe the best training tools shouldn't cost thousands of dollars. Competing platforms charge $1,000+ per year for software capabilities we're delivering completely free.

πŸ‘‡ This is your roadmap as much as ours. Vote on what matters most to you. Watch us build. Hold us accountable.

We're on a mission to build the most capable free patient monitor simulator in existence β€” one update at a time. πŸ’ͺ

🌐 TrainingMonitor.App · 🏒 Sponsored by MedTechKits.com

Researching

8

Under consideration

Feature Request

Full frame Mode

A Full Frame Mode for Tablet Users which allows to visualize all the Vitals and Buttons without the need of Scrolling.

Feature Request

Mini CAD - Computer-Aided Dispatch Simulation

A second screen/panel that delivers scenario context the way a real EMS crew receives it: dispatch tones, call card, address, optional map preview, and the ability to push en-route updates. Components to build: - Dispatch tones and voice (pre-recorded or synthesized) - Call card: call type, address, caller info, age/sex, chief complaint, dispatch notes - Map view: static map tile or simple route line (OpenStreetMap recommended) - En-route updates: controller can push mid-response updates - Pre-arrival info: pertinent history if dispatch has it - Timestamps: dispatch, en-route, on-scene, transporting, at-hospital (auto or controller-stamped, feeds event log) Architectural fit: extends TMA's existing Controller/Display architecture. Controllers gain a CAD tab in session controls. Scenarios in the existing library can carry an optional cad block (call type, address template, dispatch notes) so loading a scenario auto-populates dispatch. Recommended starting scope: ship the call card + dispatch audio + en-route updates first. Defer maps and full CAD-vendor styling. Delivers most of the teaching value at a fraction of the build cost. Note: almost no free tool offers this. Pulls TMA toward free EMS scene simulator positioning - a deliberate positioning decision is needed before v2 ships.

Feature Request

Reference Library - ECG, Capnography, and Waveform Encyclopedia

A built-in, browsable, searchable encyclopedia of every waveform and rhythm TMA can render. Usable both as a standalone study tool (no session required) and as a quick lookup during active sessions. Each entry is a live, animated rendering using TMA's existing rhythm/waveform engine - not static images. Sub-libraries confirmed for v2: ECG Rhythm Library: Every rhythm TMA supports (50+). Each entry includes a live animated strip, rhythm name and common synonyms, AHA/ACLS classification, rate range/regularity/P-wave/PR/QRS details, key identifying features and common look-alikes, common causes, and a Load into active session button (controllers only). Ectopy Library: Dedicated section for ectopic beats - PVCs (unifocal, multifocal, coupled, bigeminy, trigeminy, R-on-T), PACs, PJCs, and escape beats. Each entry shows the underlying rhythm with the ectopic beat in context and labeled callout overlays. Capnography Library: All 15 waveforms with live animation, phase labels (I, II, III, 0), typical EtCO2 range, and clinical correlation. Stretch sub-libraries to consider: Pleth waveform library, 12-lead presentation library (pairs with v1.5), alarm sound library. Strategic value: reuses existing rendering engine at low engineering cost, creates a non-session use case driving traffic, significant SEO opportunity (high-volume search queries like what does torsades look like), and evergreen content for MedTechKits.

Feedback

case media

One feature that would be huge for EMS simulation would be a temporary case-media upload option inside the monitor app. The instructor could upload a 12-lead, scene photo, patient presentation image, med list, or other case-specific visual. Students could access it during the scenario through a tab on the monitor, use it for clinical decision-making, and then the image would clear when the simulation ends. It would create faster engagement, more realistic decision-making, and a stronger bridge between classroom scenarios and actual patient care without permanently storing sensitive images.

Feature Request

Per-Beat Pleth PTT Variability

Real Pulse Transit Time (PTT) varies slightly beat-to-beat due to respiratory variation and other physiological factors. Adding subtle randomization of +/-10-20 ms per beat would increase the realism of the pleth waveform. In v1, PTT is a fixed value per the slider setting. This feature adds optional per-beat variability around the set value. Deferred from v1 - low priority but meaningful for advanced realism. Can be implemented as an optional toggle for instructors who want maximum physiological fidelity.

Feature Request

Live camera feed + recording for instructors

Let the instructor view the learner's device camera live during a session, with a separate one-click "Record" action to save video+audio to a folder on the instructor's own machine (not cloud storage). Requires camera/mic permission on the student's device. Since our controller and display already run on separate physical devices connected over the network, this needs genuine real-time video streaming between two devices (WebRTC β€” peer-to-peer video, typically needs a small signaling server, sometimes a relay server for restrictive networks). This is a multi-day engineering feature, not a UI toggle.

Feature Request

Two-Way Radio Simulation

Simulated two-way radio with an instructor (controller) handset and a student (field) handset/display. Channel switching mimics the real-world distinction between dispatch, hospital-direct, and tactical frequencies. Students push-to-talk; instructors play different roles on different channels (dispatcher, ED charge nurse, IC, medical control). Components to build: - Radio display (student side): channel name, signal indicator, last-traffic timestamp, PTT button, mimics a real handset/console - Channel list: Dispatch, Hospital 1, Hospital 2, Tac 1, Tac 2, Med Channel, etc. Configurable per session - PTT (push-to-talk): browser microphone capture, transmits to anyone on the same channel - Controller voice: instructor speaks as dispatcher, ED charge nurse, IC, medical control, switching channels to play different roles - Recording: every transmission logged with timestamp, channel, speaker - powerful for debrief - Selective audibility: students on Tac 1 do not hear Hospital 2 traffic - Optional radio reception artifacts: static, breakup, key-up tones (skinnable) - Async/text fallback: type your transmission, others see it as a transcribed radio call Key engineering challenges: - WebRTC for live voice adds infrastructure (TURN servers, signaling) - a real complexity jump from TMA's current state - Latency and quality: bad radio sim is worse than no radio sim - Bandwidth and hosting cost: voice is expensive at scale; TMA is free forever so this needs a sustainability plan - Browser permissions: microphone access prompts, iOS Safari quirks, classroom IT policies that block WebRTC Strategic note: real radio comms training is a major gap in EMS education with almost no free tools addressing it. However this is the most engineering-heavy and cost-heavy feature in the v2/v3 brainstorm and most clearly redefines what TMA is. Recommended sequencing: ship Reference Library first, then Mini CAD, then Two-Way Radio - giving the positioning question time to resolve and validating demand before the largest investment. Open questions before spec: voice (live WebRTC) vs async/text vs hybrid; hosting cost projection at concurrency; integration with CAD or independent ship; radio procedure scope (US EMS / UK ambulance / generic); browser audio compatibility audit.

Feature Request

Sensor Location Parameter for Pleth PTT

A sensor location dropdown (finger, ear, toe, forehead) that adjusts the default PTT range to reflect the chosen anatomy: - Ear: shorter PTT (proximal to heart) - Finger: middle range (current default) - Toe: longer PTT (most distal) - Forehead: shorter PTT (reflectance oximetry) Useful for advanced scenarios that simulate sensor placement decisions or teach the physiological basis of PTT differences by site. Deferred from v1 due to added complexity.

Planned

1

Committed and queued

In Progress

6

Actively being built

Feature Request

12-Lead ECG View

Extend the ECG display to support a 12-lead view alongside the existing single-lead waveform. Rather than a generic 12-lead generator, ship a curated library of clinically meaningful presentations: Anterior STEMI, Inferior STEMI, Lateral STEMI, Posterior STEMI, LBBB, RBBB, Hyperkalemia (peaked T waves), Pericarditis (diffuse ST elevation with PR depression), Wellens syndrome, AFib in 12-lead view, and VTach in 12-lead view. Controllers select the 12-lead presentation from a dropdown analogous to the existing rhythm dropdown. The monitor renders all 12 leads in the standard 3x4 grid layout with a rhythm strip at the bottom. Single-lead view remains the default; controllers toggle into 12-lead mode when the scenario calls for it. Pairs with the cardiac scenario library - STEMI scenarios should auto-suggest the appropriate 12-lead presentation when loaded.

Feature Request

Transcutaneous Pacing

Add transcutaneous pacing as an extension of the manual defibrillation panel. Controller exposes a Pacing mode toggle; when enabled, the controller sets a pacing rate (30-180 bpm) and current output (0-200 mA in 5 mA increments). The monitor displays pacing spikes preceding each captured beat in the ECG waveform. Capture is controller-determined via a Capture toggle. When capturing: rhythm shows wide complexes following each pacing spike at the set rate. When not capturing: pacing spikes appear without consistent QRS response. This teaches the clinically critical distinction between pacer firing and pacer firing AND capturing. Pacing events log to the event log with rate, output, and capture state.

Feature Request

Custom Scenario Authoring

Allow controllers to save the current state of a session as a custom scenario for future reuse. A Save as Scenario button on the controller opens a small form: scenario name, scenario group (from the existing 12 groups or a Custom group), patient population, and brief clinical context note. On save, the system serializes all current vital values, rhythm, ectopy, capnography waveform, threshold preset, and pleth parameters into a scenario object using the same data model as system scenarios (the v1 spec includes a system: true/false flag for this). Saved scenarios appear in the scenario library modal in a My Scenarios group, accessible to that controller. v1.5 ships with author-only access. Future releases will add scenario sharing via export/import (JSON) and shareable links.

Feature Request

One-click PEA toggle

Add a switch that applies pulseless electrical activity to whatever rhythm is currently selected, instead of PEA only existing as its own separate preset. In real life PEA means the heart's electrical signal looks normal but there is no effective pumping, so the actual training goal is teaching students to ch eck for a pulse even when the monitor looks fine. We tested this on a competitor app. Turning the switch on kept the ECG exactly the same, since the rhythm itself does not change. SpO2 went flat, since there is no real blood flow for the pulse oximeter to detect. EtCO2 dropped a bit but not to zero, since less blood is circulating to carry carbon dioxide back to the lungs. For our version, the rule should be that this switch only affects SpO2 and EtCO2, and never touches the ECG rendering. That is the detail that keeps this teaching the right lesson. Right now we do not have any way to trigger PEA in our controller at all, there is leftover code for it but nothing in the interface actually uses it.

Feature Request

Session recording and playback for debrief

Let instructors record a session as it happens and play it back afterward for debrief β€” watching the monitor replay exactly what occurred (vitals, waveforms, rhythm changes, shocks, pacing) instead of just reading a text log of events. Playback should run at the same real-time speed as the original session by default, since timing is often part of the lesson (e.g. how long it took to shock or start compressions). It should also support fast-forwarding through quiet stretches, jumping straight to a specific event, and pausing to discuss a moment. This is different from our Event Log (a written summary) and from Scenarios (a preset starting point loaded before a session begins) β€” this captures what actually happened during a specific live run.

Feature Request

Automatic patient deterioration and recovery

For pulseless/arrest rhythms (like VFib or Asystole), let vitals automatically get worse over time β€” SpOβ‚‚, EtCOβ‚‚, and BP falling β€” instead of staying wherever they were last set. Then, when the instructor delivers a successful shock or achieves effective pacing capture, have those vitals automatically recover, including EtCOβ‚‚ climbing back up to simulate return of a pulse. This makes arrest scenarios feel alive instead of static: a student who delays treatment sees the real consequence (falling numbers) without the instructor manually adjusting sliders every few seconds, and a correct intervention is visibly rewarded with improvement. This needs careful clinical input on the actual decay/recovery rates before it ships β€” getting them wrong (e.g. recovering too fast) could undersell the urgency of good compressions or a fast shock, which would teach the wrong lesson.

Done

10

Recently shipped

Feature Request

Manual Defibrillation

Extend the existing AED Trainer architecture to support manual defibrillation. Add an AED/Manual toggle in the AED panel. In Manual mode, the controller exposes energy selection (50-360J in standard increments: 50, 70, 100, 120, 150, 200, 300, 360), a Charge button, and a Shock button. The shock workflow mirrors real device behavior: select energy, charge (with audible charging tone and ready indicator), shock. Add a Sync mode toggle for synchronized cardioversion - when Sync is on, the device waits for the next R-wave before delivering the shock and energy ranges shift to cardioversion-appropriate values. Post-shock rhythm outcome is controller-determined. All shocks log to the event log with energy, sync state, and resulting rhythm.

Feature Request

Live monitor preview for the instructor

Show a small live copy of the Display Monitor directly on the Controller page, so the instructor can see exactly what the student sees without needing a second screen or asking the student what their monitor shows. We tested this on a competitor app. It shows up as a small panel embedded right in their instructor control screen, updating live as things change, not a separate window. Where exactly this sits in our layout is a design decision for whoever builds it, our current controller page has room for a new panel or a collapsible section. The important part is that it stays live and updates in real time, since our display monitor already has all the rendering and data polling built, this would reuse that rather than building a second version from scratch.

Feature Request

Grouped Perfusion Parameter

A single Perfusion slider that adjusts Pleth Amplitude, Pleth Morphology, and Pleth PTT together along realistic physiological curves, with a toggle to decouple for advanced scenarios. In v1 the three pleth controls are independently adjustable - ideal for power users. The Perfusion grouped parameter is the long-term direction for instructor ease-of-use, allowing a single drag from Normal to Severe Shock with all three parameters adjusting together realistically. A decouple toggle lets instructors break out of grouped mode for advanced or atypical scenarios. Should only be built after the three independent v1 controls have been validated.

Feature Request

Auto-Coupled Pleth Signal Loss at Low Perfusion

At very low PTT settings combined with very low Pleth Amplitude, real monitors lose the pleth signal entirely and display SpO2 unable to read. Simulating this signal-loss threshold is a meaningful teaching scenario. Proposed behavior: when Pleth Amplitude falls below ~10% AND PTT is at or near maximum (450+ ms), the SpO2 channel should drop the pleth waveform, display SpO2 as ---, and trigger an SpO2 INOP alarm. This teaches students that peripheral SpO2 measurement becomes unreliable in severe shock or profound vasoconstriction. Deferred to v1.5 - in v1 the waveform always renders if amplitude > 0%.

Feature Request

ECG not working

Thank you very much for your work! I have designed something similar a long way back And I know how much effort goes into such things. You are great! Sadly, the ecg does not seem to be working. It just shows a sinus rhythm, independent of the set rhythm (eg. asystoly). Maybe its just me, but you might want to have a look at it. Kind regards and keep up the good work! Florian Schwander, Switzerland

Feature Request

Refresh Page

It seems you have to refresh the page to apply changes to the ecg! But only to the ecg, the other graphs work fine.

Feature Request

QR Code

Hello team, Are you able to help me? I have been trying to use your website for mini simulations. I connect my phone to a laptop via the QR code to have my phone as the controller and the laptop as the display. The issue is that I have to keep pressing enter to change the observations on the display monitor. Sometimes observations will change but not all of them. Are the observations meant to change one by one, is there something I am meant to be doing? Any help would be appreciated.

Feature Request

Paramedic

I was using the display monitor and had a couple of suggestions. If V-tach is selected and the rhythm is shocked, it would be really helpful if the shock could also be shown on the display monitor. Also, would it make more sense for the person participating in the simulation to be the one who can charge and shock the patient on the display, rather than the instructor? That seems like it would make the scenario feel more realistic and hands-on. I also noticed that torsades de pointes does not appear to be available as a displayed rhythm.

Feature Request

Monitor

Having had a brief play to get a feel of the system, I feel that it would be more beneficial to have the Analysis, Charge & Shock buttons on the system used by the students, I also feel that the layout could be worked a little differently so that all sections can be viewed at once when using the monitor on a landscape iPad/tablet.

Feedback

Educator

Pulseless VT shows pleth at wrong rate. Truthfully, VT and other pulseless events should not show SPO2 pleth as that is a reflection of pulse.