fbpx

An Introduction to QUASR Basic

Abishek Goda

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 Enterprise version. Even amidst our customers and prospects, we understand Lite is a little too simple for their process because they have had a computerised 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 flavour 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 a workflow

QUASR Basic is Lite with a workflow. It does not have all Enterprise version features and will probably remain that way for more time. BASIC and Enterprise target different types of organisations. 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 linearising sequence of events in the incident lifecycle is what we call the “workflow”.

There’s more

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 on the incidents to a pre-determined 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 organisation.

QUASR Basic vs QUASR Enterprise

Lastly, as I mentioned, BASIC is Lite with a workflow. But how does Basic compare to Enterprise? Enterprise, as the name suggests, is unlimited in many ways. Enterprise targets a group of institutions as opposed to independent hospitals or providers. A group have 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, customisation provisions in Enterprise that aren’t available in Basic. For more information, feel free to reach us out, and we’d be able to give you even more clarity on both these versions and options.

Why should you keep your process simple

Abishek Goda

“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 the 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 don’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 setup 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 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 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 details 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 its 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 arise 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 Lite

Abishek Goda

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 organisations 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 organisations 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 organisation 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? Here is how.

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 centres and individual hospitals, that are either:

  • New to incident management 
  • Looking forward to digitalising 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 Enterprise’ 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 30-day free trial here.