You’ve put a different design thought into this than I have, but we have similar problems as we transition hazard, near miss, and accident reporting to SafetyCulture.  We too are struggling between various inspection templates and Issues.

My idea to solve for our company:

1. Improve submission of Issues (soon to be Incidents) with things such as requiring site, by category requiring pictures, within categories by question requiring certain ones, and more.
2. Allow the new Analytics the ability to chart Issues by the questions within each category (which might be things like who was injured, what room, what equipment was involved, was an immediate corrective action put in place, etc.).
3. Add access to Issues timeline data feed (chat and questions’ answers) to the Exporter tool and Power BI connector.
4. Add the ability to link Inspections to Issues, but rather than just adding the Inspection, have the question answers, title, description, category, and other fields from the Issue automatically populate data in the inspection you start from the Issue. 

The reason I’m looking at this approach is we are having an internal debate on the following:

• How should we classify hazards simply observed (safety hazard observation), hazards where someone almost got hurt (near miss), and accidents (first aid or more was required)?
• How should we capture the information at the moment it happens to ensure it is not lost or translated incorrectly later (inspection template, Issue, paper, phone call to management)?
  • We have to understand that when it happens there will be little known, and reporting needs to be fast - who was injured, what might be injured, equipment involved, what they were doing before and during, and eyewitnesses.
  • We have to consider HIPAA laws. If reported electronically, do we need to quickly archive the record so other employees/shifts can’t see it (it is just the basic info at that point)?
• How do we notify site management and the corporate safety team of incidents?
  • Depending on the type and severity of incidents, the corporate safety team may not always need to be aware. Most of the time, the site management team should always be made aware.
  • For the “on the fly” as it happens basic info, if we rely on paper or phone calls, the correct people may not always be informed. If we use “Issues” we can better automate notifications. If we use an Inspection template, we can use a question to trigger notifications, but it’s more limited.
• Who will do the investigation after the accident’s basic info was reported and who needs to see it?
  • Most of the time, our Office Managers will be doing the details investigation. In some cases, it is a plant manager, production manager, or someone else. We have people with user accounts that may only exist for accident reporting.
  • We have templates setup with only access by those specific people, and the reports only share to those people and the corporate safety team for HIPAA reasons.
• How should we transfer the basic “on the fly” information to the investigative report?
  • For now, sites are left to capture the “on the fly” info however they want. They have to transfer that to an Inspection template manually.
  • There is a lot of additional investigation that occurs for improvement, corrective action, discipline, and insurance purposes - address of employee, SSN, work hours, training, employment length, job role, state of mind/sleep, etc.
• How do we get the information to our insurance carrier for Worker’s Compensation claims?
  • We can submit claims through a phone call, using their form emailed, emailing our own report, or through and EDI automated process. 
  • For now, our template is setup to capture duplicate information so we can format it exactly how the insurance carrier wants it depending on the method the site will use to report the accident to them.

We are only exploring Issues at a couple sites because of the limitations the feature has. Because we are requiring the template for accident reporting, we’re now left with a large, inconsistent gap. For us, I think those 4 simple changes above would allow us to overcome most of these debates.  Not to say your ideas would not also have additional value for us.

Hey Gary! I’m a product designer here at SafetyCulture. I love this idea and what you’ve proposed.

I’d love to hear more about these two ideas below:

1. User Allocation and Reminders:

   • Assign users to specific sections within investigations.
   • Set criteria-based reminders for overdue tasks.

2. Sequential Progression:

   • Prevent users from advancing to subsequent pages unless previous reviews and sign-offs have been completed.

Ideally, what sections/pages would you want an investigation to include? 

​​​​​​Hello Sasha,

When an Incident is reported, the status of that issue would be “New” and it would capture basic information about an incident. 

The next step - users belong to specific group (e.g. Managers/Supervisors) should be able to change the status to “In Progress” and at this stage, Rate the seriousness of the issue, set “Due Date”, “Assign the issue to specific person”, create actions to address the issue, conduct investigations

Reminders to go out for specfic group when Issue reported stays unassigned for 24 hours or issue is still “In pogress” stage past the due date.

When it comes to sequential progression, 

> “all users” be able to report issues

> “specific group of users” to move issue to “in progress” (and do activites as described above)

> User for whom issue is assigned to move the item to “Submit for review”

>Users belong to H&S manager, Environmental Manager depending on issue category to be able to review the incident actions, investigations etc and close out the incident 

For above to work, Ideally, three stages would be required 
1.New, 2. In Pogress, 3. Under Review, 4. Closed.

Also When an item is under review or closed, specific users (H&S manager, Environmental Manager) should be able to push back the workflow to early stage (in progress) of the investigation is not satisfactory

Having read all the replies in principle I agree with the concept as having an area where it becomes aligned to an EHS system. 

However. 

There some things that I do not align with. 

When using the word Incident. 

What are we defining. 

The user base from the front end need a user tool hence front end workers - this is where issues sits.

I am fine with that. 

In reality though... This is not used in the right manner by personnel at the front end that can scan a QR code and then creatvan issue. 

Which in Adys idea would I assume be picked up in the system. 

It would then be filtered to SC users in the Org. 

These imo would be Managers who again based upon the company should have EHS knowledge. 

Hence we get the filter to escalate in Adys idea into the new Section called Incidents. 

Imo having been involved in Safety for 30 years we need to be careful about the layers we then have an the amount of information we need to review. 

It needs to be relevant. 

Therefore yes HS&E advice / involvement.

However I would prefer another buffer. 

This could be HIPOs. 

High Potential Near Misses. 

These can be potential or actual and are scored based on the actual or potential consequence to the Org with regards to.. 

• Occ Safety
• Environmental
• Assets

This then will define the risk to the business and as Ady suggested required level of control and access via gdpr and confidentiality but still having the ability to enable incident closure process. 

I have seen too many systems develop into an unmanageable tool. 

The scoring of an HIPO therefore is a way for the organisations capability to demonstrate it works. 

What I would like to say is that we are all after the same thing. 

Prevtiin before it happens. 

The HIPO type of system in the Incidents or similar can then be a prevention measure. 

It is how we get the initial report that is the key to this. 

Hope that makes sense, but to be fair we all seem to be singing from similar hymm sheets - so that is a bonus. 

Regards Johnny