CASEVAC coordination software: medevac requests on the tactical COP

A casualty's survival is measured against the clock. The interval between injury and definitive surgical care — the so-called golden window — is short, and the single largest controllable variable inside it is coordination: how fast a 9-line medevac request reaches a decision-maker, how cleanly it is matched to an available platform, and how reliably the casualty's clinical picture follows them to the receiving facility. CASEVAC coordination software exists to compress that timeline. This article examines the data model, the request workflow, and the integration with the tactical common operating picture (COP) that turns a sequence of stressed voice transmissions into a single shared, auditable picture.

CASEVAC versus MEDEVAC: why the software must model both

The two terms are not interchangeable, and software that treats them as one introduces dangerous ambiguity. MEDEVAC — medical evacuation — uses dedicated, marked medical platforms staffed with trained medical personnel and protected under the Geneva Conventions. CASEVAC — casualty evacuation — uses a platform of opportunity: a logistics truck on its return leg, an armored vehicle, an attack helicopter heading back to base. There is no dedicated en-route care, and the platform carries no protected status.

In practice a single casualty's journey often spans both. A wounded soldier may be lifted by CASEVAC from the point of injury to a casualty collection point (CCP), then transferred to a dedicated MEDEVAC airframe for the run to a role-2 facility. The data model must therefore treat the casualty as the persistent entity and the evacuation legs as a sequence of linked events, each with its own platform type, protected status, and timing. Modeling the evacuation as a single immutable record — a frequent mistake in first-generation tools — breaks down the moment a casualty changes platforms, which is the norm rather than the exception.

The 9-line medevac request as a structured form

The 9-line medevac request is the standardized brevity format that has structured evacuation requests for decades. Its nine lines are: (1) location of the pickup site, (2) radio frequency and call sign, (3) number of patients by precedence, (4) special equipment required, (5) number of patients by type — litter or ambulatory, (6) security at the pickup site, (7) method of marking the pickup site, (8) patient nationality and status, and (9) terrain or NBC contamination at the pickup site. Lines 6 through 9 change content between wartime and peacetime reporting, a detail the software must encode rather than leave to the operator.

The engineering opportunity is that most of this is derivable or pre-known. Line 1 is the requester's own GPS position, which the device already holds. Line 2 is the unit's communications plan, which can be provisioned before the mission. That leaves the medic entering only the clinical and security lines — patient counts, precedence, equipment, marking — under the worst conditions a user interface will ever face: one-handed, gloved, possibly under fire, with a casualty bleeding in front of them. A guided form with large touch targets, sane defaults, and aggressive field validation is not a usability nicety here; it is the difference between a request that launches an aircraft and one that bounces back for clarification.

Field validation under pressure

Validation must be unforgiving about completeness and forgiving about everything else. A request missing the precedence line cannot be prioritized and must be blocked from transmission. A request with a patient count of zero is nonsensical and must be rejected. But the software should never impose friction that slows a correct entry — no confirmation dialogs on routine actions, no mandatory free-text fields, no multi-screen wizards for what should be a single scrollable form. The validation logic runs locally on the device so that it works with no connectivity, and the completed request queues for transmission the instant a bearer becomes available.

MIST clinical handover: a separate, linked record

The 9-line is a tactical and logistical document. It does not carry the clinical detail the receiving facility needs to prepare. That role belongs to the MIST report: Mechanism of injury, Injuries sustained, Signs (vital signs and their trend), and Treatment given. MIST travels with the casualty and updates as the patient is reassessed, while the 9-line travels with the evacuation request and is largely fixed once transmitted.

Keeping MIST as a record linked to — but distinct from — the 9-line is a deliberate architectural choice. The air mission commander deciding whether to launch needs the pickup location, the security situation, and the patient precedence; they do not need the casualty's blood pressure trend. The receiving role-2 trauma team needs exactly the opposite. By modeling the two as separate records bound by a shared casualty identifier, each consumer subscribes only to the information relevant to their decision. Vital signs in the MIST record are timestamped individually so the receiving facility sees a trend — a falling blood pressure across three readings is a different clinical story than a single low reading, and that distinction drives trauma-bay preparation.

Putting the request on the common operating picture

The historical failure mode of medevac coordination is the serial voice relay: the medic reads the 9-line to the company net, the company relays to battalion, battalion passes to the medical operations cell, the cell coordinates with aviation. Each hop introduces latency and transcription error, and none of the participants share a common picture of where the casualty is or what state the request is in.

Surfacing the casualty event on the COP collapses that chain. CASEVAC software publishes the casualty and evacuation events as Cursor on Target events over TAK Server, so the pickup point, the patient precedence (color-coded), and — once a platform is assigned — the evacuation asset's live position all render as map markers. The medical operations cell, the air mission commander, and the receiving facility see the same picture simultaneously. The request-to-launch decision becomes a glance at a map rather than a reconstruction from a half-heard radio transmission.

The casualty marker carries only the tactical fields appropriate to a shared map — location, precedence, patient count, and request status. The clinical MIST record routes separately to the receiving facility's queue, so the operational picture stays uncluttered and the casualty's medical detail is not broadcast across every connected client on the network. This separation of concerns mirrors the standard approach to publishing structured field data to the COP: put the minimum on the shared map, route the detail to the consumer who needs it.

Cursor on Target events also carry a stale time — the moment after which the event should be treated as expired if not refreshed. For a casualty marker this is a meaningful design parameter. A marker that never stales clutters the picture with resolved casualties; a marker that stales too aggressively can disappear from the map while the casualty is still on the ground awaiting pickup. The correct behavior ties the stale time to the request lifecycle: the marker persists, refreshed periodically, until the casualty record is closed at handover, at which point a final event sets the marker to resolved and lets it stale out of the active picture. Tying marker lifetime to record state rather than to a fixed timer is what keeps the COP honest.

Mapping precedence to symbology operators recognize

Casualty markers should render in a symbology operators already read fluently rather than a bespoke icon set. The widely used military symbol standard provides medical and casualty modifiers that map cleanly onto the COP, and an open symbol-rendering library such as milsymbol can generate the glyphs client-side from a standard symbol code. The practical payoff is that an air mission commander scanning the map distinguishes an Urgent litter casualty from a Routine ambulatory one by symbol and color without reading a label — the visual encoding carries the priority. Consistency here matters more than cleverness: a novel icon that requires a legend defeats the purpose of a shared picture.

Precedence-driven prioritization and launch timers

Standard medevac precedence has four categories, and the software treats each as a state with an attached deadline. Urgent requires evacuation within one hour to save life, limb, or eyesight. Urgent-Surgical demands surgical intervention to stabilize. Priority must be evacuated within four hours or the casualty will deteriorate toward Urgent. Routine allows up to 24 hours. The software sorts the casualty queue by precedence and elapsed time, runs a countdown against each casualty's deadline, and raises an escalating alert when an Urgent casualty approaches the one-hour mark without an assigned platform. The timer is the system's most important nag: it makes the cost of indecision visible to everyone watching the COP.

Connectivity, sync, and the audit trail

Medevac coordination happens precisely where connectivity is worst — forward, dispersed, and often under electronic attack. The software must therefore be offline-first in the strict sense: every function that does not inherently require the network must work without it. The casualty record is created locally, the 9-line is built and validated locally, the MIST report is captured locally, and all of it queues for synchronization the moment any bearer — a mesh radio, a satellite uplink, an LTE bridge at the CCP — becomes available. A coordination tool that blanks out when the link drops is, like any other connectivity-dependent field application, a garrison tool wearing tactical clothing.

Synchronization must be conflict-aware. The same casualty may be updated by the medic at the point of injury and by the operations cell on the COP within the same disconnected window. Last-write-wins is unacceptable for a medical record. The standard pattern is field-level merge with a per-field timestamp, so a vital-sign reading added forward and a platform assignment added at the cell both survive the merge rather than overwriting each other. Every state change is recorded with an author, a timestamp, and a position, producing an audit trail from point of injury to definitive care — valuable both for after-action review and for the medical-legal record that follows any casualty.

The audit trail also serves a quieter analytical purpose. Aggregated across many missions, the timestamps reveal where the coordination timeline actually bleeds time — request-to-decision, decision-to-launch, launch-to-pickup, pickup-to-handover. A unit that believes its bottleneck is aviation availability may discover, on the evidence, that the dominant delay is the minutes spent reconstructing malformed 9-line requests on the radio net. That kind of finding only emerges when every event is timestamped and attributed, which is why instrumentation of the workflow is part of the tool's value rather than optional overhead.

Security and need-to-know on the medical record

Casualty data is sensitive on two axes at once: it is operationally revealing — a cluster of Urgent casualties signals a unit in trouble — and it is personally protected health information. The software must enforce role-based access so that the tactical COP shows only what the operational picture requires while the full clinical record is visible only to the medical chain. Transport is encrypted end to end, and the audit trail records read access to the clinical record as well as writes. Building these controls in from the data model outward is far cheaper than retrofitting them, and a coordination tool that leaks casualty detail to every node on the network will not pass the accreditation needed to deploy.

CASEVAC coordination sits at the intersection of field application engineering and the broader military medical logistics chain — blood supply, field pharmacy, and the role-of-care network that the evacuated casualty enters. A coordination tool that ends its responsibility at handover misses the chance to feed those downstream systems the demand signal they need to pre-position resources.