June 29th, 2017
To us, the most fascinating thing about process improvement within a medical practice is how it has a clear clinical counterpart: differential diagnoses. In a typical scenario, a patient presents with a chief complaint ("I don't feel well"), and it's the provider's job to figure out just what is wrong and what to do to make the patient better. The problem with "I don't feel well" is that it encompasses hundreds of possible conditions, and it often takes a bit more than a quick physical exam to get to the root cause. Thankfully, diagnostic testing and evidence-based medicine databases provide the physician with the data (or evidence) he or she needs to separate the wheat from the chaff.
In process improvement, we engage in this same process, except instead of the clinical aspect of medicine, process improvement focuses on the business side of medicine. Why would we even want to have a process focus? Well, many good reasons exist, but the three we tend to stick to the most are:
1. We want (need) to have a real understanding of how the process actually works. For example, the check-in process alone, when properly mapped out, is much more complicated and has many more steps than most folks see.
2. We need to have a better understanding of the relationships between steps and how and where handoffs of responsibility occur between staff members.
3. Our ultimate objective must be to make better decisions that result in solving problems.
Know How To Use Your Tools
Tools like flow charting (or process mapping), value stream mapping, casual analysis (often referred to as an Ishakawa analysis), Voice of the Customer (sometimes referred to as the Kano model), and Critical to Quality (CTQ) trees are great, but if you don't know how to use them, they can be as dangerous as they are helpful (think of a scalpel in the hands of a 2-year-old). However, to shed some light on the purpose and strength of these tools, let's discuss the five basic steps they all have in common:
1. Defining the issue;
2. Creating the benchmarks;
3. Finding the root cause(s);
4. Identifying and testing possible solutions, and
5. Validating the results
It sounds simple enough until you realize that many organizations get stuck on number one, defining the issue. It's not that we don't recognize an issue when we see one, but rather we see so many issues popping out all at once that it becomes overwhelming and makes it difficult to choose which one to address first.
This effectively is the initial triage stage of the process. Creating the benchmarks often becomes the starting block for any process improvement project, and analytics define the difference between anecdote and antidote. Maybe here more than anywhere else, the phrase "if you can't measure it, you can't manage it" comes into play.
If you contemplate the first four aforementioned steps, it's easy to see the straightforwardness with which these steps stitch themselves together. But the final step, validating the results, might be the most critical step in the entire process and unfortunately, it's the step most often neglected before wrapping up a project.
Here's an aphorism we coined: Whenever you change something (anything), you always end up with something different. What's important, however, is to recognize whether the "something different" is better or worse (or the same as) what you started with. In other words, you might have completely revamped one or more of the critical processes within your practice and felt really good about making those dramatic changes, but if you haven't validated whether any of those changes actually improved your organization in any quantifiable way, what's the point?
Deployment platforms include DMAIC, PDSA
Of all the different deployment platforms, two tend to get most of the attention, and for good reason. The first is DMAIC, which stands for: Define, Measure, Analyze, Improve, and Control. As you can see, these steps match quite nicely with the five steps outlines previously. The other main deployment platform is referred to as PDSA (or PDCA), which stands for: Plan, Do, Study (or Check), and Act. Although it's similar to DMAIC in its conceptual approach, it's much leaner, and as it sounds, much more applicable to Lean projects.
PDSA is about small, nondestructive tests. For example, if you want to improve wait time, then DMAIC would demand a long-term statistically valid, well-designed experiment that would take 3 months and much staff time to complete. Using PDSA, on the other hand, you could complete your project within a week with limited resources and at just about no cost. We don't want to give the impression that DMAIC is never a good idea; it's just that PDSA is a less cumbersome and most often, equally effective platform to use for medical practices.
When Practice Improvement Fails
In all, one question bears answering: Does process improvement always work and is it the antidote for all that ails us? The answer is an unequivocal "no". When a process improvement project fails, it may be because the project wasn't a good candidate for process improvement. Most often, however, the failure is due to more tangible, human issues. And although projects fail for many reasons, three reasons seem to be the most common, in our experience:
lack of support and/or buy-in from top management
lack of a specific target or goal
However, the key takeaway here is that for most of the operational and workflow-related problems we face when addressing the profitability and sustainability of a medical practice, process improvement in fact is the answer. Continuous process improvement in general- and LSS specifically - is a scalable model that is as applicable to the solo provider as it is to the 1,000-physician healthcare system and we strongly encourage anyone to consider how to implement these tools within their practice. Do keep in mind though, before deciding to sail off headlong into the sea of organizational change, make sure that your crew is on board and don't forget to keep a close eye on your compass and map.