Why Battlefield Medicine Needs Offline Systems — An LSCO Architecture Overview

The Golden Hour Disappears

In peacetime trauma, the golden hour defines everything. Get the patient to a trauma center within 60 minutes and survival rates are dramatically higher. Helicopter, ambulance, highway — the system is optimized for speed.

In Large Scale Combat Operations (LSCO), there is no golden hour. Helicopters are grounded by hostile air. Roads are contested or destroyed. The nearest surgical capability is 12 hours away by ground, if it is still there when you arrive.

The patient stays where they are. For hours. Sometimes days. And the medic who is keeping them alive has no way to call for guidance, no access to the patient's records from three stations ago, and no system to document what was done and why.

This is the problem xGrid's LSCO suite solves. Not by replacing the golden hour — nothing can — but by giving the medic a complete digital system that works without any network, runs on hardware that fits in a backpack, and documents every decision for the review that will inevitably follow.

The Four-Layer Care Chain

LSCO medicine follows a defined chain. A casualty moves through distinct phases, each with its own clinical priorities, documentation requirements, and decision points. xGrid implements each phase as a module:

All four layers share the same patient ID. A casualty's journey from point-of-injury through surgery is a continuous, traceable chain — not four disconnected paper forms.

Layer 1: Prolonged Field Care

PFC is the holding pattern^[1]. When a patient cannot be evacuated, someone has to keep them alive for 72 hours with limited resources.

The PFC module creates a digital care plan and tracks serial vital signs — heart rate, blood pressure, respiratory rate, SpO2, temperature, Glasgow Coma Scale — at configurable intervals. Typically every 15-30 minutes.

The clinical value is in the trends, not individual readings. A single blood pressure of 100/60 could be normal or alarming depending on whether it was 130/80 an hour ago. The system detects these trends automatically:

• Continuous blood pressure drop (>10 mmHg per reading): generates a WARNING alert
• Tourniquet applied: auto-alert at 2 hours (WARNING), 4 hours (CRITICAL)
• GCS drop ≥ 2 points: immediate alert
• Medication due: reminder 15 minutes before scheduled time

The dashboard shows trend arrows next to each vital sign — HR 110↗ means heart rate is rising. A medic scanning ten patients can spot the one who is deteriorating without reading individual numbers.

Break-glass: In an emergency, a medic can record vital signs without creating a care plan first. The system auto-creates an ad-hoc plan tagged as break-glass. Battle does not wait for bureaucracy.

Layer 2: TCCC Card (DD 1380)

The DD 1380 is the NATO standard casualty card^[2]. In paper form, it is a folded card tucked into the casualty's clothing or tied to a tourniquet. It records mechanism of injury, treatments given, medications administered, and tourniquet times.

The paper version has three problems in LSCO:

1. It gets lost, wet, or illegible
2. It cannot be duplicated at handoff — whoever has the card has the only copy
3. It cannot be transmitted ahead to the receiving facility

xGrid's TCCC module digitizes this card. The data is entered once and produces three outputs:

• QR code: A compact encoding of the complete casualty summary. At handoff, the receiving station scans the QR and the patient's data populates automatically. No re-entry, no transcription errors.
• MIST report: Mechanism, Injuries, Signs/Symptoms, Treatments — formatted as a plain-text radio report. The medic reads it directly into the radio without reformatting.
• Persistent record: The digital card survives device failure via the Lifeboat Protocol. The paper card in the patient's pocket is a backup, not the primary record.

The QR payload is compact (approximately 2 KB) and fits in a standard QR code. It includes a version tag for forward compatibility and a hash for tamper detection.

Layer 3: MEDEVAC Queue

When evacuation becomes possible, who goes first?

The MEDEVAC module maintains a priority queue using the NATO standard classification:

Priority	Criteria	Auto-Suggestion Trigger
URGENT	Life-threatening, immediate evacuation	GCS ≤8, SBP <90, SpO2 <90%
URGENT SURGICAL	Requires surgical intervention at higher echelon	Injuries requiring Role 2+ capability
PRIORITY	Serious, evacuation within 4 hours	Open fractures, burns >20%
ROUTINE	Stable, evacuation within 24 hours	Stable closed fractures
CONVENIENCE	Minor, no urgency	Minor injuries

The system auto-suggests priority based on the patient's vital signs and injuries, but the physician can override. It also generates a NATO 9-Line request — the standardized radio format for calling in evacuation — as copyable text.

Waiting times are tracked automatically. When a helicopter finally arrives, the queue tells you exactly who has been waiting longest at each priority level.

Layer 4: Damage Control Surgery

DCS inverts the normal surgical philosophy^[3]. Instead of definitive repair in one operation, it uses three phases:

Phase 1 — Abbreviated Surgery: Stop the bleeding. Control contamination. Temporary closure. Get out in under 90 minutes. Leave everything else for later.

Phase 2 — ICU Resuscitation: Correct the lethal triad — hypothermia, acidosis, coagulopathy. The three conditions that kill surgical patients faster than their injuries. The system monitors all three with traffic-light visualization:

Phase 3 — Definitive Repair: Once the patient is stable, complete the deferred procedures. The list of what was left unfinished in Phase 1 — which organs were packed, which vessels were shunted, which fractures were temporarily stabilized — follows the patient through the system. No matter how many stations they pass through, the deferred procedure list is always visible.

Beyond the Four Layers

The LSCO suite includes four additional modules that support the care chain:

Walking Blood Bank (WBB): In the field, blood supply comes from people, not blood centers. The WBB module registers pre-screened donors, matches blood types, tracks donation intervals (56 days standard, 28 days emergency), and monitors the 24-hour shelf life of fresh whole blood.

Burn Rate: Real-time consumption tracking. Not "how much do we have?" but "how long will it last?" The system calculates hours-to-depletion for every supply category and alerts when critical thresholds are crossed. (See Burn Rate & Approvals for details.)

Multi-Signature Approvals: Irreversible procedures — amputations, organ removal — require multiple physicians to vote before proceeding. A digital version of the 1862 Letterman Rule, with tamper-evident vote hashing.

Permission Escalation: Three operating modes (Peacetime → Emergency → Wartime) that expand what combat medics are authorized to do. Every scope expansion is documented with full audit trail. (See Burn Rate & Approvals for details.)

The Readiness Gates

We do not deploy LSCO modules incrementally and hope they work together. Each module passes through readiness gates:

Gate 1 — API Verification: Every endpoint returns correct responses. Automated test suite covers happy paths, edge cases, and break-glass scenarios.

Gate 2 — Cross-Module Integration: A patient created in PFC can be referenced in TCCC, queued in MEDEVAC, and operated on in DCS. The chain is unbroken.

Gate 3 — Walkaway DR: All LSCO data survives a full disaster recovery cycle. Export from a running server, restore to a fresh device, verify chain hashes match.

Gate 4 — 72-Hour Stress Test: 13 patient scenarios running simultaneously. 353 automated steps. Evacuations, station failures, blood transfusions, surgical cases — all happening in parallel. 592 of 595 total steps pass across 6 test suites. Zero failures.

Why Offline Matters More in LSCO

Every system described above works without any network connection. Not "most features work offline" — all of them. Every vital sign recording, every TCCC card, every MEDEVAC request, every surgical phase log.

This is not a technical preference. It is a clinical requirement. In LSCO:

• Communications are jammed or destroyed
• Electromagnetic emissions can reveal your position
• Network infrastructure does not exist at point-of-injury
• Even local WiFi may be deliberately disabled for security

A medical system that requires connectivity is a medical system that does not exist in these conditions. xGrid treats offline as the default state, and connectivity as an occasional bonus for syncing data between stations.

The entire LSCO suite — 8 modules, 83 API endpoints, 17 database tables — runs on a single Raspberry Pi 5 that costs $80 and fits in a cargo pocket. That is the point. Not that we could build it bigger, but that we built it small enough to go where the casualties are.

---

Related: Walkaway DR — How a Phone Rebuilds a Dead Server · Burn Rate & Approvals — Resource Intelligence and Collective Accountability · Offline-First Is Not a Fallback

---

References

1. Ball JA, Keenan S. Prolonged Field Care Working Group Position Paper. J Spec Oper Med. 2015;15(3):76-79. PubMed

2. Butler FK, et al. Tactical Combat Casualty Care: Beginnings. Wilderness Environ Med. 2017;28(2S):S12-S17. PubMed

3. Rotondo MF, et al. "Damage Control": An Approach for Improved Survival in Exsanguinating Penetrating Abdominal Injury. J Trauma. 1993;35(3):375-382. PubMed