Why NIBRS readiness starts before the submission.
The NIBRS-Ready RMS Series
When NIBRS rejects submissions
The fault In the RMS workflow
When a NIBRS submission is rejected, the problem appears to be at the end of the reporting process.
Often, it began much earlier.
Perhaps an offense was mapped incorrectly.
A required relationship was not captured.
Property information was incomplete.
An arrest was entered differently than the reporting rules expected.
A state-specific field was missing.
Or the RMS allowed a record to travel too far through the workflow before alerting anyone that something was wrong.
That is why one of the most important principles of NIBRS readiness is this:
The quality of the submission begins with the quality of the original record.
NIBRS begins with the incident
NIBRS is designed around detailed information about individual crime incidents and the offenses associated with them.
The FBI describes it as an incident-based system that captures considerably more context than aggregate summary reporting.
For an agency, this means everyday records activity becomes part of the reporting process.
Consider the path of one incident.
An officer records what happened.
The officer selects offenses.
Victims, known offenders, or other involved people are attached.
Property is entered.
A location is saved.
An arrest may occur.
The report is reviewed.
Corrections may be made.
Only after all of those steps does the information eventually become part of a NIBRS submission.
The submission file is therefore the output of an operational workflow.
If the workflow is difficult, fragmented, or inconsistent, the reporting process inherits those problems.
The risk of creating a second workflow
The more separate processes an agency creates, the harder it becomes to maintain consistency.
Enter once. Use throughout.
A better approach is to make information collected for agency operations useful for reporting as well.
When an officer enters incident information, those data should support the eventual NIBRS record.
When property is entered, that information should flow into the applicable reporting structure.
When an arrest is recorded, the RMS should use the arrest data that already exist.
When a location is saved, available geographic information should remain associated with the record.
This creates a simple operational principle:
Enter the information once. Use it throughout the reporting process.
That does not mean every NIBRS requirement disappears.
It means the RMS should reduce unnecessary duplication wherever possible.
Officers should document the incident—not reconstruct it for NIBRS
Officers already have an important job in the NIBRS process.
They must accurately document what happened.
That may include:
What offenses occurred
Who was involved
Relationships among the people involved
Whether property was stolen, damaged, or recovered
Whether weapons were involved
Whether an arrest occurred
Where and when the incident occurred
Other facts necessary for classification and reporting
Those facts require human understanding.
But once the information has been accurately entered, users should not have to reconstruct the same incident solely to satisfy a second reporting interface.
A well-designed RMS should reuse reliable source data wherever possible.
The RMS should help prevent errors earlier
Re-entering the same information simply because the RMS separates operational records from NIBRS reporting is not.
Records personnel should review quality, not re-type reports
A transition-ready RMS should therefore help identify missing or inconsistent information while the record is still moving through the normal agency workflow.
NIBRS readiness is workflow readiness
Questions agencies should ask
The answers will reveal far more about operational readiness than a simple NIBRS checkbox on a feature list.
The goal: make NIBRS part of records management
What reporting complexity should the RMS actually handle for the agency?
Is your current RMS ready for what comes next?
