quasr-logo-header
TRY QUASR FOR FREE

Category: Product Updates

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

An Introduction to QUASR Basic

Abishek Goda
Basic-Features-Banner

When we brainstormed the QUASR Lite design, we had a list of features for another version that’s slightly more advanced than Lite but not as involved as the Premium version. Even amidst our customers and prospects, we understand Lite is a little too simple for their process because they have had a computerized system in place for a while and are familiar with the advantages of having one. They need to upgrade but are not ready to set aside budgets or time for enterprise implementation.

So we built QUASR Basic to give you a flavor for what the enterprise system can do for you without having to go through full implementation. There are limitations, of course. In this post, allow us to introduce QUASR Basic to you.

QUASR Basic is Lite with an automated workflow

QUASR Basic is Lite with a workflow. It does not have all Premium version features and will probably remain that way for more time. BASIC and Premium target different types of organizations.

BASIC targets single/independent hospitals, which are:

 

1) accustomed to having a system in place.

2) using Lite for a while and want to graduate their process.

3) Enterprise-ready users who wish to try QUASR before taking on an enterprise implementation.

 

I hope we convinced you to read on, as this might be just what you need at your org right now.

 

What do we mean by a workflow anyway?

In Lite, when you report an incident, the system doesn’t do much apart from saving it to a database and ensuring the data’s integrity. In BASIC, however, a few things happen: the system triggers an email to a pre-designated group of Quality Managers as soon as you report an incident.


The incident details collected also contain additional information such as the Supervisor for the incident, a team of investigators, a group of people to sign off on the incident etc. Each of these is a stage in the incident lifecycle. The Supervisor assigned is then required to perform the review and fill in the SBAR. Similarly, upon quality review completion, the investigation report can be updated and so on. This linearizing sequence of events in the incident lifecycle is what we call the “workflow”.

There’s more to QUASR Basic compared to QUASR Lite

But that’s not all of it either. There are more things under the hood in BASIC as compared to Lite. Flags assigned to incidents in Lite are merely indicators. They help you identify or classify incidents at a glance. However, in BASIC, you can use Flags to include pre-designated people in the incident loop. They’d automatically get notifications and access to the incident details.

Similarly, you can add other users to the incident and notify them of the occurrence – voluntarily. These might be other department heads or an HR supervisor or a Line supervisor instead of the department supervisor. These users would otherwise not have access to the incident or its details.

 

One last thing to highlight about Basic would be the “Sensitive Incidents” feature. We will write a detailed note on sensitive incidents in another post in the future. But for now, sensitive incidents are a type of flag that limits the access to the incidents to a predetermined group of users – Quality Managers, investigators and other management level users. QUASR does not have an opinion on how or when to use this flag. We leave it to our customers to use it as they see fit in their organization.

QUASR Basic vs QUASR Premium

Lastly, as I mentioned, BASIC is Lite with automated workflow.

 

But how does Basic compare to Premium?


Premium targets a group of institutions as opposed to independent hospitals or providers. A group has other requirements in terms of uniformity of process across their participant hospitals. They tend to prefer a single cluster implementation where the group management can get their dashboard with the essential information they need about the overall incident performance.


BASIC, on the other hand, does not support a cluster implementation. There are other differences in terms of support access, implementation, customization provisions in Premium that aren’t available in Basic.

For more information, check our pricing page, and it’d be able to give you even more clarity on both these versions and options.

Why should you keep your process simple

Abishek Goda
simple incident process

“Everything should be made as simple as possible, but not simpler.” – A quote often attributed to Nobel winning Physicist Albert Einstein.

Incident Management process is often quite simple. The process provides a lot of information beyond incidents themselves and are essential inputs for overall clinical risk management as well. In many cases, the knowledge that the incident management process is a first step to overall risk management is sufficient to drive us into analysis paralysis mode. Risk management is a very complex topic and has far too many factors in its implementation. We, at QUASR, have insights into clinical risk management and we will eventually integrate QUASR to provide this option for our clients. In this post, we want to address some of the common complications in implementing an incident management system and our solutions.

QUASR follows an industry-standard workflow for incident management. We implement a simple workflow and we are pretty proud of that fact. We believe we have achieved the simplest possible standard workflow that also captures the essence of incident management itself. However, during enterprise implementations, clients usually need quite a bit of convincing as to why this simple workflow is usually a good place for their needs. From our experience, this happens in two cases: when the clients have a legacy system that they have used for a while and are looking to keep the same process. Or they are looking to map their existing manual flow as-is into the new system. Both these approaches, frankly, are inefficient. Let us explain.

Legacy System Hangover

Systems that were built at least a decade back qualify as legacy systems. Any reasonably newer system might not have the issues that we are going to discuss here. For newer systems, the IT team was likely asked to implement their manual process as is! In software circles, there is an inside joke – “some unexplained bugs are actually features.”.

On a more serious note, systems that were implemented a long time back don’t fully take advantage of all the technological developments of recent times. Some of their design decisions could have been technology driven rather than user driven simply because it would be prohibitively difficult to implement differently.

A newer system built on more recent technologies doesn’t suffer from the same limitations. And hence it is possible to achieve more elegant solutions or workflows than wasn’t possible in a legacy system. That said, if we carried forward the legacy system as is, we might not fully utilize all the enhancements that technology offers us.

Mapping Manual Process to Digital Process

Since many of our customers are implementing their first digital system for incident management, this is the typical set of issues we face while onboarding and customizations. Many things we do manually, do not scale well to digital systems as such. And we all have seen examples of this: have you ever tried to collect all people interested in paying for a gift to a colleague? We send out an excel sheet and each person returns a sheet of their own and we merge them manually?

That’s exactly what we’d do before emails. We’d just go person to person, find out if they’d contribute and write it down in a piece of paper. But we all do know how inefficient that is, right? If we have to do the same thing today, we should probably set up a google form that each of the participant fills out and you get an excel sheet at the end of it. Same data is collected but far less work needs to be done by the person trying to collect it. The second option is a more digital native way of solving that problem. Incident management, incidentally, is full of such problems.

A typical example we often get as a customization request is to include additional workflow steps: include HoD as part of the workflow. Yes, we understand why you’d want to do that. But in many cases and as many of our customers agree too, this step is an FYI for the person involved. In a manual system, the HoD had no way of knowing what was happening unless you intentionally ran things by them. But digital systems aren’t really like that. Online systems are even lesser so. You’d just need to notify them in these cases.

In QUASR, we solve this problem by automatically having HoDs in the loop for all incidents in their department. You don’t need to do this additionally. However, we do not notify them every single time. EMail based notifications have become so common that we mindlessly mark things to read or archive them even without reading them. And we do not want to add to the inbox clutter either. So the HoDs just have to login periodically and they’d be updated on all the active incidents in their department. But unless we explain this, most of the users don’t see the solution. They are wondering how to implement an additional step in the workflow because that’s what they do in the manual flow.

Another example is typically around data collection fields. Many clients request adding quite a few descriptive fields whereas these aren’t very useful for systematic analysis. Descriptive data necessitates quality managers or investigators to spend time reading and understanding much information. But there is another downside: lack of sufficient information. Some people can describe an incident in vivid detail while others tend to write very little. Situations like these can be avoided by collecting quantifiable, standardized data instead. This, too, is an artifact of using paper based forms.

In paper based forms, it is impractical to collect incident type specific information for every incident type we want to track. So we end up with a few generic descriptive boxes for the users to fill up. However, adopting the same to a digital system does not allow you to utilize the full power of a digitalized solution.

Adopt Digitally Native Solutions

We just saw a few reasons why users typically have difficult-to-use, complex workflows in a digital system. But it’s not entirely their fault. As service providers, our first mantra is “Customer is always right!”. Blindly following the mantra, however, does very little to help the customer. While the customers know what they want, it is our duty to explain and clarify how best to provide what they want. Users tend to get carried away at the flexibility and try to plan for a future well ahead. It is worth remembering that technology evolves faster than our processes. So it is not very useful to plan far ahead into the future but plan for medium to short term only.

Enhancing software solutions are often quite simple and needn’t be as expensive either. Hence it is better to implement enhancements when the need arises rather than implement them all at once. Besides, having a digital native solution allows us to adapt to a digitalized workflow better – especially moving from a legacy or a paper-based system. Once we have acclimatized to a digitalized solution, we are better suited to decide how we need to enhance our systems in the future.

A brief introduction to QUASR Lite

Abishek Goda
quasr-lite

When we launched QUASR a couple of years back, our motivation was to create an enterprise incident management software specifically for healthcare organizations in this region (South-East Asia). Having over a decade of experience working with the big guys in this region, we have an excellent understanding of what the big solutions did to service the big guys as well. In some sense, we were uniquely positioned to generate value. But we also figured that the big organizations are well serviced and tended to have very complex requirements on their tools. So our entire vision was to bridge the gap for medium-sized hospitals. To date, all our customers say they are pleased about their implementation of QUASR, which is unique to their organization and processes.

In early 2020, the pandemic hit. The pandemic meant a lot of the healthcare organizations had to start working remotely too. Much non-frontline work had to go remote in an environment that is traditionally not trained to work remote. While our solution is perfect for organizations to take their quality process online and remote, our solution wasn’t armed to help the smaller or niche, healthcare providers. Some of these providers have not evolved to have their quality processes, have a paper-form based flow but do not have volumes to warranty a separate software or are very early to benefit from even a mid-sized solution like QUASR. The features in QUASR, though, strategic and straightforward, is sometimes far more involved and complex for an organization that is just getting started on this path.

That’s the genesis story for QUASR Lite. QUASR Lite is aimed at organizations that are just getting started on an incident management process. Whether you have a simple paper-form method or looking to create your own structure and process, Lite has you covered. QUASR Lite is unopinionated in that it does not enforce a workflow.

What is QUASR Lite?

QUASR Lite is an online incident repository. It is a simple data capture tool and allows you to capture the incident data in a structured format. It makes your life easy to gather incident statistics and generate reports.

Want to know how it works? QUASR Features 

You could very well do the same with an excel sheet. And we would have to agree. But the main advantage Lite brings to you over vanilla excel sheets is that: we have thought this one out for you. We have built it specifically for hospital incident scenarios. We consolidated our experience working with many hospitals and created a starter tool that will grow with you as you mature to bigger and more involved processes.

Who is QUASR Lite for?

Lite perfectly suits small hospitals, clinics, speciality hospitals, nursing homes and care centers and individual hospitals, that are either:

  • ✅New to incident management 
  • ✅Looking forward to digitalizing their incident data; 
  • ✅Looking to get started with a starter tool and graduate to more complex tools along the way.

Lite takes all these scenarios into account. There are some opinionated decisions we have made in Lite, though. Lite is primarily meant as a tool for the Quality Management team. So we limited the number of user licenses to 5 per account. Ideally, 5 seats are plenty enough to have quality managers and even senior management from your hospital.

Also, since Lite is for a closed team of Quality Managers, we don’t have email notifications baked in. We believe that if it is your primary tool for work, you might not want to be notified of every small action. However, this might change in the future. There are other uniquely designed features that we’ll go over in individual posts over the next couple of weeks.

Join the community

Lite is an evolving product. The first version which is taking trial requests now is the first feature-complete version. We will be adding an overall roadmap of features to Lite over the next several quarters. But more importantly, we believe that its users will drive the roadmap for Lite.

We built the enterprise version of QUASR, ‘QUASR Premium’ the same way – based on customers’ direct feedback, their specific needs and requests. So we don’t see why Lite is any different. So if you want a product that suits your process, get on the train right now and help build the product you need.

Check out more features of QUASR Lite.

You can sign up for a 14-day free trial here