BluePrint: Sahana First Response (SAFIRE)

• User Guidelines - getting started and operating SAFIRE

Introduction

Sahana First Response (SAFIRE) is designed to support a Simple All-Hazard Emergency Operation Center (EOC); especially during the 72 hour golden window. The An EOC could be as simple as a single terminal with a single user (e.g. a call center) recording incident reports and dispatching an emergency service. The emergency service might be the maintenance engineering crew of a telecommunications service provider deployed to fix a backup power generator.

A, larger, Police EOC might utilize SAFIRE for managing field-observation (burglary, accident, dispute) and casualty-illness reports (accident, murder). The Police response and resources allocated to an incident varies upon the scenario. The other extreme is managing a crisis such as an earthquake with many casualties, damages, and losses. All these, whether big or small, require managing a series of response actions (or inactions) and sharing information with a Multi-Agency Coordination System (MACS).

Problem

The problem that SAIFRE is solving is providing a simple crisis and emergency response management system.

Under a well-developed emergency management system, the Emergency Management Services of a Country should be aware of and should map every significant emergency incident and its response. Sharing and managing such information across multiple agencies with can be complicated. Solutions such as ​WebEOC are hard for small developing nations to finance. ​Silo-ed Organizations and inter-agency rivalry at various levels of a national emergency management system becomes a difficult challenge to integrate. Managing ​who is doing what where and when, typically termed as 4W in the humanitarian space, becomes chaotic and costly to manually manage. There is a need for accountability and coherence in the public emergency and first response services.

Solution

FUNCTIONAL SECTION DISCUSSES THE COMPONENTS IN DETAIL

SAFIRE is a Sahana Eden template combining various modules to support the work flows of a simple EOC from incident report inception through a cycle until the situation is contained. Important SAFIRE features:

1. Asset, Fleet, and Staff/Volunteer management are essential for the SAFIRE database to realize the current state of the resources
2. Incident reporting, whether it be the public or a first-responder using mobile app, social media, email, SMS, or connecting to a call center it would be captured as information pertaining to an event
3. Crisis mapping contributes to the common operating picture and categorical representation of the reports with situation visualization and decision management
4. Able to input and output reports in various formats (JSON, XML, PDF, XSL, SQL, GIS-Raster/Vector) and emergency data exchange standards (​EDXL, ​HXL)
5. Use a combination of voice and data input and output streams for collecting and disseminating situational reports and resource messaging
6. Adaptable to handheld and desktop devices for collecting, processing, and sharing information
7. Generic but flexible to customize to any user's liking; i.e. disaster management, police, civil society, private companies, and NGOs

Stakeholders

There are 3 categories of stakeholders who will use the system for different information needs; namely those who coordinate from a central unit, field operatives responding on site, and other stakeholders who indirectly respond to the incident. The users described below are from a humanitarian perspective. However, a utilities company may chose to use the system where they may only have EOC staff and field operatives (e.g. engineering and maintenance teams).

Who are the users?

1. EOC Staff / Units (Operational):
   1. Director / Commander
   2. Operations / Dispatch
   3. Planning & Logistics
   4. Communication
   5. Fiance & Administration
2. First-response teams (Operational):
   1. Public Safety (e.g police, fire, coastguard, military)
   2. Emergency Medicine (e.g. ambulance, quarantine)
   3. Community Emergency Response Teams (CERTs)
   4. Utilities & Infrastructure (e.g power company, road maintenance, telecom)
3. Non-operational stakeholders
   1. Presidents Office, Ministries, and other Government departments
   2. Civil Society, Local NGOs, International Organizations (e.g. Sarvodaya, Red Cross, UN agencies)
   3. Public

How the users are affected?

Element	Description
Coordination	avoid duplication and brings efficiency with a shared information platform opposed to creating own siloed information stacks
Consistency	information is believable because it is collected, processed, and shared from a trusted source
Channels	stakeholders can integrate multiple information channels (e.g. call center, mobile app, social media feeds)
Completeness	there is no ambiguity because the system forces integrity and requires that all necessary information is made available
Control	access control and security, along with restriction to private information
Culpability	or accountability ensures that no one is forgotten and all information related to the activities can be audited

User Stories

CLICK to read complete set of user stories. The examples discussed below are summaries of those same user stories.

1. Missing Persons (SAR) - Two hikers are reported missing in the national park; managing the SAR incident.
2. Landslide (restoration) - Heavy rains has caused a landslide damaging and covering a popular B-52 county road in Badarawella hill-country
3. Explosion (casualties) - large hazardous material factory explosion that has spread fire is reported to the Call Center
4. Flash floods (evacuation) - a village with 12 families and 2 disabled persons need immediate rescue from the rushing food waters
5. Utilities (restoration) - a forest fire destroys a far remote Base Transmission Station (BTS) disconnecting fire fighters from data communications

Tropical Cylcone

The First-Responders are dispatched to sweep the area to find any victims as well as assess the damage. The EOC collects the incident reports and begins compiling situation-information reports to plan the required response resource to restore immediate utilities and services. EOC coordinates the critical infrastructure restoration.

Train derailment

A high speed train derailed in a mountainous area. An observer calls in reporting mass number of casualties and several survivors stuck in unsafe carriages. The EOC dispatches local authorities to the scene to assess the situation and provide immediate assistance. After receiving field-observation reports the EOC dispatches other relevant First-Responders to stabilize the train and to rescue the survivors.

Requirements

<Group requirements in subsections, e.g. _{etc.> <​http://en.wikipedia.org/wiki/Requirements_analysis requirements> <Identify different types of requirements:>}

Functional

Features in these kind of terms - NOTE WE HAVE ALL of these features already - they 'just' need bringing together into a coherent template which has been tested and documented.

• Crisis Mapping for receiving and visualizing the situation (incidents reported and incident being or are contained)
• Staff/Volunteer Management - Credentials of personnel can be tracked (Skills, Training & Experience) to:
  • remind people when they need to attend refresher training and see where there are gaps in cover that need addressing
  • categorization allows for automatic matching to a resource requirement
  • Check-in to confirm that the staff/volunteer is at their duty station according to their duty roster
  • Create new teams and resource personnel (e.g. when volunteer firefighter, outside of their jurisdiction, come to support a major wildfire)
• Asset Management - Assets can be tracked through purchase, deployment, loans and repairs.
  • Known and available equipment for immediate dispatch are registered as resources
  • Other external suppliers or private contractors, for various services, are registered and requested for deployment as and when needed
  • Send out a request to procure or use resources when they are unavailable (e.g. requesting for boats to assist with flood evacuation)
• Fleet Management - Vehicles can have their:
  • fuel usage monitored and
  • use GPS Tracking to report their current positions
• Incident Reporting - Incidents can be:
  • logged by call centre staff
  • reported from the field by both trusted agents
  • reported by the general public (including through Twitter/SMS/Email)
• Dispatch - Teams of people & their equipment (vehicles/radios/etc) can be assigned to an incident according to their Skills & Availability (Roster)
• Incident Management
  • SOP checklists can be worked through based on scenario templates
  • The Incident Manager can file status updates & request additional resources to be dispatched
  • Crisis map is updated with eachh response action to provide a near real-time common operating picture
• Share Information amongst heterogeneous systems
  • Action requests can be shared with all authorized
  • stakeholders, whether or not they use Sahana (as long as they support open standards such as EDXL)
  • or we would develop a custom adapter

Non-functional

​http://en.wikipedia.org/wiki/Non-functional_requirements

Interoperability

Standards

Incident Command System (ICS)

We aim to build an ICS template which would extend the core SAFIRE template to provide ICS compliance.
(A deployment-specific template can still exist on top of that if-required)

• Incident Command System

We could similarly also build AIIMS (AU) and/or CIMS (NZ) templates

HXL

EDXL-SITREP

SAFIRE will adopt the Situational-Reporting (SITREP) EDXL data standard. Provides a device independent platform for submit field-observation and casualty-illness reports. Those reports are transformed into situation-information and required-response reports. Finally a Management Summary Report to complete the EDXL SITREP family of reports.

EDXL-RM

Resource-Messaging (RM) coordinates the dispatch of response resources to manage the incident. First the system requests for resources by multi casting a EDXL RM, through various messaging channels, to the resource supplier agents, in a geographic area. The status and decision of the resource supplier agents are received as a RM reply. The RM data provides insights to decision makers on their resource dispatch strategy (prioritizing and scheduling).

System Constraints

Design

• Whenever possible, we ​comply with ICS terminology.

Use Case Diagram

The use cases focus is on multiple hazards.

SAFIRE SIMPLE EOC	collection of Sahana software components that provide functionality for incident reporting, dispatch, resource management, resource messaging, situational-reporting, and providing a common operating picture
Reporter	a source for receiving incident reports. They may arrive over public or closed channels. Potential channels would use Social Media, Emergency Hotline 112, HF/VHF radio
DISPATCH CENTER	facility and staff that handles emergency calls from the public and communication with emergency management/response personnel. The center can serve as a primary coordination and support element of the large MACS or a small single person operation center that manages utility repairs.
Operator	a trained and authorized user with a role of processing the incident reports coming through the various channels. One or more Incident reports may result in activating an emergency situation, which activates generating a situation information document.
Manager	essentially an emergency manager that analyses the situation information to realize the situational and then make a decision to activate or inactivate the response plans. The crisis map is updated with the new activated situations. Manager decides on the required resources and sends out a request. The manager dispatches the resources
Unit Leader	is an individual in charge of a collection of human resources, assets, and/or fleets. When the Unit Leader is requested to commit resources to a situation, they will analyze the situation and assess the capacity constraints to reply with a yes or no.
COMMON OPERATING PICTURE	provides an overview of a situation by all relevant Stakeholders that provides incident information enabling the Incident Commander, EOC Operations and any supporting entities to make effective, consistent, and timely decisions.
Incident Commander	the individual responsible for managing the incident, typically, on site at the scene. Incident Commander may order the release of more resource and would continue to update the situation information.
Operations	are individuals, typical at an EOC (static or mobile), providing tactical support the response units (or teams). They rely on the Common Operating Picture for their analysis and support. Visual analytic with features to filter and drill-down into information important.
RESOURCE MANAGEMENT	a system for identifying available resources at all jurisdictional levels to enable timely, efficient, and unimpeded access to resources needed to prepare for, respond to, or recover from an incident.
Planning & Logistics	are individuals, typically EOC staff members, that assist in managing the human resources, assets, and the fleet. The resource mapping allows for applying location specific filtering or resources.

Data Model

Very abstract and basic ER diagram to illustrate the entity relationship between Events, Incidents, and Operation Plans (i.e. tasks and resources)

Workflows

Site Map

<for User Interface solutions>

Wireframes (GUI Design)

The GUI DESIGN for SAFIRE is discussed in detail in a separate page. In this section we give a brief overview of the expectations.

1. Incident reporting (Browser app, Andoid/iOS App. IVR, Social Media, SMS, Email)
   1. Field-Observation Report (e.g. Accident, Damage, Rescue)
   2. Casualty-Illness Report (e.g. Summary of sick and injured, hospital triage contributions, diseased victim information)
2. Plan response resources
   1. select skilled personnel
   2. select assets (equipment, tools)
   3. select fleet (vehicles)
3. Send request for resources
   1. create message
   2. send message to: targeted location or registered organizations
   3. monitor replies
4. Dispatch resources
   1. select resources from the available pool
   2. confirm to activate resource deployment
5. Monitor and update Crisis Map
   1. View Common Operating Picture
   2. Select and view full report
   3. Filter and drill down in to reports
   4. Update response resources
   5. Update situation other information

Technologies

Current Implementation

<Leave open for a list of existing implementation of this solution in Sahana Eden:> <*a brief description of the implementation (date/time, name, design options chosen)> <*a link to the code> <*list of deployments of the implementation> <*links to case studies> <*short analysis of achievements/problems>

Planned Implementation

<List of goals for your implementations which you (include your name/github repo/IRC handle) are currently working on>

Seychelles Disaster Risk Management

The Seychelles National Disaster Risk Management (NDRM) is keen on implementing Sahana Eden. Broadly-speaking they want an Operations Center, so SAFIRE. They have previously used ​VEOCI But very expensive; hence, was discontinued it despite liking it. NDRM but minimally need Call Logging and would also like some 'databases' - currently XLS sheets which she will send me copies of.

Deliverables

1. Customized D(R)MIS software (means of verification: manual of software amended to include customizations
2. Trained staff (approx. 13 staff) (means of verification: questionnaires for trainees to be annexed in main report)
3. Training Report

Questions

1. currently unclear on the scope of the customizations required.
   1. Minimally we can provide a custom template which will include
      1. a customized homepage with your Logo
      2. relevant modules enabled/disabled with (Currently I have no knowledge of even which modules you intend to use.) i, some reordering of menus & relabeling to match your context.
2. Do you have specific requirements?
   1. It can, of course, go a lot deeper then
3. Which languages does the system need to be available in? English Only
   1. default is English,
   2. we have some of the system translated into French, but this may need some work to complete
   3. Do you want to work on a translation into Seychellois?
4. Where do you plan on hosting the software? (Ideally this should be up and running before the training of-course.)
   1. We normally use Amazon Web Services,
   2. are you planning to host in house?
   3. Will it be delivered via a URL like ​https://sahana.drdm.gov.sc or ​https://drmis.drdm.gov.sc ?
   4. Due to the specialist nature of the tool, we generally recommend that you see it as a SaaS solution rather than managing the server yourselves, although it is certainly possible for you to manage it if you have the requisite skills
      1. if this is SaaS then I just need you to handle the DNS & SSL certificate.
5. Do you have data available that you wish to import into the system?
   1. I see some data on HDX: ​https://data.humdata.org/group/syc a, the airports, for instance, could be worth importing
   2. this doesn't include the Administrative Boundaries (generally the most important data to load). a, I can get the Districts from Wikipedia (​https://en.wikipedia.org/wiki/Seychelles#Administrative_divisions) but if you had the Polygons (e.g. Shapefile) that would be great.
   3. Seeing the data that you currently work from also helps give an idea of the workflows you want to make use of & the degree of customization required to get the system to fit.
6. Do you need assistance with the installation

Sitreps

At their simplest,

• these are a Rich-text field where a summary of the current situation can be manually entered.
• The sitrep can be associated with a place on the map
  • can include Incident marker, and
  • potentially markers for assigned Resources (if we will have such granular data)

Assessments

• A user-customisable set of Questions/Answers

Reports

• Structured data pulled in from the rest of the system, such as which

Personnel / Assets are assigned (& for how long? Do you need to recharge at all?)

• PDF export

State of Washington, US - Common Operating Picture

The Washington State Common Operating Picture (WA-COP) is being designed to manage and present the influx of state and county level emergency services data streams on in a single Eden-based application.

• An Eden-2-Eden synchromnization of incident data between SAFIRE AND WACOP was tested
• ​WACOP Wireframes

Future Extensions

<List of features which could be included, but are outside of the scope of this extension>

Outstanding Questions

<Questions about the features or design that haven't been (and need to be) answered>

References

Contexts drawn on

Context	Who	Details
Honduras National EOC	Fran	Visit
Los Angeles City EOC	Fran	Visit, worked with to customise Sahana: creating Give2LA site which integrated with WebEOC
Philippines Red Cross EOC	Fran	Visit
Portuguese Bombeiros Town Fire Station	Fran	Visit, worked with to customise Sahana: creating Fire module
Taiwan National EOC	Fran	Visit
Timor-Leste National EOC	Fran	Worked with to customise Sahana: creating DRM.tl site
Montana Forest Fires	Nuwan	Volunteer worker for the Missoula country USDA Forest service, 1999
Provincial EOC B.C, Canada	Nuwan	Visit, studied the communications systems and the EOC setup
Sri Lanka DMC EOC	Nuwan	Worked on mapping the work flows and elements necessary for proposing a Sahana solution
Timor Leste, Police HQ, EOC	Nuwan	Visit, evaluated the communication workflows (only use VHF voice)

Similar solutions

1. ​LogySIS CAD
2. ​WebEOC
3. ​Sri Lanka Disaster Incident Reporting System

Incident Command and Control

1. Incident Command system curriculum offered by FEMA
2. NIEMS - National Integated Emergency Management System
3. ​Why ICS training sucks

SITREP Feeds

1. ​Humanity Road and their after action ​Nepal Earthquake Report

Hardware

1. ​HamWAN for enabling WiFi and access to the Internet using 5.9GHz frequency band

Current Status

Fit-Gap analysis spreadsheet

Available features:

1. Manage and allocate skilled resources (SAR, Engineering, Defense), assets (radios, vehicles, equipment), and track their current location
2. Common Operating Picture with Crisis Mapping (who needs and doing what, when, and where)
3. Approve or Reject asset management, incident reports, situational-reporting, and resource messaging
4. Desktop and Mobile applications to integrate and to server as a publisher and a subscriber
5. Support multiple language message delivery options: REST API, EDXL, RSS/Atom, SMS, Email, FTP
6. Incident specific SOP check list

Missing features:

Prototype

1. manage event type specific work flows pre-populated message templates and messages (field-observation, casualty-illness, situation-information, response-resource, resource-messaging and management-summary reports)
2. Locations selectors using geocodes or other categorical datasets, other than administrative boundaries.
3. input and output ​HXL #Event, ​SITREP and ​RM feeds [2] to serve as an aggregator and a publisher-subscriber
4. Using SMS and other data casting channels to share incident report information with targeted first response teams (mainly Incident commander)
5. digitally sign the messages
6. Pictographs for reporting incidents (field and casualty-illness reports)
7. ​Assigning a Code to the incident (some cases event) - for example, the EOC Commanded would announce that all incidents related to a large event (e.g. earthquake) should use the incident code, which automatically populates the incident and event titles, along with other relevant informaiton, so they don't have to search for it.
8. CMS to document SOPs (e.g. with FAQs). Example, the caller might ask for the Incident Commander's contact details, the SOP / FAQ would have an answer for it.

High Priority

Low Priority

1. Find a location to automatically draw the polygon, possibly using geocodes or other method. As in the SAR example, the incident search area needs to be marked.
2. Performance evaluation, would require that the incident report status updates are time-stamped. Currently Eden maintains the time-stamp of the record was last updated. Perhaps we need to have a separate module that can be enabled / disabled to trigger a separate log to maintain the information.
3. ​The incident location (area) can be demarcated into sectors to assign teams to each sector as well as monitor the progress. The question is whether we give a map tool to define the sectors and mark them off one by one, or just use text without the map to note as a remark? Map would be useful only a mobile device?
4. Split Incidents to allow for assigning a second incident commander. Process should copy the associated incident reports to too and then later delete the irrelevant ones.
5. Reverse geocoding, when the location is set on the map the process fills in the Lx values.