🩸 Combat Medic AI Decision Support Under Fire
This simulation provides artificial intelligence-based decision support for combat medics operating under enemy fire. It helps medics make critical decisions in high-stress situations to optimize patient care and survival rates.
Sensor Data Fusion at the Point of Injury
The first seconds after a casualty falls are the most information-poor and decision-critical moment in trauma care. A combat medic — often a 19-year-old with a few weeks of dedicated medical training — must interpret bleeding, breathing, and consciousness under direct fire, in the dark, through smoke, while being shot at. Wearable sensor fusion aims to replace guesswork with continuously streamed, objective physiology.
- ~25%: Potentially survivable deaths (of combat deaths, per DoD trauma data)
- Hemorrhage: Leading preventable cause (~90% of survivable battlefield deaths)
- ~16 wks: Typical combat medic training (vs. years for a physician)
- Minutes: Time to hemorrhagic shock (from major vascular injury)
Why decision support, not just monitoring
Standard combat casualty care already relies on Tactical Combat Casualty Care (TCCC), the doctrine that has driven battlefield mortality down since the 1990s by prioritizing hemorrhage control (tourniquets, hemostatic dressings) ahead of airway and breathing in the "care under fire" phase. TCCC works because it compresses a complex clinical decision tree into a short memorized sequence: MARCH — Massive hemorrhage, Airway, Respiration, Circulation, Hypothermia/Head injury.
But executing MARCH correctly still requires a human to notice the right signs, in the right order, while under extreme physiological and cognitive stress themselves. Studies of stress and cognition consistently show that working memory, pattern recognition, and protocol recall all degrade under acute threat — exactly the conditions a combat medic operates in. AI decision support does not introduce new medical knowledge; it removes the burden of noticing and recalling under duress, surfacing the next indicated TCCC step so the medic's limited attention is spent on execution, not deliberation.
What the sensors actually capture
A wearable physiological status monitoring (PSM) rig for this concept typically fuses several low-cost, low-power sensor streams into one packet transmitted to a handheld or heads-up device:
• Pulse oximetry (finger or ear clip): heart rate and SpO2, sampled continuously • Chest-worn patch: ECG-derived heart rate variability (HRV), respiration rate via impedance or accelerometry, skin temperature • Non-invasive or near-continuous blood pressure estimation: pulse transit time or photoplethysmography-derived surrogates, since a cuff is impractical mid-firefight • Motion/impact sensors: detect the casualty-producing event itself and timestamp "time of injury" automatically, which is otherwise often unrecorded or estimated after the fact
None of these signals alone is diagnostic. The value is in fusing them into a continuous multivariate trend line and handing that trend — not a single noisy reading — to both the medic's eye and the onboard model.
The handheld device as a shared decision surface
The handheld or wrist-mounted display is deliberately minimal: a scrolling readout of the fused vitals, a confidence indicator, and — once the AI has enough signal — a single recommended next action. Design research on decision aids for high-stress environments (aviation, emergency medicine, and now combat casualty care) converges on the same principle: under load, more information is worse than less. The device is built to answer one question at a time — "what do I do right now" — rather than present a dashboard the medic has no bandwidth to read.
AI Injury Pattern Recognition — Seeing Shock Before It Is Visible
Hemorrhagic shock is compensated for a surprisingly long time: the body vasoconstricts and raises heart rate to preserve blood pressure to the brain and heart, so a casualty can look stable — talking, alert — right up until they suddenly are not. Machine learning models trained on vital-sign trend patterns are being developed specifically to catch this compensated phase, before a human observer would.
- US DoD/CDMRP: CRI research funder (Compensatory Reserve Index program)
- Arterial waveform: CRI input signal (PPG feature analysis via ML)
- Often silent: Compensated shock window (BP holds until late decompensation)
- HR, HRV, SpO2, BP trend: Key predictive features (not single-point thresholds)
The Compensatory Reserve Index and trend-based shock prediction
One of the most concrete lines of real research behind this concept is the Compensatory Reserve Index (CRI), developed with funding from US military medical research programs (including the Department of Defense's Combat Casualty Care research portfolio). CRI does not read blood pressure directly; instead, machine-learning models analyze the shape of the arterial waveform (captured via a simple finger photoplethysmography sensor) and compare it against a library of waveforms from human subjects undergoing controlled blood-loss simulation (lower-body negative pressure studies). As blood volume is progressively reduced, the waveform morphs in a characteristic, learnable way — well before systolic blood pressure itself drops.
The result is a continuous 0–100% "reserve" score: 100% is a fully compensated, euvolemic state, and the score falls steadily as the body's compensatory mechanisms are progressively consumed, with clinically significant drops preceding hypotension by minutes. That lead time is the entire value proposition — it converts shock from something diagnosed after it becomes obvious into something predicted while it can still be preempted with fluids, hemorrhage control, and evacuation prioritization.
Research from lower-body negative pressure human studies has shown compensatory-reserve style waveform models can flag hemodynamic decompensation while standard vital signs — heart rate, blood pressure, SpO2 — remain within normal ranges. As one Army-funded research summary framed it: by the time a casualty's blood pressure has fallen, the body's reserve has often already been exhausted; the goal of trend-based prediction is to warn while reserve still remains.
From single thresholds to learned trend signatures
Traditional field triage relies on simple threshold rules: heart rate above 120, systolic BP below 90, respiratory rate outside 10–30. These thresholds are easy to teach but blunt — they fire only once decompensation is already underway, and they treat each vital sign in isolation.
Machine-learning approaches explored in military medical research instead train on the joint trajectory of multiple signals over time: a rising heart rate together with narrowing pulse pressure together with falling HRV is a materially different — and earlier — signal than any one of those alone. Models used in this space have included logistic regression and support vector machines on engineered waveform features (for interpretability and low compute cost suitable for a handheld device), as well as more recent recurrent and convolutional approaches trained on raw waveform windows. The output in this simulation is deliberately simple: a percentage confidence and a plain-language flag such as "suspected internal hemorrhage" — the underlying trend classification, not a raw number, is what is surfaced to the medic.
Why pattern recognition, not diagnosis
It is worth being precise about what these systems claim to do. They do not diagnose a specific anatomical injury — a model flagging "probable internal hemorrhage" is reporting a statistical pattern match to prior casualties who deteriorated in a similar way, not an imaging-confirmed finding. The intended clinical role is closer to an early-warning smoke detector than a diagnostic scan: it raises the index of suspicion and shortens the time to the correct TCCC response, while the medic's own exam and judgment remain the final arbiter of what is actually wrong.
Real-Time Protocol Recommendation Under Fire
Knowing the correct TCCC step is not the same as executing it while being shot at. The third function of the system is translating a flagged pattern into a single, unambiguous, high-contrast instruction — collapsing the medic's decision space from "what should I do" to "do this now" at the exact moment cognitive bandwidth is lowest.
- 3: TCCC phases (Care Under Fire / TFC / Evacuation)
- 5: MARCH sequence steps (Hemorrhage→Airway→Resp→Circ→Hypothermia)
- Seconds: Time pressure in CUF phase (while still taking fire)
- Explicit caveat: Automation-bias risk (in all fielded decision-aid concepts)
Collapsing MARCH into the next single step
TCCC's MARCH algorithm (Massive hemorrhage, Airway, Respiration, Circulation, Hypothermia/Head injury) is designed to be simple enough to run from memory, but under real fire even a five-item mnemonic can be skipped, reordered, or forgotten — particularly by less experienced medics or first responders with minimal training (including the "first responder" tier of combat lifesavers who are not medics at all). The AI decision-support concept modeled here does not replace MARCH; it runs MARCH continuously in the background against the fused sensor state and surfaces only the single next indicated action as a large, high-contrast overlay — for example "APPLY TOURNIQUET — right thigh" rather than a list.
This mirrors decision-aid design in other extreme-stress domains: aviation checklists were redesigned decades ago around the same principle, presenting one item at a time rather than a full list, because attention narrows under stress and a long list is either skipped or only partially read.
Designing for the care-under-fire phase specifically
TCCC divides care into three phases, and the demands on a decision-support device differ sharply across them:
• Care Under Fire (CUF): the casualty and medic are still under effective hostile fire. Only massive hemorrhage control is attempted; the device's job is to confirm or flag hemorrhage and prompt an immediate tourniquet, nothing more. • Tactical Field Care (TFC): once the immediate threat is suppressed, a fuller MARCH assessment proceeds and the device can safely present a richer readout and log more detail. • Tactical Evacuation Care (TACEVAC): en route, the device shifts role toward continuous monitoring and preparing the handoff packet.
A decision-support system that presents CUF-phase urgency and detail during TFC (or vice versa) would itself become a hazard — which is why the recommendation logic modeled here is phase-aware, not a single static algorithm.
Automation bias — the central caveat
Every serious military and clinical discussion of AI decision support in trauma care foregrounds automation bias: the well-documented human tendency to over-trust an automated recommendation, including following it when it is wrong or when it conflicts with direct clinical evidence in front of the operator. In a domain where the "operator" is a stressed, undertrained medic, this risk is amplified, not reduced, by exactly the conditions that make the tool attractive in the first place.
Fielded concepts and research programs in this space are explicit that such systems are intended to augment, not replace, medic judgment — the device recommends, the human decides and acts, and the interface is deliberately designed to keep the medic's own assessment (are they breathing, is there visible catastrophic bleeding) as the primary check against a sensor artifact or model error driving the wrong recommendation.
Medic Action and the AI Feedback Loop
A decision-support system is only as useful as its ability to confirm that an action worked and re-plan from the new state. Once the tourniquet is applied, the same sensor stream that flagged the hemorrhage now watches for the physiological signature of controlled bleeding, and the AI moves to the next MARCH item.
- Falls: Expected HR response (toward baseline after hemorrhage control)
- Recovers: Expected BP trend (if bleeding source controlled)
- Continuous: Re-assessment interval (not a single checkpoint)
- Automatic: Escalation path (to next MARCH item on confirmation)
Confirming an intervention actually worked
Applying a tourniquet does not guarantee bleeding control — placement can be too distal, too loose, or on the wrong limb segment in the chaos of contact. A closed decision-support loop treats the intervention itself as a hypothesis to be tested against the sensor stream: if heart rate begins trending down and blood-pressure surrogate trends up within the expected physiological window, the system treats the action as confirmed effective. If vitals continue to deteriorate despite the logged intervention, the system re-flags — surfacing a second tourniquet, a junctional device, or escalation rather than silently assuming the first action succeeded.
This is the same "verify, don't just log" principle used in modern closed-loop clinical systems (for example closed-loop glucose control or ventilator weaning protocols): the value of automation is not just recommending an action but confirming its physiological effect and adapting.
Sequencing the next MARCH item
Once hemorrhage control is confirmed, the system advances to the next item the algorithm has not yet cleared — typically airway, then respiration, then circulation more broadly, then hypothermia prevention. Because the device already has continuous respiration-rate and motion data, it can pre-screen some of these (for example, flagging an irregular or absent respiration pattern as a possible airway problem) rather than asking the medic to run the entire exam manually from scratch.
This sequencing is presented, again, one step at a time on the display, with prior confirmed steps logged automatically with a timestamp — building the record that becomes the handoff packet in the final stage.
Sensor reliability in the loop — a real limitation
The feedback loop is only trustworthy if the sensors themselves are trustworthy, and combat environments are close to worst-case for wearable physiological sensing. Motion artifact from casualty movement or being carried, dust and debris on optical sensor windows, blood pooling over a pulse-oximetry site, cold peripheral vasoconstriction reducing signal amplitude, and electromagnetic interference near vehicles or radios can all degrade or corrupt a sensor stream. A decision-support system has to detect signal degradation itself and downgrade its own confidence — silently trusting a corrupted "vitals improving" reading after a botched sensor reattachment would be actively dangerous. This is why sensor data quality is modeled explicitly in this simulation as a direct input to AI confidence, not a cosmetic slider.
Handoff Packets and the Learning Health System
The final function of point-of-injury AI decision support is not clinical at all — it is informational continuity. A digitally logged timeline of every vital sign and every intervention, timestamped from the moment of injury, is compiled and transmitted ahead of the casualty so the next echelon of care is never starting from zero. At a system level, that same captured data is what allows TCCC guidelines themselves to keep improving.
- 2004: DoD Trauma Registry est. (Joint Trauma System registry)
- Often absent: Historical point-of-injury data (undocumented pre-hospital phase)
- Ongoing: TCCC guideline updates (driven by registry-derived evidence)
- 4–5: Echelons of care (point of injury through Role 4)
Closing the point-of-injury documentation gap
For most of military medical history, the point-of-injury phase — the minutes immediately after a casualty falls, in the middle of a firefight — has been the least documented part of the entire casualty care chain. A medic focused on keeping someone alive under fire cannot also be filling out a paper record of exactly when a tourniquet went on or what the heart rate was at each stage; that data, if it exists at all, is reconstructed afterward from memory. This gap has historically limited how precisely trauma researchers could evaluate which interventions, and which timing, actually improved survival.
An AI decision-support device generates that record automatically as a side effect of doing its primary job: every flagged pattern, every recommendation shown, every confirmed action, and every raw vital-sign sample is already timestamped and stored. Compiling it into a structured handoff packet transmitted to the next echelon (a forward surgical team, a Role 2 or Role 3 facility) costs nothing extra at the point of injury.
The Department of Defense Trauma Registry and the "Learning Health System" model
The Department of Defense Trauma Registry (DoDTR), maintained under the Joint Trauma System, has been central to how TCCC itself evolved — the shift toward earlier and more aggressive tourniquet use, junctional hemorrhage control devices, and hemostatic dressings was driven by registry analysis of what actually correlated with survival across large numbers of real casualties, not solely by theory. This is the "Learning Health System" concept applied to combat casualty care: point-of-injury data feeds a registry, the registry is analyzed, and the findings feed back into updated clinical practice guidelines — a continuous loop rather than a fixed doctrine set once and left unchanged.
Digitized, sensor-derived point-of-injury data of the kind modeled in this simulation is positioned as the next step in that loop: instead of registry entries built from after-the-fact recollection and paper trauma cards, entries built from continuous objective sensor logs and AI-flagged events, which is expected to sharpen the evidence base used to refine future TCCC guidance.
The Joint Trauma System has described the goal explicitly as building a "learning health system" for combat casualty care — one where every casualty encounter, properly captured, becomes data that improves care for the next casualty, closing a feedback loop that historically took years of retrospective study to complete.
What still has to go right
None of this removes the underlying constraints of combat medicine: transmission bandwidth and connectivity at the point of injury is often degraded or absent, so packets may need to queue and burst-transmit opportunistically; the packet must be small and standardized enough to integrate into existing systems (such as the Military Health System Genesis electronic health record) rather than creating a new isolated data silo; and privacy/security of casualty medical data in a contested electromagnetic environment is a nontrivial engineering problem in its own right. The handoff packet is valuable exactly to the degree these logistics are solved — a perfect log that never reaches the surgical team is no better than no log at all.
Traditional vs. AI-augmented medic decision-making
| Product | Indication | Trial Design | Key Result |
|---|---|---|---|
| Traditional (unaided) | Decision speed | Bounded by memory recall of MARCH/TCCC under stress; can be delayed or skipped | No dependency on power, sensors, or connectivity |
| AI-augmented | Decision speed | Next step surfaced continuously in real time from live sensor trends | Faster recognition of subtle/compensated shock patterns |
| Traditional (unaided) | Consistency | Varies with training level, fatigue, and individual experience | Judgment adapts fluidly to unanticipated situations |
| AI-augmented | Consistency | Same protocol logic applied identically regardless of medic experience | Standardizes protocol adherence across skill levels |
| Traditional (unaided) | Data use | Manual pulse checks, visible bleeding, verbal responsiveness only | Robust to sensor failure — always available |
| AI-augmented | Data use | Continuous multivariate vitals fused into trend-based predictions | Can flag deterioration before it is clinically obvious |
| Traditional (unaided) | Key limitation | Cognitive overload and undertraining under fire | — |
| AI-augmented | Key limitation | Automation bias and sensor unreliability (motion, dust, blood) in combat conditions | — |
This simulation provides artificial intelligence-based decision support for combat medics operating under enemy fire. It helps medics make critical decisions in high-stress situations to optimize patient care and survival rates.
2D · HTML5 Canvas 2D · 60 FPS target · runs fully client-side, no install