Dr Craig Weinschenk, Lead Engineer for NERIS at the Fire Safety Research Institute, discusses rebuilding the foundation of US emergency data management from the ground up
For nearly half a century, US fire departments have relied on the National Fire Incident Reporting System (NFIRS) to record and share incident data.
But a framework designed for paper forms in the 1970s has struggled to keep pace with the demands of a connected, data-driven era.
Its manual processes, static structure and years-long data lag limited the fire service’s ability to analyse trends or act on emerging risks in real time.
The new National Emergency Response Information System (NERIS) aims to change that.
Developed by the Fire Safety Research Institute (FSRI) in partnership with the US Fire Administration and the Department of Homeland Security’s Office of Science and Technology, NERIS provides a cloud-based, geospatial and user-focused platform that captures and shares fire data almost instantly.
IFSJ Editor Iain Hoey sat down with Dr Craig Weinschenk, Lead Engineer on NERIS at FSRI, to learn how the system was built and what it could mean for the future of fire service data.
NFIRS served the fire service for nearly 50 years – what were its limitations, and why was a new approach required?
NFIRS was conceived in 1973 after the Fire Control Act and it started as paper forms, even carbon copy forms where you had three copies.
To make field reporting doable, “structure fire” became “111” because three numbers are easier to process than handwriting.
That served the field well for a long time, but you needed a big lookup table to know the codes.
When things started to digitise in the late 80s, early 90s into the 2000s, the approach was to digitise NFIRS.
It became a digital version of paper forms instead of taking advantage of advances in database technology.
Expectations for data expanded, but the system stayed tied to that older mindset.
It was not geospatial.
You filled out a complete address but there was no latitude and longitude in the payload, even though incidents all occur somewhere.
It was also very manual.
You completed the record locally, exported a text file, sent it to the state, then to the federal government.
Everyone processed plain text files that were emailed around.
That does not scale and it creates data lag.
When your environment changes in three-to-nine-month windows but the data lags 18 to 24 months, you miss chances to make real time impact because by the time it is aggregated you are looking too far in the past.
There were practical constraints too.
The hardware was old and the software was old, and you could not upgrade one without breaking the other.
If you tried to build an NFIRS 6.0 you were rebuilding the same system and moving one step forward.
The decision was to rebuild from the ground up, take lessons learned from geospatial needs and time lag, and put the fire service first on incident collection.
That is what we did with NERIS.
How did this public-private partnership work in practice, and why was it important?
We work hand in hand with the United States Fire Administration and with DHS S&T.
We have weekly stand-ups and the rigor you expect from a national project.
We produce documentation and artifacts, and we have oversight from security scans to operational performance metrics, all documented and shared with the federal government.
That oversight ensures we have no blind spots and keeps the project healthy.
As a nonprofit building this, we can also be nimble.
We are not owning local data or hosting on federal servers inside federal firewalls, which have limitations.
We can hire a dynamic team and move quickly while following standards and best practices.
We see ourselves as stewards of a national system by and for the local fire service, building to support USFA’s mission and DHS’s mission while putting the fire service first.
Data governance is foundational.
Local departments own their data.
They collect it and send it.
The value is in aggregating at local data regionally statewide, and nationally, but the department still owns the record.
That principle is a critical piece that makes this work.
What is causation data and why does it matter for incident reporting and prevention?
In NFIRS the causation data was in the primary record.
That created a challenge.
Either the record stayed open while you waited for an independent investigator to provide answers, or people put something in just to close the record.
We decoupled the schemas.
We have a core schema that looks at general causality from a fire behaviour and safety perspective, not from criminality.
We are deliberate in our language so we can understand the incident from safety, response and frequency perspectives.
Then we have a follow-on called Incident Analysis.
The two are decoupled.
You can close the first part so we know the call happened and we can run metrics on demand, while the analysis can be completed 24 or 48 hours later when the right staff are available or when more time is needed to understand the incident.
That puts the right information in front of the right people at the right time, instead of forcing someone who may not be qualified to answer those questions.
How does the system balance the need for national-level analysis with the practical, day-to-day needs of local departments?
In addition to collection, we are building an analytics platform that runs as part of the system.
Every department gets an Insights tab with high level information about response.
Incidents appear on maps, colour coded by response duration so you can spot hotspots.
We are deploying a unit-level response dashboard to see metrics on particular units, frequency of units running together and distances travelled.
We also show things around casualties and rescues, so you can understand both loss and saves.
Data ladders up.
A state sees the same dashboards in aggregate.
They can view activity percentages, performance across the state and distributions of calls by discipline.
Because we built an API-based system instead of manual data movement, when a record shows up it is available to the local and to the state, and it is available to be pulled by the federal government into its infrastructure via secure API.
They keep a full copy and can run their analytics in real time.
We have cut lag from roughly 14 or 15 days from local to state, and 6, 12 or 18 months to federal, down to hours.
In practice we usually see records completed at the end of a shift, QA and QC over the next shift, then submission.
If you want to keep using your own tools, you can do that and still access your data via secure API.
Looking ahead, what do you see as the next steps for NERIS?
NFIRS sunsets on 31 December 2025.
Looking at 2026 there are two phases: take what we learned on onboarding and improve the system, schemas, questions and workflows.
Then focus on analytics.
Provide products that help departments do their job, identify gaps in response at hyper-local levels, and surface larger trends regionally, at state level and nationally.
The aim is to identify the next hazard and where to invest in research, because we are seeing data fast enough to act.