BY LAUREN KEYSON
An Interview with Michael Fay, publisher of FirePoint® software
Is NFIRS 5 reaching its full potential? According to Michael Fay, publisher of FirePoint® software, NFIRS 5 cannot begin to succeed until it is finally defined. Lack of a final NFIRS 5 standard is diminishing the efforts of many to make NFIRS 5 a success.
NFIRS 5, the government’s new incident reporting system, was designed to be the Y2K-compatible alternative to NFIRS 4.1. NFIRS 4.1 had a few minor Y2K issues, so in 1995 the Federal Emergency Management Agency (FEMA) started the process of creating a new incident reporting system. FEMA was to have a final NFIRS 5 standard in place well in advance of the year 2000. But, according to Fay, “There have been dozens of NFIRS 5 revisions, yet after all these years nothing is final.”
NO FINAL STANDARD
The chaos surrounding NFIRS 5 standards is causing software chaos and is taxing technical support resources. This is dragging down the release of innovative technology. Here’s how Fay sees it.
•Almost seven years into NFIRS 5 standards development, there is still no final NFIRS 5 standard.
•Without a final NFIRS 5 standard, there is no stable NFIRS 5 reporting system.
•With each NFIRS 5 change, regardless of how small, vendors are forced to completely upgrade their entire customer base. This burdens technical support and development resources. Local fire departments and vendors are forced to make all incidents retroactively compatible with the latest version of NFIRS 5, regardless of the date on which the incident occurred.
•The lack of a stable NFIRS 5 system keeps incident reporting compliance down. It’s difficult to get “valid” incidents into the system when the definition of “valid” is subject to frequent change.
•FEMA blames vendor software when “errors” are detected. The vendors blame FEMA for the lack of a final standard. But sadly, new technology that could benefit the fire service is being stalled by the requirement to constantly update NFIRS 5 software.
THE FUTURE OF NFIRS 5 REPORTING
Fire Engineering talked with Fay about the future of NFIRS 5 reporting.
LAUREN KEYSON, FIRE ENGINEERING: What changes have there been in the past year with incident reporting and FEMA?
MICHAEL FAY: I would say there is obviously an antagonism toward vendors, particularly small vendors and those who are pushing for stable NFIRS 5 standards. But that isn’t a change.
LK: Why do you think there is this antagonism?
MF: I honestly don’t know for sure. My suspicion is that-given the best of all possible worlds from its perspective-FEMA would like to provide the software people use to put the data into the incident reporting system, and it would like to decide how the data are dispersed to the fire service community. I think it’s kind of a bureaucratic turf issue-it wants to own fire data.
LK: Do you have any evidence to support your allegation that FEMA is trying to dominate incident reporting?
MF: I think it revolves around a lack of a final NFIRS 5 standard. Frequent changes keep the system off balance, as vendors are forced to keep up with changes. Under the current system, all NFIRS 5 data must be made retroactively accurate to the latest specifications-regardless of when the incident was entered into the system and regardless of the standard for incident reporting that was in effect at the time the incident was entered. Every time you upload an older incident, chances are something will be rejected. All software “errors” are referred to the vendor for correction.
The vendor’s phone rings. You have to work with the fire department and explain that old incidents frequently do not meet new standards. While the information may have been accurate at the time the incident occurred and the form was filled out, it is no longer considered acceptable for upload to FEMA.
This situation makes it very difficult for vendors to do business. Whether it’s intentional or not, I really don’t know. But from where I sit, it certainly appears FEMA may be using standards chaos to eliminate the software “competition.” The number of vendors has decreased dramatically since FEMA started releasing multiple NFIRS 5 standards. It’s not the only reason for vendors dropping out of the fire service market, but it’s a very significant one.
LK: Are you saying it’s you against the federal government?
MF: No, that’s not the way it should be. I, for one, was very forgiving of all the missteps that occurred while developing the new standard. NFIRS 5 is complex, and a lot of people and priorities were being taken into consideration. I knew we would have problems and we would all need to work together to resolve them. But somewhere along the line, FEMA started to lay the blame for NFIRS 5 reporting problems on the vendor’s software product. That simply was not true, and it was not fair.
As years pass without a final NFIRS 5 standard, it’s easier to believe FEMA may actually be protracting the standards-setting process to diminish “competition.” It’s quickly becoming the only rational explanation for the current situation. But the lack of a standard does not just affect the vendors. It’s a big problem for states as well.
LK: How are states affected?
MF: I recently visited a state that is mandated by law to collect and analyze its own fire data. To accomplish this mandated requirement, it developed a program in Oracle. It spent thousands of dollars to get the system up, running, and debugged. As soon as it got operational, FEMA changed the specifications, and the developers had to be brought back in to redo significant portions of the system. Again, there was thousands of dollars of additional expense the state could hardly afford.
Those responsible for NFIRS 5 in this state were angry to have to waste resources to keep up with an ever-changing standard. But it was grateful it only had to redesign its own software. It couldn’t understand how vendors could possibly keep changing their software while having to update hundreds and, in some cases, thousands of customer installations. Those customers, local fire departments, pay a price too.
LK: How are local fire departments affected?
MF: Some fire departments have computer people. These fire departments have no problem upgrading their software. Other departments don’t have computer expertise beyond that required to operate the software. For them, even the seemingly small task of downloading files and replacing them on their network can be intimidating. So with each required “upgrade” of software, valuable time is spent working in unfamiliar technology. Some departments even opt to hire outside computer personnel to perform the upgrade. It’s time-consuming and expensive. And, it doesn’t even account for the time required to “correct” older incidents to the latest NFIRS 5 standard.
I don’t think FEMA understands how local fire departments use software.
LK: What doesn’t FEMA understand?
MF: FEMA’s focus is rightfully on incident reporting. Local fire departments track their incidents, but a good fire department software application does a lot more. FirePointT, for example, provides 40 fire service modules covering everything from training records to network operations, plans checking, occupancy inspections, preplans, hazardous materials, personnel, leave, overtime, equipment, hydrants, hose, parts, and supplies, just to name a few. NFIRS 5 is covered by only three of the 40 modules in FirePointT. Fire department decision makers need all of this information to manage their departments. It makes sense to keep this information in one place. It doesn’t make sense to split it into different databases.
NFIRS 5-only software takes fire operations out of their proper context. Fire departments do a lot more than respond to incidents. Their operations database is far more complex than the NFIRS 5 incident reporting system FEMA envisions.
LK: Where do we go from here?
MF: Three things. First, FEMA must recognize immediately there is little to be gained from yet another change to NFIRS 5 specifications. It’s far more valuable to have a final NFIRS 5 standard. Freeze NFIRS 5. In five years, release one stable update and call it NFIRS 5.1. Stop the standards madness!
Once standards are frozen, vendors will focus on making the necessary adjustments. Within six months, most local fire departments will be upgraded, and the system will operate much more efficiently.
Second, FEMA must include a broad spectrum of vendors in its decision-making processes. Currently, only large vendors are adequately represented. If competition is reduced to one or two large vendors, innovation will be suppressed. Prices will rise. Service will decrease. FEMA should be in the business of encouraging new approaches, not forcing its bureaucratic edicts onto the fire service.
Third, fire department software vendors should be recognized for what they are. They are members of the fire community. Like myself, most have grown up in the fire service. They choose to make their contribution by designing new technology based on their fire service experience. They should not be treated as “associate” members of the NFIRS 5 standards-setting pro-cess. Their experience is focused on the needs of local fire departments. They have much to contribute.
LK: Any final comments?
MF: I’m impressed with the irony of the situation. Just at the time when we need new technology, the private vendors, who provide technology, are being squeezed out of the process. I don’t see how the fire service benefits from the current situation.
Michael Fay publishes FirePoint software. He was a firefighter/EMT for 15 years and was part of the original faculty that opened the National Fire Academy in 1980. He designed the National Fire Academy’s first computer lab and served as program chair of the Management Series. His e-mail address is email@example.com.
LAUREN KEYSON is executive editor of Fire Engineering and conference manager for the Fire Department Instructors Conference. Previously, she directed digital and print publishing in high tech and finance. She has a bachelor’s degree in political science from UC Berkeley and a publishing certificate from Stanford University. If you have a burning issue to discuss in this column, e-mail her at firstname.lastname@example.org.