Note: This is the last of a four-part series on improving your practice processes and workflow to boost revenue. The third article ran in the August issue of The Business of Medicine.
We use 24 tools, chosen based on our experience, in our process improvement work with healthcare facilities. Obviously, we don’t use all of them on every project. In fact, the tools can be mixed and matched pro re nata. The five that we tend to use in almost every engagement however are:
- Flow charting (or process mapping),
- value stream mapping,
- causal 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.
In process mapping, we create a flow chart of all of the steps within a given process. For example, for a typical patient visit, we would map out from appointment to check-out, and we would include all of the steps in between, such as check-in, wait time, provider encounter, coding, etc. Remember, the purpose of the flow chart is to be able to visualize the process steps, and its creation requires the involvement of the process owners.
When we move to value stream mapping, we begin to apply data and other information to the process map. For example, for each step in the process map, we want to know things such as, how much staff does the step require? How long does it take? How long from the last step to this step? What are the step details? What are the biggest mistakes that are made, and how often are they made? We also want to develop a list of things that could go wrong at each step, along with their risks. This is a great way to create contingency plans ahead of time, allowing errors to be caught before they create any collateral damage.
We then use these data to get to the root cause or causes for each issue identified. Remember, we want to be etiological in our approach; we want to cure the problem, not just treat the symptom. We use the latter two tools, Voice of the Customer and CTQ trees, to identify process improvement projects based on customer needs.
The Kano model creates a matrix of issues that identifies the differences between what the customer expects, wants, and needs and how variation in each of these creates both business opportunities as well as risk. For example, the basic need for a patient is proper diagnosis and treatment. It’s tough to improve much on this process, but if you don’t meet this basic level, you’re in the wrong business and likely won’t last long.
A patient’s expectations, referred to as “performance attributes” may elevate variables like being seen within a reasonable period of time, or being treated with courtesy and respect. Improvement in this area improves satisfaction scores and can drive more business to the practice, especially in a more competitive market.
When we deal with “excitement attributes,” we see activities such as a call from the office on the day of a visit to check on the patient and see how he or she is doing. Patients appreciate this and are likely to share this with their friends.
Know How to Use Your Tools
Also, consider the manner in which these tools will be implemented into the process model. Tools are great, but if you don’t know how to use them, they can be as dangerous as they are helpful (like a scalpel in a 2-year-old’s hands). For this exercise, we consider an assortment of what we refer to as deployment platforms, which are structured processes that are used to deploy, manage, and validate process improvement projects. Before we look at their differences, however, let’s discuss the five basic steps they all have in common:
- Defining the issue,
- creating the benchmarks,
- finding the root cause(s),
- identifying and testing possible solutions, and
- validating the results.
It sounds simple enough until you realize that many organizations get stuck on the first step and can’t define the issue. Often their problem is not a failure to recognize issues, but rather having so many concurrent issues that they are overwhelmed and can’t choose one to prioritize.
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. Finding the root cause, as discussed previously, is critical to effective problem-solving; and identifying and testing possible solutions comes from the ability to prioritize the root causes.
The first four steps are easy to follow logically, but the final step, “validating the results,” might be the most critical step in the entire process and yet it’s often the most neglected.
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 outlined 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? The answer is an unequivocal “no.” When a process improvement project fails, it may be because the project wasn’t a 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. Support normally comes in the form of passive approval from the owners of the practice, usually the physicians. In the current economic environment, everyone is on-edge, and risk-aversion rules the roost when it comes to investing into new opportunities. Without active support from the top, you can pretty much count on a failed effort.
- Lack of a specific target or goal. More specifically, if you don’t know where you want to be, it’s highly unlikely that you’ll know when you arrive. Not having a specific goal will make it nearly impossible to stay on track, just about guaranteeing failure.
- Unanticipated effects. The third reason that projects fail is more phenomenological, and it rests in the understanding of chaos. Not always, but much of the time, when you apply a change to one area, it creates changes in other areas, often unexpected change. It’s important to recognize that, in most cases, change is more global than we might imagine. Looking at the system as a whole is one way to assess the potential for collateral effects.
Is process improvement the silver bullet, the antidote for all that ails us? Again, the answer is “no.” If a process is not subject to some form of quantification, then it’s not a candidate for what we have discussed here. In a medical practice, quality of care is of utmost importance, and although LSS can be applied to the understanding of outcomes, quality is a characteristic inherent within the practice and the practitioners. And as a characteristic, like class, either you have it or you don’t; it’s not something that can be taught or learned.
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.
— Frank Cohen and Jason Stephens ([email protected]). Frank is Director of Analytics and Business Intelligence at DoctorsManagement. Jason is Director of Consulting Business Partners & Vendors at DoctorsManagement.
