What an Emergency Response App for Nepal Actually Needs

Emergency response software written for a large Western city assumes a single dispatch authority, a fleet with GPS, addressed streets and a caller with a smartphone. Change any one of those and the design starts to creak. Change all four, which is roughly the situation across much of Nepal, and it stops working.

This is not an argument that the software cannot help. It is an argument that the imported product will not, and that the useful version looks structurally different: less command-and-control, more directory and broadcast, with a fallback to a phone call on every screen. What follows is the set of assumptions we would start from, and the ones we would refuse to carry over.

Location without addresses

Large parts of the country are not addressed in a way software can parse. A caller may describe a location by landmark, ward or the name of a shop. The system therefore needs to accept a coarse fix and refine it, rather than demand a street address before it will proceed. Sending a coordinate from the handset, even a rough one, is worth more than a perfectly formatted address that nobody uses.

In practice that means several things at once. The app should transmit whatever location it has immediately, with its accuracy radius attached, and keep improving it in the background rather than blocking on a precise fix, because a GPS lock in a valley or between tall buildings can take a long time to settle. It should let the caller add a landmark in Nepali as free text, since a human dispatcher can use "behind the Bhatbhateni in Chuchepati" better than any geocoder can. And it should carry a plus code or similar short location string that a caller can read out over the phone when the data connection fails, which it will. The location model underneath all of this is the same one that road safety reporting needs, and the problems are described in more detail in Nepal's road crash data problem.

Many responders, no single dispatcher

• Ambulance provision is a mix of public, private and community operators, with no single controlling authority.
• The nearest capable responder is often not the one formally assigned to that area.
• Hospitals differ sharply in what they can actually receive at a given hour, and a facility with a sign saying emergency may not have a surgeon on that night.
• Volunteers are frequently first on scene and have no way to log what they did or hand over cleanly.
• Police, fire and ambulance are separate numbers with separate systems and no shared incident record.

A system that models this honestly is a directory and a broadcast, not a command hierarchy. It should tell a caller who is genuinely nearby and reachable, and tell responders what is already en route so two vehicles do not chase the same case. Anything that assumes it can assign a unit and expect compliance is describing an authority structure that does not exist, and it will be quietly ignored by the operators it depends on.

Capability matters as much as proximity. The nearest ambulance may be a converted van with a driver and no oxygen, and for a cardiac case that is a different answer from a stroke case. A directory worth having therefore records what each vehicle and each facility can actually do, not just where it is, and it presents that honestly rather than ranking everyone by distance. This is also the field most likely to be out of date, which brings us to the part nobody demos.

Working when the network does not

Every screen should have a fallback that resolves to a phone number. If the app cannot reach its server it should still display the relevant numbers for the caller's last known district, from a cached copy. An emergency tool that shows a spinner has failed at the only moment it existed for.

Design for the moment the network is worst, because that correlates with the moment the emergency is worst.

Concretely: ship the full responder directory in the app bundle and update it in the background, so a fresh install works offline on the first day. Cache the last known directory for the user's district and the two adjacent ones, because people travel. Make every call button a real dialler intent rather than an in-app voice feature, because the mobile voice network survives conditions the data network does not. Compose an SMS fallback containing the coordinates and the caller's details, ready to send with one tap, for the case where data is gone but a text still gets through. And design the whole thing to work on a mid-range Android device several versions behind current, because that is what most of the country carries, a constraint we treat as a baseline in all mobile work for Nepali users.

The parts nobody demos

Keeping the responder directory current is the entire project. Numbers change, vehicles go out of service, hospitals close departments overnight. Whoever builds this has to fund the boring maintenance loop that keeps the directory true, or the app becomes a confidently wrong list within a year.

There is a mechanism for this that works, and it is unfashionable: treat each entry as having an owner and an expiry. A hospital or operator confirms its own entry on a schedule, an entry that has not been confirmed in six months is shown as unverified rather than silently trusted, and every failed call reported by a user is logged against the entry it came from. That last signal is the cheapest quality check available, because users find dead numbers faster than any audit will. Budget for a person whose actual job includes ringing round, because no amount of software replaces that call.

Data and dignity

Health emergencies produce sensitive data. Collect the minimum needed to dispatch, set a short retention window, and be explicit in plain Nepali about what is stored and who can see it. Trust is the operating requirement, not a compliance checkbox.

The practical rules are short. Do not require registration before someone can find a number, because a login screen between a person and an ambulance is indefensible. Do not retain precise location traces after an incident is closed; keep the coarse district for reporting and drop the rest. Do not sell, share or analyse call content, and say so in the interface rather than only in a policy page. If the app is run by a public body, publish the retention period. These are the same disciplines that any serious healthcare technology project has to get right, and they are cheaper to build in than to retrofit.

What to build first, and what not to build at all

The first version is a verified, offline, district-aware directory with one-tap dialling and a location string the caller can read out. That is a small piece of software and it is immediately useful, which is a rare combination in this field. Everything else, live vehicle tracking, in-app chat, automated triage, hospital bed availability, depends on institutional participation that does not yet exist and will produce a convincing demo and a dead product.

Two things are worth saying plainly. Automated triage advice to the public is a bad idea in a first version, because a wrong instruction under stress is worse than no instruction. And an app is not a replacement for a well-publicised phone number, in the same way that a phone alert is not a replacement for a siren, an argument made at length in what a Bhote Koshi warning system would actually take. The app is a supplement for people who have it installed, charged and connected. Design it as the second channel and it will be honest about its own limits.