In an emergency, a voice call is unavailable or difficult for people with hearing, speech or vision impairments, while the dispatch center needs to quickly get the type of danger, the location, and route the call to the right operator.
We built a mobile app and a dispatcher web panel on a shared API: a person picks the right service with one tap, coordinates are attached automatically, repeat calls stay pinned to the same dispatcher, and important alerts are duplicated across four channels at once - push, SMS, email and a web socket.
The solution ran the full path from signal to routing, handling and notification, and was validated by focus groups of people with hearing and vision impairments; it hasn't been moved into permanent operation yet - that needs separate approvals and a regulation from the service side.
Sometimes the call itself becomes the obstacle
In an emergency it is hard for a person to calmly explain what happened and where they are. For someone with a hearing or speech impairment, an ordinary voice call may be entirely out of reach. A person with low vision struggles to dial the number, read the prompts, and dictate an address.
The solution was originally meant for foreigners held back by a language barrier. As the work went on, the focus shifted to people with special needs: for them the problem was not the quality of translation, but the very requirement to make a call and speak with an operator.
The scenario had to be reduced to a single action that would tell the service three things: who is calling, what help is needed, and where the person is. On the dispatch side the task is a mirror image: a new signal must reach the right operator at once, receive a status, and not vanish into a shared queue.
The person picks the service, the location is added automatically
The system consists of a mobile app and a dispatcher web panel that work through a shared API. In the app, a person selects the type of service. The region, city, and coordinates travel along with the request, so the operator gets the location without a spoken explanation of the address.
The point of the signal is not to imitate a long conversation. The app structures in advance the minimum a dispatcher needs to start reacting, and sends it in a single action.
A phone number is tied to the profile, but a return call is not always allowed. In a dangerous situation, sound can give a person away to someone nearby. If "do not call" mode is on, the dispatcher sees this restriction and does not dial the number.
An ordinary call was not made any harder in the process. When a user chooses to call an emergency service themselves, the app launches the standard cellular dialer. No extra internet layer appears between the person and the operator that the familiar scenario would depend on.
The subscription to events is also tied to a place. The user picks their region and does not have to scan a nationwide feed to notice an event that concerns their city or area.
The medical card opens only during a call
A user may, if they wish, record chronic conditions and other states relevant to emergency medical care in advance. During an active medical request, the operator sees what to prepare for and which particulars to pass on to the crew.
This way an ambulance call carries more than coordinates and the general type "medical help needed". The card helps to understand in advance what condition the crew may face and what equipment will be needed. The user fills in this information voluntarily; the absence of a card does not prevent sending the signal itself.
This information belongs to the most sensitive data in the system. It is stored in the database in encrypted form: stealing the database itself does not turn the records into readable medical cards without the key.
Decryption happens at the moment of an active call. The rest of the time the operator cannot open the card out of curiosity or view it outside of a request. The data becomes available when it is needed to help, and closes again beyond that context.
A new request gets a place in the workflow right away
Incoming requests appear in the panel over web sockets, without a manual page refresh. Every request goes through a fixed lifecycle: incoming, in progress, handled, cancelled, or erroneous. Separate tabs in the panel are built around these states, so the dispatcher sees both the queue and the unfinished cases.
Moving between tabs reflects the real work with a request. A new record stays in incoming, one accepted by a dispatcher moves to in progress, a completed one to handled. Cancelled and erroneous signals are kept as separate states rather than disappearing from the history without explanation.
An unassigned signal is routed by two attributes: type of service and region. It goes to the dispatchers responsible for the right area in that territory.
A repeat request behaves in a more involved way. If an operator is already working with a person, the next signal from them is pinned to the same dispatcher. Without this, the new record would land in the shared queue again and could go to a colleague who had not seen the earlier context.
Pinning turns a set of separate signals into consistent work with one person. The operator understands what happened before and does not start each new request from scratch.
An important alert does not depend on a single channel
Events for a region's residents are sent along four paths: a push to the device, SMS, email, and a web socket for those who are online right now. Each channel has its own way of failing: the phone lost internet, the carrier delayed the SMS, the app was unloaded from memory, the email arrived late.
That is why an important message is duplicated rather than waiting for confirmation from one "ideal" transport. A design with a single channel and delivery confirmation would look more economical and technically neater, but it would leave one point of failure between the event and the person.
The mobile app hands the server a device token, while the push delivery is carried out by an external service. Stale tokens are removed automatically, so the server does not keep sending messages to devices that no longer accept them.
The redundancy here is deliberate, and the same reasoning explains the fixed statuses and pinning a repeat request to a dispatcher. The cost of a mistake in a system like this differs from an ordinary product: a lost signal means not a missing record in a report, but a person who might not have been helped. This risk shaped the architecture more than any drive to make it minimal.
The set of services is kept in configuration
The system started with SOS, fire, police, ambulance, and the gas service. The type of request and the link between a dispatcher and that type are not hard-wired into the code forever. When a new line was needed, it was added to an already running system without rewriting the core.
Operationally, connecting a service comes down to an agreement with it and a dispatcher workstation. After setup, the new type appears among the options, and its requests get their own responsible dispatchers.
The same mechanism allows for further expansion into utility and household cases: a plumber for a burst pipe, an electrician for a power outage, or a tow truck for a car on the highway. But it is important to separate the working foundation from the direction of growth.
| Capability | State |
|---|---|
| Emergency types SOS, fire, police, ambulance, and gas | built into the core |
| Adding a new type and assigning dispatchers | proven in operation |
| Different priority and expected response time by type | direction of growth |
| Utility and household services | direction of growth |
| Different scope of visible data for each service | direction of growth |
Utility and household cases are a natural application of the same mechanism, not part of the solution's current operation.
Priority really does depend on the meaning of a request. The smell of gas calls for an immediate response, while a car stuck on the highway allows for help within a few hours. The type defines not only who acts, but also the expected urgency.
As the list of services grows, minimizing data becomes more important. A tow truck needs only the car's location; a medical card and a home address are of no use to it. For an ambulance, on the contrary, medical information can be critical. Encryption and showing the card only during a call are already implemented in the emergency core. Separate visibility rights for each future type of service remain a direction of growth, not a ready feature for all the scenarios listed.
The interface was tested by people for whom a call is out of reach
The app was tested by more than just developers. Focus groups of people with hearing and vision impairments worked with it. They checked whether the action was clear, how the signal confirmation looked, and whether it was obvious that the request had been accepted.
Their comments came back into the interface and changed it before the demonstration. The assembled system was also shown to a specialized state emergency-response service in demonstration runs.
What was tested this way was not abstract accessibility against a checklist, but a concrete human path: pick a service, send a location, and understand the result without a mandatory voice conversation.
The assembled system has not yet become a permanently operating service
The solution covers the path "signal - routing - handling - alert". It does not replace the police, an ambulance, the fire service, or the rules of their work. The accuracy of the location is limited to the device's coordinates. Routing by region and type of service works by a preset rule rather than predicting the dispatchers' current load; as the team grows, balancing will need to be developed.
The API, the dispatch panel, and the delivery channels are separated, so the mobile scenario, the routing rules, the dispatcher workstation, and the notification delivery methods can each evolve independently.
The solution is assembled, worked as a whole, and was tested by focus groups, but it has not been put into permanent operation. Launching it requires separate approvals, regulations, and funding.
The approvals determine who receives a signal, under what regulations they respond, how the workstation is funded, and who bears responsibility for operation. The government cycle here can take longer than the development itself, and program code does not remove that boundary. The system can be adapted to a specific service or region, but at the moment it is not a publicly available, operating emergency channel.
Oleksandr
This is a real project, presented anonymized. We deliberately change the identifying details - the industry, the specifics, anything that could point to the client - and we don't reveal the client's name or trade secrets. What stays intact is the substance: the problem we solved and the engineering approach behind it. This case study is here to show the problem and its solution - what we do and how.