Incidents and injuries

Something happened on site that was not meant to. Teralo keeps two records of it, and knowing which one you are filling in is the whole of getting this tool right. An incident is the event: what happened, where, who saw it, what was done about it in the first ten minutes. An injury is the harm to one person: the body part, the mechanism, the treatment, the time lost.

They are separate registers, side by side in the sidebar, because they do not map one to one. An event can hurt nobody and still be worth reporting, and it can hurt three people, who each need their own classified record. An injury can also be recorded on its own, with no incident behind it, which is what you want when somebody reports a strain three days later and there was no event anyone witnessed.

The register is the project's, not your organisation's

Worth knowing before you write anything down. Both registers are project-wide: everyone who can view incidents on the project sees every incident on it, whichever organisation reported it, and the same for injuries. Nothing here is filtered by who you work for. The permission to view is the whole of the control, so decide carefully which organisations get it, and see How permissions work for granting it against a role rather than a person.

That makes the draft state more useful than it first looks. A draft is visible in the register, but nothing has been sent and nothing has started; it is a report in progress rather than a report. Issuing is the event that puts it in front of people, by emailing the distribution list. So the distribution list is the mechanism rather than a courtesy copy, and an incident issued with an empty distribution list has been filed but not reported.

Both registers behave like every other register in Teralo. See The register screen for the filtering, grouping and saved views that work the same everywhere.

Reporting an incident

Open Incidents and choose New Incident. Your own name, position and contact details are filled in as the reporter, and all three stay editable, because the person typing is often not the person who saw it.

The core of the form is short on purpose: the incident type, when it happened, where on site, and a description of what happened. The location comes from the project's location tree, the same one inspections use, so an incident is filed against a room or an area rather than a typed-in place name.

Underneath that, fill in what you have. Immediate actions taken is what was done at the time, and written while it is fresh it is the part a regulator reads first. Injuries and observations can be linked or created without leaving the form. Attachments take documents, photos, whiteboards, mail and direct file uploads.

Every change to an incident is written to an activity trail, so the record shows not just what it says now but when each part of it arrived.

Witnesses and interviewed persons

Two separate lists, and the difference between them is the point. Witness details records the name, contact and comments of each person who saw it happen. Interviewed persons records who was spoken to afterwards, which is not the same set: it usually includes a supervisor who arrived later and excludes the visitor who has gone home.

Notifying an authority or the client

Where an incident is notifiable, record it as such: whether the authority was notified, the date, which authority, and the reference number they gave you. That reference is the one thing in this form nobody can reconstruct later, so capture it on the call. The same four fields exist for notifying the client.

Root cause and preventative actions

The root cause and what will be done to stop it happening again. This section is almost always filled in days after the rest, once somebody has looked properly, and an incident whose root cause still says what the description says has not been investigated yet.

Draft, then issued

Save Draft keeps the incident editable and sends nothing. Save & Issue publishes it.

Issuing does four things in one transaction: it stamps who issued it and when, it moves the status to Issued, it emails the distribution list, and it starts the workflow bound to the incident's type. It cannot be undone. There is no un-issue, no return to draft and no second issue of the same record, which is deliberate: an incident report that could be quietly withdrawn after it had been circulated would not be worth much as a record.

So there is no hurry to issue. Leave it in draft while the details firm up, because that is the only stage at which the wording is still yours alone to change.

The distribution list

Who gets the email when the incident is issued. It is set on the incident itself rather than inherited from a project-wide setting, because the right audience for a near miss on level three and the right audience for a notifiable event are not the same people.

Set it before issuing rather than after. Adding somebody afterwards puts them on the record but does not send them the notification they missed. Injuries carry their own separate distribution list, for the same reason.

Under investigation, and closed

Draft and Issued are written by the act of saving. The two statuses after them, Under investigation and Closed, are written by the workflow bound to the incident type rather than by anyone choosing them from a menu.

That has a consequence worth knowing. An incident type that genuinely needs no investigation is bound to a workflow that does nothing, and its incidents come to rest on Issued and stay there. An incident type that does need one moves to Under investigation the moment it is issued, and reaches Closed when the workflow's last step is signed off. So the status tells you where the investigation is, not merely whether somebody has typed something.

Incidents do not appear in My Items. Where an investigation step is waiting on you, it appears in Waiting on you on your dashboard, alongside the approvals waiting on you elsewhere.

Recording an injury

Injuries have their own register and their own New Injury form, and one can be created straight from an incident, which links the two.

The form asks for the person first: what kind of person they are (an employee, a subcontractor's worker, a visitor, and whatever else your organisation has configured), which organisation employs them, and their name. Then the shift: when it started, when it ended, and what they were mainly doing. Then the injury itself, on the day and time it happened, classified against five lists:

• Nature of injury, what kind of harm it is
• Bodily location, the part of the body
• Mechanism of injury, how it happened
• Injury agency, what was involved
• Treatment type, what was given

Each of the five takes more than one value, because real injuries rarely fit one box. The last field is lost time, which takes yes, no, or to be confirmed, and "to be confirmed" is the honest answer on the day far more often than the other two.

An injury goes from draft to issued the same way an incident does, and issuing notifies its own distribution list. Unlike an incident it runs no workflow, so it has no statuses beyond those two.

When a finding needs work rather than a record

An incident often turns up something that has to be fixed rather than merely written down. Raise it as an observation, which carries an assignee, a due date and a close-out, and keeps a link back to the incident it came from. The incident stays the record of the event; the observation carries the work.

SettingsHost only

Incidents and injuries are configured in two separate places, and both exist at organisation level and project level. See Organisation level and project level for what that split means in general, and The tools catalogue for how a tool is turned on.

Tools, then Incidents holds the incident types. A type is a name, a description and, crucially, the workflow bound to it. Types written at organisation level are shared across the organisation and switched on per project; types written on a project belong to that project alone. Write them at organisation level unless a project genuinely needs a category nobody else does, because reporting across projects only works if two projects mean the same thing by "near miss".

Tools, then Injuries holds the five classification lists above plus the injured person types, each of them an organisation-level list activated per project. These are worth setting up before the first injury rather than after it, because reclassifying historical records is nobody's idea of a good afternoon.

The incident types are drawn from the project's host organisation, so a guest reporting an incident chooses from the host's list rather than their own.

PermissionsHost only

Four permissions cover both registers together, because injury classification is incident reference data rather than a tool of its own:

• Can view incidents shows the sidebar items and both registers
• Can create incidents allows new incidents and injuries, and saving drafts
• Can manage incidents allows editing, issuing and configuring the tool settings
• Can permanently delete incidents is separate, and is deliberately not implied by managing

That last split is the one to be careful with. Deleting an incident removes the record and everything hanging off it, including the activity trail that proves what it said, so grant it narrowly. See How permissions work.

WorkflowsHost only

Every incident type must have a workflow bound to it, and an incident cannot be issued until one does. This is a hard requirement rather than an option, and it is the one piece of setup that will stop somebody mid-report if it has been skipped.

Where a type needs no investigation at all, bind it to the seeded No sign-off required workflow, which starts and finishes in the same instant. That is the right answer rather than a workaround: leaving the binding empty gives the reporter an error at the worst possible moment, and the empty workflow leaves the incident resting on Issued, which is exactly what a type with nothing to investigate should look like.

Anything more than that is built in the workflow builder and attached as described in Binding a workflow to a tool. Injuries take no workflow at all.