Incident Investigation & RIDDOR

Incident Investigation & RIDDOR

NexusRMS provides a structured incident investigation workflow that guides your team from initial report through to resolution, ensuring thorough root cause analysis and regulatory compliance with RIDDOR requirements.

Investigation Workflow

Every incident follows a defined lifecycle through four statuses:

1. Reported — incident logged with initial details, date, location, and severity
2. Investigating — an investigator is assigned and the investigation timestamp is recorded
3. Resolved — root cause identified, corrective actions defined and completed
4. Closed — lessons learned documented and investigation formally concluded

Starting an investigation assigns a designated investigator and automatically records the commencement timestamp. The investigation duration metric tracks the total number of days from the reported date to final closure.

Root Cause Analysis

Multiple analysis methods are supported to suit different incident types. The system records the method used, analysis data, and root causes identified:

• 5 Whys — iterative questioning to drill down to the fundamental cause
• Fishbone / Ishikawa — categorised cause-and-effect diagram analysis
• Fault Tree Analysis — top-down deductive failure analysis
• Barrier Analysis — identifies which controls failed or were absent

Witness Statements

Witness statements are appended to a JSON array on the incident record. Each statement captures the witness name, contact details, and their full written statement. Statements can be added throughout the investigation and are preserved as an immutable audit trail.

Corrective Actions

Each corrective action is stored as a JSON entry containing:

• Action description — what must be done to prevent recurrence
• Responsible person — linked by responsible_person_id
• Due date — deadline for completion
• Priority — urgency level of the action
• Status — pending, in_progress, or completed

RAMS Update Tracking

When an incident reveals gaps in existing risk assessments, the rams_update_required flag is set to true. Once the relevant RAMS document has been revised, the rams_updated_at timestamp is recorded — linking incident findings directly back to RAMS document improvements.

Closing an Investigation

To close an investigation, all corrective actions must have a status of completed and the investigator must provide a lessons_learned summary. The system enforces this requirement and will not permit closure until both conditions are met.

RIDDOR Compliance

The Reporting of Injuries, Diseases and Dangerous Occurrences Regulations (RIDDOR) require certain workplace incidents to be reported to the Health and Safety Executive (HSE). NexusRMS automatically identifies reportable incidents.

An incident is auto-flagged as RIDDOR reportable when any of the following apply:

• Severity is classified as major or catastrophic
• The incident involves a fatality
• The injured person requires 7 or more consecutive days off work
• The incident is classified as a dangerous occurrence

RIDDOR-specific fields tracked on the incident record:

Field	Description
riddor_reportable	Boolean flag indicating the incident must be reported
riddor_reported_at	Timestamp of when the report was submitted to HSE
riddor_reference_number	Reference number received from HSE upon submission

The checkRiddor method returns a structured response containing is_reportable, category, and reasons — providing a clear audit trail for the reportability decision.

RIDDOR Report Generation

NexusRMS generates a formatted PDF report suitable for HSE submission. This document compiles all incident details, witness statements, injury classification, and the reportability assessment into the required format.

Notification System

Serious incidents automatically trigger notifications to management through the NotifyHseOfIncident listener. This ensures that relevant personnel are informed immediately when a significant incident occurs, without relying on manual escalation procedures.