Fix Real Problems, Not Perceived Ones

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?"

U: "Nothing"

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:

• Step 1: Something happens, requiring someone to call 9-1-1.
• Step 2: 9-1-1 operator answers the call.
• Step 3: Call deemed medical in nature.
• Step 4: Call goes through the EMD process.
• Step 5: Closest unit identified.
• Step 6: Initial alert sent to closest unit.
• Step 7: Acknowledgement from responding crew.
• Step 8: Crew goes to the ambulance and starts engine.
• Step 9: Crew opens bay doors.
• Step 10: Crew contacts dispatch center for full dispatch.
• Step 11: Dispatch relays call information.
• Step 12: Crew repeats dispatch.
• Step 13: Crew looks up call in CAD or map books ensuring proper destination.
• Step 14: Crew puts the ambulance in drive and pulls out of bays.
• Step 15: Crew closes bay doors.
• Step 16: Ambulance is en route to call.

There can be many more steps depending on your system; remember, every single step--no matter how small--must be documented and laid out in linear form. Once the steps are all diagramed out, attach timelines to each one in terms of the number of seconds it takes to complete each step in the process. Use real times, not assumptions.

Once the process map is complete you realize there's a significant period of time between the initial alert and the crew acknowledging the call, if they are not already in the ambulance, regardless of time of day.

Armed with this information, begin to investigate possible causes and perform a root cause analysis of the issue.

Diagram out this process and bring in feedback from the people closest to the problem (in this example, speak to the front line providers). Share the data and goals with everyone involved to build buy in.

During the analysis process you learn that the initial alert is not always being picked up by the radios in the substations.

D: Do--In this step of the process focus on one--and only one--specific area for improvement.

Because of the information learned in the planning phase, start a "test of change"--basically an experiment--to see if that gets you the results you're hoping for. In this example, the EMS organization decides to purchase pagers for the northern portion of the response area (five ambulances) and test their results against the rest of the system for a month. Dispatch buys into the program and agrees to participate with the added step for notifying the ambulances.

S: Study--For the next month collect data on the pilot study. This is more than just the metrics associated with the response times. Talk to the crews wearing the pagers to find out if they're comfortable, if they interfere with day-to-day work, etc. Address concerns or problems as they arise.

With the new data in hand compare it with the rest of the system and see if the solution fixed the problem. For this example the crews in the pilot program had chute times below 90 seconds for 97%of all calls.

If needed there are mathematical measures for statistical significance to ensure that this reduction in call time is considered "significant."

At the end of the pilot more analysis awaits. First, is this problem worth fixing? This is a tough question to answer. In the example used, there is some obvious credence to the affirmative, but not all issues are that transparent. Find the answer that is right for your system and keep your employees informed every step of the way.

A: Act--Following the example, after looking at budgetary costs in capital for the physical pagers and data charges, along with non-productive time associated with training the providers and dispatchers on the new process, leadership decides to go ahead with purchasing pagers for the entire system. The crews don't mind wearing them and see the better clinical outcomes due to decreased waits to respond to calls.

This is a circular process that feeds directly back to the planning stage, which continually ensures goals are being reached and that this is a value-added process.

Notice the distinct differences between the perceived problem--our providers are lazy--and the real issue--the radios don't work well in our substations. By becoming a transparent organization and communicating the problems and solutions with staff, engaging them in idea resolution and celebrating their success, leadership gains employee engagement, satisfaction and trust. And that leads to less turnover, lower training costs and increased revenue.

The PDSA model is not the only systematic way to attack problems. As mentioned above, numerous others exist. Research and discover what works best for your organization.

Using any method consistently will allow your organization to answer the right questions, saving you the time, money and headaches associated with trying to turn on a computer monitor when the power is out.

Patrick Pianezza, MHA, NREMT-P, is a consultant experienced with Studer, HCAPS, Gallup and Press Ganey principles. Along with nearly a decade of experience in the prehospital arena, he has worked for Johns Hopkins Hospital and Studer Group. He is currently the manager of service excellence for San Joaquin Community Hospital in Bakersfield, CA. Contact him at ppianezza@gmail.com.

Related

• Why Rounding Works
• Avoiding the Potholes: Common Mistakes of New Leaders
• A Call for Accountability
• Leadership Training
• Dealing With Low Performers in EMS
• From Leading on Scene to Leading an Organization
• Are Your Employees Looking to Leave?
• Do We Deserve To Be Called Ambulance Drivers?
• Why Being Nice Is Part of Patient Care