Improving emergency response logistics through advanced GIS

Abstract

Background

Emergency call centres, commonly known as “112” or “911”, are a crucial part of modern infrastructure. The location of the emergency, any related data, and good GIS support are required for their efficient operations. The location in particular is a vital piece of information but nevertheless often not obtained automatically at all or with insufficient accuracy, thus limiting both the speed and the reliability of emergency response.

Methods

We present multiple improvements and novel features aimed at emergency response. A smart phone app speeds up and simplifies the acquisition of the location and other data. The typical problem of low penetration of such apps is solved by the web application accessible via an SMS. Common operational picture allows the operators to manage resources used throughout an intervention as well as review the past resource management. Statistical analysis strives to suggest the best course of action to the operators. Road access time calculations enable the analysis and improvement of emergency preparedness.

Results

All our improvements, which are currently in various stages of development, were evaluated by the domain experts at the Slovenian Administration for Civil Protection and Disaster Relief. The automated data collection through web and native app, the calculation of road access times for emergency response units, and common operational picture management are already used in day-to-day operations. They have helped to find lost people, to establish new emergency response units where needed, and to manage resources in refugee camps. On the other hand, the suggested statistical approach to guiding call takers was discarded and suggested that the collected data rather be used for personnel training only.

Conclusions

Most of our contributions to the emergency response process and software have proven valuable during actual emergencies, with certain shortcoming that still need to be addressed.

Background

Emergency call centres throughout the world play a crucial part in providing protection and rescue to the people. They serve as the first point of contact to emergency victims. Even though these call centres are dispersed throughout countries and cover smaller regions, they typically take hundreds of emergency calls daily [1]. The speed and quality of the emergency response depends critically on both the training of the operators as well as the available technology [2].

Emergency call centre operations

A typical sequence of steps done by the operator is:

• 1. Receive an emergency assistance request.

• 2. Collect the information from the caller and other sources.

• 3. Start the rescue action based on predefined plans and monitor the intervention throughout its duration.

• 4. Compile a report.

We will detail steps 2 and 3, which are central to our work. For each call, the call operator has to determine the location of the caller and the nature of the emergency as quickly as possible to be able to provide efficient help. Call operator’s job is very difficult if the caller does not know his location (lost people), can’t speak or can’t be heard clearly. To a certain extent, difficulties collecting the caller information can be mitigated by the experience of the call taker, but nevertheless some interventions are performed based on incomplete or erroneous information.

In certain cases the collected information may reveal that the call was placed accidentally, that there is no actual emergency, or that the emrgency can be solved by the operator guiding the caller. Either way, some calls do not require operators’ further actions.

More often, emergency response units from one or more emergency service have to be dispatched. The dispatcher, who may or may not be the same person as the emergency call taker, initiates an intervention. The dispatcher/operator then keeps contact with the team and manages the logistics of the intervention. He receives any additional emergency calls related to the same event. Status updates help the operator to have a better understanding about the progress of the emergency response operation. This is particularly important in larger emergency situations, such as chain collisions, earthquakes, etc.

GIS in emergency response

The location of the emergency and the related geospatial information, such as the responsibility areas of response units, are crucial for the operator. A GIS thus typically forms a major part of the call centre IT systems [3, 4]. In Estonia, for example, the GIS112 project was implemented in 2014 with the aim of reducing the response time. It allows the emergency services to perform a first evaluation within 60 s [5]. Throughout the course of intervention it also allows the operators to follow the emergency vehicles and units live on the map.

In case of Slovenia [6], a GIS was built based on the open source Gaea+ 3D client [7]. Its 3D nature increases the operator’s situational awareness both in urban and in mountanious terrain. It is based on NASA WorldWind Java SDK [8], with a PostGIS/Geoserver backend [9, 10].

Automated data collection

As described above, oral collection of location and other incident data is time consuming, error prone and sometimes even impossible. Automatic collection of calling number, subscriber name, street address and, through GIS integration, location on a map is typically performed for all calls from fixed phones (PSTN or ISDN). The so-called nomadic IP phones, on the other hand, provide just the home address, which may or may not be the current location of the caller.

Mobile calls are becoming the dominant way of reaching the emergency services and SMS is also increasingly used. On one hand, data on mobile users’ location is even more valuable because they typically call directly from the location of the emergency, and not for example from the nearest pay phone. On the other hand, oral collection of location is even more difficult, making automation even more desirable. For example, in central London the percentage of mobile emergency calls grew from 5% in 1999 to 29% in 2004. After implementation of automated location collection, typically referred to as emergency mobile location, the average ambulance vehicle response time dropped from 469 to 444 s [11].

Technically, the mobile network operator can obtain the location based on the coverage area of the currently used cell (typical accuracy from 300 m to many km) or using trilateration of signals from multiple cells, e.g. based on the “observed time difference of arrival” method (typical accuracy 100 m in densely covered areas) [12]. Methods with a theoretical accuracy of 25–50 m have also been suggested [13].

A European Union directive requires the mobile network operators to provide emergency location. However, the implementing laws do not mandate a high accuracy and thus only the cell coverage method is used in most countries [14]. The typical time required to obtain the location also varies greatly between countries and operators, from a few seconds to multiple minutes.

The ubiquity of smart phones provides the opportunity to use the phone itself, rather than the mobile operator’s equipment, to provide the location and other data. Many Android-based phones support Advanced Mobile Location (AML), which uses the phone’s GPS receiver to obtain accurate location information and automatically send it to the emergency services in a standardized, free-of-charge SMS message whenever a call to an emergency number is made [15]. AML is already in use in the UK and Slovenia and is being tested or implemented in 8 other European countries [16, 17].

Finally, and most related to our work, the emergency services of certain countries or regions offer emergency apps for most smartphones with AML-like functionality [14]. Their major downside is that very few users have them pre-installed and that installation during an emergency is typically too slow and stressful.

Methods and results

In this section we first illustrate how our contributions fit into the everyday operations of the emergency call centres, which of the problems listed in the Introduction we address, and then describe our approach in detail. In the next section we report on the validation of the contributions and their positive effect in emergency services operation.

The black-and-white parts of Fig. 1 show the standard workflow used to process mobile calls. The GIS interface shows the coarse caller location as provided by the mobile network operator and various geospatial data layers, such as administrative coverage zones of the emergency units. Based on this data, the operator dispatches the appropriate units for the intervention. Separate phone equipment is used to talk to the caller as well as to record and later replay any call.

Fig. 1

Schematical view of our contributions. The original emergency response process is shown in black and white. The blue parts illustrate the enrichment of the GIS interface as a result of our work

The improvements enabled by our work are shown in blue in the same figure. First, we address the automated collection of location and other emergency-related information for calls made using smartphones, as shown in the lower left corner of Fig. 1 as data streamed from the phone into the GIS. Second, we improve the logistics of emergency interventions, as shown by the two database icons in the lower right corner. Both contributions enrich the GIS interface with crucial information, as shown in the central part of the figure.

Obtaining emergency-related information

A major improvement over existing emergency smart phone apps is the SMS Locator. The operator sends to the caller a pre-configured SMS with a link to a web app, as shown in the upper part of the smartphone screenshot in the left of Fig. 1. The web app acquires the location using the built-in GPS and other location services, then sends the location to the back-end server. This approach requires no installation of apps before or during the emergency. In contrast to AML it also works with iOS, Android, Windows, Symbian and possibly other smartphones with data connectivity and built-in GPS, regardless of make or operating system. The one downside is that the user must know how to enable the location services and mobile data, because web applications are typically not allowed to do this on their own.

A native SmartLocator app was also developed to complement the SMS Locator. In addition to initiating a call to 112 and providing the location, it sends pre-configured optional user data. The user can enter their name, address, blood type, allergies or other medical conditions, etc. The app also allows the caller to select the kind of emergency service needed (police, firefighters or medic), what the nature of the emergency is, or add a free-form description of the situation.

Both the web and native apps continue sending until the user stops them, such that the operator can follow the locations of all callers live in the GIS. Moreover, they can send photos or a video feed from the phone camera, allowing the operator to visually inspect the incident site. We are currently integrating additional phone sensor data, such as using the camera for measuring heart rate and rhythm [18], informing the operator about the caller’s heart condition. The mobile network signal strength and battery level are also important as a hint to the operator on whether the call is likely to be disconnected soon. Finally, smart phone connectivity is being added to many kinds of external sensors aimed at users with certain medical conditions, such as BlueTooth-connected ECG [19] or blood glucose monitors.

Logistics of emergency interventions

The second set of our contributions target the call takers, dispatchers, and other emergency management personnel, rather than people in emergency situations directly. Their main problems are to decide which unit to dispatch where and when as well as how to manage the data supporting these decisions.

First, we have implemented the so called Common Operational Picture (COP). It allows a managing operator (COP manager) to enter and manage information about all resources available and about those deployed on emergency sites, such as various emergency service units, equipment and consumables (food, blankets, medicine, etc.). Reflecting reported changes on site, the COP manager adds or removes resources, updates their locations and status in real time. The COP module records all changes and makes them available to others, as shown on the example of a tent in the GIS interface in Fig. 1. It also offers a “Time machine” view, allowing to go back and forward in time and to review past interventions in order to analyze, report, or use the recorded data to train new personnel.

We have researched the correlation between individual calls and between the calls and the dispatched units, taking into account the location of the caller and other available information. Our intent is to suggest to the call taker whether the incoming call relates to an emergency already being processed or a new one, and which units to dispatch. The latter is currently implemented in a trivial form only (the software suggests that the same unit be dispatched as the last time when the same type of emergency occurred in the same municipality), while the data is being collected for further statistical research. Any decision must ultimately be made by the operator rather than automatically by the software. Our goal is thus to offer sensible defaults in order to save precious clicks and seconds.

To further help the dispatchers draw better and quicker decisions, the GIS can estimate the time for emergency service units to reach the emergency site. This is currently possible for motorized units (firefighters, paramedics, police) or for units that use foot paths (such as mountain search and rescue units). For others, such as cave rescuers, the estimation is not possible due to lack of quality data. In case of static starting locations, such as fire brigade bases, access time estimations can also be done in advance for whole regions.

Evaluation and discussion

The presented improvements and ideas were evaluated in cooperation with the Slovenian Administration for Civil Protection and Disaster Relief (ACPDR). We will first discuss the features that are already in production and were thus also validated during live operations, followed by theoretical validation of the features currently being developed. It was unfortunately not possible to fully measure the impact of our work due to other changes at ACPDR at the same time, and thus many results can only be illustrated anecdotally, rather than quantitatively.

The SmartLocator native app is not yet in production in Slovenia. It has been presented by ACPDR to organizations of people with specific disabilities, e.g. hearing or speech impaired, for whom it is crucially important. A rebranded version, known as retteMi.ch, is used in certain cantons of Switzerland with a total population of 2.3 million people. The Android version has been installed 5.462 times and the iOS version 22.135 times from its introduction in October 2016 until January 6th 2017. The penetration is low, as expected, because most people are either not aware that such apps exist at all, or for various reasons unwilling to install them before an actual emergency occurs.

The low penetration of the app leads to SMS Locator being used more often. However, the operator uses it only if he thinks the caller will know how to enable location services and mobile data on the phone. Furthermore, waiting for a GPS “fix” can take a long time, depending on the phone model and environmental situation (obscured sky, out-of-date GPS ephmeris and almanac data [20]). In known surroundings, describing the location is quicker. On the other hand, SMS Locator was invaluable in the case of a lost person in Bavaria. The mountain rescuers of Bergwacht Bayern were able to locate him and reached him one hour after the call, thus saving them a lot of time and saving him a long wait late in the night. A similar case was a lost driver in the hilly forests of central Slovenia.

Some of the additional data provided by the (web or native) app, such as picture from the phone camera, was found to greatly assist the call taker to assess the emergency. Continuous updates of the location, on the other hand, were assessed as not important. Any medical data are not directly usable to the 112 operators but rather forwarded to the medical personnel. Their importance therefore could not be verified yet.

Another production feature that already proved to be useful is Common Operational Picture. This feature was particularly useful for ACPDR during the refugee crisis in Autumn 2015 to monitor the resources in refugee camps. Certain shortcomings were revealed, mainly that managing large inventories by hand can be daunting. The ability to modify the inventory would also need to be shared among the personnel, rather than centralized with the COP Manager.

The road access times from base locations of the emergency response units to the whole country of Slovenia were pre-calculated and visualized by color-coding road sections according to access times, as shown in Fig. 2. This static analysis was first used for optimization of areas of responsibility, as illustrated by updated coverage area in Fig. 1. It was then further used for long-term planning, where all areas of the country not reachable within 20 min were analyzed and four new units were established.

Fig. 2

Emergency access times. Visualisation of access times for specialized firefighting units. The centre of the shown area contains many yellow and red shaded roads, representing the problematic access times longer than 20 min

It was decided not to use the correlation between past calls and dispatches to make suggestions to the operators. ACPDR was in their assessment worried about inaccurate data causing false correlation. Furthermore, any automation may conflict with the pre-defined scenarios for each emergency type, which the operators are obliged to follow. On the other hand, ACPDR suggested to use the collected data for automated and realistic training of personnel, who can play over the past scenarios and learn how to respond without the stress of an actual emergency.

Conclusions

We have described typical emergency call centre operations. We presented multiple novel features that are currently in various stages of development. Some are aimed at retrieving the caller location and other emergency related data, while others at helping the emergency workers with their logistic tasks. All features were evaluated by domain experts at the Slovenian Administration for Civil Protection and Disaster Relief.

The SmartLocator app and SMS Locator web application proved their value in cases when the caller could not communicate their location, either because of their impaired communication abilities or because they were lost. Two cases of the latter were reported in this paper. Apart from the location, the photo and video capabilities were also deemed valuable, while other data was judged to be of limited significance to the call takers.

The research on applying statistical analysis of past events to future emergencies was discarded; however, it was suggested to use the collected data for call operator training. The logistic tools were seen as highly valuable and have been used for tasks ranging from establishing optimal bases for four new emergency response units to handling resources in camps during the 2015 refugee crisis.

The improvement of emergency response capabilities is an ongoing process and thus, following the results of the evaluations, the features judged to be beneficial will be developed further. In particular, real-time road access time calculations and training tools require further development before they can be used regularly in call centre operations. The benefits of supplemental medical data were not yet adequately evaluated, thus we are contemplating to cooperate with the relevant experts on that.