NERIS introduces a fundamental update to Incident Types that changes the way they are stored and structured in First Due, and may require adjustments to how your agency reports on them.
NFIRS Incident Types
In NFIRS, one Incident Type is required for each Incident Report.
Types are represented using a Code (e.g. 320) and a Description (e.g. Emergency Medical Service Incident, Other).
We can also categorize types at a higher level. In First Due, we refer to this as the “Incident Type Series” (e.g. 100 - Fire, 200 - Rupture/Explosion, 300 - Rescue & EMS, etc.).
NERIS Incident Types
NERIS increases the number of Incident Types that can be applied to a single incident, and updates the structure/values of the Incident Types themselves.
Instead of having to choose one per incident, agencies can now add three.
Primary Incident Type
Secondary Incident Type
Tertiary Incident Type
Each NERIS Incident Type also breaks down into three segments.
Group
Sub Group
Type Description
Each segment represents a data point we can use for analyzing incident data.
Impacts in Ad Hoc
NOTE: For detailed information on how Ad Hoc was adapted for NERIS, see the article NERIS Reporting in First Due: Overview & FAQ. If any of the following in this section is not yet available in Ad Hoc, please refer to the “Release Timeline” section of that article.
Once your agency switches to NERIS you will see data for the new Incident Types populating in the Incident Report (NERIS) data source. Each type level has a column for it’s three distinct segments.
Primary Incident Group
Primary Incident Sub Group
Primary Incident Type
Secondary Incident Group
Secondary Incident Sub Group
Secondary Incident Type
Tertiary Incident Group
Tertiary Incident Sub Group
Tertiary Incident Type
To report on NFIRS Incident Types you can use the Incident Report (NFIRS) data source. You can also use Incident Report (NERIS) and join NFIRS Deprecated Fields to create a unified dataset with both current and deprecated columns.
Because NFIRS/NERIS Incident Types are different, both in terms of structure and value sets, they cannot be stored together in the same column without affecting data integrity.
Reporting on NERIS Incident Types
Incident Type is one of the most frequently used fields in Ad Hoc, and is central to how many departments report on incident data. For most applications, NERIS Primary Incident Type can be used in place of NFIRS Incident Type and NERIS Primary Incident Group can replace NFIRS Incident Type Series.
The NERIS update also provides more flexibility than what was previously possible with NFIRS. Combined with core Ad Hoc features, NERIS Incident Types can be used for deeper analysis and more complex reporting logic.
Combine Group & Sub Group for Detailed Breakdowns
Create multi-row summary reports with granular breakdowns of each Incident Type Group by Sub Group.
Analyze Incidents Using Types at Each Level
Apply conditions to Primary, Secondary, and Tertiary types in one go to find any incident that had a certain component (e.g. Medical), even if the more pertinent type was something else.
Leverage Criteria with Advanced Order of Operations to Apply Complex Inclusion Logic
Combine “AND/OR” conditions in Criteria across multiple dimensions of Incident Type level (Primary, Secondary, Tertiary) and Incident Type category (Group, Sub Group, Type) to return the exact incidents you want to see.
Reporting Across the NFIRS/NERIS Transition
Many agencies will want to find ways to report on Incident Type across their NFIRS/NERIS switchover date, especially for retrospective reporting in 2025.
In terms of data inclusion in tabular reports, this is easily handled in Ad Hoc. Both the Incident Report (NFIRS) data source and the new Incident Report (NERIS) data source will contain all past/future data at the row level, regardless of which form it came from. NFIRS Incidents Types will continue to be available in Incident Report (NFIRS). If using Incident Report (NERIS), you can join the child data source NFIRS Deprecated Fields to create a large unified dataset of new NERIS columns and deprecated NFIRS columns.
For example, you could use NFIRS and NERIS columns together in the Criteria of a single Ad Hoc report to get specific Fire incidents based on the respective Incident Type version.
Limitations to Historic Reporting
Reporting on NFIRS/NERIS Incident Types as a single concept, or column, presents challenges. These are described below.
1. Combined Storage Approach 
Using the same column to store either the NFIRS Incident Type or the NERIS Primary Incident Type, depending on which version of the form the record came from, would present data integrity issues that would impact reporting. Essentially, two separate value sets representing the same concept of “incident type”. If you had, for example, a summary report that counts calls by type, you would have separate groupings for “111 - Building Fire” and “Fire - Structure Fire - Structural Involvement”, which represent the same thing.
2. Mapping Approach
“Mapping”, or migrating an equivalent NERIS Incident Type into historic NFIRS records, is a more sound approach from a data perspective, and we can evaluate it for each segment of the NERIS Incident Type.
Mapping: Type Level
NERIS provides a “crosswalk” for context on how prior NFIRS types relate to NERIS ones. Unfortunately, it does not provide a 1:1 mapping between NFIRS and NERIS types. For example:
NERIS Group | NERIS Sub Group | NERIS Type Desc | NFIRS Crosswalk |
Fire | Outside Fire | Construction Waste | 141, 142, 143, 140, 150, 151, 152, 153, 154, 155, 160, 161, 162, 163, 164, 170, 171, 172, 173 |
Fire | Outside Fire | Other Outside Fire | 141, 142, 143, 140, 150, 151, 152, 153, 154, 155, 160, 161, 162, 163, 164, 170, 171, 172, 173 |
Fire | Outside Fire | Outside Tank Fire | 141, 142, 143, 140, 150, 151, 152, 153, 154, 155, 160, 161, 162, 163, 164, 170, 171, 172, 173 |
Fire | Outside Fire | Trash / Rubbish Fire | 141, 142, 143, 140, 150, 151, 152, 153, 154, 155, 160, 161, 162, 163, 164, 170, 171, 172, 173 |
Fire | Outside Fire | Vegetation / Grass Fire | 141, 142, 143, 140, 150, 151, 152, 153, 154, 155, 160, 161, 162, 163, 164, 170, 171, 172, 173 |
Fire | Outside Fire | Wildfire - Wildland | 141, 142, 143, 140, 150, 151, 152, 153, 154, 155, 160, 161, 162, 163, 164, 170, 171, 172, 173 |
Fire | Outside Fire | Wildfire - Urban Interface | 141, 142, 143, 140, 150, 151, 152, 153, 154, 155, 160, 161, 162, 163, 164, 170, 171, 172, 173 |
Fire | Outside Fire | Utility Infrastructure Fire | 141, 142, 143, 140, 150, 151, 152, 153, 154, 155, 160, 161, 162, 163, 164, 170, 171, 172, 173 |
Fire | Outside Fire | Dumpster / Other Outdoor Container Fire | 141, 142, 143, 140, 150, 151, 152, 153, 154, 155, 160, 161, 162, 163, 164, 170, 171, 172, 173 |
The 10 new NERIS types in this table all map to the same set of 19 NFIRS types, and vice versa. This means a 114 - Chimney or Flue Fire, Confined To Chimney or Flue or a 172 - Cultivated Orchard or Vineyard Fire could map to any one of these NERIS types. And a NERIS Utility Infrastructure Fire could be any one of these NFIRS types, even though NFIRS had no real equivalent.
Mappings at this level would be imprecise and subjective.
Mapping: Sub Group Level
While an NFIRS/NERIS Sub Group mapping is closer to being possible, it is still incomplete and would not meet the data integrity standards users expect.
Some Incident Type Groups are close to having a Sub Group mapping (e.g. Fire, Hazardous Situation), save for “Other” types. NFIRS utilized many of these, such as 100 - Fire - Other and 400 - Hazardous Condition - Other. In NERIS, “Other” types have largely gone away, leaving these NFIRS types with no equivalent to map to.
Other Groups, like Medical, have more significant challenges. NFIRS had ~6 types related to medical incidents which were broad and non-specific to clinical disposition. NERIS adds 46 clinically-specific medical types that break down into the Sub Groups Illness, Injury/Trauma, and Other. NFIRS types lack the detail required for mapping to these Sub Groups.
Mapping: Group Level 
Migration at the Group level is possible and has been mapped out by First Due’s Reporting team. We are currently exploring solutions to achieve this type of reporting that would benefit both Ad Hoc and ODBC users.