Create More Robust Safety Committee Data Analysis SD52/465/466
Currently, participants submit incident reports to the Safety Committee, which then compiles the data and looks for trends in the aggregate (it does a lot more than that as well, but this aspect of its work is onerous). If we connected incident reporting with routes/places and even illustrated on a map, committees could analyze trends and information much more rapidly and wouldn't have to wait for Safety Committee reports. Safety Committee efforts could then be more available for training and prevention work now that the data crunching burden has been reduced. Members and Leaders could then have information about incident "hot spots" available to them in deciding what level of risk they are comfortable with. Data could be filtered by activity, committee, location, type of incident, etc.
KD Dase commented
Separate the near-miss report and incident report. They serve different purposes and require attention and follow-up on a different scale.
Thanks for your feedback Jacob. As we shared in our last update, we are working on inclusion across our organization, and are seeking ways to be sure the behavior complaint form is more visible on the website so it can be used when needed. The E&I Committee hopes to eventually partner with the Safety Committee on ways to incorporate emotional safety into our safety reporting. To keep all of our safety committee improvements stored in one place, we're merging this request with Create More Robust Safety Committee Data Analysis.
Jacob Wolniewicz commented
After an activity, the behavioral complaint form should be also be included with the safety report form. If a member experiences any sort of discrimination we need to have the path of reporting a complaint simple and easy to find.
This is possible and would be a medium-sized project or maybe a big project depending on the needs and desires. It requires:
1. Changing the Incident Report Form from a web form to a content type (i.e. data object in both Plone and Salesforce with a Plone-SF sync of all the fields).
2. Salesforce licensing is staff only, so either a staff person would need to be responsible for incident reporting or we'd have to reconsider Salesforce licensing options and access for key volunteers.
Steve Smith commented
Connecting incident reports to flow into Salesforce would allow us to use reports and dashboards to identify trends in more robust ways. Is this possible for the future?
Mike Courts commented
Below are some draft incident reporting classes/categories we have played around with in the Tacoma Branch Kayaking Club. I think the same thought process could be applied to other activities. From an incident reporting standpoint, I took this concept from my 30 years in Army Aviation. I believe establishing classes or categories of incidents would encourage incident reporting but also help the reading audience understand the severity of the event right off the bat.
Kayak Safety Reporting Classes:
Class A: Loss of Life
Class B: Injury requiring external evacuation/medevac
Incident or equipment damage requiring external evacuation
Class C: Injury not requiring external evacuation but causing internal evacuation
Incident or equipment damage that significantly impacts paddle
Class D: Minor Injury not requiring evacuation
Minor incident or equipment damage that does not impact paddle
Class E: Unintended wet exit requiring self/assisted rescue in a non-training