QUASR results from a decade-long experience working in the incident and risk management space across industries. Through that experience, we saw the specific difficulties that the healthcare industry suffered from using generic products altered to suit their needs. We didn’t want to be presumptuous either. So we spoke to many industry leaders across the region, of hospitals of different sizes, and across roles and functions. One common feedback we received early on was the need for “anonymous reporting”.
As the name suggests, anonymous reporting is when an incident report is not attached to any particular user/staff in the system. Many hospitals felt the need for such a system to ensure more participation from all staff. While every hospital works very hard to provide a safe space for all its staff, fear is irrational. While the purpose of incident reporting and management is to improve organizational quality and safety, it isn’t easy to convince their staff that reporting an incident will not lead to repercussions.
Generally, anonymous reporting is employed only for whistle-blowing. And whistle-blowing is typically associated with grave issues in the organization. Incidents, on the other hand, whether grave or silly, are valuable sources of lessons and improvements for the organization. Secondly, coming from a computing background, we understand that genuinely anonymous is somewhat difficult to guarantee. It is usually possible to narrow it down to a small list of people! But not everyone realizes this. So we did not want to design a solution that would potentially blindside a staff. After all, the only guaranteed way to drive away any fear of repercussions is to build trust.
The other problem with anonymous reporting is: we cannot enable many user-friendly and time-saver features like multi-stage captures, draft retrievals, and the like. We are forcing the user to fill in a, typically, long incident form in a single sitting. Hospital staff is usually amongst the most time-crunched workers ever. Expecting them to block off time to report incidents will deter them from actually reporting any minor or near-miss incidents at all. For the organization, though, the near-miss or minor incidents are where the wealth of inputs are lost. Additionally, the quality managers and investigation teams do not have any starting point for conducting further assessments on the incidents — assuming they do not know who reported the incident.
At QUASR, we aren’t thrilled with anonymous reporting. We strongly feel that making incident reporting anonymous does not enable our customers with the right tools to improve their overall culture. After many discussions internally and externally, we arrived at what we call the “pseudo-anonymous” reporting or the “Protect” feature. This feature is available as standard and out of the box for all our enterprise customers. Lite does not support this feature. For Basic, we will wait to hear from you before enabling support for this feature.
To report an incident in the pseudo-anonymous mode, the staff user must first log in to the system. The reported incident is internally attached to the user. However, QUASR will hide this information from most stakeholders of the incident. QUASR will show the reported user as “PROTECTED” instead of their actual name. This way, the user’s identity is protected from the rest of the system. We believe this enables them to report without any fear of repercussions.
Like we mentioned, this mode is not an anonymous reporting mode. Typically, only Quality Managers will have access to the reporting person’s identity. Accessing the identity ensures that the quality teams can proceed to facilitate further investigations without much difficulty. Additionally, in places where a user trusts their supervisor, they can allow access to their supervisors. In most installations, only quality managers and optionally supervisors have access to the identity for protected incidents.
When users choose to report an incident with “protection” enabled, they have to read and understand their choice. There is an inline explanation of the behaviour of the “protect” mode and allows the user to make a conscious choice. This additional step acts as a deterrent to using this mode unless necessary. We do not want the staff to abuse this option — even though it is not entirely anonymous, it does complicate the investigation process. It limits the options available to the quality management teams.
Advantages of Pseudo-Anonymous Reporting
The main advantages of pseudo-anonymous reporting or protected mode are as follows:
- It allows users to report an incident without being anonymous and still protecting their identity from the larger group.
- It enables quality management and investigation teams to perform meaningful analysis of the incident without revealing the reporting person’s identity. For anonymously reported incidents, it isn’t straightforward to get a significant investigation done from the report. Quality teams are left to make reasonable assumptions and proceed, which doesn’t lead to preferred outcomes.
- It enables the organisations to set the right precedent in terms of their follow up actions to assure the staff that incident reporting does not lead to punitive measures.
Disadvantages of Pseudo-Anonymous Reporting
There are no silver bullets. And our solution is not without its limits. The main disadvantages of our approach are:
- The staff must trust their quality managers to do the right thing. As we noted, this is not an easy task for the hospitals or the quality departments to achieve amongst all their staff.
- Our solution targets Clinical incidents. However, many of our customers choose to track other incident categories as well. For a selection of HR-related issues, the pseudo-anonymous mode is not a good solution. It might worsen the situation for the staff.
- Some incidents need to be whistle-blown for real change to occur. These are usually severe issues within the organisation that pervade the entire structure. Pseudo-anonymous mode is not an answer to these types of problems.
We worry that enabling users with this mode gives them a false sense of security in the wrong situations! One of the purposes of this blog post is to educate our users on using this mode responsibly.