Introduction
The Incident module involves a fair amount of background set up but when done correctly it should make investigators' jobs much easier!
Glossary:
Cause Set: the incident cause tree, based on RSSB standards and used to add causes to an investigation.
Incident Properties: the fields that investigators need to populate to inform an investigation.
Respondent: a person involved in an incident.
All of the tasks below are completed in Menu > Reference Data > Incident
Cause Set
The list of causes which can be attributed to an incident. A bespoke cause set can be created, however typically we follow the standards outlined in the RIS-3119-TOM. AssessTech can copy the RIS-3119-TOM cause set on to systems so that it doesn't have to be manually built.
It's possible to make certain causes mandatory for each investigation by setting up 'Required' root folders. Different causes can be set up to also require an assigned respondent. For example, an unsafe act should be assigned to a respondent, however an unsafe condition should not be.
Much like criteria sets, 'Sealed' cause sets are those which can be assigned to investigations whereas 'Influx' cause sets are in an editable and therefore unusable state.
Incident Category
Categories can be set up to categorise different incident types. Required information to complete an investigation is defined at this level, as well as the necessary cause set.
To make a tab optional for an incident category, tick both the required and optional boxes. To make a tab mandatory for an incident category, only tick the required box. The tabs will always be displayed within investigations but the optional/mandatory configuration alters whether or not investigations can be completed without certain pieces of information.
Incident Property Type
Incident properties are the fields used to collect the information necessary to inform each investigation. Typically we replicate the fields used on pre-existing investigation forms.
There are a number of different property types - text, number, list, date, time, datetime.
It's not yet possible to make certain properties mandatory, however it's the responsibility of the DCP to ensure that all of the required information has been collected before an investigation is closed.
New Incident Properties are added by selecting 'Add' under the admin which opens the page shown below. There are a number of different property types - text, number, list, date, time, datetime. Depending on which type is selected, the mandatory fields will change.
Make sure to set the status of any properties to 'Sealed' so that they can be applied to investigations.
Incident Respondent Property Type
Respondent Properties are properties that are associated with individuals rather than the incident as a whole. For example, different drugs and alcohol test results may need to recorded for each respondent.
New Respondent Properties are added by selecting 'Add' under the admin which opens the page below.
Make sure to set the status of any properties to 'Sealed' so that they can be applied to investigations.
Investigation Type
Different types of investigations can be set up and assigned to incident categories based on incident severity. To add a new investigation type, select 'Add' under the admin and the page shown below will open.
A number of different things are defined at this level:
Investigation length (days) - this is the number of days the investigation should be completed in from the time it was started. Investigations that go beyond the set days will be displayed as 'Overdue' on ACMS.
Default report type (upload/generate) - there are two ways that investigation reports can be uploaded in ACMS
- Generate: ACMS will generate a report based on the information that the investigators have input on the system
- Upload: this allows users to upload a report from their computer
- Report - the report template used for the generated ACMS report
Incident category - the incident category that the investigation type applies to
Same Lead and DCP (yes/no) - this dictates whether a user can apply the same person to be the Lead and DCP of an investigation.
Incident Type
Incident Types can be set up to outline the different types of incidents that will be investigated on ACMS. To edit add a new Incident Type, select Add under the admin. This will open the pop up shown below.
- Name/Description
- Default Investigation Type - dictates the investigation length and default report for the incident type
- Status - controls whether the incident type can be used for new investigations
- Category - assigns the incident category and therefore the mandatory information for the particular type of incident in question
- Evidence guidance - additional guidance for the evidence that is required for the incident type
Properties and Respondent Properties can be assigned by dragging them from the 'Unassigned' section to the 'Assigned' section.
If you add a new incident/respondent property to an already sealed incident type, the property will display on all open and future incidents/investigations. The property will not appear for closed incidents/investigations.
Recommendation Category
Recommendation Categories can be set up so that recommendations that derive as a consequence of an investigation can be categorised into different types based on a pre-defined list. For example, Recommendations and Local Actions.
This is an optional feature, the default Recommendation Category is simply 'Recommendation'. All that is required to add a new category is a Name and Description.
Remit Item Type
Remits can be set up so that investigators can add them to investigations.
There are two types of Remits on ACMS; locked or unlocked:
- Unlocked remits are editable by investigators, for example to add information specific to the investigation in question e.g. the name of the Lead investigator.
- Locked remits are uneditable
To add a new Remit, select 'Add' in the admin. The 'Description' field is used to outline the content of the Remit and typically editable sections of unlocked remits are indicated with square brackets.
Post Incident Decision Type
Post incident decision types can be set up so that they can be added against a candidate as as marker, which gives an indication of the recommended course of action for this person, should they have an incident.
Examples:
- Low
- Medium
- High
Importing Incidents and Investigations
Historic incidents can be imported into ACMS using the importer linked below
In 5.2.3f we also have a new investigation workflow which can be used to import historic investigations, including all properties.
Configurable Features:
- Weather condition → The condition type which defines the available values for weather condition properties within incidents.
- Chief only → Disables the need for users to have chief duties in order to add and incident, add a historic incident, add respondents to an incident that it yet to be investigated and to start an investigation.
- Exonerated Filter → Defines the default filter applied to the incident tab on the candidate dashboard.
- Show Category Column → Defines whether the incident category column is displayed by default in the incident admin.
- Show Respondent Column → Dictates whether the respondents column is displayed by default in the incident admin.
- Expand Cause set → Cause sets are displayed in a folder structure within investigations. ACMS can be configured to either expand or collapse the cause set folders within an investigation.
- Get Mine Default → The investigation admin can be filtered by default to show only display investigations assigned to the logged in investigator or all investigations that they have permission to see.
- Investigation Report URI (AssessTech only) → The default report format used when generating an investigation report. It is possible to assign the other report formats at the investigation type level e.g. more detailed report for formal investigations.
- DCP Edit Complete → Dictates whether a DCP is able to edit completed investigations without needing to re-open them.
- Use Completed Plug in → The completed plug in adds a tick next to investigation dashboard once the mandatory information has been filled out.
- Use Investigation Auto Save → It's possible to enabled background investigation auto save functionality.
- Auto Save Expiry → Defines how often the autosave occurs in milliseconds
Useful Reports
We have many incident and investigation reports, here are a few examples:
- N1 Incident Property - displays incidents according to the date range and property entered in the input controls. This allows users to report on incidents which include a particular property e.g. TPWS.
- N1.4 Period End Date - lists all incidents that have occurred within the given date range.
- N2 Incident Summary - lists all incidents according to the selected status (Open, Closed, All).
- N3.1.1 Incident Report (Weekly) - this report is designed to be sent to recipients weekly as it lists all incidents that occurred during the previous week.
- N5.1 Incident List with Causes - lists all incidents with causes
Useful Widgets
Incident
Displays the number of incidents and their current state on ACMS. When you click on the widget, the Summary section as the top of the page displays a count of all incidents on ACMS sorted by Incident Category and status.
Investigation
This widget is much the same as the Incident widget, however it specifically shows a count of the investigations which are assigned to the logged in user (unless they have chief access) and their states. When you click on the widget, your assigned investigations will be listed.
FAQs
If an incident is raised by accident, can it be deleted?
Yes, an AssessTech user can delete the incident but we will require the request on a Redmine ticket.
Is it possible to make Incident Properties mandatory for certain Incident Types?
Not yet but this has been requested by a number of customers and we have targeted this feature for the 5.2.3g release.
Can the investigation tabs be re-labelled?
Yes, all of the tabs are localisable, just let us know what you want them to be changed to.