quasr-logo-header
TRY QUASR FOR FREE

Tag: features

QUASR Feature: Pseudo-Anonymous Reporting

Abishek Goda

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”.

anonymous-reporting

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 are 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.

Pseudo-Anonymous Reporting

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 anonymus reporting mode. Typically, only Quality Managers will have access to the reporting person’s identity. Accessing the identity ensures that the qualty 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 behavior 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:

1. It allows users to report an incident without being anonymous and still protecting their identity from the larger group.

2. 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.

3. It enables the organizations 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:

1. The stff 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.

2. 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 soluion. It might worsen the situation for the staff.

3. Some incidents need to be whistle-blown for real change to occur. These are usually severe issues within the organization that pervade the entire structure. Peudo-anonymous mode is not an answer to these types of problems.

QUASR Feature: Sensitive Incidents

Abishek Goda
QUASR-Feature-SensitiveIncidents-Header

One of the core tenets of QUASR is transparency and knowledge sharing. In some sense, these two go hand in hand in most cases. Knowledge sharing happens when there is transparency within the community or organization. Incident Management is an essential first step to many organizational improvements. Pro-active Risk Management uses Incident Management as one of its drivers, for instance. Awareness of the incidents that occur in the hospital helps the management plan their mitigation and ensure they do not affect their facility’s overall quality and safety. Similarly, tracking and investigating incidents usually gives valuable inputs to quality and safety policy that every institution’s staff is aware of intimately.

Incidents, sometimes, have information that cannot be widely disseminated or discussed across all staff. We can identify many reasons why this is the case: maybe the people involved are highly placed individuals in the society; perhaps the event has a far-reaching impact if mishandled, or maybe there are legal reasons to restrict the audience. General dissemination of such information can lead to gossip or widespread speculation. In the era of viral social media, the organization may be dealing with a PR nightmare while managing the actual issue or incident. Besides, such speculation can also cause unintentional and unfounded concerns to staff or patients.


It is, then, only natural that Senior management and Quality Managers will want to restrict the audience of specific incidents to a select staff only.  

Sensitive Incidents are the digital equivalent of a “Private & Confidential” document of the paper-office era.

Sensitive Incidents in QUASR

We, at QUASR, recognize this problem very well. While we want to build a transparent, knowledge-sharing platform, we also want to enable our customers to restrict information to a restricted group of staff as the need arises. This feature is a standard feature built into QUASR and is available for all BASIC and Enterprise plan customers.

The LITE plan does not include this feature since the plan only targets a closed group of users within the larger institution. If enough customers feel LITE should have this feature, we will enable it for that plan.

Sensitive Incidents in BASIC

In BASIC, any user with sufficient privileges can mark an incident as Sensitive. Sensitive incidents in the BASIC plan have a fixed behaviour for all our customers. Only users with the privilege to view such incidents are allowed to view all parts of the incident. Other users can only access the basic incident information and supervisor review information. Similarly, access to widgets is also limited to users with access to sensitive incidents. Only users with sensitive incident access can attach files, invite other participants, and add new notes to such incidents.

Sensitive Incidents in Premium

The premium plan has two significant differences from the BASIC plan. In the premium plan, the sensitive feature is in quality manager access. By default, the quality manager is the only role that can mark an incident as sensitive. The Quality Manager role is the primary stakeholder in the premium plan for incident management, hence this decision. However, it is possible to configure and extend this to other roles at the time of implementation.

Secondly, we implement the sensitive feature as a “flag” in the system. Doing so allows us to extend all the additional benefits of the flag to the sensitive flag. Flagging an incident adds a visual cue to the incident view to indicate the flag. It also notifies a predefined set of stakeholders about the occurrence of a sensitive incident. Additionally, these predefined stakeholders automatically gain access to the incident — even if they are not initially involved in the incident. We will dedicate another post in the future to discuss the flag system in QUASR.

Premium and BASIC versions treat the access to the incident information similarly. Whereas the role and its permissions determine the behavior in BASIC, Premium restricts access to Quality Managers, Administrators, and Management roles. Again, in Premium, it is possible to configure this behavior to the organization’s specific needs

Striking A Balance

In QUASR, by implementing this feature, we forgo transparency and open communication. However, we believe we have struck a middle ground between restricting access and openness. The primary incident information remains accessible to all staff at all times. Only the more advanced information like Quality Review or Investigation and RCA details are unavailable to all users. We believe this still allows all stakeholders to stay updated on all their concerning incidents in the organization.

How does your organization handle sensitive incidents? Whether you use a manual or a paper-based system or a digital system to manage your incidents, please let us know your thoughts and suggestions on this feature.

You can reach us on Twitter or Facebook