Volunteer Firefighter International

Now is the Time to Finally Fix NFIRS With These 14 Steps

Let’s Make ‘Timely Information Sharing’ the Rallying Cry for the Post-COVID Fire Service

Dr. Matt Hinds-Aldrich

In the shadow of 9/11, the American fire service rallied around one theme among many — Interoperability. Our responses to the attacks that day highlighted the many ways incompatible LMR (land mobile radios) systems, inconsistent 10-codes, and reticent incident response coordination limited our ability to scale effectively during major emergencies. These limitations were not epiphanies that only reared their ugly head on that fateful day; they were issues that had existed in the background for many years. They were issues we had developed local solutions and ad hoc workarounds to function in our respective communities and with our respective neighbors. Fast forward to the current COVID-19 pandemic response we’re beginning to see a new theme emerge, a theme that is certainly not novel, but a theme we can and should rally around — timely information sharing across fire service agencies and across public service sectors.

Information sharing, and specifically data sharing, has been a much talked about topic for years. It is a topic that we collectively have dedicated considerable effort and energy at all levels of government to addressing already. While there is still much to be done and much that can be improved upon, we’ve made tremendous progress in the past two decades. Yet there is one vital cog in our fire service information sharing ecosystem that has not kept pace with changes in technological approaches and how the wider fire service is now using data — the National Fire Incident Reporting System (NFIRS).

Let me be clear from the outset, no matter how you pronounce it — N-FIRS, NifFIRS, NeeFRS or even N-FIReS — NFIRS is and should remain a vital part of our national fire service information sharing infrastructure. But it is a system and an approach designed for a different time and for a different purpose. That is one of the challenges, many of the things fire service personnel criticize are things that NFIRS was not originally intended to do. It is a bit like holding a screwdriver and complaining that it makes a terrible hammer — it was never intended to bang in nails, it might be able to do it with enough effort but it is certainly going to be frustrating and likely elicit some choice words. To make sure we’re starting from a common understanding, it is helpful to go back to the original charter of the National Fire Data Center that was to set up and manage the system that would become NFIRS:

Source: PUBLIC LAW 93–498-OCT. 29, 1974 https://www.govinfo.gov/content/pkg/STATUTE-88/pdf/STATUTE-88-Pg1535.pdf#page=14

The first three parts are clearly baked into the current NFIRS approach:

(1) information on the frequency, causes, spread, and extinguishment of fires;

(2) information on the number of injuries and deaths resulting from fires, including the maximum available information on the specific causes and nature of such injuries and deaths, and information on property losses;

(3) information on the occupational hazards faced by firefighters, including the causes of deaths and injuries arising, directly and indirectly, from firefighting activities;

The stated purpose of NFIRS is to understand the frequency, causes, spread, and extinguishment of fires at a national level. Local fire departments certainly share an interest in evaluating the causes of fires. A growing number of fire departments are using the data collected locally in the NFIRS format to assess their organization’s performance, measure the effectiveness of their activities, and evaluate their emergency operations. These are not questions NFIRS was designed to help us answer. But with each passing day there are more local fire departments asking these questions and asking them in more refined ways.

It is important to remember that fire data is more than NFIRS incidents reports. Fire departments use and collect a tremendous amount of other information and data besides NFIRS. This is a point I’ll come back to shortly, but it is important to understand how quickly the wider fire data ecosystem is growing. The veritable alphabet soup of different programs and systems in the US alone can be a bit overwhelming and bewildering at first. While this list (in alphabetical order) is certainly not exhaustive it begins to highlight how complex this fire data world is getting, and this only includes national data collection and sharing systems (some of which are federally managed and others are managed by non-profit organizations) not specific vendors:

· BATS (Bomb and Arson Tracking System)

· Fire Data Lab

· FireCARES (Fire Community Assessment Risk Evaluation Systems)

· IRWIN (Integrated Reporting of Wildland Fire Information)

· NEMSIS (National EMS Information System)

· NFDS (National Fire Data System)

· NFORS (National Fire Operations Reporting System)

· NFR (National Firefighter Registry)

· NMAS (National Mutual Aid System)

· ROSS (Resource Ordering and Status System)

· YFIRES (Youth Firesetter Information Repository & Evaluation System)

When you add in software vendors it only gets more and more complex. One of the most comprehensive illustrations of the fire data landscape was put together by Battalion Chief Zach Wells from Kern County, California for FIRESCOPE as part of their Emerging Information Technology group.

Source: Battalion Chief Zach Wells on behalf of FIRESCOPE

No wonder many fire service personnel get easily overwhelmed by all the systems and places they need to enter information. Moreover, frustrations with NFIRS and any of the dozens of systems they have to enter information into only serve to amplify one another. But it also speaks to some of the frustration and impatience waiting for changes to NFIRS — as it is likely not the only clunky legacy system they may be struggling to navigate.

As the COVID-19 pandemic has yet again highlighted the need for a dynamically-adaptable, rapidly-scalable and timely fire service information sharing ecosystem is more vital than ever. And again, I should reiterate, NFIRS can and should have a place within that ecosystem. But is it equally important to note that NFIRS has not been and should not be considered the only or exclusive source of information or “truth” in that ecosystem. As it is currently configured there are some significant limitations that threaten the long-term viability and relevance of NFIRS. So it is more incumbent than ever to use this opportunity to collectively call for and support the federal funding, the human resources, and the political support to finally and fundamentally fix NFIRS to make it the system we need for where the fire service community is going not where it has been.

Why Don’t They Just Fix NFIRS:

So, the obvious question is, why don’t they just fix NFIRS? There are likely hundreds of reasons why NFIRS is the way it is. While many of these are likely to elicit strong reactions and some may be dismissed as excuses or ‘cop outs’ these highlight some of the many complexities that are often glossed over with the simply statement, “let’s just fix NFIRS”: (Note: I should start by acknowledging that I do not necessarily share or hold each of these opinions or perspectives myself but am sharing some concerns that I have learned over many years.)

Money and Appropriations: I have not been able to find any publicly available evidence (and suspect I would never find it publicly documented) to support this challenge, but anecdotally I have been told for several years that when the US Fire Administration has been successful in securing funding for modest enhancements to the NFIRS system through the federal budget appropriations process these funds have been significantly reduced or “re-appropriated” to fund other higher priority or urgent concerns such as beefing up the cyber-security of vulnerable government databases and the like. And while I have heard people posit, ‘why don’t they just get an AFG (Assistance to Firefighters Grant) to fix NFIRS’, federal law prohibits federal agencies or programs from applying for or receiving grant funding from federal sources or third parties.

“It Ain’t Broke (enough)”: While this point is certainly likely to elicit visceral reactions, from the stand point of meeting the basic requirements of its’ scope and purpose, it could be argued that NFIRS meets the requirements set forth in the original charter. The system functionally operates, it can accept new data submissions and can process, store, and export data — so technically it isn’t broken per se. Now the yard stick(s) the rest of the fire service would certainly use to measure whether it truly meets the wider needs of the fire service would likely highlight many of the limitations and could strongly justify significant modifications — but in a world where the mantra, “if it ain’t broke don’t fix it”, reigns supreme, NFIRS isn’t “broke” enough to justify the significant financial costs necessary to replace it.

“There Isn’t Consensus on What Needs to Be Fixed and How to Fix It”: One of the challenges about how best to fix NFIRS goes back to the old saying about opinions and bellybuttons (navels), everyone’s got one. The growing chorus of voices about the imperative to fix NFIRS speaks as much to the growth of awareness and use of data within fire departments. The more refined fire departments have become in their use of data, the more vocal they have become about the limitations based upon that data. So in many ways it is a great sign that there is so much discussion, it means people are starting to use the data more regularly. But back to the question of a lack of consensus it does highlight the various needs of the various different user groups — this is a point I’ll come back to shortly. Moreover, it highlights that the system is trying to be effectively the jack-of-all-trades that struggles with competing priorities and competing expectations.

“It Takes a Long Time to Turn an Aircraft Carrier”: Sticking with the topic of the competing priorities and expectations even if there was widespread consensus on what to fix and how to fix it, it has been often noted that changing a complex system such as NFIRS with as many external parties submitting data, and all the different State Fire Marshals Offices it would impact, and the different vendors it might impact, and the various layers of government approval and review it would have to go through would take time and would likely take far longer than most people in the field would think necessary or reasonable.

“Government Databases Tend to Take Decades to Create or Fix, Just Look at NIBRS”: To further evidence the last point about the possible glacial pace of change on government databases one should consider the case of the National Incident Based Reporting System that has been in the works for several decades in law enforcement circles and is an attempt to basically catch up to what the fire service has had for half a century. To put it into context NIBRS was proposed and initiated in 1989 and as of 2018 only had 40% of all police departments in the US participating with all police departments expected to be participating by 2021 — COVID-19 notwithstanding!

All FEMA personnel have emergency and disaster duties: While it may only minimally impact NFIRS, all employees of the US Fire Administration and by extension the National Fire Data Center that manages NFIRS are FEMA employees and thus they all have additional duties and responsibilities during federally declared disasters and other statutory emergencies. So occasionally projects and updates end up taking longer than anticipated because the key personnel needed to oversee, implement, or approve the changes are tied up with their other emergency duties.

There are likely many other concerns or reasons that NFIRS “hasn’t been fixed” as many people might want that you have heard besides these; many other common concerns will be addressed in the rest of this article so as to avoid unnecessary repetition.

A Roadmap for “Fixing NFIRS”:

So, what could and should be done to fix NFIRS? In what follows I’ll articulate what I see as the most pressing concerns, any evidence to substantiate that they are legitimate concerns, how to possibly fix them, and what is already being done successfully to make some of these changes, even if only at a local level. This is a rather long list and perhaps even a bit verbose, but if were easy to fix NFIRS it likely would have happened long ago. It is also worth noting that for many of the folks who have been actively working with NFIRS at the local, state, and national level for years, many of these observations or recommendations will be well-known or seem obvious — my point in sharing them, and frankly my purpose for writing this article, is to highlight that many of the problems and most of the possible solutions are well-established and rely upon established technology but have many dependencies and complexities that must be thoughtfully approached.

1 — Move to a Federated or Semantic Architecture:

The first and perhaps most fundamental change that can and should happen is a philosophical shift that moves NFIRS, conceptually and technically, from a standard enterprise architecture to a more federated or semantic architecture. Enterprise data systems work very well in large enterprises, like a large business, where the entire system is controlled by the same organization. So for instance if a major company decides that all of their sales teams across the country are going to move from a patchwork of legacy systems to a unified Salesforce® system then once they build the system, configure it to meet their specific needs, and train their employees, they then migrate all of their users to the enterprise system, whether they like it or not. The key feature is that one entity or organization controls the decision making and dictates how and when the change is going to happen. So if the Midwest sales team isn’t happy about the new system and wants to retain their old system or the Southwest sales team doesn’t think the new system goes far enough it doesn’t really matter, the company has purchased the new software for the entire enterprise and the various teams don’t get to choose whether to adopt it or not.

The US fire service is not a single, unified, and cohesive enterprise. There are approximately 30,000 different fire departments, 50 state fire marshal’s offices, likely thousands of other fire investigation teams, rescue squads, fire protection districts, fire service oversight boards, national stakeholder groups and likely many stakeholders that don’t fit into any those broad categories. This is most certainly not an environment well-suited for a traditional enterprise architecture.

One possible solution is a federated architecture is a standards-based approach intended for semi-autonomous entities where there isn’t a central controlling entity. This approach has already been proposed elsewhere to address similar concerns. In Australia they utilize a system called AIRS (Australia Incident Reporting System), which is heavily modeled on NFIRS for consolidating fire incident data from the various states. A decade ago, they launched a project to develop a methodology for linking other datasets across the different fire rescue services. This project was lead by Fire Rescue New South Wales and resulted in a data dictionary and plans for a federated system that accepted or otherwise acknowledged that trying to convince each of their six (6) states, some with two fire services each (at the time) to adopt a consistent national data standard would be unnecessarily burdensome. In the US if we only had to try to corral upwards of 12 different entities to get some consensus and consistency it would be a real blessing.

Another possible solution is a decentralized approach where a set of minimum standards is required to cooperate in the larger framework. This is the crux of the Semantic Web which is the backbone of something we utilize every day, the World Wide Web, and is coordinated by a group known as W3C. Rather than getting obsessively focused on getting everyone’s forms to be identical, which is infinitely more complex the more entities (thousands of fire departments, hundreds of vendors, etc.) are involved and the more uses of the data (various different data standards and use cases), the focus is upon standardizing terminology the relationships between variables. This was exactly the approach we utilized in a previous project trying to standardize community risk reduction data given the thousands of variations in the types of activities and forms used to document those activities. We developed prototype data models for each of the types of activities to begin to provide some standardization without creating a rigid, relational, data dictionary that would have forced everyone to adopt a universal system that would have increased the hurdles to participation and slowed down innovation. This sort of decentralization aimed to allow for more flexibility at the local level (or with the various RMS software) but it would require some forms of standardization to share elements into the national system.

2 — Jettison any module where another group or agency has established an industry-recognized data format:

NFIRS version 5 was intended to be an “all-hazards” or “all-incident” reporting system. As such, it was intended to help fire departments document all of the incidents or other responses they might attend to as well as helping document other activities within their remit such as arson investigations and hazardous materials incidents. With the release of Version 5 of NFIRS additional modules were included such as the EMS module (NFIRS — 6), Hazardous Material module (NFIRS — 7), Wildland Fire module (NFIRS — 8), Apparatus and Resources module (NFIRS — 9), Personnel Module (NFIRS — 10) and the Arson module (NFIRS — 11). While these additional modules are supplemental and optional, they are often in conflict with other systems that have been widely adopted in the industry. The EMS module is perhaps the most obvious illustration.

NEMSIS is adopted by most states as the de facto reporting format for EMS incidents, yet the NFIRS EMS module has not kept pace with and is not consistent with NEMSIS formatting/coding. To make matters worse, the incident types for EMS (NFIRS 300 series) are woefully non-descriptive for understanding the types of EMS incidents that fire service agencies are responding to. Given that many if not most fire departments that provide any sort of medical care consistently report a large proportion of their runs every year are medical in nature (specifically code 321) not having detailed information that quickly identify and distinguish the broad categories of medical complaints or medical emergencies responded to is a considerable blind spot.

EMS is not the only area where there is considerable overlap between NFIRS modules and other national systems. The Bomb and Arson Tracking System (BATS) run by the Bureau of Alcohol, Tobacco, Firearms and Explosives (ATF) is a widely used system for fire and arson investigators that are sworn and certified peace officers. The ATF convened a group of subject matter experts who identified the specific data elements necessary for documenting fire investigation activities and to manage fire investigation cases. So, it would be worthwhile to adopt or at least mirror the (sharable) elements of their data model for documenting arson cases rather than having a competing and not-compatible module.

The same can be said for wildfire data. Other than EMS data nowhere (in the fire service worldview) is there a more robust and mature data ecosystem than wildfire data — this is not to say they have everything all figured out and they don’t have considerable challenges they are actively working through, but they have dedicated considerable resources, time, and personnel to identifying, mitigating, and fixing fire data problems in the wildfire world. There are a number of standardized forms and systems in the wildfire community that are inconsistent with the NFIRS wildfire module (which is optional anyways) and ultimately confound national wildfire documentation efforts (especially when trying to answer deceptively simple questions like “how many wildfires occurred last year” or “how many acres of land burned last year”).

3 — Operational data matters:

One emerging area where NFIRS does not currently have an existing module but is another blind spot is around emergency scene operations, or fireground operations. Going back to the point I made earlier, NFIRS was never originally designed to help fire departments manage their emergency operations or determine how effective their operations are. However, now more than ever these are vital questions that fire departments, labor leaders, local governments, insurance companies, and anyone else interested in “what works” in fire department operations are asking. Consistent with my previous points rather than having NFIRS create a bespoke Operations Module, I’m suggesting that in the future NFIRS should focus on figuring out how integrate with the data standard/dictionary especially the operational timestamps identified by a group of subject matter experts, in this case, convened by the NFORS project several years ago.

The Fire Data Lab project lead by the Western Fire Chiefs Association and developed by Intterra Group have also foregrounded the importance of timely data about emergency scene operations (as well as after-the-fact data for comparison purposes). Interest in the ability to share and compare data across jurisdictional boundaries is only going to increase. This interest is also being evidenced by the explosion in software technology to help incident commanders, responding personnel, and other responders rapidly access and consolidate pertinent information about the properties and people they are responding to while also helping them manage where resources are located on an emergency scene and what they were tasked with. To illustrate the point this list of emergency operations and incident command software is likely not exhaustive: First Due Size UpRoverAdashiTablet CommandRhodiumSCOUTStreetwiseBattalion3MarvlisIntterraALERTWildfireWIFIREPageTrackIamResponding, and even citizen engagement platforms like Pulsepoint and others.

While it is clear that there is considerable growth in technology to help fire departments of all types manage their incidents, resources, and responders, what is less clear is whether there is consistency in how this information are being collected. There appears to be little consistency in how the insights and analytics based on these activities are being persistently documented, shared, and consolidated. So, we’re still not able to say with any measure of certainty how effective different types of fireground and emergency scene operations are based upon the data collected by these different systems.

4 — We need to reduce the burden of data entry upon firefighters:

Wherever possible and whenever feasible we should aim to reduce the burden of data entry upon firefighters. There are two (non-mutually exclusive) ways to reduce this burden, improving the fire data software and taking a hard look at the data fields that are required:

First, we can and should encourage software vendors to apply their best software development know-how to transform how firefighters enter data. If one wants to see what is possible, they need only look at most modern EMS Patient Care Report (PCR) software. Most of the modern, competitive, PCR software platforms incorporate functionalities like license scanning to pull in relevant data about the patient (name, address, date of birth, etc.) and which can then be queried against previous incidents to identify the incident reports for earlier calls involving the same patient. This is but one minor example of a time saving technology that is becoming common in a parallel type of software. While the market for EMS PCR software has become quite innovative, even when dealing with the complexities of the latest NEMSIS standards, the rate of change in fire incident software industry remains significantly slower.

While it is easy to point the finger at software vendors for the lack of changes, over the past few years I learned in talking with many vendors that there are often a very obvious reasons for the lack of changes: 1) the NFIRS system hasn’t substantively changed in many years, which would require the software vendors to invest resources in upgrading their software, 2) according to several vendors I’ve spoken to while EMS customers tend to expect and demand these sorts of innovative features during sales demos, many fire customers are not demanding the same levels of innovation (a point I’m sure some might strongly debate) and 3) fire software vendors have focused their efforts on building out and expanding their software suite through integrated modules and ‘peripherals’ (external 3rd party software that is offered through partnership agreements and is natively connected) such as building inspection software, inventory management software, scheduling and rostering software, and the like. One might say, when it comes to fire service software fire departments come for the NFIRS reporting and stay for all the other features — so the question now is how to incentivize the wider vendor community to apply the same innovative approaches to improve the fire incident reporting platforms.

Since the software vendors largely control the interface through which firefighters typically interact with NFIRS, they are a vital piece of this puzzle — but not all vendors are created equally and not all software systems are as invested in improving the user experience. Hopefully industry efforts like the recently released version of NFPA 950 Standard for Data Development and Exchange in the Fire Service will begin to chip away at or at least make painfully evident those software systems that are no longer fit for purpose. One of the key takeaways of that effort is to chip away at data silos, vendor lock-in, and other unfortunately common concerns that hamstring technical development in the fire service. But again, it is important to avoid the impression that software vendors are a nefarious cabal out to frustrate the fire service. The fire service by in large has not been educated technology consumers in many cases and occasionally didn’t understand the complexities around specifying, configuring, and integrating software and technology systems and somewhat expectedly there are many horror stories as a result.

The second way to reduce the burden of data entry is to re-evaluate the number of data fields and the number of codes in those data fields. This is a point Dr. Lori Moore-Merrell has been making forcefully for many years. As Dr. Moore-Merrell notes the priority should be on the “need to have” data elements. While there is certainly differences in opinions in terms of what falls under “need to have” versus “nice to have” data elements, the point remains that unless we’re able to clearly articulate how a data element, or a form, or a module helps the fire community better answer a specific question it should be on the chopping block. But this highlights an important problem and a problem that got us into our current predicament.

5 — Relational databases and traditional data dictionaries limit progress:

The tug-of-war between what should be considered “need to have” versus “nice to have” is an artifact of traditional relational coding schemes — at the end of the day there needs to be some sort of agreement forged or consensus reached of the specific questions, what each of the different variables will be coded as, and what questions/variables are not going to get asked. This all seems pretty elementary. It is during the consensus creating process where the tug-of-war is most evident. In the case of NFIRS the tug-of-war tends to be between the people who are entering the data (typically operational personnel) who prefer to narrow down the total number of questions and codes to make any data entry easier on the one hand and analysts and other interested stakeholders who want as much specificity as possible.

To put this another way, the tendency (or at least the concern voiced by many) has been to add as many possible mutually exclusive codes to be able to drill down as narrowly as possible to answer very specific questions. In the case of NFIRS with literally millions of stakeholders, some of whom may have never filled out an NFIRS report but would like information on fires involving specific products or equipment, may all want different things there is a tendency to need to add more and more codes. So using recent history, when electronic cigarettes, hoverboards, and COVID-19 became a concern the tendency was to add more and more codes to be able to drill down into the data to see exactly what sorts of impact these emerging topics were having on the overall fire problem and on fire departments. Given that NFIRS has existed since the 1970s we’ve had over 40 years of adding more and more codes to capture every possible permutation of phenomena. As a result the data dictionary has grown, slowly but significantly, over that time to the point where the NFIRS Complete Reference Guide is now over 500 pages (to be clear there are not 500 pages of data dictionary codes as those pages also include narrative about the system and question logic and many other topics).

This tug-of-war does not need to be so intractable and the resulting compromise/consensus need not leave everyone so unsatisfied. There are other ways to approach the collection and coding of data. In a previous project I worked with Dutch firefighter and data scientist Bart van Leeuwen to modify his Firebrary and FireGraph concepts that uses RDF (Resource Description Framework) graph databases specifically to tackle the topic of Community Risk Reduction (CRR) activity data.

The challenge there was that fire departments across the country were already collecting data in hundreds or even thousands of different formats and coming in late in the game and trying to create or mandate the change to a new universal data dictionary format would run into exactly the same concerns. For instance, it would be very easy to create a code for installing a smoke alarm in a home. But inevitably someone is going to suggest, we should create different codes for smoke alarms with 9-volt replaceable batteries and smoke alarms with long-life sealed batteries. And some departments may install combination smoke alarms and CO alarms so likely we should add another code for those too. There are other departments that install smoke alarms for the deaf and hard-of-hearing so we should add another code for those. As you can see, we’d quickly end up in the same place, and that doesn’t even include the hundreds of other types of CRR activities that fire departments across the country already do. And at the end of the day the personnel doing the CRR activities are likely to yet again bemoan why there are so many codes they have to remember or scroll through in a drop-down menu.

By using graph data models were we able to identify that all those specific types of alarms are all types of smoke alarms so whether one agency opted to consider all of these as “smoke alarms” and another agency preferred to use all the variations we would still be able to query and analyze the data (as long as we could standardize some of the definitions and terminology through a data model) while sidestepping some of the more vitriolic arguments that tend to accompany data dictionary creation. A similar approach, which unconventional, could be utilized to mediate between some of this tug-of-war.

6 — Without an emphasis on training any changes to NFIRS will be wasted:

For better or worse when assessing how the fire service is doing on various topics someone will inevitably make a comparison to the law enforcement community. One area where this comparison is justifiably appropriate is the differences in how police officers and firefighters are trained in the finer aspects of documentation. While I have never seen a study to prove the point, it is often anecdotally noted that trainee police officers often spend upwards of a month learning report writing, how to query computer systems, and the harsh reality that what they write down (or don’t) can come back to bite them in a court room months or years later. This is often contrasted with the scant time typically dedicated to incident documentation in many firefighter recruit training programs.

Dr. Denis Onieal, who recently retired from the US Fire Administration, was and is a vocal supporter for NFIRS but he has rightly emphasized that without an emphasis on improving training any changes in NFIRS will be blunted. This training and education should be broad-based about the value of data, how to correctly fill out the reports, how to appropriately use the data, and this should not be addressed only during initial recruit training. Certainly, in the zero-sum game of trying to add more material to an already stuffed firefighter training curriculum there is no one suggesting we carve out a month of time for report writing at the expense of other vital and likely mandatory material. In fact, there is even a strong argument to be made to actually remove report writing entirely from the firefighter recruit school. While counter-intuitive, this model has been successfully adopted in Virginia Beach Fire Department. To be clear, I’m not suggesting or downplaying the necessity of training fire service personnel on the value of report writing — rather the question is when should report writing be taught?

In Virginia Beach Fire Department Battalion Chiefs Josh Goyet and Amy Valdez, noted (as is often the case in many departments) that filling out the incident report was often delegated by the company officer to the lowest ranking person. It highlighted that filling out the incident report was often viewed a bit like cleaning the toilets, an undesirable, menial task befitting the person with the lowest rank or length of service. Unsurprisingly, the quality of the data collected, either from inexperience, lack of training, or an impression that it does not really matter anyways, was consistently poor. As part of Chief Goyet’s Executive Fire Officer (EFO) project the department modified its training practices and report writing policies. They removed the short lesson on filling out the NFIRS report from the recruit training and filled that time with a series of lessons that they lead on how the information collected through incident reports and all of the other forms of documentation are used to make decisions, to justify expenses (like requests for new equipment), and to demonstrate the value of the organization to the community. They also modified the department’s policies so that only personnel off probation and who have completed additional training, including on report writing, are approved to complete the incident reports.

So training on report writing still occurred, just not during recruit training, it was done later as part of in-service and promotional training for firefighters coming off probation and moving up the rank structure. Simply changing policies didn’t miraculously improve report writing, but their coordinated and comprehensive training approach that emphasizes the value of the information as much as the mechanics of how to tick the boxes has begun to improve documentation in that department.

7 — Improve the usefulness of narrative remarks:

Training to improve incident documentation is not simply a matter of showing people how to ‘correctly’ fill out the report. There should be an equal emphasis on educating firefighters on the mechanics of basic report writing, which is known among English professors as ‘technical or professional writing’. There are two technical writing professors who have turned their attention to the fire and emergency services. Dr. Liz Angeli is a technical writing professor at Marquette University in Milwaukee and a trained EMT, she recently started a training company to help EMTs frame what they saw and what they did to write better narratives. While there are plenty of popular mnemonics to help EMTs and Paramedics write their narratives — SOAP, CHART, (there is a new fire service mnemonic, FIRES) — the approach that Dr. Angeli is advocating is based in technical writing premise that writing is a complex and demanding cognitive process and thus she helps the writer — in this case the EMT — learn how to “think” a narrative, which in turn helps them write a narrative. As Dr. Angeli notes, ‘when providers better understand that process, they can better translate (or “write”) their decisions and actions into a document that supports a patient’s care continuum.’[i]

Similarly, Dr. Aimee Roundtree, a technical writing professor from Texas State University, San Marcos, led a project with several fire departments in Texas to pull themes from narratives and identify better ways to document incidents. Any training to improve filling out incident reports should also include basic education on the mechanics of effective writing and communication not just how to select codes from drop down menus.

Dr. Roundtree’s work highlights another significant area that could dramatically transform how firefighters complete reports and significantly reduce the data entry burden — using natural language processing tools and other modern data science techniques to extract the relevant information from a written or spoken narrative, rather than having a firefighter select from dozens of drop down menus. Currently, narrative remarks are a bit of an afterthought; they are situated at the end of the NFIRS report and once the person entering the data has completed all of the required fields, they are then asked to write what really happened. Just like the last conference speaker before lunch the incident remarks are often written as quickly as possible so the person can get done the report. In my previous experience, in an organization with considerable redundancy with an independent EMS agency, sometimes operational personnel may even begin to make up an ad hoc language or a series of colloquial acronyms. So, for instance, their entire narrative might read like: “E99 COS by A1234 RTS” for one of the all too frequent calls where the EMS agency arrived on scene first and cancelled the fire-based responders upon arrival allowing them to get back in service for another call.

Ultimately, since the narrative remarks fields are often free-text fields many agencies are not well equipped to easily query the narratives, so short of a complaint or other reason to do a Quality Assurance (QA) review of the report many times the narratives never get utilized. At the state and national level the narrative remarks are often not well used either (and almost certainly not shared publicly) in part because of concerns about potential inclusion and disclosure of sensitive and legally protected Personally Identifiable Information (PII) such as Social Security Numbers, Names, Addresses, or the like and Personal Health Information (PHI). So, while the narrative could serve as a rich resource of information this information is typically locked away and excluded from typical analyses, but that is changing.

There are several recent and on-going projects exploring the usefulness of narrative remarks for filling out incident reports and patient care reports. In an earlier project, Bart van Leeuwen developed a prototype tool that could parse through an NFIRS narrative and extract the relevant NFIRS codes. At the University of Virginia, Dr. Homa Alemzadeh is leading a team to develop a cognitive assistant that can convert spoken words into a narrative that can be parsed to complete a PCR. Simultaneously, the Department of Homeland Security — Science and Technology Directorate (DHS S&T) has partnered with NASA Jet Propulsion Lab (JPL) to explore whether the AUDREY (Assistant for Understanding Data through Reasoning, Extraction and Synthesis) platform could assist paramedics in completing required hospital forms through testing at Hastings-Quinte Paramedic Service in Ontario, Canada. While none of these approaches have moved from the realm of technical proof-of-concept into anything approaching a production level tool there are interesting developments occurring that could transform the way firefighters and EMS providers enter information.

8 — Expedite data sharing:

Every fire department has a geographic territory that they cover and are responsible for. In that area, however big or small it is, the fire department is typically the most knowledgeable people about the types of incidents they are seeing, emerging trends, and possible patterns. But what happens when there is only one “weird” incident in your community and there are a bunch of “weird” isolated incidents in another areas across your state or across the country, when we only look at the local community our “emerging issue surveillance” is quite limited. In the past decade this sort of cross-jurisdiction emerging issue surveillance in the UK has identified a few brands of refrigerators that were only causing a fire or two in each county fire rescue service but accounted for a major trend nationally. London Fire Brigade made a significant push to force a major recall of several brands, however, they struggled to gain political traction before a fire that began in a refrigerator consumed Grenfell Tower Block killing over 70 residents. In our increasingly connected digital world we may get lucky and start to connect the dots on a series of otherwise isolated incidents, but we should also be able to rely upon systems like NFIRS to rapidly identify these trends across the country.

Currently sharing NFIRS data is an afterthought in many fire departments. The data is exported on a (somewhat) routine basis by local personnel or by the records management system vendor and then it is sent to or uploaded into the respective state NFIRS systems. Typically, this happens on a monthly basis, although some agencies do so on a quarterly basis or only once a year. This approach is what I refer to as the “Share When Convenient” approach — in that it is typically up to the fire departments to decide when to share the data with their State. The State then decides when to send or release the data to the USFA. It is worth noting that sharing data on a monthly basis is actually pretty quick and provides a monumental leap from historical practices in the fire service. However, if most of fire departments in a state share data on a monthly basis but there are a few fire departments, especially if they are big fire departments, that only send data on a quarterly or annual basis many states will withhold sharing or releasing the data to the national dataset until the data is complete for their entire state. So, while the State Fire Marshal’s Office has access to during that time it typically isn’t available for use by other fire departments, national stakeholders, or other users who might be able to identify emerging trends.

I propose moving to a “Share By Default” approach, while being cognizant that local fire departments can and should be able to withhold record that are not ready for sharing, for example, incidents that are under investigation, incidents that are very sensitive due to a death or injury, or the like. These records could be and should be marked as temporarily not ready for sharing. By moving to an approach where records are automatically shared on a daily or weekly basis would provide far more timely awareness of emerging issues and trends beyond the bounds of a fire department’s jurisdictional boundaries.

Note: It is worth mentioning that I’ve deliberately tried to avoid using the term “real time” when referring to information sharing preferring the term “timely” in large part because the term “real time” is often used but poorly understood. How urgent information sharing is depends considerably on the context. If one is referring to data sharing between sensors or devices to alert firefighters or incident commanders of a situation that poses immediate danger to life and health (IDLH)— say like a Mayday or an impending flashover what is considered real time is likely measured in milliseconds. Whereas when identifying the availability of a fire apparatus through a CAD system perhaps a 60 second lag time might be sufficiently real time. When we consider something as regional or national in scope as NFIRS a delay of one to seven days might be considered sufficiently real time as the criticality of the information sharing is less urgent.

9 — Automate as much of the data sharing process as possible:

There are a number of technical and bureaucratic reasons for the current data sharing approach — most obviously, the various state fire marshal’s offices are not prepared or staffed to be able to manage and process records more than once a month. The current process for accepting, validating, processing, and posting NFIRS records at the state level are typically a series of manual or semi-automated processes. So, the prospect of increasing the data sharing frequency is understandably likely to lead to considerable push back. In most states the NFIRS program management role is overseen and managed by one person — and sometimes that one person has other duties or competing responsibilities. Significantly increasing their already stretched workload based on the current workflows and processes is simply not reasonable.

So the question is how to automate some of the basic data sharing functions without undermining or devaluing the often underappreciated contributions and experiences of the state NFIRS program managers? It should also be noted that there is a key ‘states-rights’ issue here in that the configuration and practices of the respective state NFIRS program managers are dictated by the laws, policies, and technology requirements of each independent state.

10 — Develop data sharing APIs:

Recognizing the independence of the states it is possible and vital to create a standardized “machine-to-machine” API (application programming interface) data sharing interface that allows approved software vendors and technically advanced fire departments to set up secure, automated, and fast data sharing interfaces. For those not familiar with APIs they are basically the technological equivalent of a standardized hose coupling. It is a technical interface that is available to software developers that specifies how to connect to the system, what data can and should be passed, in what format, with what security or encryption protocols, and any validations or receipts to expect in return to ensure the data was received appropriately.

For the foreseeable future there will be fire departments that are using legacy systems or locally controlled records management systems that may not be able to support APIs for data sharing. So there will likely still need to be other ways of sharing or entering data but the more we can incentivize, encourage, and help fire departments to move to more modern systems that can support more automated data sharing the better for all fire departments — especially those who move onto more modern and capable platforms. But it must be acknowledged that if there is a significant change to NFIRS it would likely render some older legacy systems obsolete, which is a double-edged sword for sure, but it would certainly expedite the transition to a more modern data sharing infrastructure.

11 — Adopt JSON as default data format:

Part of the burden upon state NFIRS program managers is dealing with the inconsistently formatted “standardized” NFIRS data submitted. At its core NFIRS is a standardized data format. However, one would be mistaken in assuming that since the data is supposed to be standardized, that is actually is standardized. The data export formats from various vendors often have considerable variations that create a significant headache and consume a fair bit of time to manage. The USFA has created a series of tools to help state NFIRS Program Managers process and transform the data from different vendors into a standardized format, but this takes time and effort. Some of the differences come from different delimiters between items that deviate from the use of carats “^” which is the standardized delimiter but some systems substitute pipes “|”, commas, or other non-standardized (at least based on the NFIRS standard) delimiters. The other common difference is in the file type. Typically, NFIRS files use the ASCII or .txt format. But some vendors have created their own file formats (i.e. “.inc” files and others) that require the creation of complex ETL (Extract, Transform, and Load) workflows that all add time and complexity to the manual processing of NFIRS records.

If NFIRS moved to a more standardized, but still human readable, data format like JSON or XML it would significantly reduce the burden on program managers, software developers, and analysts alike. While XML is often preferred by legacy systems and traditional IT personnel, I’d suggest moving to a JSON (JavaScript Object Notation) format as the files are much smaller in file size and do not have as much extra formatting information included. JSON is the data format that most data sharing systems have adopted.

By creating a more useful, standardized, and easily transportable file format that eliminates much of the need for manual data processing will allow the state NFIRS Program Managers, software vendors, and other users to focus their efforts on deriving value from the data, working with non-reporting or inconsistently reporting department, and any of the multitude of other ways they can use their skills to increase the value of the data.

12 — Fix the fledgling feedback loop:

As has been discussed NFIRS is both a coding scheme and a national database for consolidating incident records. Where one begins and the other ends is not always clear. This is most evident in the efforts to articulate the value of NFIRS to local fire departments, the same fire departments that complete the reports in the NFIRS format that get submitted into the NFIRS consolidation pipeline. For example, this brief note is from the somewhat dated NFIRS Complete Reference Guide:

Each fire department is responsible for planning and managing its operations so that firefighters can perform their roles of fire control and fire prevention most effectively and efficiently. The availability of accurate information about fires and other incidents is vital in achieving maximum performance. Patterns that emerge from the analysis of incident data can help departments focus on current problems, predict future problems in their communities, and measure their programs’ performance.

The point here is that fire departments can and should be using their local data to drive decision making. What is missing is how the NFIRS infrastructure at the state or national level helps do this. Certainly, the respective states, the USFA, and other groups like NFPA use consolidated NFIRS data and create reports, analyses, infographics, and targeted public outreach campaigns based upon the national level data. However, other than consuming these other types of aggregated information there isn’t a clear feedback loop that directly benefits or supports the fire departments that submit the data. To put it another way, if I send you a package and then in six to 18 months later you send it back to me unchanged, there is very little net benefit to me.

This is something the USFA is already working to address, the Enterprise Data Warehouse (EDW) that the USFA is setting up should allow enhanced functionalities including business intelligence tools to do some comparisons with other agencies. Although that said, some of the current security and access control precautions do significantly limit the benefit of the system for local users. And it is also worth noting that the existing SORT (Summary Output Reporting Tool) does help fire departments without any internal capabilities or built in analytics tools within their current RMS platform to be able to run simple queries. These efforts and tools go a long way to closing the broken feedback loop so fire departments can begin to reap the benefits of the information they contribute to the national NFIRS ecosystem.

The question remains how timely the information available through the EDW and the state systems are in order to help local fire service agencies effectively manage their organizations. This goes back to my earlier point; it is vital to change the data sharing paradigm so that data feeds into these state and national systems days or weeks after an incident occurs not months or years later. That is on everybody, the local fire departments, the states, the RMS vendors, and the USFA. If the systems are not intended to rapidly share info then we cannot and should not blame the USFA for the lack of timely and contemporary data available within these systems.

13 — Continue to make it easy for small rural fire departments to enter data:

One trend that has made significant inroads into improving the quality, quantity, and consistency of NFIRS data collected have been the proliferation of State RMS platforms, especially for smaller, rural, volunteer fire departments. These statewide platforms are typically paid for by the State Fire Marshals’ Office (SFMO) and are made available for free to any recognized fire department in their state. The need to provide a free way for fire departments to submit electronic records has been recognized for a while. The USFA has provided the Data Entry Browser Interface (DEBI), a free tool to enter individual incident records directly in the federal system, for years. However, the proliferation of statewide and state-controlled RMS platforms has quickly and dramatically improved the collection and sharing of data in those respective states. Now the SFMO has access to the data about incidents, inspections, and all of the other data entered within hours rather than having to wait months for the data to be submitted.

While these systems are typically free to recognized fire departments in the respective states, they are not well-suited or appropriate for every fire department. Many if not most medium to large size fire departments in a state would typically not make use of this free service, for very practical reasons. The state systems typically do not and cannot connect to each local Public Safety Answering Point (PSAP) so the systems would not be auto-populated with basic information about the call like the address, time, incident number, units dispatched, incident timestamps, and the like. So, while the state systems are free they are not typically that convenient. If you are a small fire department with a hundred or so runs per year the minor inconvenience of having to request this info from the PSAP and manually enter it into the incident report is a reasonable trade off since you don’t have to foot the bill for the software. But if you’re a large fire department with tens of thousands or even hundreds of thousands of runs per year this sort of inefficiency would be a non-starter. These state systems also often don’t integrate with other local software systems such as payroll systems or 3rd party inspection software so there are certainly limitations for larger and more complex agencies.

14 — Improve the economic estimates for fire loss and saves:

The final point on how to fix NFIRS is about improving the estimates of the value of properties, contents, and the value of the losses therein. One of the consistently problematic areas of fire incident reports are the estimates of fire loss. Going back to an earlier point, there is often little to no training on how to estimate fire loss or where to find information to hopefully even get to the right ballpark. Yet, the expectation is that whoever fills out the report will enter the pre fire values and the post fire losses with little to go on to base the judgement. This knowledge gap has significant consequences for the wider fire service.

Public fire protection might be considered an essential service but that doesn’t insulate fire departments from the tough zero-sum budget calculus of local governments. Fire departments that cannot demonstrate their value, typically in clear cut dollars and cents, will struggle to maintain their existing resources and justify additional resources. While using cumulative fire loss is a poor measure of the value of a fire department, even at the best of times, not having this elementary information handicaps fire departments as they go through the municipal budget process. Worse yet, if these dollar loss estimates are way off (typically significantly under-estimated although it is possible that some over-estimate fire losses), or as often happens, they leave the report with a $0 dollar loss, then the fire department is doing themselves a significant disservice.

One of the most obvious solutions has proven the most intractable. When asked about how to improve fire loss estimates many fire service personnel will retort, why are we making wild guesses when the insurance companies and insurance adjusters have the skills, tools, and experience to make far more accurate assessments of the actual value of the fire loss. These concerns are not unfounded, in Vermont the State Fire Marshal’s Office publishes a table in their annual report that compares what the fire departments report as fire loss and what insurance carriers in the state reported paying out as part of their required reporting to the insurance commissioner.

Source: https://firesafety.vermont.gov/sites/firesafety/files/files/Documents/dfs_fmreport_18.pdf

Now to be clear this likely isn’t an apples to apples comparison, and that is part of the problem. The reported insurance losses likely include ancillary policies and payouts related to the fire loss that fire departments are often not aware of or don’t consider. The insurance losses likely are being impacted by things like business disruption coverage, which is a major type of loss that is likely never included in fire departments calculations of fire loss. But if insurance companies are paying for things like business disruption after fires, then why aren’t fire departments factoring these losses into their calculations about what was lost and what was saved.

The disconnect between the fire service and the insurance world has been puzzling to many people for years. The insurance industry seems to have the most to gain from successful fire service interventions, yet many fire departments have expressed frustration getting insurance companies or adjusters to share things as simple as how much the loss was estimated at. Much of this disconnect likely owes to the equally decentralized, tightly-regulated, and highly-competitive nature of the insurance industry where sharing information on losses, even with state insurance regulators, insurance advisory service organizations (such as American Association of Insurance Services, Washington State Rating Bureau and the Insurance Services Office), and anyone else with a benevolent interest in loss data, is tightly controlled. Yet there is much that can and should be done to tear down these walls and build bi-directional data sharing pipelines that benefit the wider insurance world and the fire service world. If the insurance industry wants or needs granular data about fire department deployment, water supply capabilities, radio system configuration, and fire prevention activities in exchange they should be just as willing to develop, test, and provide tools to help fire departments better identify and mitigate risk in their communities, and at the very least help fire departments do a much better job estimating or imputing the exact economic cost of fires.

There have been a number of recent efforts to help the fire service quantify the true cost of fire losses (as well as the economic value of saves) in recent years. For example a project by Arizona State University in 2014 applied a REMI (Regional Economic Model, Inc.) regional forecasting model to estimate the economic impact in terms of jobs saved, tax dollars saved, and all sorts of other rarely considered economic impacts of fire losses. Similarly, NFPA and the Fire Protection Research Foundation recently commissioned a study on the Total Cost of Fire that takes into consideration many additional variables and attempts to estimate under-counting of business disruption and the economic value of lives saved, known in the industry as Quality Adjusted Life Years (QALY). While I doubt many fire service personnel are going to start patting each other on the back after a fire noting how many Quality Adjusted Life Years that they just saved when they made that successful rescue, it does behoove the wider fire service to begin doing a better job measuring the economic impact of fire losses.

Here again there is already considerable progress being made in some local communities, Fayetteville (AR) Fire Department has developed a tool to estimate the specific economic loss (and saves) from fire responses, which takes into consideration business disruptions, disruptions to the tax base, and the inter-dependency between companies (especially in the manufacturing sector). Whether it comes by using tools like the Property Loss Estimation Tool, consulting the tax assessors office, using a tool like Fayetteville, building better relationships with the insurance community, or some other approach we need to get more accurate estimations of fire loss in this country if for no other reason than to improve the fire protection political calculus that too often concludes that fire departments are too expensive and sprinkler systems are too costly.

Concluding Thoughts

If there is a takeaway from this article it is that NFIRS, as it is currently configured, is not equipped or agile enough to continue to serve fire service in our modern world. But that said, NFIRS is and should continue to be part of our wider fire data ecosystem going forward. If these seem like incompatible statements, they are not. We shouldn’t throw the baby out with the bathwater. NFIRS is worth fixing and worth saving, but it won’t happen without the support of people from across the fire service spectrum. The COVID-19 pandemic is certainly not the first circumstance that has highlighted the challenge of rapidly documenting the impact of emerging topics on the fire service. So, what makes COVID-19 different? Why should we use this moment to finally build the momentum and the political support need to make the long overdue changes to NFIRS? The answer is not as much about NFIRS specifically but about the wider lessons being learned as we speak about how important things like rapid data sharing, dynamic emerging issue surveillance, and the benefits of using larger, cross-boundary datasets, to identify trends and model impacts really are.

Given how dramatically and rapidly our world has been turned upside down it is easy to focus only on the exigent needs and plan for the hear and now. But this is also the best time to begin laying the foundation for how the wider fire service is going to emerge from this pandemic stronger, more resilient, and more capable of handling a crisis of this magnitude in the future. Having a system that can respond to emerging issues dynamically; takes user experience seriously (especially when it comes to the ever increasing burden of forms and software firefighters are being asked to fill out); and integrates with and co-exists with other data systems to help us get a more comprehensive picture of the whole fire data ecosystem is the way that NFIRS can and should continue to serve the wider fire service in the Post-COVID-19 world.

This need not be considered science fiction. Most of the pieces to dramatically transform NFIRS already exist — except perhaps for the political willpower and (resulting) federal funding to make anything remotely resembling this road map come to fruition. Perhaps one of the most vital and often overlooked (or misunderstood) pieces of this puzzle are the dedicated people at USFA who oversee and manage the NFIRS system day in and day out. Unfortunately, when frustrations with NFIRS bubble up it is sometimes assumed that the folks from USFA and the National Fire Data Center are the roadblocks to the changes and improvements that are so obvious to others. However, from personal experience I’ve found quite the opposite. While the team is populated by realists and people who have a job to do (and from what I’ve seen they do it to the best of their abilities), they have to work within the parameters that they are allowed to operate. If anything, they are perhaps more cognizant of the concerns, complaints, or opportunities for improvement than anyone, not least because many conversations people have with them about NFIRS often contain gripes about NFIRS or questions about why certain frustrating things are designed the way they are.

Lest this article be also taken as a yet another gripe about NFIRS, let me reiterate yet again, I firmly believe that NFIRS can only be improved with the help of and the support of the people of the National Fire Data Center. They cannot make changes to the system without our help and support. It is upon us to work with and support the Congressional Fire Service Institute (CFSI) and call upon the members of the powerful Congressional Fire Service Caucus, who have stood with and supported the fire service time and again, to include sufficient funding to fix NFIRS and fire service data sharing more broadly.

So this is my call for all of us to stand with the folks at USFA and the National Fire Data Center, some of whom you have undoubtedly heard of: US Fire Administrator Keith Bryant, Deputy US Fire Administrator Tonya Hoover, Director of National Fire Programs Rick Patrick, NFDC Chief Bill Troup, Marion Long, and the newest member of their outreach team Greg Williams. But also, those that you may not know who work behind the scenes: Gayle K., Marianne C., Meredith L., David M., Jim H., Frank N. And it is worth including the State NFIRS Program Managers and those who have retired in recent years from USFA that have had made significant contributions to NFIRS over the years: Dr. Denis Onieal, Brad Pabody, Alex Furr and many others I’m sure I’m forgetting. While they are actively working to manage, support, and maintain NFIRS, it is on us to heed the rallying cry that “Timely Information Exchange” should be one of our main priorities in the Post-COVID-19 world. Finally fixing NFIRS to meet our needs for the next 50 years should be something we can all get behind.

Donate Today!

Like what you see VFI? Help keep us going by donating any amount.



Translate this Website

Advertisement

Advertisement

Advertisement

Visit Our Sponsors

Follow us

Don't be shy, get in touch. We love meeting interesting people and making new friends.