How often in EMS does the provider start a treatment without doing an assessment? The correct answer, as we all know, should be never. The same should be true about solving problems in our systems, but often it's not.
The "Ready, Aim, Fire!" concept occurs all the time in EMS. As providers we're trained to find a problem and fix it quickly. However, in management and leadership quick does not necessarily equal right. A favorite example comes from the world of computer tech support:
User (U):"My computer doesn't work"
IT: "What happens when you turn it on?"
U: "Nothing, the screen doesn't turn on."
IT: "There should be a power button on the lower right hand corner, what happens when you push it?"
IT: "Let's check the wires behind it, sometimes they can get unplugged. Check behind the monitor and make sure all the wires are properly connected."
U: "I can't see back there."
IT: "Do you have a flashlight?"
U: "No, I let my co-worker borrow it to go to the bathroom. The power's out."
Sound exaggerated? Absolutely, but it gets the point across. The tech support person was trying to get the monitor to work when the power was out. A more thorough assessment would have saved everyone time and frustration, which in leadership directly corresponds to money.
So how do leaders keep from fixing phantom problems and instead identify the root cause of systemic issues? There are multiple methodologies out there, including Six Sigma, LEAN, PDSA and others. They're all good and reliable; the trick is finding one that works for your system and using it consistently. Think of it like reading a cardiac rhythm strip--you do it the same way over and over, which ensures nothing gets missed.
Let's take a closer look at the PDSA model. PDSA stands for Plan, Do, Study, Act. It's a systematic methodology which allows you to attack large scale problems reliably. The following example shows how implementing PDSA can help avoid a negative outcome.
ABC Ambulance Company is a 9-1-1 provider that has been tracking its "chute" times--the time from initial dispatch to wheels turning toward the call. ABC's goal is to be moving in less than 90 seconds once the dispatch is complete. They have discovered they are consistently not meeting that goal and typically the chute times are greater than 120 seconds.
After hearing this, the front line supervisors reach the conclusion that the providers are just lazy and not moving fast enough after the initial alert. The supervisors inform all of their direct reports that chute times need to get better, "or else."
Problem solved, right? Wrong. The chute times continue to lag and now employee morale starts to decline, as well.
Now let's use the same example but with the PDSA model in place.
P: Plan--this requires a thorough investigation and a lot of work but it's worth it. Start by verifying that the data you are tracking is reliable and valid. Once you can consider the data to be "true," create separate statements defining the problem and your goal. Both of these must be measureable and quantifiable. For this example the problem statement is "Chute times are greater than 120 seconds on 90%of all dispatched calls." The goal statement should be how you plan to measure success at the end of the pilot, such as "Chute times will be less than 90 seconds on 95%of all calls dispatched." With this clear goal in mind, everyone will know how to measure success.
Now the more relentless task occurs of diagramming out the entire process where the problem exists. In this case it's the entire dispatch and en route procedure. Remember, minutiae matters! Diagram every single step in the process, starting with: