All incidents and investigations can be viewed using the Incident and Investigations Workbench. The workbench has two views:
Once an incident or investigation is selected, the user can move to the detail screen, which has tabs for all the different stages of an investigation.
An important part of an investigation is determining the causes of an incident. Train operating companies use different causation models according to their own standards.
Causes on ACMS are modelled using ‘cause sets’. A cause set that represents the RSSB standard is provided by default. This can be used directly, edited to match a custom standard, or abandoned in favour of a completely different custom set.
Cause sets are a tree of related causes with guidance notes, that help the investigator choose the most appropriate causes for an investigation. Cause sets can have as many items and nested levels as required, and the guidance notes are completely customisable.
Companies need to manage different categories of incident and produce reports and statistics based on these categories. Typically, TOCs use these categories:
Incident categories are configurable.
Incident properties are used to capture the data about an incident, in a way that allows for granular searching and reporting. Incident properties can be recorded, against the incident as a whole, or against individuals involved in the incident. There are many default properties available in ACMS, examples of properties recorded against incidents as a whole are:
Examples of properties recorded against individuals are:
If these properties do not meet the need, then there is also a facility to add custom properties.
Incident types allow an organisation to configure a name for a specific type of incident, such as a ‘Fail to Call’ or ‘Platform Incident’ and dictate what pieces of information (incident properties) should be collected for that type of incident. Incident Types belong to Incident Categories.
The Incident Type Admin screen is a matrix of tick-boxes, allowing selection of all the different incident properties, for each incident type. It also allows for the selection of a default ‘Investigation Type’ for each one.
Investigation types allow the modelling of different investigation processes for different incident types. So, for example, a minor incident might need only 7 days to be completed and require a simple report, whereas a major incident might need much longer and require a more complex report.
Custom report templates can be created on a per Investigation Type basis.
Investigation remits can be created and issued by ACMS using a combination of pre-defined, boilerplate text, and custom information.
Only authorised investigators have permission to edit investigations. There are four levels of authorisation on ACMS as follows:
This allows granular control of who can modify what.
A Post-Incident Decision (PID) can be set against a candidate in the system. This is simply a marker, which gives an indication of the recommended course of action for this person, should they have an incident. There are three levels of PID (LOW, MEDIUM and HIGH).
The names for these levels are customisable.
When the Incident module is activated a tab appears on the candidate dashboard that enables users with appropriate security privileges to find all the incident data relevant to a particular candidate.
When the Incident module is activated a tab also appears on ‘My Page’ so that candidates can see their own incident data.
There are many standard reports associated with the Incident Module. These include, but are not limited to:
There are also individual reports, for just one person, available from the candidate dashboard:
These are often useful as contributing evidence in an investigation.
Custom reporting and bespoke dashboards are available.