fbpx

Participation Matters!

Abishek Goda

Active participation is an essential ingredient of all successful systems. Incident or Risk management is no exception to this. In this article, we understand why active staff participation is critical to all successful implementations. We will also explore a few ideas on how you can leverage this in your systems as well. Lastly, we add a note on how QUASR achieves this for you in the Incident Management space.

Participation-Matters

Participation

Active participation, we define, is the level of engagement users have with a system. In an incident management system, this can be the familiarity and comfort that users have to report an incident or an issue using the system. In common parlance, there are metrics like daily active users (DAU) or monthly active users (MAU) used to define how successful a software system is. However, in Incident or Risk management systems, these metrics are not very useful indicators. We measure participation as the willingness to interact with the application for these cases.


Interestingly, the only way to unlock the full potential of an incident or risk management system is by optimizing for high DAU. We need all the staff to play their role in ensuring incidents are handled with sufficient detail to ensure they don’t occur again. Except, this is not something that the software provider can manage. The organization needs to facilitate and encourage this as part of its culture.

Factors Affecting Participation

A common problem with most enterprise systems is the user attitude to the system. Multiple factors influence the user perception of the system: organizational stand on the system; hierarchy and their position within that; whether the system feels intimidating; and how welcome they feel when they do participate in the process. For an incident management system, however, a lack of active participation results in poor outcomes. If the system does not capture as many incidents as possible, the organization cannot improve its safety process. Or if the incidents reported are not analyzed, investigated, and brought to a closure in a timely fashion – again, the organization cannot improve its safety process. In both these cases, the problem might be that users are not playing the role required to ensure the overall success of the process.

Secondly, incidents are not the domain of any particular staff of a hospital. For instance, caregiving is exclusive to doctors or nursing staff, just as dispensing is exclusive to pharmacy staff. But when an incident occurs, everyone from the nursing staff, pharmacy staff to janitorial staff, and service providers that are peripheral to the organization have an essential role to play — report the incident and help in whatever way they can to ensure a smooth closure and learning from the incident. 

Investigation of an incident or its root cause analysis is a group activity. In many cases, each hospital has its designated and identified experts at running this activity. Despite their expertise, the investigation staff cannot conduct a productive root cause analysis if the staff who understand the incident or the process do not come forward with their viewpoints and suggestions. Often, though, staff might quickly feel intimidated to participate amidst experts and refrain from voicing their opinions. Users on the ground may have a slightly different perspective of the issue and have important insights. Their lack of participation denies the organization a chance at improving the process!

Similarly, staff should not feel like they are “on the hook” for their participation. The environment to encourage participation is very forgiving and open in nature. The management usually needs to step up, ensure a safe space for all their staff, and encourage them to do the right thing. From the perspective of patient and worker safety, the only way forward is inclusive of all stakeholders.

Lastly, an overlooked reason for the lack of participation is that the user interface is very complicated and intimidating to use. When the quality or risk management teams implement a digital solution to their process, they are often focused on the process and forget the importance of keeping things simple. As the understanding goes, it is pretty complicated to design a simple system and is quite simple to design a complicated one. When designing a system, we often optimize for the results and impacts but fail to account for ease of use; users need to participate actively to achieve the results.

How Does QUASR Achieve This For You?

A core tenet in the design of QUASR is user participation. QUASR builds on the best practices commonly used elsewhere in the software industry. Our user interface and usability are very similar to hugely popular apps like Facebook or Gmail. Similarity with other popular applications helps us leverage the familiarity that the users already have. 

Secondly,  QUASR brings multiple simple but niche features like save draft, multi-stage forms, flags, and widgets to simplify how a user sets to achieve their tasks in the incident. Further, we have features like pseudo-anonymity to encourage participation without fear of repercussions. The list is exhaustive, and covering them all would become a blog post on its own. Feel free to talk to us to understand how you can benefit from using QUASR in your organization.

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

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

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