Welcome to Module 5, Session 3 of the Cardiovascular Program Coordinator course. This module is Performance and Quality Improvement with content provided by Susan Rogers and Michelle Wood. Remember this is Session 3 of the series and the overall objectives are to formulate a performance improvement plan for the ACC accreditation process, select proper tools for completing a performance improvement project, and analyze available resources to isolate which performance to improve. We will pick up with the last component of the agenda. In this session, the learner should be able to describe tools available to utilize during performance and quality improvement. There are many useful tools to use, but the secret to success is to select the tool that will be most beneficial to accomplish the task at hand. We will be sharing information about the following six quality improvement tools. Flow Charts, PDSA, Ishikawa Fishbone Diagram, also known as Cause and Effect, Run and Control Reports, 5 Whys, and Root Cause Analysis. Let's check in with Mary and see how her team is doing. Mary and her team have written the performance improvement plan and are ready to understand current processes, but are unable to identify a common factor affecting the length of stay. There are many tools that the team can utilize to help with this. Let's see if we can give them a little guidance by reviewing a few of the different tools available. The best tool to utilize in identifying the current process is a flow chart. Key symbols in a flow chart paint a picture of the process. It is okay when you first start to just document the steps on paper or a Word document, ensuring there is clear beginning and end. Don't be afraid to ask your quality department for assistance. The shapes in a standard flow chart represent steps of the process. These are pretty self-explanatory in the slide, but we'll mention a few basic ones. The beginning and end are in the shape of an oval. Decision points are diamond-shaped. Often it is the decision points where metrics can be captured. Connectors represent the directional flow and tend to be lines or arrows. The rectangle represents individual steps in the process, like a task or an action. This will help you get started in flow charting your process. In the example that Mary has been working on, she would utilize a flow chart process to establish the current structure of the low to intermediate risk chest pain patient from arrival to discharge. After the process is flow charted, she continues to revise and break the process down into measurable steps to identify where delays are happening, which will guide the solutions or improvement process to implement. As you can see in this example, they've started with the first step of starting the process and then the second step of what action or task is done, then the decision to continue on with the next step or need to go back to the first action or task, and then any applicable documentation. The Ishikawa Fishbone Diagram is the next tool for discussion. It is commonly referred to as the Fishbone Diagram and can be used for establishing cause and effect analysis. This tool allows for visualization of the different categories that can cause potential problems in a process in order to identify the root cause. A Fishbone Diagram is useful in brainstorming sessions to focus conversations. It is very easy to utilize and is excellent for breaking down the steps previously outlined in the flow chart, allowing you to begin to get to the root cause of delays or other type of barriers to success. Start by agreeing with the problem or the effect. In Mary's situation, the length of stay is too long, so we would write it at the center of the flow chart and whiteboard and draw a box around it. Then draw a horizontal line running to it. Have the team brainstorm major categories of the problem. Now if it's difficult to get started, we can use generic headings to guide us. So think of environment, people, equipment, management, materials, and processes. Write those categories as branches from the main arrow as shown here. Start noting where causes are impacting the problem. Ask why does it happen? As each idea is given, the facilitator will write it as a branch from the appropriate category. Causes may be written in several places as they can relate to several categories. For each cause, ask again, why does this happen? Continue to ask why and generate deeper levels of causes. Layers of branches indicating causal relationships. When the group runs out of ideas, focus the attention to places on the chart where ideas are many. The Fishbone diagram is the best tool to help you understand factors affecting the problem. The PDSA cycle for process improvement has no end. The cycle will be repeated again and again for continuous improvement, but let's break it down. We'll start with P, plan. What are we doing now? Is it a big problem? What can we try? Ask your team what will happen if you try something different. Assess the objective and what predictions can be made. Develop a timeline and a plan to carry out the who, when, how, and where the change will be made. D is for do. Let's try our plan. You can even consider carrying out the plan maybe on a small scale to test for outcomes. Then next is the S, study. Collect and analyze data. Document any issues or barriers discovered and any solutions. Compare the analysis to the predictions and summarize. Ask yourself and your team, did it work? A is for at. What are your next steps? How can we keep it going? Should we try a new plan? Take action based on what you learned in the study step. If the change didn't work, go through the cycle again with a different plan. If you are successful, incorporate those learnings from the test into wider changes. Use what you learned to plan new improvements, beginning a new cycle again. The PDSA tool provides the best mechanism to assess a situation, make changes, and reevaluate after changes have been made. Next we'll talk about control charts. Control charts demonstrate if a process is in statistical control or not. The x-axis is time-based so that the charts show a history of the process. For this reason, you must have data that is time-ordered, that is chronological, entered in the sequence from which it was generated. It is a single line plotting some value over time. A run chart can help you spot upward and downward trends and show you general pictures of processes, but a control chart also plots a single line of data over time. However, control charts include upper and lower control limits with a center line. Control charts demonstrate two causes of fluctuation, common causes and special causes. This particular control chart is the door-in and door-out data for patients over time. The individual encounters demonstrate from the time you start the measure, the x-axis, and the actual time the process took. The upper control limit and the lower control limit are represented by the red dotted line. The turquoise line represents the average time, while the green line is the goal line. Encounter 6 demonstrates an event that is considered to be a special cause in this case. A chart review revealed a snowstorm that slowed the transporting ambulance, otherwise the process appears to be in control as the data points are well between the upper and the lower limits with a fairly close hold to the goal line. When do you use control charts? When controlling ongoing processes by finding and correcting problems as they occur. When you make changes to see if the new processes are in control. When predicting the expected range of outcomes from a process. When determining whether a process is stable or in statistical control. When analyzing patterns of process variation from special causes like non-routine events or common cause things that are built into the process. When determining whether your quality improvement project should aim to prevent specific problems or make fundamental changes to the process. Sometimes you may not have the capacity to formulate control charts as previously mentioned in the first session. This may be due to lack of understanding or software to assist in the development of these. Reach out to your quality department and they can assist you with this. While a control chart represents the best way to see if processes are in control, you can utilize run charts when there is insufficient data to properly analyze the process using statistical control charts. They should never be used in place of control charts and can't offer the benefits of a control chart, mainly those that ascertain whether a process is in a state of statistical control or how much variation is present or determine process capability. When you are working on PI projects for accreditation or certification, you are not necessarily looking for statistical control. When you do need that capacity, then work with the statistician at your hospital. The above example is a run chart. Be sure to enter a goal line. Here it is the red line and a median line on your run chart. Here it's the green line. Review the extreme outliers such as in case 11 on this slide or case 22 to make sure the data has been abstracted correctly before you begin. Since this data is all over the place, you would say the data is probably not in control. But once you start doing performance improvement and remeasuring your data, you would look to see if your data begins to align closer to your goal line. Another opportunity from this chart may be to review the cases closest to the goal line to see what is different in those versus those that are at or above the median line. The next tool is the five whys. Sometimes things do not go according as planned. Processes break, communications stop, and we all know the best plans still have the potential to fall apart. Those occasions require you to know exactly what happened so it doesn't happen again. Moments like these can turn to a simple but effective process, the five whys. This is a discussion of the unexpected event or challenge that follows one train of thought to its logical conclusion. Ask why five times to get to the root of what happened. The five whys technique was developed and fine-tuned within the Toyota Motor Corporation as a critical component of its problem-solving training. They repeated the five whys. The nature of the problem as well as its solution became clear to them. An example of the five whys is why did the patient not receive their medication? The nurse did not have the medication on the floor. Why did the nurse not have the medication on the floor? The patient was recently moved to the unit and the pharmacy was unaware. Why was the pharmacy unaware? The staff had not seen the orders yet to request the medication. Why had the staff not seen the orders? The computer still showed the patient on the previous unit. Well then why did the computer still show the patient on the previous unit? Staffing was low and it took longer than usual to accomplish the tasks. So of course you could go on and on with this, but you get the point and where it drives you to get to the root cause. When you run a five whys session, invite all involved and select a facilitator. Ask why five times, assign responsibilities for solutions, and email the team with results. The five whys can be done alone or with another tool such as the root cause analysis and certain parts of the fishbone. The last tool to consider is the root cause analysis, commonly referred to as an RCA. It is a tool to help identify what, how, and why an event occurred so steps can be taken to prevent future occurrences. Additionally, a root cause analysis may be used to target opportunities for system-wide improvement. Root causes are specific underlying causes that can be reasonably identified, are within management's controlled remedy, and which generate effective recommendations to prevent recurrence. The RCA process involves data collecting, causal factor charting, root cause identification, and recommendation generation. An RCA can be done prior to a project or as a result of an outlier or unexpected event. After the RCA is completed, then a multidisciplinary team should analyze a sequence of events leading to the error and why the event occurred with the ultimate goal of preventing future harm. Typically, an RCA will follow a set protocol so that all or perform the same way in an organization. There are typically seven factors considered when doing a root cause analysis. Institutional, organizational, work environment, team environment, staffing, task-related, or patient characteristics. Institutional versus regulatory. A patient on anticoagulant receives an intramuscular pneumococcal vaccine, resulting in a hematoma and prolonged hospitalization. The hospital was under regulatory pressure to improve its vaccination rates, an organizational or management factor. A nurse detects a medication error, but the nurse manager discourages her from reporting it. A work environment area. Lacking the appropriate equipment to perform a procedure, operating room staff improvise using equipment from other sets. During the procedure, the patient suffered an error embolism. Or team environments. A surgeon completes an operation despite being informed by a nurse and an anesthesiologist that the suction catheter tip was missing. The tip was subsequently found inside the patient requiring another operation. Staffing. An overworked nurse mistakenly administers insulin instead of an anti-nausea medication, resulting in a hypoglycemic coma. Task-related. A pharmacist incorrectly calculates the equivalent dose of a long-acting MS cotton for a patient who's been receiving Vicodin. The patient experienced an opiate overdose, aspiration pneumonia, resulting in a prolonged ICU course. And then finally, patient characteristics. A wife of an elderly man misread the instructions on a prescription bottle for potassium supplement, causing her husband to experience cardiac arrhythmias. So these are all different examples and ways you can relate the type of activity that was the underlying cause. In summary, it is very important to involve key people at the right time, preferably early on. Listen to team members, staff, etc. Collaborate with them and be sure that the frontline staff is included in your process change or you will not have buy-in. Don't assume everybody knows the process. They may have a general knowledge of the process, but do not know the intricate details. Monitor your data a minimum of monthly. Address any barriers with leadership, executive sponsors, or other team members early on. Then celebrate your successes. Display data in staff lounges or public locations when applicable. Recognize the work done by your team, but also those responsible for implementing the change in performance improvement. Share performance along the way, a minimum of quarterly. Consider taking your project to a hospital level versus just a department or process level. This concludes Module 5, Session 3 of the Cardiovascular Program Coordinator course.

Performance and Quality Improvement

Flow charts

Ishikawa Fishbone Diagram

PDSA cycle

Control charts