Volunteers play an increasingly important role in emergency response logistics. However, to make most use of their capabilities, they need to be dispatched to the emergency site in an effective manner and coordinated on-site. The purpose of this study is to present a requirements specification and initial design proposal for ICT-enabled dispatch of volunteers as first responders as part of emergency response digitalized co-production initiatives.
The study uses a case study approach inspired by action research and the theoretical lens of digitalized co-production. It includes a variety of methods for data collection, including interviews with volunteers, document analysis and participation in workshops.
The major themes identified are geofencing, dispatch coordination, dynamic resource allocation and communication and collaboration. First priority requirements include geofencing alert and positioning, a joint application programming interface, receipt of alert, receipt if arrival at incident site, withdrawal of resources, chat functionality and the ability to alert in descending order within the geofenced areas to avoid alarm fatigue. As to coordination and dynamic resource allocation, e.g. built-in alert restrictions, ability to pre-select profiles and to dispatch based on competence/training, capacity and equipment would enable a more optimized response.
While previous research on digital volunteerism mainly embraces spontaneous volunteers and social media, this study addresses long-time collaboration with professional response organizations – digitalized co-production – with a focus on the dispatch, coordination and task allocation of volunteers that are central to their integration with emergency response logistics.
Introduction
In contemporary society, there is an increasing awareness of the potential of digitalization to enable citizen engagement in public service delivery. It is also more and more seen as a necessity when public sector resources are cut at the same times as societal challenges increase, including, e.g. growing and aging populations, urbanization and depopulation of rural areas. The phenomenon is sometimes referred to as ICT-enabled or digitalized co-production (Rodriguez Müller, 2021; Paletti, 2019; Pilemalm and Alkusaibati, 2023). The trend of citizen engagement is specifically notable in crisis management and emergency response. Here, the use of volunteers is increasingly seen as a necessity in emergencies and in natural and man-made disasters, e.g. extreme weather events and the COVID-19 pandemic, but also in frequent emergencies such as traffic accidents, fires and cardiac arrests. Again, this is because of scarce professional response resources, in combination with increasing crises, at the same time as frequent emergencies continue to occur or increase where populations grow (Pilemalm and Alkusaibati, 2023).
Most related studies refer to spontaneous volunteerism or digital volunteerism in the context of large-scale crises. Spontaneous volunteers are volunteers that either show up at an incident site and offer their help, sometimes referred to as bystanders. Or they are digital volunteers using social media and crowdsourcing for providing and disseminating information, and sometimes, self-deploying and organizing themselves to go to the incident site (e.g. Yeo and Lee, 2020; Chatfield et al., 2013).
There is also a growing number of studies that focus on the use of volunteers as first responders in collaboration with the municipal rescue services or ambulance services in smaller, predefined types of emergencies, sometimes labeling this as an emerging digitalized co-production. Examples include SMS-lifesavers where volunteers in Scandinavia are dispatched to out-of-hospital cardiac arrests (Jonsson et al., 2023). Other studies describe volunteers that collaborate long-term with the rescue services and are dispatched as first responders to, e.g. cardiac arrests, traffic accidents, fires and drownings, while waiting for the professional response resources and label this as an emerging form of digitalized co-production (e.g. Pilemalm and Alkusaibati, 2023). Previous research has studied this concept overall and pointed out organizational, legal and ICT-related challenges and needs. The ICT-enabled dispatch of the volunteers to the emergency site, through SMS lists or apps installed on the volunteers’ mobile phones, has been pointed out as crucial to the co-production of emergency response (Pilemalm and Alkusaibati, 2023; Pilemalm, 2022). Developing an app may seem straightforward where basic technology is available. Nevertheless, current volunteer initiatives are hampered by insufficient dispatch solutions, above all lacking in geofencing, coordination capabilities and dynamic resource allocation. This has been reported to lead to alarm fatigue and difficulty keeping the volunteers’ motivation over time (Prytz et al., 2023).
Overall, there are numerous studies on existing apps for emergency and crisis response, but these mainly concern the spontaneous volunteers/citizens described above (e.g. Smith et al., 2017). There are scarce studies that focus explicitly on the ICT artifact for dispatch to smaller emergencies, if any, in the digitalized co-production context. In this study, we provide a requirements specification and initial design proposal on how such an artifact can be developed for an optimized dispatch to the emergency site and allowing for coordination of volunteers and their tasks, once they arrive, in small accidents but also in large-scale crises.
Study aim
The aim of this study is to present a requirements specification for ICT-enabled dispatch of volunteers as first responders as part of emergency response digitalized co-production initiatives. The functional requirements include:
Basic requirements needed for volunteer dispatch and first response to function sufficiently (Priority 1 requirements).
Advanced requirements that will allow for a more effective coordination of volunteers (Priority 2 requirements).
We also provide an initial design proposal for a developed app and a use-case scenario (Carroll, 2003) to illustrate the requirements. The study is a case study inspired by action research, condensing about five years of research and interaction with end-users (the volunteers) and merging previous studies with new data. The requirements specification is intended to provide standardized functionality that can be applied in various app solutions for dispatch and coordination in this type of volunteerism. The functionality primarily addresses volunteers responding to frequent emergencies. However, above all, the advanced requirements are relevant also to volunteer dispatch to large-scale crises, where dynamic resource allocation relating to tasks, competence, capacity and equipment becomes central. The target audience are researchers and practitioners in digitalized co-production, emergency response and crisis management and digital volunteers.
Background
In this section, we first describe digitalized co-production in general and in the emergency response and crisis management context specifically. We then relate this to digital volunteerism and app applications in crisis management. Finally, we provide the study context, i.e. the Swedish emergency response system, and the studied volunteer initiatives, including the current ICT dispatch situation.
Digitalized co-production in emergency response and crisis management
In co-production, citizens are not only consulted but are part of public services’ design, steering and management (Ostrom, 1996). It is increasingly seen as a necessity when public sector resources are cut or strained. A typical example is when professional first responders need to respond to a growing number of crises and extraordinary events while dealing with frequent emergencies simultaneously. Several recent studies have emphasized the role of digital technologies in co-production, using terms such as “ICT as an enabler,” “co-production through ICT” and “ICT facilitated co-production” (e.g. Paletti, 2019; Lember et al., 2019). That is, co-production is often related to digital technologies aimed at redesigning government services to fulfill changing user needs (Mergel, 2015; Lindgren and van Veenstra, 2018). In relation, studies tend to focus on rather sophisticated technologies for citizen engagement, e.g. internet of things and urban living labs (Müller, 2021; Paletti, 2016). There are fewer studies that focus on related barriers and hindrances. Lember et al. (2019) claim that the debate has been characterized by conceptual fuzziness and technology optimism where challenges such as investment of resources and motivation of citizens are not sufficiently addressed. When studies on digitalized co-production include challenges, they mostly focus on structural and cultural barriers, as seen in the literature reviews by Clifton et al. (2020) and Yuan (2019).
In crisis and emergency response, studies on ICT and digitalization seldom speak about co-production and rather relate it to “digital volunteerism” or “digital volunteers” (e.g. Yeo and Lee, 2020; Chatfield et al., 2013). There are, however, some examples where ICT-enabled or digitalized co-production is used to frame the involvement of volunteer first responders in frequent emergencies in rural and urban settings (Pilemalm and Alkusaibati, 2023; Pilemalm, 2021). They take an overall view of the volunteer initiatives but also emphasize the vital role of ICT for effective dispatch to the emergency site and for the pre-planned coordination of volunteers on their way to the site to carry out the first response. Several studies claim that the ICT currently used is lacking in this respect (e.g. Pilemalm, 2022).
Digital volunteerism, citizens and use of apps
As mentioned, most studies on digital volunteers in emergency response focus on social media and crowdsourcing. In addition, there are studies on apps in the crisis management context that focus on citizens as spontaneous volunteers explicitly. For instance, Tan et al. (2017), in their literature review, identify 49 various apps used by professional response organizations/authorities to collaborate with citizens during a disaster. Some are general-purpose apps and others developed specifically for that purpose. They include functionality such as organizing and collecting disaster-related data from the crowd, acting as a collaboration platform, alert and information functionality, functionality to gather, filter and analyze data to build situation awareness and functionality for users to notify others during disasters. Gomez et al. (2013) carry out a review on mobile applications for citizen emergency management, identifying 250 applications and finding that more than half of them are intended to be used by the victims. The apps that can be used by volunteers provide functionality such as providing location information, providing protocols to aid, sending useful information to the emergency call centers and receiving protocol instructions to solve the emergency. There are also examples of platforms/apps where volunteers can pre-register their willingness to contribute in a crisis situation, listing which activities they are willing to perform and what competences they have, ranging from manual work, playing with children, remote/digital tasks, logistic tasks, etc. (Neubauer, 2013).
As to apps developed for other types of emergencies, most studies focus volunteers acting on out-of-hospital cardiac arrests (Jonsson et al., 2023; Smith et al., 2017; Ringh et al., 2015). This example is the closest to the study’s volunteer initiatives. However, the cardiac arrest volunteers only acknowledge that they are trained in CPR or have received basic CPR training, and they do not engage in close collaboration with the professional response organizations, as in this study. On the other hand, these apps have geofencing functionality, which is a must in cardiac arrests (because the time span to increase patient survival is, in most cases, minutes). The studies presented by Jonsson et al. (2023) and Ringh et al. (2015) address the SMS-lifesavers project and the app Heartrunner. Recently, the Heartrunner app has been adapted to dispatch volunteers to fires and is used by one rescue service in Sweden (based on the same principle, the volunteers can sign up and be dispatched but are not trained or equipped by the rescue services). We also know that there are recent efforts, including the ambulance services and medical alerts, starting up in Norway (Sandvold, 2022) and The Netherlands with plans to extend to other alerts and the rescue services. There are also call-out systems for on-call firefighters in Denmark and Sweden, applying geofencing and, in Sweden, some dynamic resource allocation features.
In summary, there exist numerous apps for various emergency response contexts (crisis management and out-of-hospital cardiac arrests) and stakeholders (firefighters and volunteers). There are also several initiatives close to this study that have started but that are not yet researched. In this study, we attempt to address this identified research gap as we focus on long-time collaboration with professional response organizations in frequent emergencies of various kinds – digitalized co-production – rather than spontaneous volunteers or bystanders. Also, we base ICT requirements on solid user needs collected during a long time period. In relation to the emergency site, we move from the overall volunteer initiatives to address the dispatch, coordination and task allocation of volunteers specifically, using Swedish emergency response as an example. Overall, we focus on the perceived gap on technical barriers and on technologies other than social media in digitalized co-production. By this, we seek to pave the way for improved emergency response logistics that also includes volunteer resources.
Study context
In Sweden, the municipality rescue services are professional response organizations responsible for responding to frequent emergencies within their municipality, i.e. they are local response organizations, rather than a state authority. Other important emergency response organizations include the ambulance services (run by the city councils), the police (state authority) and the Swedish Public Services Answering Point (the PSAP), taking all incoming calls for dispatch (112). It is half owned by the state and half private. National authorities of particular relevance for the study are the Swedish Civil Contingencies Agency (MSB), responsible for coordinating crisis management, and the Swedish National Fire Protection Association (FPA), which mainly works for increasing fire safety but has recently taken an active part in the study’s volunteer initiatives.
The idea to use volunteers as first responders in collaboration with the municipal rescue services emerged more than a decade ago as a local initiative of a rescue service in a sparsely populated region in the north. The idea is to recruit volunteers, provide them with basic equipment and training and then dispatch them to predefined types of emergencies, e.g. traffic accidents, out-of-hospital cardiac arrests, drownings and certain fires, using their own ICT in terms of mobile phones, SMS lists or apps. The goal is to shorten response times by dispatching volunteers close to the emergency site so that they can start first response tasks before professional resources arrive. The concept was picked up by several municipalities in other local initiatives in rural and urban areas. It should be noted that using volunteer firefighters is a widespread practice, e.g. in many EU countries and in rural areas in North America, e.g. Brandweeracademie. (2019) and St Denis et al. (2012). In Sweden, they are called “part-time firefighters” and are found mainly in rural areas. They are, however, different from the volunteer initiatives/digitalized co-production described in this study. Volunteer firefighters may be unpaid, but they are “on call” and must respond during on-call duty. Also, they are under the work environment responsibility of the fire services and are often supposed to provide the first response on their own. Meanwhile, the idea of using volunteers as first responders in collaboration with the municipal rescue services is based on the principle “while waiting for,” i.e. the volunteers provide the first response until the professional response organizations (the municipal rescue services, the ambulance services and sometimes the police) arrive. They never replace them. It is always voluntary, i.e. one is not on call but can always choose whether to respond to an alert.
Previous related research, e.g. Ramsell et al. (2017) and Pilemalm (2020), shows how this type of collaboration/digitalized co-production is appreciated and effective, where, e.g. several lives have been saved and buildings prevented from burning to the ground (Pilemalm, 2021). Alkusaibati and Pilemalm (2023) showed that the majority of volunteers act on most alerts, mostly arrive before the rescue services, and are able to perform critical tasks at the incident site. Pilemalm (2023) argues that this is a new emerging hybrid type of volunteerism in emergency management in which the volunteers, rather than being spontaneous, engage in long-term collaboration with the rescue services. At the same time, they are organizationally unaffiliated, i.e. the rescue services have no formal responsibility for them. The hybrid type is bottom-up and local. This means that local fire chiefs or project leaders have initiated them, not the rescue services management level. Neither have they been preceded by any clear governmental strategy. This is in contrast with how co-production and digitalized co-production are usually perceived and studied.
Many local rescue services and national authorities for crisis management in Sweden have realized that future emergency response cannot cope without volunteerism. Still, the growth has been slow, with only about 30 of about 300 rescue services applying the concept with a total of 500 estimated volunteers. Therefore, national authorities have recently stepped in to provide support and coordination mechanisms for the initiatives to spread nationwide. The aforementioned studies have identified interrelated organizational and ICT barriers where the various dispatch solutions in use have been a major obstacle. It took about six years for the PSAP to develop their app. It currently lacks geofencing, as do the SMS lists used previously. The PSAP app is the app that the national authorities promote and want to further develop, as the PSAP is the Swedish alarm operator. This calls for improvement of the app to provide for volunteers as an integrated part of emergency response logistics.
Methods
In this section, we describe the research approach in terms of a case study inspired by action research and the methods for data collection.
Case study and action research
The study is a case study addressing the phenomenon of ICT-enabled dispatch and coordination of volunteer first responders as part of emergency response logistics and, in a wider sense, digital co-production. This means that ICT-enabled dispatch of volunteers in emergency response is the phenomenon under study, and that a variety of qualitative methods have been combined to gather the requirements (Myers, 2009). The case study is also inspired by action research. In the past, case studies have been successfully combined with action research to allow for both the interpretation and understanding of a setting and performing intervention and change within it (e.g. Stenmark, 2000). In our case, being “inspired by action research” implies that we are involved in the development of both the volunteer initiatives and improving the ICT dispatch. We thus take the double role as developers and researchers/participant observers. We provide recommendations to the rescue services and the national authorities that have initiated work in taking the volunteer initiatives further, including the Swedish Civil Contingencies Agency (MSB) and the FPA. However, we do not take part in implementing the recommendations.
Data collection
In this study, we take a point of departure in previous knowledge (data baseline) that have been reported in detail elsewhere (e.g. Pilemalm, 2020; Pilemalm, 2021; Alkusaibati and Pilemalm, 2023) and which includes, e.g. interviews, exercises and various user participation techniques. We include additional data collection that has taken place after the PSAP app release and use. In other words, we use data triangulation to increase the credibility of the results, which is a common approach in case study research (Myers, 2009). The data was gathered in 2023. It includes, first, interviews with the volunteer end-users. We performed ten interviews, of which five focused on the ICT artifact (the app) specifically and five on the ICT-enabled dispatch overall as part of the volunteer initiatives. Participant observation has included full-day workshops and meetings arranged by the national authority (MSB) for coordination of crisis management as part of their efforts to take the volunteer initiatives further. The workshop participants have mainly been the rescue services that already have the volunteer concept up and running or want to implement it. We have also observed two half-day meetings of a network of rescue services who exchange experiences about the volunteer initiatives. We have further had access to documentation by the FPA in their planned coordination efforts. As displayed in Table 1, the theme of geofencing was recurrent and needs expressed by all data sources. The themes of coordination of dispatch and dynamic resource allocation could also be identified in all data sources. However, expressed requirements were more common among the stakeholders coming from the rescue services and national authorities. In contrast, the requirements for communication and collaboration were only expressed by the volunteers/end-users.
Data collection methods
| Study data collection 2023 | Identified themes* |
|---|---|
| Document analysis (1) | Geofencing Coordination of dispatch Dynamic resource allocation |
| Interviews with volunteers (10) | Geofencing Coordination of dispatch Dynamic resource allocation communication and collaboration |
| Participant observation workshops (2 with 25–30 participants in each) | Geofencing Coordination of dispatch Dynamic resource allocation |
| Participant observation volunteer network (2) | Geofencing Coordination of dispatch Dynamic resource allocation |
Note: *The most prominent themes in all stakeholder groups are highlighted with italics
Several researchers have been involved in the data collection, whereas two of them have carried out the data analysis, leaning on memory notes, transcription, clustering of data and thematic analysis, as suggested by Myers (2009). All authors have provided feedback on the analysis.
Prototyping and use-case scenarios
Prototyping is an important part of the design process, especially in approaches that put emphasis on user participation. It is a means to realize ideas in a cost-effective way, in scaled-down versions of the product or system under development (Friis-Dam, 2022). They usually range from low-fidelity (lo-fi) paper or screenshot prototypes to high-fidelity (hi-fi) prototypes, including interfaces and coding close to an implementable product. In this study, we present an initial lo-fi prototype design, which has been preceded by sketching the various functions (Buxton, 2007). For the interface, we have applied Nielsen’s (1994) ten general heuristics/design principles for interaction design as guidelines. They include Visibility of system status, Match between system and the real world, User control and freedom, Consistency and standards, Error prevention, Recognition rather than recall, Flexibility and efficiency of use, Aesthetic and minimalist design, Help users recognize, diagnose and recover from errors and Help and documentation.
Scenario-based design uses concretization by building stories about use-case scenarios to the information systems development process (Carroll, 2003). Use-case scenarios are a sequence of actions users take when using a system and the flow of effects from that interaction and may be used to show what a system does and how it performs and can be gradually improved. It may also be used in data collection to add aspects of reality and recognition to the respondents. In the emergency response context, for instance, Grace (2021) used scenario-based interviews with municipal responders to examine the integration of SM in emergency management systems. In this study, a use case is presented together with the design proposal to illustrate its potential and use. The use case is built on the study baseline and data collection that has been presented in Pilemalm (2020), Pilemalm (2021) and Pilemalm and Alkusaibati, (2023).
Results
In this section, we first describe the current app solution. Then, we provide functional requirements, according to the following identified themes:
geofencing;
dispatch coordination;
dynamic resource allocation;
collaboration/communication; and
community.
We have also prioritized the requirements (Priority 1 and Priority 2) based on what the volunteer end-users and other stakeholders have pointed out as most urgent, but also on what we know is feasible in near-time app development. Finally, we provide a brief initial design proposal.
Current app solution
In the current PASP app version, the alarm operators create groups of volunteers and coordinate them through a customer portal. For the alerts on which volunteers are dispatched, the app provides brief information on the incident, in the form of a push notification and displaying information on driving time and type of incident. If the volunteer accepts the alert, they receive more detailed information such as map position, navigation aid and address to the incident site, knowledge of which of whose other volunteers and groups are alerted, number of casualties, etc. The rescue services in their turn should acknowledge the receipt of alert and be able to withdraw the volunteers if an incident escalate so the volunteers are exposed to potential danger. The information in the app is updated through a push notice, should the situation change, or new information become available.
The volunteers can create personal profiles and choose whether they want to be part in more than one alarm group and set availability for different time points. However, this must be done manually, and dispatch is based on belonging to and being available in a group. The different volunteer groups belong to various villages or parts of a municipality. Thus, there is no geofencing functionality. The volunteers can turn off push notifications of alerts or choose to have the notifications enabled. They can also choose the function “Urgent warning.” The latter is a loud notification that disregards the mobile being set to “quiet mode.”
As to security, the volunteers log in on the app using their general mobile Bank ID that is used to access most societal services in Sweden (bank accounts, patient journals and so on). To remain within the system (i.e. receive alerts) the volunteers have to login at least every 14 days. Also, the app requires access to tracking the volunteers’ activity and GPS. The app’s initial view is displayed in Figure 1.
The initial view in the app displays type of incident (in this case, fire in building, attic) and driving time (12 min, 3 kilometers based on an average positioning of the alarm group, not on geofencing)
The initial view in the app displays type of incident (in this case, fire in building, attic) and driving time (12 min, 3 kilometers based on an average positioning of the alarm group, not on geofencing)
Requirements: geofencing
As to functional requirements, the most urgent is geofencing or positioning, i.e. to coordinate the dispatch within a geographically defined area based on the volunteers’ current position. This is pointed out by all data sources and respondents, regardless of context. By not being able to dispatch the closest resource, the entire idea behind the volunteer initiatives – shorter response times – may fall short. In sparsely populated areas, many volunteers report that they go on every alert they receive. This has on occasion led to too many volunteers showing up at the incident site, blocking the way for the professional resources. Conversely, in densely populated areas, volunteers may receive frequent alerts 24/7, which they report leads to alarm fatigue and turning off their notification. Also, without geofencing, volunteers will not receive any alert if they are in the area of an emergency but do not belong to the alarm group associated with that area:
It would be good when you are out traveling and something happens. This is how it works with the SMS-lifesavers [another volunteer initiative in Scandinavia with people being alerted to out of hospital cardiac arrests] so why can’t we?
Geofencing must reside with the PSAP back-end systems, and it is therefore possible to also keep the alarm groups (as they are deemed important for community building, see below). However, it is the current geographical area that ultimately decides whether a user will receive an alert or not. The radius should be flexible, depending on e.g. population density and number of active volunteers within the area. A requirement put forward by the FPA is also that, in the next step, geofencing positioning should make it possible to see when the volunteers arrive at the incident site, follow them on site and see when they leave (time stamps). Currently, the rescue services do not have this control which results in that they are not sure who was at the incident site and should be provided feedback and support. It is also deemed important to measure long-time effects (e.g. response times). The geofencing requirements are summarized in Table 2.
Geofencing requirements
| Theme | Functional requirement | Requirement description | Priority |
|---|---|---|---|
| Geofencing | Geofencing alerts | Geofencing so that only those who are nearest the incident are alerted. Geofencing radius should be flexible (e.g. to avoid alarm fatigue) | 1 |
| Geofencing | Geofencing positioning/time stamps | Geofencing positioning/time stamps to see when the volunteers arrive at the incident site, follow them on site and see when they leave (e.g. for security reasons) | 2 |
Requirements: dispatch coordination
Coordination of dispatch is central to an effective use of volunteers as an integrated part of the emergency response chain. Requirements were identified among all stakeholders, but more common among stakeholders from the rescue services and national authorities. Requirements can also be identified at different levels. Currently, there are several ICT solutions being used, besides the PSAP app, two other apps developed by commercial suppliers (which most recue services however cannot afford) and sometimes the SMS-lifesavers app for cardiac arrests. This causes a somewhat messy situation for the volunteers/end-users. The PSAP alarm center, as mentioned previously, is half state, half private owned. In their app development they have a somewhat unclear role as either state authority (promoting their app to the national coordination organizations in their role as national alarm operator) and private actor (simultaneously wanting to earn money on it). As an example, they block the commercial app suppliers (who has geofencing functionality in their apps) from their back-office systems so that these suppliers cannot implement central functionality. Overall, the volunteers express frustration at the double, triple or mutliple dispatch systems in use. They would rather have one system that works for all:
For now, we have to use all of them [dispatch systems] because things are not working properly. One day, we receive the alert in XXX [the commercial app] and in an SMS, next day it is the PSAP app, and next time, it is only an SMS. It is such a thing that make us freak out a bit when it is in the middle of the night and the mobile phone starts ringing three times.
To have one dispatch solution was also strongly expressed by most rescue services at the workshops. In relation, even though the volunteers are supposed to receive their alerts directly in the app, this is not always the case. Rather, the rescue services alarm central operator sends out the alerts through SMS, causing some delay of the alerts. This is believed to be because of insecurity of the app:
I don’t think they trust the app really; it is not working properly. I think they (the PSAP) has realized this themselves, that it is not as stable as they want it. And then to be safe, they use the SMS too (volunteer).
The national authorities in the workshops agree that triple alert systems in use within the same area because of technical difficulties is not acceptable, as it contradicts the aim of a quick response. They, however, argue that it is not likely that all recue services will choose the same app solution. Therefore, a requirement on standardization of functionality and joint access to the PSAP application programming interface (API) is fundamental to future development.
No access to the API also inhibits coordination in the direct dispatch and response. Even though there is a receipt (accept) functionality in the current app version, it cannot be accessed by the rescue services’ own alarm operators. This has the consequence that they do not have information about which volunteers have accepted the alert or that are or have been to the incident site. This in turn limits their possibilities to provide follow-up, feedback, or trauma support. This is also frustrating from the perspective of the volunteers:
There is a button for “accept” but the rescue services do not see the receipt! If seems that we lack information sharing among the PSAP, the rescue services and the volunteers. It even happens that the rescue unit that arrives ask us: how where you alerted?
Similarly, the volunteers do not know which other volunteers have accepted the alert. They can only see who is logged into the app, i.e. that has received the alert. This implies that they make their own decision based on experience rather than facts:
If I know that x,y,z is logged into the app, I know that they are often logged in but never actually goes on an alert. Then I must let go of everything and go myself.
Similarly, even though the app includes a withdrawal function, several of the volunteers claimed that they do not receive updated information or withdrawal of an alert that has already been sent out. They think this might be because the existing withdrawal function is not sufficiently distinct in the app. Currently, it is provided as an update in text, not with a noise or signal. This makes it easy to miss. When speaking to the rescue service personnel at the volunteers meeting, the problem rather seems to be that, again, they cannot access the API, and hence, the withdrawal function. Meanwhile, it is they who are supposed to alert and withdraw resources. A functioning withdrawal function is therefore a central requirement.
A similar requirement that relates to dispatch coordination is alert restrictions. From the perspective of the rescue services, there are examples where built-in restrictions are required. For instance, volunteers are usually alerted to all traffic accidents taking place off the highway, but there are examples where they should not be allowed to go, e.g. if there is a part of the road that is very slippery in the wintertime. There is also, in a long-term perspective, a need to follow up on the volunteers having left the emergency site to provide trauma support and successive improvements of the volunteer initiatives. The coordination requirements are summarized in Table 3.
Requirements for coordination of dispatch
| Theme | Functional requirement | Requirement description | Priority |
|---|---|---|---|
| Dispatch coordination | Joint API | All apps should have access to a joint API (provided by the PSAP) to allow for the same basic functionality | 1 |
| Dispatch coordination | Receipt of alert | Functionality for receipt of alert where a respondent can answer yes or no to the rescue services | 1 |
| Dispatch coordination | Receipt of alert | Functionality for receipt of alert where a volunteer can see which other volunteers who have accepted or not accepted | 1 |
| Dispatch coordination | Receipt of arrival at incident site | Functionality for receipt of arrival at incident site, based on positioning. The receipt short includes concise information such as “first at site there is a sharp injury” or “I am not first a site” (e.g. to measure response times) | 1 |
| Dispatch coordination | Withdrawal of resources | Functionality to withdraw resources, e.g. if the situation turns into something dangerous must be accessed by the recue services and more distinct to the volunteers | 1 |
| Dispatch coordination | Standardized functionality | Basic standardized functionality should be available in various app solutions | 2 |
| Dispatch coordination | A built-in alert restriction | A built-in alert restriction so that a volunteer is not alerted to risky situations | 2 |
| Dispatch coordination | Receipt of leaving the incident site | Functionality for leaving the incident site, based on positioning. The receipt short includes concise information such as what the volunteer did and what equipment they used (to be used for follow-ups) | 2 |
| Dispatch coordination | Need for follow-up | Functionality for leaving the incident site should include information on whether the volunteer needs follow-ups (e.g. trauma support) | 2 |
Requirements: dynamic resource allocation
Geofencing functionality is related to the requirements on dynamic resource allocation. Requirements were also identified in all stakeholder groups, but more explicitly articulated among the rescue services and, in particular, the FPA. In the current app version, the same alerts go out to all volunteers in the alarm group in question. In the workshops, in particular the FPA workshop, respondents have put forward the requirement that the volunteers or alarm groups in a certain area should be alerted in descending order, i.e. if the first volunteer rejects the alert, others should be alerted. This is to avoid too many people showing up at the incident site simultaneously. This scenario has happened, particularly in rural areas with few alerts, leading to a lack of coordination when arriving at the emergency site. The opposite, that some volunteers in urban areas receive too many alerts 24/7, instead leads to alarm fatigue (Prytz et al., 2023). In the next step, volunteers could also be alerted in sequence or parallel if the situation requires, but still based on their geographical positioning. This would be relevant for situations where many resources are needed, for instance, a fire in apartment buildings with many injured people, as suggested by one volunteer.
Further, in the current app version, all volunteers have the same permissions to go on all alerts, even though some of them are more trained or have specific competences and qualifications that could be useful in a wider range of incidents and tasks. Several volunteers argue that this is because the rescue centers do not have the capacity to dispatch dynamically based on specialization and competence. Many express frustrations in this respect:
We are not allowed to act on cardiac arrests of children, which I believe is strange since we are trained in CPR on children. I am even an instructor in children CPR. If we could help saving a child’s life, why not?
Further, as representatives in the workshop pointed out, in some areas dominated by non-Swedish ethnicities, many people do not speak Swedish, which sometimes causes communication challenges among the rescue services and victims. Therefore, dispatching volunteers based on language skills should sometimes be beneficial. This has also been noted in previous research (e.g. Pilemalm, 2020).
Also, as noted both at the volunteer network meetings and national workshop and expressed by a few volunteers, not all volunteers chose to go on all alerts. As an example, some volunteers do not go on medical alerts because they know that these are cardiac arrests (and that they will encounter a person with a high risk of dying, regardless of intervention) but go to all fire alerts. Thus, the dynamic resource allocation functionality should enable volunteers to preselect their profiles, e.g. what types of incidents they are willing to act upon and what tasks they can perform. The requirement for dynamic resource allocation is even more relevant to large-scale crisis management, where the range of competences needed for on-site tasks – in direct response and over time – will increase. It would be beneficial to dispatch based on competence, equipment and experience from certain tasks. From the interviews, most volunteers say that they are willing to act also in large-scale crises and as part of a civil defense, but what they are willing to do ranges from “anything I am asked to do” to “first response tasks since there are other organizations that take care of transportation logistics and food supply.” The requirements for dynamic resource allocation are summarized in Table 4. That most requirements have Prio 2 does not mean that they are not important; rather, the app’s basic features must work before these steps toward specialization can be taken.
Dynamic resource allocation requirements
| Theme | Functional requirement | Requirement description | Priority |
|---|---|---|---|
| Dynamic resource allocation | Receipt of alert | Functionality for receipt of alert where a respondent can answer yes or no. If a volunteer answers no, the alert should go to the next volunteer in descending order within the geofenced area | 1 |
| Dynamic resource allocation | Receipt of alert | Functionality to allow for sequential, parallel or in descending order dispatch of volunteers within the geofenced area is required | 2 |
| Dynamic resource allocation | Dynamic resource allocation | Functionality for dynamic resource allocation to alert based on competence/training, capacity, equipment, language and to use pre-selected profiles | 2 |
| Dynamic resource allocation | Pre-select profiles | The volunteers should be able to pre-select their profiles, e.g. as to what types of incidents they are willing to act upon | 2 |
Collaboration and communication
As to collaboration and communication, a common notion among the volunteers is that good collaboration on-site with the professional responders is an important factor influencing both the effectiveness of response work and their retention, i.e. motivation to continue as volunteers. From the beginning, the idea was that the volunteer first response was “waiting for,” i.e. that they leave when the professional response organizations arrive, but experience has shown that as collaboration is established, they might stay at the emergency site to support the professionals. The volunteers simultaneously report examples when the rescue services alarm operators refrain to alert the volunteers, resulting in that they are excluded from incidents they are able to act upon:
It is a matter of trust. The rescue services must recognize that we do a good job and don’t be afraid to dispatch us. I must not be “them and us”. Also, the operators should get to know the volunteers and what competences they have […] we should get closer to each other.
While first response collaboration on-site requires comparatively little ICT support, the ICT can support the pre-planning of effective emergency response logistics. Most of the volunteers request communication functionality in the app to be able to better prepare for this on-site collaboration, both among themselves and with the rescue services. In other words, there is a need to communicate among the volunteers/users before and during an emergency, also reflecting the dynamic resource allocation requirement:
It would be good to be able to share information with each other and know who and how many goes on an alert. It might be good to know who will be there and what competences and functions are filled at the incident site.
In the current app version, the volunteers cannot communicate directly with the rescue services personnel who are on their way to the incident site. The only solution is to call the rescue center as a mediator. Direct communication could simplify things both for the volunteers and the rescue personnel, according to several volunteers:
Direct communication with the rescue unit would have been good. On one occasion we had a fire, and the fire unit went by because they had the wrong direction. If we had been able to contact them and inform them of our whereabout, things would have been easier.
Several volunteers also pointed out a need to collaborate among volunteers in between alerts and first response assignments, i.e. to create a volunteer community. This may, in turn, contribute to the recruitment of more volunteers and to create a sense of togetherness between missions. In general, it is notable that communication is a common theme among the volunteers/end-users, while not expressed explicitly by the rescue services or the national authorities. The collaboration and communication requirements are summarized in Table 5.
Collaboration and communication requirements
| Theme | Functional requirement | Requirement description | Priority |
|---|---|---|---|
| Collaboration and communication | Chat functionality | Chat functionality to see that more volunteers are on their way | 1 |
| Collaboration and communication | Chat functionality | Chat functionality to communicate with rescue services representative | 1 |
| Collaboration and communication | Functionality for on-line communication | Online communication functionality to establish collaboration and community between incidents | 2 |
Initial design proposal
Based on the requirements, we suggest an initial design proposal, addressing a sub-set of primarily Priority 1 requirements and some Priority 2 requirements. The requirements are selected to provide an initial overview of how an updated version of the app could look like. The design is thus based on the PSAP app, but with added functionality and design features. We have also leant on the Nielsen (1994) design principles, as listed in the methods section.
When an alert goes out to volunteers in a certain area, view number 1 is shown in the volunteer’s mobile phone (see Figure 2). If they accept, the volunteer is directed to the next view where they can navigate directly to the incident site by pushing the button placed in the middle, which is connected to a navigation app on the user’s phone.
The user can also choose to collaborate with other volunteers who have accepted alerts by pushing on the button “collaborate.” If they click this button, they are transferred to view 3, which is a chat-site for all group members, i.e. all volunteers who have accepted the specific assignment and they can also reach a representative from the rescue services (view 4). If the user needs to contact some of the group members, there is an overview under a button called “view group members” leading to view number 5. Hence, the user can contact group members through a joint group chat as well as individual contact in the form of phone calls and private messages. The volunteer can also contact the rescue services representative through a direct phone number, which is activated by pushing a button.
If an alert is withdrawn, view number 5 is shown. The updated information is accompanied by a distinct signal. View number 6 shows the user profile, including, e.g. what alarm groups the user belongs to that are activated. From here it is possible to navigate further, e.g. to competences, which is view number 7. Here, volunteers can select their individual preferences, competences and personal profiles. This reflects the dynamic resource allocation requirement that volunteers should be able to preselect what types of incidents and tasks they are willing to act upon. Checkboxes are used with the ability to scroll to more detailed descriptions. Because the rescue services should be responsible for confirming the competences of the volunteers, the icons are static (should be set from the rescue services and their back-office systems) and cannot be changed by the volunteers. Nevertheless, they can have a view of what competences a volunteer can have. It is also possible to navigate to “Community,” i.e. the forum where volunteers can communicate with each other between assignments. To distinguish this function from the Collaboration function, this page takes the form of an online forum where communication can take place both via open threads and private messages (View 8). In the new design, the current assignment is in focus, while there is a possibility to scroll down and access previous assignments. This is for the volunteers to capture experience but also reflects the requirement of leaving the incident site, because it is intended to contain information of who was there, what happened, equipment used, etc.
The alarm groups are present in the initial design proposal and are in a similar way decided by the rescue services. However, this must be adapted once geofencing functionality is introduced. The basic idea to have alarm groups connected to certain areas is kept, as most often a volunteer will be near the incident in the area(s) where they work or live. It also reflects the community requirement. However, with geofencing, not all volunteers in a certain alarm group will receive the alert, and a volunteer may also receive an alert “outside” their groups if they are positioned nearby an incident site. Figure 2 illustrates the initial design proposal screenshots 1–8.
Use-case scenario: fire in a tenant building
The scenario exemplified in the screenshots above describes a fire in a tenant building (Screenshot 1). In the scenario, we assume that dry cooking on a stove has caused the fire (this is one of the most common causes of fires in tenant buildings in Sweden, especially in areas dominated by non-Swedish ethnicities that are not used to western stoves). In this case, all volunteers in a radius of 5 km or closer from the tenant are alerted. There is no need for specific competence because all volunteers have received basic fire extinguishing training (Screenshot 7). Two volunteers accept the alert (Screenshot 1) and receive further information, e.g. estimated driving time and address (Screenshot 2). On their way, they have a quick chat to notify each other (Screenshot 3). One of the volunteers also calls the rescue services representative (Screenshot 4), because a fire in a building might quickly spread to an extent where the volunteers should not go into the building. However, this is not the case this time. The first volunteer arrives and extinguishes the fire with a handheld fire extinguisher. The other calms the mother and the children that are in the apartment. The mother only speaks Arabic, but so does the volunteer who lives nearby. The rescue services arrive a few minutes later and talk to the family. In this case, oil has been involved in the dry cooking, and the rescue services inform the family how to handle similar situations in the future (i.e. do not try to extinguish the fire by pouring water on it). Afterwards, the volunteers are offered debriefing by the rescue services but do not feel that they have the need this time. However, they inform the other members in their alarm group about what has happened and how they handled the situation, i.e. lessons identified (Screenshot 3).
Discussion
In this section, we first discuss the growing number of volunteers as part of the chain of emergency response logistics. Then, we relate this to the role of ICT support for this digitalized co-production form and to the role of co-creation and user participation. Finally, we discuss study transferability and limitations.
Improving co-production: effective dispatch and use of volunteers at the incident site
In the background section, we identified several gaps in previous research on digitalized co-production. It speaks of opportunities rather than addressing, specifically, ICT-related hindrances. It focuses on social media or sophisticated technologies rather than basic ICT that may seem simple but is still vital for the outcome of co-production initiatives. Those studies that do focus on apps for dispatch do not label this as digitalized co-production, and more importantly, they address slightly different contexts and stakeholders than this study. Several of these apps have geofencing functionality and some have some dynamic resource allocation features. However, the app requirements and design presented in this study are intended to suit a more complex setting than, e.g. apps used for out-of-hospital cardiac arrests (one type of emergency, to types of tasks; go straight to the emergency site and start CPR or get the heart defibrillator). Therefore, the study can serve as inspiration for similar volunteer initiatives that begin to emerge and expand in other countries.
Also, when turning to spontaneous volunteers in large-scale crises that are often labeled as “digital volunteers,” it is possible to discern similar needs and requirements as those put forward in this study. Most often, they are seen as a resource that needs better collaboration and integration with professional response actors through dissemination of information and sharing of data. For instance, Purohit et al. (2014) and Webersik et al. (2015) point at the need for more pre-defined collaboration and coordination between response organizations and digital volunteers, where responsibilities and tasks are pre-defined. This is to avoid disorganization during the response phase. Other studies show how volunteers often organize themselves digitally using social media and then transfer their organization and tasks to the physical incident site (Starbird, 2013). Others argue that digitalization changes the dynamics of spontaneous volunteerism, when individual engagement becomes collective (Jurgens and Helsloot, 2018). In the case of digitalized co-production in this study, tasks and major responsibilities are pre-defined. However, ICT tools that enable improved coordination and collaboration with the rescue services and the PSAP, and communication functions that enable collective engagement, are required. Some of them, such as geofencing/positioning, are urgent for the volunteer initiatives to expand and survive long-term.
In relation, there are several studies that point at the need for ICT-support that is directed to and suited to the needs of the spontaneous volunteers (Purohit et al., 2014; Webersik et al., 2015). Also, professional response actors must improve their coordination of volunteers and integrate them with their own organizations, command and control functions and ICT systems (Abdulhamid et al., 2021; Majchrzak and Birnbaum, 2011). Batard et al. (2019) and Reuter et al. (2015) specifically argue that professional response organizations must be better at integrating their volunteers in their back-office systems, e.g. to track activities, distribute tasks and responsibilities and support risk awareness. In the Swedish context, Murphy (2021) has studied digital volunteerism and spontaneous volunteers, using the multiple forest fires in north Sweden in 2018 as an example, and claims that no coordination mechanisms or digital support for coordination of the volunteers exist. As to similar functionality, Gómez et al. (2013), in their review of mobile applications for citizen emergency management, show how many apps have functionality such as volunteers providing location information and sending useful information to the rescue centers. Detjen et al. (2015) argue for the coordination of trained volunteers by a professional control center with the objective of a more efficient distribution of human resources and technical equipment in the large-scale management context, including mechanisms for motivating long-term engagement. We conclude that what seems important to spontaneous volunteers in large-scale management also applies to digitalized co-production in smaller emergencies. Requirements concern improved coordination of dispatch, dynamic resource allocation and standardized functionality and joint API – i.e. better integration with the PSAP back-office system. A difference compared to large-scale crises may be the importance of geofencing/positioning. In the volunteer initiatives studied, the focus is on fast response and first aid, and, thus, geographical proximity is the most important variable. This also applies to the immediate response phase of a large crisis. However, many large-scale crises have long-time spans and vary in character over time. Tasks may range from evacuation to transportation, sheltering, distributing food, etc. In the recovery phase, geographical distance may not play a major part because you have sufficient time to go to the site. The geofencing positioning requirement would still be helpful though, e.g. to see where volunteers are, if they have left a hazardous area, etc. In the general ICT-enabled or digitalized co-production context, we can, in a similar vein as Lember et al. (2019), argue for a certain kind of technology optimism, where even basic ICT solutions are taken for granted but, after some use, deemed insufficient and severely hampering the volunteer initiatives and their integration in the emergency logistics chain.
User participation in the development of ICT support for volunteers
The current app for dispatch has, to our knowledge, not been developed together with the volunteers/end-users and the current version is lacking in certain central functionality. It is specifically reflected in that one of the themes – the need for volunteers to communicate and collaborate among themselves – has been disregarded. The terms “co-creation,” “co-design” and “co-production” have often been used interchangeably to describe the development of initiatives involving multiple stakeholders and citizens (Vargas et al., 2022; Brandsen et al., 2018). In the systems development context, studies have similarly argued that including user participation in development for functional ICT is a must, regardless of if we call it user-centered design, participatory design or user innovation (Holgersson and Karlsson, 2014). It may seem a bit strange that an app that has been in development for about seven years seems to have escaped user participation. One reason may be the bottom-up character of the volunteer initiatives. The volunteers have been dispersed through the country, fragmented and perform their engagement on their spare time. They are difficult to actively involve over time and physically and to engage with other stakeholders using traditional user participation methods and techniques (Pilemalm, 2018). The lack of user participation is also reflected in the Tan et al. (2017) systematic review of mobile apps for crisis informatics, where they conclude that user involvement has been sparse and that it is important that future research engage in user-centered studies to gain more insights from the citizens on using the apps. Here lies one of our study’s major contributions. The requirements presented are based on a baseline of many years of interaction, data collection from and active involvement of end-users and other stakeholders of relevance for the initiatives (e.g. Pilemalm, 2020; Pilemalm, 2021; Pilemalm, 2023), including the data collection from 2023. Also, the initial design proposal is based on established design principles/heuristics (Nielsen, 1994).
Onwards, the local initiatives are intended to spread nationwide and receive governmental authority support. The PSAP app is the solution that most of the rescue services, and thus the volunteers, will use. Therefore, ways to involve the end-users, e.g. through functionality, design proposal and prototype evaluation, are a continued must, should the dispatch solution contribute to effective volunteer first response to incident sites as part of emergency response logistics. This relates both to smaller emergencies, extraordinary events and large-scale crises.
Study transferability and limitations
The app requirements presented in the current study are most relevant to digitalized co-production or digital volunteerism, where volunteers engage with professional response actors over time. However, the functionality is grounded in solid user needs, and because previous studies on apps in the crisis management and spontaneous volunteers’ context show some overlaps, many of the requirements should apply to this setting too. As for the digitalized co-production type in the study, the setting is Sweden. However, we know that similar initiatives begin to emerge, e.g. in Norway, and the SMS-lifesavers exist throughout Scandinavia. Thus, we can expect that similar initiatives will emerge in other countries, and the results should have international relevance.
A limitation of the study is that the data has been collected from various stakeholders at different occasions, i.e. volunteers have not been mixed with the rescue services representatives. Also, the study focuses on functional requirements and does not include human–computer interaction requirements. However, the initial design proposal represents a subset of the identified requirements in a graphical interface, for illustrative purposes.
Conclusions and future work
In a world characterized by instability and increased natural and man-made threats and disasters, the integration of volunteers as part of emergency response work is becoming increasingly urgent. This relates to bystanders, spontaneous volunteers, or the digitalized co-production type in this study alike. If used adequately and effectively, they can provide immense support to response organizations at the incident site, regardless of its size. In the future, they will increasingly be seen as part of emergency response logistics. However, for this development to take place, the integration must, to a greater extent than currently, be pre-planned. This particularly applies to the dispatch process and the ICT support for dispatch. Emergency response logistics will be improved if volunteers are dispatched correctly in a coordinated manner and allocated tasks beforehand so that they can start the first response immediately when arriving at the site. This goes for small emergencies where volunteers of the digitalized co-production type are active, but also larger crises alike, where they currently are an unused asset.
This study set out to bridge an identified gap in digitalized or ICT-enabled co-production of emergency response where previous studies have focused the concept overall, while others study mobile apps for spontaneous volunteers or citizens, but of a different kind and in a different context than this study. The study contributes with a requirements specification and initial design proposal for ICT dispatch of volunteers as first responders, based on end-user needs and the perspectives of other relevant stakeholders. It identifies requirements related to geofencing/positioning, coordination, dynamic resource allocation and collaboration and communication that can be used for various applications aiming to optimize volunteer first response. Future work will include forming a design group of volunteer representatives and other stakeholders (e.g. the national authorities, the municipal rescue services and the PSAP) working specifically with evaluating requirements, design proposals and revised dispatch solutions. Here, the prototype and the use case can serve as a point of departure. This is part of the larger national initiative for expanding and improving volunteer digitalized co-production as an integrated part of emergency response logistics.
Executive summary
Volunteers play an increasingly important role in emergency response logistics. Usually, they are studied in relation to large-scale crises and spontaneous volunteerism. However, there are emerging initiatives when volunteers collaborate with professional response organizations, e.g. the rescue and ambulance services also in smaller emergencies. They receive basic training and equipment and are dispatched to predefined incidents, e.g. traffic accidents, small fires and out-of-hospital cardiac arrests. At the incident site, they start first response/aid while waiting for the professional response organizations to arrive. However, to make most use of the volunteers’ capabilities, they need to be dispatched to the emergency site in an effective manner and coordinated on-site. The purpose of this study was to present a requirements specification and initial design proposal and use case for ICT-enabled dispatch of volunteers as first responders, as part of emergency response logistics and under the theoretical lens of digitalized co-production. The major themes identified were geofencing, dispatch coordination, dynamic resource allocation and communication and collaboration. First priority requirements include geofencing alert and positioning, a joint API, receipt of alert, receipt of arrival at incident site, withdrawal of resources, chat functionality and the ability to alert in descending order within the geofenced areas to avoid alarm fatigue. As to coordination and dynamic resource allocation, e.g. built-in alert restrictions, ability to pre-select profiles and to dispatch based on competence/training, capacity and equipment would enable a more optimized response. The dynamic resource allocation functionality would also allow for a dual use of the volunteers in smaller emergencies and large-scale crises, where they currently are an unused asset. Practitioners may use the requirements specification when developing their own volunteer initiatives and dispatch applications. The results should be internationally transferable because first response tasks (e.g. doing heart-and-lung rescue, stopping bleedings, extinguishing small fires and directing traffic) are similar in other countries.
This study was financed by the Swedish Civil Contingencies Agency (MSB) and the Swedish Fire Protection Association.
