A first responder app is judged on the call with no bars.

The app has to work when the network does not

Public safety radio and commercial data coverage are separate systems with separate holes. A crew can have a clear channel in a basement and nothing at all on the phone. An app that answers a failed request with a red banner is really asking the medic to hold the numbers in their head until the bars come back.

The rule that fixes it is short. Every write lands on the device first, then syncs. No screen waits for a server to confirm. Times, vitals, medications and free text go into local storage as they are typed, each stamped with the moment it was entered rather than the moment it was uploaded. When the connection returns, the queue drains in order and the server keeps the original times.

Two things break this in practice. Sign-in that checks a server on every launch, which locks a crew out of their own data at the worst possible moment. And an upload that is tried once. A retry that gives up quietly is the same as no sync at all, because nobody finds out until a report is missing a week later. How far a phone can actually be pushed here is its own subject: working where there is no coverage.

We checked what an AI built app does on this rather than assuming it. The project template Newly generates from is local first by default. App data goes to an on-device store, and the template rules state plainly that the app does not talk to a backend unless you ask for one. There is no over the air update package in it, so a release build does not fetch anything before it starts, and the analytics key ships empty. On that reading a plain build opens and works on first launch with no connection. What we did not do is cold install a TestFlight build on a handset in airplane mode and watch it, so take that as read from the project rather than measured. Add sign-in, a hosted backend or any remote API and first launch does need one online session, because nothing is cached yet.

The run report is a data standard, not a notes field

Whatever the screens look like, the data underneath has somewhere it must go. EMS runs in the United States report into NEMSIS, the national EMS data standard, and fire incidents report into the National Fire Incident Reporting System, which more than 22,000 US fire departments send data to. Invent your own field names and somebody maps them by hand later, every month, forever.

The NEMSIS EMS dataset is not one flat form. Version 3.5.1 groups its elements into named sections including eResponse, eDispatch, eTimes, eScene, eSituation, ePatient, eHistory, eExam, eVitals, eMedications, eProcedures, eAirway, eArrest, eInjury, eNarrative, eDisposition and eOutcome. A second dataset describes the service itself, with sections such as dAgency, dPersonnel, dVehicle and dFacility.

That structure is free design work for an EMS app. Model the screens on those groups and the export becomes a mapping job rather than a rewrite. It also settles what is one per run and what repeats: one dispatch, one disposition, many vitals, many medications, many procedures. Putting repeated readings in a single text box is the cheapest mistake to make and the most expensive one to undo.

NEMSIS v3.5.1 data dictionary, section grouping for the EMS and demographic datasets

A patient record sitting on a phone

Storing writes on the device is the right call, and it puts protected health information in a pocket that gets dropped, left on a bumper and occasionally lost. An EMS service that bills is a covered entity, so what the app holds is electronic protected health information and the HIPAA Security Rule reaches it.

The technical safeguards are worth reading rather than paraphrasing. Unique user identification is required: assign a unique name or number for identifying and tracking user identity. So is an emergency access procedure for reaching the data when the normal route is not available. Automatic logoff, encryption and decryption, integrity checks and transmission security sit in the addressable group, which means you assess each one and record what you decided. It does not mean optional.

In build terms that is concrete. Each responder signs in as themselves instead of sharing one station login. The local database is encrypted at rest and the screen locks after a set idle period. Every view and edit writes a line you can read back. And the offline queue needs a clearing rule, because a queue that never drains is a year of patient records living on a handset nobody thinks about.

45 CFR 164.312, technical safeguards for electronic protected health information

Most of a shift is not a call

Response time gets the attention, but the screen crews open most is the one for everything between calls. Shift handover, rig checks, drug box seals, bottle pressures, ladder and hose records, a note that the latch on bay three is broken again. A fire department app that only knows about incidents is shut for most of the day.

Those checks are the same shape as any equipment inspection app: a list of items, a pass or fail on each, a photo when something is wrong, and a name and time on the result. The daily walk around the apparatus is closer to a pre trip inspection app, because a pump is still a vehicle and the questions are the ones any driver asks before rolling.

Keeping the checks in the same app as the runs is worth doing for one reason: history. When a piece of gear fails on scene, the question that matters is when it was last checked and by whom. That answer exists only if the check was a record with a timestamp on it, not a clipboard in a drawer. Build the check as data on day one, because you cannot backfill it.