Development of a Risk-Based Decision Support Tool to Assist Fire Departments in Managing Unwanted Alarms SupDet 2013 Conference

Transcription

1 Development of a Risk-Based Decision Support Tool to Assist Fire Departments in Managing Unwanted Alarms SupDet 2013 Conference John R. Hall, Jr. Fire Analysis & Research Division National Fire Protection Association August 2012

2 Objective of Presentation Present background of 2012 project Describe project tasks and results Spend most of the time describing the tool

3 Background of project Some fire departments implemented policies to delay response to commercial alarms during verification efforts Fire service had submitted several proposals for changes to NFPA standards; the proposals were not successful IAFC declared this a major challenge for fire service NFPA and IAFC co-hosted a summit in February 2011

4 Background of project As background to the summit, NFPA provided some national statistics In 1980, fires outnumbered false alarms by 3-to-1 In 2010, false alarms outnumbered fires by 3-to-2

5 Background of project Coming out of the summit, NFPA committed to developing a guide to ways to reduce unwanted alarms. This was published in July 2012 NFPA also committed to a year-long project to develop a tool that fire departments could use to estimate effects on costs and losses of various strategies they might use to deal with an unwanted alarm problem.

6 Background of project In particular, departments wanted a tool to help them decide whether the net effect of a strategy of verification with delayed response until verification attempt is complete would be a net benefit And departments wanted to know how much their unwanted alarm problem might be reduced by certification or like programs

7 Project Tasks Task 1: Project Advisory Panel Task 2: Literature Review Task 3: Protocol and Form for Collection of Local Data Needed by the Model and the Tool Task 4: Identify Candidate Alternative Strategies (the strategies that the tool would help evaluate) Task 5: Develop Decision-Support Tool (create the model, identify needed data, provide default data)

8 What We Learned Early On The problem was much, much worse than we had imagined. Many calls from commercial alarms that proved not to be fires were recorded not under false alarms but under good intent calls That meant far more non-fire calls from commercial alarm systems were available for cost savings through verification

9 What We Learned Early On The problem was much, much worse than we had imagined. We needed to focus not just on fires in non-dwelling properties (where commercial alarms might be used) but on fires reported by commercial alarms and not reported as quickly by any other means That meant far fewer fires whose losses were in play to offset the cost savings

10 What We Learned Early On Data from three independent sources indicated that non-fire situations outnumbered fires by 90-to-1 to 250-to-1 That s before you narrow down the fires to working fires Or take account of the working fires that are reported nearly simultaneously by commercial alarm system and building occupants

11 What We Learned Early On Early on, we thought the problem could be brought under control by a good program to check alarms and improve their performance Our initial estimate was that a really good program (e.g., certification) might reduce non-fire calls by 50-75%. Even so, the non-fire to fire ratio would still be at least 22-to-1.

12 As the Project Progressed But members of our Technical Advisory Panel most familiar with certification programs said we were predicting much better certification results than they d seen. They suggested more like a reduction of one-third. That would mean the non-fire to fire ratio would still be at least 60-to-1. No one would call that a problem under control.

13 As the Project Progressed While we were still absorbing the implications of all this the Advisory Panel pointed out that the call volume was already creating delays in responding to some calls. When two calls come in at the same time, one of them is probably going to get a response from a station farther away, resulting in that delay Verification might lead to a reduction in calls needing a response so fewer simultaneous calls and fewer calls getting a delayed response

14 Hopes for the Project Early and Late I was expecting the tool would slow down the rush to delay while verifying by showing that the added losses at fires were greater than the cost savings For that to happen, a community will probably need to have a much smaller unwanted-alarm problem than we ve seen or access to a much more effective certification program Either way, the tool should do what it was supposed to do help a local fire department decide what approach made the most sense for their community

15 Why is the ratio of non-fire to fire calls so high? Hazardous conditions that aren t fires? Behavioral errors rather than equipment problems? Could a really low failure rate still mean 100x as many non-fires as fires, which are a very rare event? Other reasons? We don t know. Stay tuned for possible future research

16 An Overview of the Model and the Tool The model is set up using a tree structure. There are branching nodes wherever there are multiple possibilities. For example, fire or non-fire working fire or does not need extinguishment small or large fire At the end of each branch, there are various estimated values for average loss or cost per incident, for that type of incident

17 An Overview of the Model and the Tool You set up the model using a baseline several years of calls for emergency response (preferably the user s own calls) mix of incident types, e.g., fire and non-fire and outcomes produced by the response strategies being used during that baseline period The model assumes you are not already using delay during verification. The model is set up to run separately for six different property use groups.

18 An Overview of the Model and the Tool The tool walks you through the local data you need, tells you how to access default data to use if you don t have local data (and the model assumes that you won t have enough local data for most of the parameters in the model), and calculates results for several different response strategies

19 Overview of Model Parameters and Needed Data What percent of calls from commercial alarm systems prove to be non-fires? Most important parameter in the model If local user can only develop data for one parameter, it should be this one CAD data is not coded to generate this value automatically. Probably will need some custom coding and data enhancement. Need at least 1,000 calls in database to work with

20 Overview of Model Parameters and Needed Data What percent of fires reported by commercial alarm systems prove to need extinguishment? Local data is solicited but not expected Probably need at least 50 fires in database to work with Or 50 fires for each property use group you will analyze

21 Is it a fire? If yes, does it need extinguishment? Fire needing extinguishment Fire Call Reported to Fire Department Property Use Group i Fire not needing extinguishment Not a fire Not a fire

22 Overview of Model Parameters and Needed Data Of the fires needing extinguishment, what percentage reach various final fire sizes? This refers to the baseline fires and how they turned out. The model is going to run what-if analysis of how the fires would have turned out if different verification and response strategies had been used. Local data is not solicited

23 Fires needing extinguishment by size of fire Flame confined to object of origin Flame confined to room of origin Fire needing extinguishment Flame confined to floor of origin Flame extends beyond floor of origin

24 Overview of Model Parameters and Needed Data For fires of defined size, what are losses per fire? Local data is not solicited Civilian deaths and injuries Direct and indirect property damage Firefighter deaths and injuries on scene Firefighter deaths and injuries during response or return (these losses apply to all responses, not just fires)

25 Estimating losses per call, by call characteristics Civilian deaths based on average deaths per fire for structure fires in property use Civilian injuries based on average injuries per fire for structure fires in property use Flame confined to (or beyond) XXX (Estimated loss per fire) Direct property damage based on average damage per fire for structure fires in property use Firefighter deaths based on average on scene deaths per structure fire in property use Firefighter injuries based on average on scene injuries per structure fire in property use

26 Estimating losses per call, by call characteristics Indirect property damage based on % multiplier from "Total Cost" report for property use group Flame confined to (or beyond) XXX (Estimated loss per fire) (Continued) Firefighter deaths based on average response/return deaths per response (Loss applies to any response, not just fires needing extinguishment) Firefighter injuries based on average on average response/return injuries per response (Loss applies to any response, not just fires needing extinguishment)

27 Overview of Model Parameters and Needed Data For fires of defined size, what are costs per fire? Other parameter(s) where local data is most needed Apparatus costs during response/return, cost per mile Apparatus costs running on site, cost per hour Personnel costs not included Costs for cleaning, maintenance, replacement of equipment (default data is a 50% multiplier) Intangible costs, such as effects on recruitment, retention, morale, public perceptions and goodwill (not included)

28 Estimating costs per call, by call characteristics Vehicle or apparatus costs during response and return (based on cost per mile and average round trip distance) Vehicle or apparatus costs while on site (based on cost per hour and average time of operation) Any call receiving a response (Cost per response) Personnel costs are not variable with volume of calls and so are NOT included Costs of cleaning, maintenance, replacement of equipment (added to Excel version of model as 50% add-on to apparatus costs) Also not included in calculation but possibly in discussion effects on morale, retention, recruitment, public goodwill, traffic and accidents

29 Overview of Model Parameters and Needed Data For fires of defined size, identify time penalties and time credits related to response strategy Local data is not solicited If reduced response sent after failed attempt at verification, a time penalty is imposed for fires too large for reduced response but not too large for standard response If baseline shows some delays because some simultaneous calls must be handled by units that are farther away, then verification effect on call volume will incur a time credit by reducing simultaneous calls

30 Time penalties and time credits calculated by the model Time penalty for delay during verification Time penalty for delay IF no response after failed attempt at verification Flame confined to (or beyond) XXX Time penalty for certain size fires IF reduced response after failed attempt at verification Time credit if verification reduces simultaneous calls and need to handle some calls with units from farther away

31 Overview of Model Parameters and Needed Data For fires of defined size, identify time penalties related to response strategy and characteristics of property Local data is not solicited If property is densely populated, will assume selfgenerated phone calls will provide verification with no delay, hence, no time penalty for verification If no one is on site, time penalty for verification AND if strategy is no response after failed verification, additional time penalty until fire is large enough to be reported by passersby

32 Overview of Model Parameters and Needed Data Time penalties related to response strategy and characteristics of property (continued) If someone is on site but property too large to expect accurate verification, time penalty for verification AND if strategy is no response after failed verification, time penalty until fire is large enough for passerby reporting If someone is on site and property not too large, time penalty for verification but no time penalty after failed verification

33 Characteristics related to whether verification will fail Is the property densely populated, indicating phone call reports will come in on fire with no delay after alarm? No delay due to verification Flame confined to (or beyond) XXX Is there no one on site? Delay due to verification and additional delay IFstrategy is for no response after failed verification Are there some people on site but too much space to expect accurate verification? Delay due to verification and additional delay IFstrategy is no response after failed verification Are there enough people on site to check the building to provide accurate verification? Delay due to verification but no delay due to failed verification

34 Default data Default data is available for all parameters Default data based on Data supplied by members of Advisory Panel, Data identified during literature review and other sources in the literature, and Data from NFPA analysis of NFIRS.

35 End of project and next steps Final reports were completed in December 2012 and circulated to Advisory Panel in January 2013 Excel spreadsheet version of the tool was completed at the beginning of February 2013 Presentations on model and tool at SupDet 2013 and at NFPA meeting in June 2013 in Chicago Hoping to arrange for some fire departments to bring in their own data for a live demonstration and test of the tool at the Chicago meeting

36 Possible Phase II activities Making the tool better: Possibly ask some departments to beta-test the tool and suggest improvements, making it easier to use Making the model better: Possibly find some additional data sources to broaden the base for estimation of various model parameters Understanding the problem better: Possibly gather data from several departments on every commercial alarm system non-fire call: Why did it activate? What can be done about it?