How does offline SQLite storage in a TCCC app handle sync conflicts with the role-2 system?

Conflict resolution in a medical record context cannot use last-write-wins because two legitimate updates — a vital signs reading added by the forward medic and a treatment note added by the TCCC coordinator at the collection point — may be created in the same offline window and both must survive. The correct approach is field-level merge with per-field vector clocks: each field carries its own creation timestamp and author identifier, so when the app reconnects and pushes its local state, the server merges at the field level rather than the record level. Fields that were updated on both sides are flagged for review rather than silently overwritten. This produces a complete, conflict-auditable record that the receiving facility can trust.

Tactical Field Applications

Military medical apps for TCCC: point-of-care documentation and medevac coordination

By Corvus Intelligence Engineering Team · About the team →

June 25, 2026 11 min read

Every minute after a penetrating injury without hemorrhage control raises the probability of a preventable death. Tactical combat casualty care (TCCC) exists to reduce that probability by standardizing the care medics deliver at the point of injury — but the protocol only works when the data it generates follows the casualty through every role of care. A paper TCCC card can be lost in a vehicle fire, soaked illegible, or simply transcribed incorrectly at handover. Military medical apps solve the documentation problem by capturing the DD Form 1380 digitally, pairing with field monitoring devices for automated vital signs entry, and converting the clinical record into a pre-filled 9-line medevac request the moment an evacuation decision is made. This article examines the engineering decisions that make those capabilities work in an austere, connectivity-denied, operationally stressed environment.

TCCC workflow and digital documentation requirements

TCCC divides care into three phases that correspond to the tactical situation rather than to clinical criteria. Care Under Fire is the phase when the medic and casualty are both under direct fire — the only interventions appropriate are moving the casualty to cover and applying a tourniquet to life-threatening extremity hemorrhage. Tactical Field Care begins when the immediate threat has been suppressed and the medic can safely perform a systematic assessment: airway, breathing, circulation, hypothermia, and head injury, in that order. TACEVAC — tactical evacuation care — is the phase during which the casualty is being transported to a higher role of care.

Each phase has different documentation requirements, and a well-designed TCCC app models this explicitly. During Care Under Fire, the interface should require nothing more than a single tap to start a casualty record and a tourniquet timer — capturing more during active contact is unrealistic and dangerous. Tactical Field Care opens the full DD Form 1380 fields: mechanism of injury, systematic assessment findings, every intervention with the time it was performed. TACEVAC adds the reassessment cadence, vital signs trends, and the MIST handover summary that the receiving facility needs. Collapsing these three phases into a single undifferentiated form is the most common design failure in first-generation TCCC apps; it results in a form that is too complex to use during the first phase and too simple to carry the clinical detail needed during the third.

What a complete digital TCCC card must capture, across all three phases, includes: casualty identification and unit; date-time-group with device-generated timestamps; mechanism of injury with free-text supplement; anatomical injury diagram; hemorrhage control (tourniquet application site, time, number of twists, conversion to wound packing if attempted); airway adjunct used; needle thoracostomy or chest seal if performed; IV or IO access site and gauge; all fluids administered with volume and time; all medications administered with dose, route, and time; hypothermia prevention measures; burns assessment; and evacuation precedence. The receiving role-2 trauma team uses every one of these fields. A partial card is not just incomplete — it forces the trauma team to treat the casualty's condition as unknown rather than as documented.

Digital DD Form 1380 — field-optimized UX for gloved hands

The DD Form 1380 was designed for paper and pencil, which imposes constraints a digital implementation must deliberately break. The paper form is organized by field type — a table of interventions, a section for vitals, a diagram on the reverse — because that layout minimizes paper consumption. A digital form can and should be organized by clinical workflow, presenting the fields the medic needs in the order they perform the assessment, not the order an administrative designer laid out a table.

Gloved-hand usability sets hard constraints on every interactive element. Touch targets must be a minimum of 44 by 44 points, which means the default size for most UI frameworks is too small. Toggle controls (tourniquet applied yes/no, needle decompression yes/no) should be implemented as large binary switches rather than checkboxes. Dropdowns with more than four options should be replaced with a full-screen selection grid where each option is a tap target large enough to hit reliably with a nitrile glove. Free-text fields should be used sparingly — the medic cannot type a paragraph under fire, and any field that could be a structured selection should be. When free-text is unavoidable (the specific drug name of an unusual medication, a non-standard improvised intervention), voice input using the device microphone is a meaningful fallback for situations where typing is impossible.

The injury diagram is the most information-dense field on the card and the one most commonly handled poorly. The correct implementation is a body outline with anterior and posterior views — the standard anatomical illustration used in military medical training — where the medic taps to place injury markers and selects the injury type from a small context menu that appears at the tap location. Markers should be distinguishable by color (penetrating, blunt, burn) and should be placeable with a single tap-and-confirm gesture. Exporting the diagram as an annotated image that can be attached to the electronic health record at the receiving facility closes the documentation loop without requiring manual re-drawing.

Mandatory field enforcement must be designed carefully. Fields that are truly mandatory — casualty precedence, at minimum one intervention — should block form submission and highlight clearly what is missing. Fields that are important but context-dependent — tourniquet time is mandatory if a tourniquet was applied, irrelevant if it was not — should use conditional visibility: if the tourniquet toggle is set to yes, the time field appears and becomes mandatory. Applying mandatory status to fields without this conditionality creates forms that the medic learns to fill with placeholder values to bypass the enforcement, which destroys the clinical value of the record.

Vital signs integration from monitoring devices

Manual vital signs entry introduces two failure modes: transcription error (the medic reads 94 on the pulse oximeter and types 49) and incomplete capture (the medic performs the reading but does not have a hand free to enter it). Bluetooth integration with monitoring devices addresses both by streaming readings directly into the TCCC card fields.

The field-deployable Bluetooth monitoring ecosystem is more capable than it was five years ago. Pulse oximeters that measure SpO2 and heart rate simultaneously, transmit over Bluetooth Low Energy, and survive the ingress and temperature extremes of field use are widely available and appear in military procurement specifications. Waveform capnographs that measure end-tidal CO2 and respiratory rate — a more demanding measurement that previously required clinic-grade equipment — are now available in devices small enough for a medic's kit, several with BLE connectivity compliant with the Bluetooth Health Device Profile. Non-invasive blood pressure cuffs with BLE transmission round out the basic vital signs set.

The NETT (National Emergency Triage Training) device ecosystem has pushed standardization of data interfaces for military-specific monitoring equipment, and recent DoD procurement guidance has made BLE connectivity an expected feature rather than a premium option. The app receives device readings as structured packets — a blood oxygen saturation reading is not just a number but a typed value with a timestamp, a signal quality indicator, and a device identifier — and maps these into the vital signs fields on the TCCC card with all that metadata preserved.

Alarm thresholds make the stream of readings actionable rather than just archival. A pulse oximeter reading below 94% warrants immediate reassessment of airway and breathing. An end-tidal CO2 above 50 mmHg suggests hypoventilation; below 30 mmHg, hyperventilation or reduced perfusion. A heart rate above 120 combined with a deteriorating SpO2 trend suggests hemorrhagic shock requiring immediate fluid resuscitation. The app highlights out-of-threshold values on the vital signs display and can generate a clinical alert that appears prominently on the current screen, not buried in a sub-menu, because the medic may be performing a procedure when the alarm triggers and needs to see it on the device they are holding.

The practical challenge is pairing reliability. Bluetooth connections in the field compete with other 2.4 GHz traffic, drop when the device moves, and require re-pairing after battery changes. The app must handle pairing drops gracefully — reverting to manual entry with the last known connected device still displayed — and must make re-pairing a single tap rather than a multi-step process. A pairing workflow that requires navigating three menus will not be used under operational conditions.

Medevac 9-line request generation

The 9-line medevac request is the operational handshake that launches an evacuation platform. Generating it from the TCCC record data rather than requiring the medic to construct it from scratch is one of the highest-value features a military medical app can deliver. The derivation logic is straightforward for most lines.

Line 1, the pickup site location, is taken from the device GPS at the moment the medic initiates the request. The app should display the coordinate in both MGRS and decimal degrees and allow manual correction if the medic is marking a pickup site that is not their current position. Line 3, the number of patients by precedence, is derived from the current casualty list — if the medic has three open TCCC records with assigned precedences, the app counts them and formats the line. Line 5, the number of patients by type, is derived from the litter or ambulatory status entered on each TCCC card. The MIST summary — mechanism, injuries, signs, treatment — is pre-populated from the TCCC card fields for the clinical handover that accompanies the request to the receiving facility.

The medic must still supply the fields the app cannot derive: line 2 (radio frequency and call sign, which may be drawn from a pre-provisioned communications plan if the app integrates with the unit's SOI); line 4 (special equipment — hoist, ventilator, blood products — which depends on clinical judgment); line 6 (security at the pickup site — no enemy troops, possible enemy, etc. — which depends on the tactical situation the medic observes); line 7 (marking method — smoke color, VS-17 panel, IR strobe — a tactical decision); line 8 (patient nationality and status, which the TCCC card carries in the casualty identification fields); and line 9 (NBC contamination, which the medic assesses locally).

The generated 9-line should be displayable on-screen in the exact format used for voice transmission over the radio net, so the medic can read it verbatim without reformatting. It should also be transmittable as a structured digital message over any available data bearer. Dual-mode output — voice-readable text and machine-parseable data — means the system works whether the evacuation coordination is happening over voice radio, over a digital mesh, or over a satellite text channel. Radio and digital paths are not mutually exclusive; a system that requires the medic to choose between them at the moment of crisis is poorly designed.

A core aspect of broader combat casualty management software is ensuring that the 9-line generation step feeds from a single source of truth — the TCCC card — rather than requiring the medic to re-enter data they have already captured. Every second of re-entry is a second of delay in launching the evacuation platform, and every re-entry is an opportunity for error.

Offline-first architecture for austere environments

The defining characteristic of a tactical medical environment is intermittent, unpredictable connectivity. A TCCC app designed for stable connectivity — one that makes network calls to validate inputs, saves records to a cloud backend in real time, or requires a server session to open a form — will fail precisely when it is most needed. Offline-first is not a feature to add; it is the foundational architectural constraint from which every other design decision follows.

Local storage uses SQLite, which is mature, well-understood, runs in-process without a network service, and handles the structured relational data of a TCCC record naturally. The schema stores one row per casualty record, with related tables for vital signs readings (many per casualty, timestamped), medications (many per casualty, timestamped), and 9-line requests (one or more per casualty, with transmission status). Every write to the local database is immediately durable — the app never holds data in memory that has not been written to SQLite — because a device restart during a casualty care event must not lose a partial record.

Synchronization to the role-2 or role-3 system runs over a background queue that wakes when any network bearer becomes available. The queue is prioritized by evacuation precedence: an Urgent casualty's record transmits before a Priority casualty's record, which transmits before a Routine record. Within the same precedence tier, records transmit in creation order. The app does not block the medic on sync completion — care continues in the foreground while the queue drains in the background. Sync failures are retried with exponential backoff, and the queue state persists across app restarts so a record created two days before connectivity is restored will transmit correctly when the bearer becomes available.

Conflict resolution at sync time uses field-level merge rather than record-level last-write-wins. A vital signs reading added by the forward medic and a treatment annotation added by a TCCC coordinator at the collection point, both created in the same offline window, must both survive the merge. Field-level vector clocks — each field carries a creation timestamp and an author identifier — allow the server to merge at the field level and flag genuine conflicts (two different values for the same field updated by two different users in the same window) for review rather than silent overwrite. The result is a complete, conflict-auditable record that the receiving facility can trust as representing the actual care delivered.

This offline-first approach mirrors the architecture used in other offline-capable TAK field apps where local-first data capture with structured synchronization is the established pattern for austere military environments.

MEDEVAC tracker integration

A TCCC app that stops at generating the 9-line request leaves the coordination cell managing the evacuation with a radio message and no shared picture. MEDEVAC tracker integration closes that gap by publishing the casualty's status and the evacuation platform's position to a common operating picture that every relevant actor — the medical operations cell, the air mission commander, the receiving surgical team — can see simultaneously.

Publication uses Cursor on Target events over TAK Server. The casualty record generates a point of interest at the pickup location with precedence-coded symbology (the standard medical marker set from the military symbol standard, rendered by the milsymbol open library to ensure operators read the symbology fluently without a legend). Patient count and precedence appear as attributes on the marker. The marker carries a stale time tied to the record lifecycle: it refreshes periodically while the casualty is on the ground awaiting pickup, and it is resolved and allowed to stale out of the active picture when the casualty record is closed at handover.

When the evacuation platform is assigned, the coordination cell links the platform's TAK position track to the casualty record. The medic's app and the coordination cell's display both show the platform's estimated time of arrival against the precedence deadline countdown, without a voice check-in. This removes the most common source of timeline uncertainty in evacuation coordination: the question of whether the platform is actually en route, or whether the launch order has not yet reached the aircrew.

Hand-off to the receiving surgical team is a distinct data event, not just a closure of the coordination view. The app transmits the complete TCCC record — vital signs time series, full treatment log, injury diagram image, and the MIST handover summary — to the receiving facility's intake queue the moment the casualty crosses the threshold. The surgical team can review the record before the casualty arrives, pre-position blood products, and brief the trauma bay without waiting for the medic to give a verbal handover under the noise of a landing aircraft. The verbal handover still happens, but it supplements a written record rather than replacing one.

The broader logistics implications of accurate casualty tracking extend into the medical logistics military supply chain: blood products consumed at the point of care generate a demand signal that travels faster than the next resupply cycle if the TCCC record is integrated with the logistics system rather than isolated in a medical silo. A MEDEVAC tracker that feeds only the coordination cell captures less than half its potential value.

Privacy and security for medical data on tactical devices

Casualty data is sensitive on two axes simultaneously. As protected health information it falls under HIPAA technical safeguards — encryption at rest, transport encryption, audit logging of access, minimum necessary access controls. As operational data it reveals the unit's casualties, locations, and combat effectiveness to any adversary who can read it. These two sensitivity axes are not in tension; they both point toward the same set of controls, applied rigorously.

Encryption at rest for PHI on a military device must use a FIPS 140-2 or FIPS 140-3 validated cryptographic module. On modern Android devices this means AES-256 encryption with keys stored in the hardware-backed keystore — the secure enclave that is physically separate from the application processor and survives a software compromise of the operating system. SQLite databases that store PHI without hardware-backed key storage fail this requirement regardless of the encryption flag set in the application layer. The device management profile must also enforce full-disk encryption, automatic screen lock after a configurable idle interval, and verified boot so that the app cannot run on a device with a compromised operating system image.

Wipe-on-tamper policy addresses the physical capture scenario. If the device is taken by a threat actor, the policy triggers cryptographic erasure — destroying the encryption keys rather than overwriting data, which is both faster and more complete — when defined tamper events are detected: a configured number of failed authentication attempts, a remote wipe command from the mobile device management server, or loss of heartbeat with the management server beyond a configured interval. The policy must be calibrated carefully for field use: a tourniquet being removed from the adjacent pocket should not trigger a failed authentication event. Hardware security modules that distinguish legitimate handling from adversarial access — based on motion patterns, temperature profiles, or explicit tamper-evident seals — provide more nuanced trigger logic than a simple attempt counter.

Authentication without a Common Access Card reader — the normal condition for a forward medic — is supported through derived credentials stored in the device's hardware-backed keystore, biometric authentication using the device fingerprint sensor or face recognition, or time-limited offline tokens provisioned before the mission. Each method binds the session to a specific identity, which feeds the audit trail. The audit trail records not just writes to the TCCC record but reads of the clinical detail — who accessed the PHI, when, and from which device — satisfying the HIPAA access logging requirement and providing an investigation path if PHI is later found to have been disclosed.

Role-based access controls enforce need-to-know at the data model level. The tactical COP sees only the pickup location, precedence, and patient count — the minimum needed to manage the evacuation. The full clinical record is visible only to users with a medical role credential. Transport between the field device and the TAK Server uses mutual TLS 1.3, with certificate pinning in the app to prevent man-in-the-middle attacks on the local network segment. These controls are more expensive to implement correctly than to describe, but they are the price of accreditation — and an unaccredited app does not deploy on operational networks regardless of its clinical capability.

Key insight: The most operationally significant design decision in a TCCC app is the phase model: Care Under Fire, Tactical Field Care, and TACEVAC must present different interfaces with different levels of required input. A single undifferentiated form that exposes all fields at all times will either be abandoned during the first phase (too complex under fire) or produce incomplete records during the third phase (too simple to carry the clinical handover the receiving surgical team needs). Model the phases explicitly in the UX, and the rest of the design follows naturally.

Integrate field medical documentation with your tactical COP

TAKpilot connects point-of-care field reporting, medevac coordination, and operator displays into a unified ATAK-based picture — built for real operational tempo. TCCC record publication, 9-line generation, and Cursor on Target integration in a single deployable package.

Explore TAKpilot → Book a Briefing

This analysis was prepared by Corvus Intelligence engineers who build mission-critical ISR and field applications for defense and government organizations. Learn about our team →

Frequently Asked Questions

What does a TCCC app need to capture on the digital DD Form 1380?

A digital DD Form 1380 must capture all the fields of the paper card in a structured, queryable format: casualty identification, date-time-group, unit, mechanism of injury, anatomical injury diagram, hemorrhage control interventions with tourniquet application time, airway management, breathing assessment, circulation findings, hypothermia prevention, medications administered with dose and time, IV or IO access, fluids given, vital signs at each assessment, evacuation precedence, and provider signature. The digital form enforces mandatory fields so no critical intervention can be skipped, and it timestamps every entry automatically to reconstruct the clinical timeline at the receiving facility.

How do TCCC apps work without network connectivity in the field?

TCCC apps use an offline-first architecture where all data entry, form validation, and local storage operate entirely on the device without any network connection. Patient records are written to a local SQLite database the moment they are created. When a data connection becomes available — via a mesh radio, a satellite terminal, or a cellular bearer at a casualty collection point — the app synchronizes the record to a role-2 or role-3 receiving system using a priority queue that puts Urgent casualties first. The critical design constraint is that the medic must never see a connectivity error during patient care; the network state is invisible to the user.

How does a military medical app generate a 9-line medevac request from TCCC data?

The app pre-fills the 9-line directly from data already in the TCCC record. Line 1 (pickup location) is inserted from the device GPS at the moment the request is initiated. Lines 3 and 5 (patient count by precedence and by type) are derived from the casualty list. The MIST summary — mechanism, injuries, signs, and treatment — is pre-populated from the TCCC card fields into the clinical handover section. The medic then confirms or adjusts the pre-filled values and adds the security, marking, and radio fields, which the app cannot derive automatically. This reduces the cognitive and manual load on a medic who is simultaneously managing a casualty.

What Bluetooth medical devices can pair with a TCCC field app?

TCCC field apps can pair with Bluetooth Low Energy monitoring devices including pulse oximeters (SpO2 and heart rate), waveform capnographs (end-tidal CO2 and respiratory rate), non-invasive blood pressure cuffs, and temperature probes. Devices compliant with the Bluetooth Health Device Profile transmit readings as structured packets that the app maps directly to the vital signs fields on the TCCC card, eliminating manual transcription errors. The NETT device ecosystem has expanded the range of field-compatible monitors with standardized data interfaces, and military procurement is increasingly specifying Bluetooth connectivity as a requirement.

What encryption standard applies to PHI stored on a military tactical device?

Protected health information stored on a military device falls under both HIPAA technical safeguards and DoD information assurance requirements. At rest, PHI must be encrypted using a FIPS 140-2 or FIPS 140-3 validated cryptographic module — typically AES-256 in a hardware-backed secure enclave on modern Android or iOS devices. Transport encryption uses TLS 1.3. The device management policy must enforce full-disk encryption, automatic screen lock, and a remote wipe capability so that a lost device does not expose a casualty's medical record. Apps that cache PHI in unencrypted SQLite databases without hardware-backed key storage fail this requirement and cannot be deployed on accredited military networks.

What is the difference between a MIST report and a SBAR handover in a military context?

MIST (Mechanism, Injuries, Signs, Treatment) is the standard tactical handover format optimized for speed in the prehospital environment — it conveys the clinical essentials in the order a trauma provider needs them and can be transmitted verbally in under 60 seconds. SBAR (Situation, Background, Assessment, Recommendation) is a broader handover framework used primarily in hospital and role-3 settings where more context and recommendation are appropriate. Military medical apps generate MIST output for field-to-field and field-to-role-2 handovers; some then supplement the MIST into an SBAR structure for the role-2 to role-3 transfer note, since the receiving surgical team benefits from the assessment and recommendation fields the SBAR format adds.

How does a wipe-on-tamper policy work for a field medical device?

A wipe-on-tamper policy triggers an automatic cryptographic erasure of the device when physical or logical tamper events are detected. Physical triggers include the device being opened, the SIM tray being removed, or a hardware security module detecting mechanical penetration. Logical triggers include a set number of failed authentication attempts, a remote wipe command from the device management server, and — in some implementations — loss of heartbeat with the management server beyond a configured interval. The wipe destroys the encryption keys rather than overwriting data, which is both faster and more thorough. For a medical device, the policy must be calibrated to avoid inadvertent wipe during battery changes or case swaps in the field, which requires the hardware security module to distinguish legitimate maintenance from adversarial access.

Can a TCCC app replace the paper DD Form 1380 for legal and medical-legal purposes?

A digital TCCC card is legally equivalent to the paper DD Form 1380 when it meets DoD records management policy requirements: the record must be created at or near the time of the event, it must identify the creator, it must be stored in a system that preserves integrity and prevents undetected alteration, and the system must be capable of producing a human-readable printout. An app that stores records in a tamper-evident database with per-field timestamps and cryptographic hashes satisfies these requirements. The practical advantage over paper is that the digital record is legible, timestamped to the second, and automatically synchronized to the medical record system without a re-transcription step at the receiving facility.

How does the medevac tracker publish patient status to the coordination cell?

The medevac tracker publishes patient status as structured events over TAK Server, using the Cursor on Target schema with medical extensions. Each casualty appears as a point of interest on the coordination cell's map with precedence-coded symbology, patient count, and current care phase. When the evacuation platform is airborne, the platform's live position is linked to the casualty record so the coordination cell can see the platform en route without a voice check-in. At handover, the app transmits a closure event that updates the casualty's status to 'transferred' and routes the TCCC record to the receiving facility's intake queue, completing the chain of custody from point of injury to definitive care.

What authentication options exist for a TCCC app when CAC readers are not available?

When a Common Access Card reader is not physically available — the normal condition for a forward-deployed medic — TCCC apps can authenticate through derived credentials stored in the device's hardware-backed keystore, biometric authentication using the device's fingerprint sensor or face recognition backed by a FIPS-validated enclave, or time-limited offline tokens provisioned before the mission. Each method feeds into the same audit trail so the record of who created or modified a TCCC entry is preserved regardless of the authentication path taken.