Is the healthcare system volatile? Not only are there many moving pieces, but its evolution must be proportional to a combination of various factors: the variable demands of pathophysiology, technology, policies, research, availability of personnel etc.

One example of how healthcare demand is vulnerable to change is given by the story of emergency departments (ED). As adapted from war setups, the process was meant to serve a population that needed acute care: new symptoms or concerns that can be addressed readily. But as time went by and chronic illnesses increased, the ED was no longer providing just acute care; the complexity and demands of the patient conditions increased, and the patients that required extensive care also increased. This resulted in a backlog in the system that was designed only for acute care. The problems hit the system faster than it could resolve them and the impact accumulated.

An estimate of the current total turn around time for addressing the problem systemically can be obtained by:

Total Response time = Time to Realize Problem + Time to Ideate and create a Solution + Resource Time (financial and others)+ Time to implement a solution

This total response time could be between six months to many years, depending on the complexity of the problem. Considering the dynamic nature of the inputs to the system, the problem can change by the time a solution is mobilized. During this mobilization, cross-functional sub-systems also have to respond and sync up.

Do we make the system rapidly re-definable? Or every time we encounter a change in the input, do we create a new process from scratch? How absurd is that? Well, we already try to do that when we introduce a product when solving a problem. See if this sounds familiar:

Trigger

Experience or analysis of efficiency indicators reveal a problem. Further understanding helps people articulate the matter at hand. Depending on the articulator, this may end up in a text to a friend or in a peer-reviewed journal.

Stating the problem

When trying to root-cause the problem, it has to be isolated from its native environment. Just like how I did earlier, we may define the problem as the impact of the variables on the outputs of the system or processes.

Now we have patients with more co-morbidities that require extensive treatments, which leads to patients staying in the hospital longer and thus creating a backlog.

Finding what to solve

We can’t control input to this system. We can only respond to it. Depending on who reads the statement above, the plan of attack will be different. Some will try to change the input: public health policy-makers, food and drug regulators or health educators. Others will find the part that we can control. Most likely, it’s the part of the system that directly interacts with the input.

An unrelated example of input management is a company with a program that reads data files. In its first release, the program can only ready text files. A couple months later, the company starts losing customers and decides that they need to support CSV inputs as well. Depending on how this program was designed, they may have to make significant changes, or just a small module within it. For healthcare, the fact that our processes are often so intertwined and customized, the solution may require a change to many operations and sub-systems. As you would expect, this will be expensive.

Depending on the illustrator, the problem is refactored again. A hospital administrator may think the problem exists because we don’t have someone orchestrating the process; the entrepreneur may see an information accessibility problem; a team leader may believe this is because of culture.

The Solution

Let us take a dashboard solution for the lack of information accessibility problem. We hope that the newly presented data will increase situational awareness and lead people to act on it and catch issues readily.

This need won’t translate when the number of patients overwhelmingly increases or when the type of patients and categories change. This information really just ends up becoming one of the 30 other notifications that the overstimulated staff members will get in a given hour. Soon it won’t be a priority to address the information, and the dashboard will lose usage after a couple of months. Since there is no explicit process dependency on this product, it only achieved improved information accessibility. In a situation where there is an actionable plan associated with this product, it will require a change to the current process. For example, depending on implementation, there may be additional people involved and further decision making steps. This could be very beneficial, but since it increases the number of moving parts, it makes the system more vulnerable. Eventually, it may even be the case that acting on the information becomes prohibitive for this non-forgiving process.

Was the intent of solving the problem good? Yes.

Was the solution reasonable for the defined problem? Probably.

But when we put it into the process, did it work? Not necessarily.

Was it worth it?

The return on this solution is minimal, and the effort (getting people convinced, getting everyone on the same platform, and changing current process) is too high – it’s just not worth the effort. That’s why this solution has a higher potential for failure. It considered the isolated process of communication while understanding the problem, but didn’t understand the impact and integration with associated processes – a.k.a the higher level.

Products that do succeed, design for the native environment while managing the variability of the inputs. That’s obviously a generalizing statement, but I think products that get adapted and add value do attack the raw workflow.

An example is Synaptive Medical’s exoscope: Modus V. An exoscope that shows the surgeon an augmented surgical field. Its competitor is the microscope. The Modus V solution, doesn’t isolate one problem, but understands the process and optimizes it. By doing this, Modus V solves a set of challenges: surgeon neck strain, lack of awareness about the surgical field for the supporting surgical staff, better visualization, less heat exposure to the patient from the light intensity of the microscope etc. Individual solutions to these problems won’t provide enough value to the users and may even require a change to their workflow. For Modus V, the return on cost is significant, and the learning curve is minimal; it is literally using one machine in the operating room instead of another.

What’s more interesting is how Modus V has the potential to manage the variability of inputs. A surgeon suited up per COVID-19’s surgical guidelines is unable to use a microscope. Did the product predict this need (like how we all anticipated a pandemic)? No, it didn’t foresee the change in the input, it just optimized the process in a modular way for easy future adaptation. Similarly, this product can be used in many operating rooms where an augmented view can improve surgical workflows, not just a neurosurgical one.

Looking at a process and designing for it adds value to the healthcare systems and workflows. Future products have the opportunity of making our workflows robust and adaptive by modular designs. We may not be able to predict the variability in the input, but we sure can develop methods that will be adaptive to change in the future.

For inquiries, comments and feedback reach-out at communications@snoor.ca