Skip to content

Guide

The NERIS data model

NERIS is not a form with numbered boxes. It is a structured record that changes shape depending on what happened. Understanding that shape is most of what makes filing feel less arbitrary.

The one idea that explains the rest

An NFIRS report was a form: the same boxes every time, and you left the irrelevant ones blank. A NERIS incident is a record with modules that switch on according to what the call actually was. A medical call activates the medical detail. A working fire activates the fire detail. Nothing makes you scroll past a section that has nothing to do with your call.

Almost everything people find surprising about NERIS follows from that.

Four things that changed shape

One form with numbered boxesModules that switch on

An incident carries only the modules that apply to it. A medical call does not drag a fire section along behind it. Which modules apply is decided by what the incident actually was.

Numeric codesReadable text codes

Values are strings like STRUCTURE_FIRE rather than numbers you had to look up. You can read a payload and tell what happened, which makes a wrong value obvious instead of invisible.

One incident typeSeveral, one marked primary

A car into a pole with a patient and a wire down is genuinely several types. NERIS lets you say so rather than making you pick the least wrong one.

A flat address fieldA geocoded location

Location is structured and carries coordinates, which is what makes the mapping and response-time analysis possible at all.

How an incident type is written

Incident types are a three-level hierarchy. The levels are joined by a double pipe, and that full string is the value NERIS stores.

FIRE||STRUCTURE_FIRE||ROOM_AND_CONTENTS_FIRE

Category

Group

Specific type

Not every type goes three deep. Some are complete at two levels, and a few are a single value. Those are finished types, not ones you failed to fill in — a distinction that trips up nearly everyone at first. There are 128 types across 7 top-level categories; all of them are in our incident type lookup.

Why rejections are usually one bad value

NERIS validates submitted values against fixed tables. That means the common failure is not a malformed report — it is one field holding a value that is not in the table for that field. A near-miss spelling, a code from the NFIRS era, or a plausible-sounding value nobody defined will all be refused.

This is worth knowing because it changes what you go looking for when a submission fails. The structure is rarely the problem. One value is.

Where the authoritative definitions live

This page explains the shape. It is deliberately not a copy of the schema: NERIS maintains its own reference and a stale duplicate of it would do real harm. For field-level definitions go to NERIS's data dictionary and technical reference.

Our field reference covers the fields we have verified, in plain language, and says which ones it does not cover.

NFIRS to NERIS: what changed · The NERIS API · Incident type lookup

You should not have to think in modules at 3am.

Describe the call out loud and the structure gets filled in for you, shown field by field for you to correct. No account needed to try it.