= !BluePrint: Sahana First Response (SAFIRE) = [[TOC]] * [wiki:UserGuidelines/SAFIRE User Guidelines] - getting started and operating SAFIRE == Introduction == [[Image(http://eden.sahanafoundation.org/raw-attachment/wiki/Deployments/SAMBRO/broker.JPG, align="left")]] 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 === [wiki:BluePrint/SAFIRE#UserStories The problem that SAIFRE is solving is providing a simple crisis and emergency response management system.] [[br]][[br]] 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 [http://preparedness.intermedix.com/solutions/webeoc WebEOC] are hard for small developing nations to finance. [http://lirneasia.net/2012/05/masas-iscram-2012/ Silo-ed Organizations and inter-agency rivalry] at various levels of a national emergency management system becomes a difficult challenge to integrate. Managing [https://www.humanitarianresponse.info/en/operations/nepal/article/whos-doing-what-where-and-when-4w 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 === [wiki:BluePrint/SAFIRE#Functional FUNCTIONAL SECTION DISCUSSES THE COMPONENTS IN DETAIL] [[br]][[br]] 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. [http://eden.sahanafoundation.org/wiki/BluePrint/Assets Asset], [http://eden.sahanafoundation.org/wiki/BluePrint/Vehicle Fleet], and [http://eden.sahanafoundation.org/wiki/BluePrintPersonRegistry Staff]/[http://eden.sahanafoundation.org/wiki/BluePrintVolunteer Volunteer] management are essential for the SAFIRE database to realize the current state of the resources 1. [http://eden.sahanafoundation.org/wiki/BluePrintIncidentReporting 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 1. [http://eden.sahanafoundation.org/wiki/BluePrint/CrisisMap Crisis mapping] contributes to the common operating picture and categorical representation of the reports with situation visualization and decision management 1. Able to input and output reports in various formats (JSON, XML, PDF, XSL, SQL, GIS-Raster/Vector) and emergency data exchange standards ([https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency EDXL], [http://hxlstandard.org/ HXL]) 1. Use a combination of voice and data input and output streams for collecting and disseminating situational reports and resource messaging 1. Adaptable to handheld and desktop devices for collecting, processing, and sharing information 1. Generic but flexible to customize to any user's liking; i.e. disaster management, police, civil society, private companies, and NGOs [[br]] == 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): a. Director / Commander a. Operations / Dispatch a. Planning & Logistics a. Communication a. Fiance & Administration 2. First-response teams (Operational): a. Public Safety (e.g police, fire, coastguard, military) a. Emergency Medicine (e.g. ambulance, quarantine) a. Community Emergency Response Teams (CERTs) a. Utilities & Infrastructure (e.g power company, road maintenance, telecom) 3. Non-operational stakeholders a. Presidents Office, Ministries, and other Government departments a. Civil Society, Local NGOs, International Organizations (e.g. Sarvodaya, Red Cross, UN agencies) a. 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 || === Roles and Capabilities === These are default user roles and respective permissions; including the accessible menus ==== Permissions ==== C = Create, R = Read, U = Update, D = Delete ||=Roles =||=Responsibilities =||=Permissions =|| ||Call_Logger ||* search, initiate, and update incident reports [[br]] * Manage incident details [[br]] * Manage action plans (i.e. assign personnel and equipment to tasks) ||CRUD - incident reports and incidents || == User Stories == [wiki:BluePrint/SAFIRE/UseCases CLICK to read complete set of user stories]. The examples discussed below are summaries of those same user stories. 1. [wiki:BluePrint/SAFIRE/UseCases#MissingPersonsSearchandRescue Missing Persons (SAR)] - Two hikers are reported missing in the national park; managing the SAR incident. 1. [wiki:BluePrint/SAFIRE/UseCases#Landslide Landslide (restoration)] - Heavy rains has caused a landslide damaging and covering a popular B-52 county road in Badarawella hill-country 1. [wiki:BluePrint/SAFIRE/UseCases#ExplosionMajorFire Explosion (casualties)] - large hazardous material factory explosion that has spread fire is reported to the Call Center 1. [wiki:BluePrint/SAFIRE/UseCases#FlashFloods Flash floods (evacuation)] - a village with 12 families and 2 disabled persons need immediate rescue from the rushing food waters 1. [wiki:BluePrint/SAFIRE/UseCases#Utilities 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 == === 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. * [wiki:BluePrint/CrisisMap 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 [http://eden.sahanafoundation.org/wiki/Domain/EmergencyManagement/IncidentManagementSystems/IncidentCommandSystem%28UnitedStates%29 ICS compliance]. [[BR]](A deployment-specific template can still exist on top of that if-required) * [wiki:Domain/EmergencyManagement/IncidentManagementSystems/IncidentCommandSystem(UnitedStates) 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 [http://www.gwu.edu/~icdrm/publications/PDF/GLOSSARY%20-%20Emergency%20Management%20ICDRM%2030%20JUNE%2010.pdf comply with ICS terminology]. === Use Case Diagram === The use cases focus is on multiple hazards. [[Image(http://eden.sahanafoundation.org/raw-attachment/wiki/BluePrint/SAFIRE/use_case_ICS.4.png, width=1050)]] [[br]][[br]] ||=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) [[Image(http://eden.sahanafoundation.org/raw-attachment/wiki/BluePrint/SAFIRE/ER_Diagram_v5.png)]] === Workflows === [[Image(http://eden.sahanafoundation.org/raw-attachment/wiki/BluePrint/SAFIRE/process_flow_incident_management.3.png, width=650)]] [[br]][[br]] === Site Map === === Wireframes (GUI Design) === The [wiki:BluePrint/SAFIRE/GUIDesign GUI DESIGN] for SAFIRE is discussed in detail in a [wiki:BluePrint/SAFIRE/GUIDesign 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) a. Field-Observation Report (e.g. Accident, Damage, Rescue) a. Casualty-Illness Report (e.g. Summary of sick and injured, hospital triage contributions, diseased victim information) 1. Plan response resources a. select skilled personnel a. select assets (equipment, tools) a. select fleet (vehicles) 1. Send request for resources a. create message a. send message to: targeted location or registered organizations a. monitor replies 1. Dispatch resources a. select resources from the available pool a. confirm to activate resource deployment 1. Monitor and update Crisis Map a. View Common Operating Picture a. Select and view full report a. Filter and drill down in to reports a. Update response resources a. Update situation other information === Technologies === == Current Implementation == <*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 == [[br]] === Seychelles Disaster Risk Management === [[Image(http://eden.sahanafoundation.org/raw-attachment/wiki/BluePrint/SAFIRE/seychells.png, width=300px, align='right')]] 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 [https://www.info.veoci.com/emergency-management 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 1. Trained staff (approx. 13 staff) (means of verification: questionnaires for trainees to be annexed in main report) 1. Training Report '''Questions''' 1. currently unclear on the scope of the customizations required. a. Minimally we can provide a custom template which will include i. a customized homepage with your Logo i. 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. 1. Do you have specific requirements? a. It can, of course, go a lot deeper then 1. Which languages does the system need to be available in? '''English Only''' a. default is English, a. we have some of the system translated into French, but this may need some work to complete a. Do you want to work on a translation into Seychellois? 1. Where do you plan on hosting the software? (Ideally this should be up and running before the training of-course.) a. We normally use Amazon Web Services, a. are you planning to host in house? a. Will it be delivered via a URL like https://sahana.drdm.gov.sc or https://drmis.drdm.gov.sc ? a. 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 i. if this is SaaS then I just need you to handle the DNS & SSL certificate. 1. Do you have data available that you wish to import into the system? a. I see some data on HDX: https://data.humdata.org/group/syc a, the airports, for instance, could be worth importing a. 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. a. 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. 1. 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 * [https://sites.google.com/sahanafoundation.org/wacopdesign/home WACOP Wireframes] == Future Extensions == == Outstanding Questions == == 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 || || Seychelles DRDM NEOC || Fran & Nuwan || Visit, worked with to customise Sahana & deployed to handle all 112 calls for Police, Fire and Ambulance || || 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. [https://logisys911.com/cadproducts/ LogySIS CAD] 1. [http://preparedness.intermedix.com/solutions/webeoc WebEOC] 1. [https://play.google.com/store/apps/details?id=com.geoedge.CFRData&hl=en Sri Lanka Disaster Incident Reporting System] === Incident Command and Control === 1. [http://eden.sahanafoundation.org/wiki/Domain/EmergencyManagement/IncidentManagementSystems/IncidentCommandSystem%28UnitedStates%29 Incident Command system] curriculum offered by FEMA 1. [# NIEMS] - National Integated Emergency Management System 1. [https://triecker.wordpress.com/2015/06/02/incident-command-system-training-sucks/ Why ICS training sucks] === SITREP Feeds === 1. [http://humanityroad.org/ Humanity Road] and their after action [http://humanityroad.org/nepal-eq-aar/ Nepal Earthquake Report] === Hardware === 1. [http://www.hamwan.org/t/Wiki+Home+Page 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 1. Common Operating Picture with [wiki:BluePrint/CrisisMap Crisis Mapping] (who needs and doing what, when, and where) 1. Approve or Reject asset management, incident reports, situational-reporting, and resource messaging 1. Desktop and Mobile applications to integrate and to server as a publisher and a subscriber 1. Support multiple language message delivery options: REST API, EDXL, RSS/Atom, SMS, Email, FTP 1. Incident specific SOP check list ==== Missing features: ==== '''Prototype''' 1. manage [wiki:BluePrint/Event 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) 1. Locations selectors using geocodes or other categorical datasets, other than administrative boundaries. 1. input and output [http://hxlstandard.org/standard/1_0final/dictionary/#crises HXL #Event], [https://www.oasis-open.org/news/announcements/emergency-data-exchange-language-situation-reporting-edxl-sitrep-v1-0-committee-s SITREP] and [http://docs.oasis-open.org/emergency/edxl-rm/v1.0/errata/EDXL-RM-v1.0-OS-errata-os.html RM] feeds '''[2]''' to serve as an aggregator and a publisher-subscriber 1. Using SMS and other data casting channels to share incident report information with targeted first response teams (mainly Incident commander) 1. digitally sign the messages 1. [http://eden.sahanafoundation.org/wiki/BluePrint/Pictographs Pictographs for reporting incidents] (field and casualty-illness reports) 1. ​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. 1. 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 [http://eden.sahanafoundation.org/wiki/BluePrint/SAFIRE/UseCases#SearchandRescue SAR example], the incident search area needs to be marked. 1. 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. 1. ​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? 1. 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. 1. Reverse geocoding, when the location is set on the map the process fills in the Lx values.