NERIS Changes: A Data Perspective
At a high level, the transition to NERIS does three things:
Continues the use of many fields that already existed in NFIRS
Introduces new fields added by NERIS
Deprecates a number of NFIRS columns not being used in NERIS
How NERIS is Handled in Ad Hoc
You will soon see two Incident Report data sources:
Incident Report (NFIRS)
Incident Report (NERIS)
Incident Report (NFIRS) is simply a relabeling of the existing “Incident Report” data source. It will remain intact and function the way it does today. Reports using this data source will continue to be supported.
Incident Report (NERIS) is a new data source developed around the NERIS framework. Like Incident Report (NFIRS), it contains all of your historic Incident Report records but with the following differences:
Deprecated NFIRS columns are removed
New NERIS columns are added
Lesser-used columns from specific data categories (Fire, Prevention/CRR, Property, Weather) are segmented into separate child data sources for improved navigation and performance.
An easy way to think of this is in terms of “rows” and “columns”. At the row level, the two data sources are the same and will contain past records from NFIRS and any future records from NERIS. The difference is at the column level, where the data source will contain columns representing fields from each respective version of the form.
How Other Incident Report Related Data Sources are Handled
While the exact implementation for each column depends on several factors, such as it’s relationship to the incident and whether the concept is a new addition by NERIS, the experience on the user end will be much the same as it is today.
Existing Child Tables to Incident Report (e.g. Incident Report Apparatus)
These tables are largely unaffected by NERIS and will be available to join as a child from both Incident Report (NFIRS) and Incident Report (NERIS).
Existing Data Sources that come from Sub Forms in Incident Report (e.g. NFIRS EMS)
NERIS adds a number of new fields to these existing sub forms: NFIRS EMS, NFIRS Firefighter Casualty, and NFIRS Civilian Casualty. New NERIS columns will simply be added to the respective data sources.
For Ad Hoc users, the “NFIRS” part of the data source name will be removed soon. For ODBC users, the table names in the warehouse will remained unchanged for the time being, to prevent errors in queries and ETL jobs.
New NERIS Concepts with 1-to-Many Relationships (e.g. Emerging Hazards)
These will appear as new child data sources to Incident Report (NERIS). They will not be available as joins to Incident Report (NFIRS) since they were never part of that form.
Historic Reporting Across the NFIRS/NERIS Transition
As mentioned earlier, both data sources will contain past and future Incident Report records. This provides users with multiple pathways to address historic reporting.
Scenario 1: I need to run a historic report on a field that was part of NFIRS but is not in NERIS.
The historic data from any deprecated NFIRS field will continue to be available in Incident Report (NFIRS). Use this data source for your report and select your desired date range.
Scenario 2: I need to run a report where the dates cross my NFIRS/NERIS switch and it uses a common field from both forms (e.g. Year-Over-Year Incident Totals by Fire Station).
This report could technically be run from both data sources and return the same result. There will, however, be advantages to using Incident Report (NERIS). Details on this are in the FAQ section below.
Scenario 3: I need to run a report where the dates cross my NFIRS/NERIS switch and it requires both a deprecated NFIRS field and a new NERIS field (e.g. Incidents where NFIRS Incident Type = “111 - Building Fire” or NERIS Primary Incident Type = “Fire - Structure Fire - Structural Involvement”).
We will be adding a new data source called NFIRS Deprecated Fields, which will be available as a child join to Incident Report (NERIS). This will allow you to join old NFIRS fields to your NERIS data source, creating a fully unified dataset capable of retrospective reporting on any prior and/or current field.
Release Timelines
The release of NERIS data sources in Ad Hoc will begin around August 1, 2025 and continue until Mid-September. Incident Report (NERIS) will be part of the initial release, with child tables being updated based on anticipated reporting priorities.
Frequently Asked Questions
Will my existing Ad Hoc reports continue to work after switching to NERIS?
Yes. The current data source will be retained indefinitely to support existing reports, as well as historic reporting on deprecated NFIRS fields.
Is there a deadline for switching our existing reports from Incident Report (NFIRS) to Incident Report (NERIS)?
No. Since First Due is maintaining Incident Report (NFIRS) indefinitely there is no deadline to transition off of it.
There may be scenarios where this is necessary or beneficial, such as an existing report you want to incorporate a new NERIS field into, or one that uses an NFIRS field being deprecated and you need to reconstruct it with a NERIS equivalent, but these transitions can be done on your timeline.
I have reports already built off of Incident Report (NFIRS) that don’t involve any deprecated NFIRS fields, or require any new NERIS fields. Will they continue updating with new data from NERIS or stop updating when we switch?
They will keep updating. Because most fields between NFIRS/NERIS are the same (Incident Number, Fire Station, First Unit Arrived, etc.) you will still see data in their Ad Hoc columns from Incident Report (NFIRS) after you switch to NERIS.
Please note, however, that utilizing the new NERIS tables offers additional benefits:
More organized and segmented column lists
Improved column navigation
Improved performance for less complex/granular reports
Pathway to all new NERIS fields
While many reports will continue running on both data sources, we recommend using the new tables for any future reports after switching to NERIS.
Can I continue reporting on deprecated NFIRS columns after switching to NERIS?
Yes. While data at the “record” (row) level is the same in both data sources, the difference will be in the columns they contain. To report on NFIRS fields that did not carry over to NERIS, you can utilize the Incident Report (NFIRS) data source.
In a case where you need to run a single report on data that crosses your NFIRS/NERIS switch, and also needs to incorporate new NERIS fields and dropped NFIRS fields, this will be accomplished using Incident Report (NERIS) and joining NFIRS Deprecated Fields as a child.
In Incident Report (NERIS) why are certain columns placed in different data sources (e.g. Incident Report Fire Fields, Incident Report Property Fields, etc.) when they used to all be a part of Incident Report (NFIRS)?
As Incident Report (NFIRS) grew to incorporate virtually all NFIRS fields having a one-to-one relationship with the incident, it became a very large dataset with nearly 200 columns. This started presenting usability and performance challenges, and the cost came with little benefit to users. Most Ad Hoc reports on Incident Report data involve a small number of frequently used fields, like PSAP Call Date/Time, Incident Type, Address, and Fire Station. The remaining fields are used far less often, with many only relevant to certain incident types, like fire and hazmat.
The adoption of NERIS presented an opportunity for optimization. This new structure provides lighter, faster datasets that are easier to navigate. If your report requires data from Fire, Prevention, Property, or Weather related fields, join one or multiple as children and pull those columns into the report. If not needed, simply leave them out.
I’m an ODBC user and our agency is switching to NERIS. How does this impact the data warehouse?
You will continue having access to the existing f_incident_report table just as you do today, and it will continue populating NERIS-based rows with data in any of the common columns. The switch to NERIS also does not modify the table in any way, so there is no concern for broken pipelines.
To query new fields introduced by NERIS, you will need to use the new tables described in this article. You will also have the ability to create custom data structures with joins on incident_report_id.
As with Ad Hoc, many of your current reporting workflows or ETL jobs likely use common columns that are supported with both tables. Even so, we recommend starting a transition to the new NERIS tables since they will be the focus of ongoing support/enhancement.