The PDSA Cycle Testing and Implementing Changes

1. Fran Griffin, RRT, MPA Director The Institute for Healthcare Improvement The PDSA Cycle Testing and Implementing Changes

2. Drilling down into aggregate data will hopefully give us clues for changes we may make to get an improvement Improvement involves a change What we learn from drilling down into aggregate data will hopefully lead to changes to test - this is our model for testing This model was developed in the 1980�s as a general tool. Not designed for use in collaboratives. You don�t need permission to use this method on problems other than the focus of the collaborative. It provides a common language for testing. Some teams say�our company wants to use Juran model. OK, whatever you want, just keep up with the work. Our experience has been that people adopt this model by the end of the collaborative. We think this model will work for execution, nothing wrong with using another model. Drilling down into aggregate data will hopefully give us clues for changes we may make to get an improvement Improvement involves a change What we learn from drilling down into aggregate data will hopefully lead to changes to test - this is our model for testing This model was developed in the 1980�s as a general tool. Not designed for use in collaboratives. You don�t need permission to use this method on problems other than the focus of the collaborative. It provides a common language for testing. Some teams say�our company wants to use Juran model. OK, whatever you want, just keep up with the work. Our experience has been that people adopt this model by the end of the collaborative. We think this model will work for execution, nothing wrong with using another model.

3. The PDSA CycleFour Steps: Plan, Do, Study, Act We tell those in collaboratives that all they have to do in these 9 months or 12 months is to answer these 3 questions! But it can be hard to do. They could use some help. The PDSA cycle can help them. -Introduce PDSA cycle and it�s history and other names associated with it -Sometimes we don�t have idea -Or have idea but don�t know how to implement it -If need help getting or implementing ideas we can use the PDSA cycleWe tell those in collaboratives that all they have to do in these 9 months or 12 months is to answer these 3 questions! But it can be hard to do. They could use some help. The PDSA cycle can help them. -Introduce PDSA cycle and it�s history and other names associated with it -Sometimes we don�t have idea -Or have idea but don�t know how to implement it -If need help getting or implementing ideas we can use the PDSA cycle

4. Use the PDSA Cycle for : Testing or adapting a change idea Implementing a change Spreading the changes to the rest of your system

5. The PDSA CycleWhy Test? The PDSA cycle. In addition to the three questions, the model also contains an action component - the Plan, Do, Study, Act Cycle. This is where the real work of improvement begins�.putting your ideas into action. You may be familiar with the PDSA cycle. It is a simple yet powerful approach to moving from planning to action. What is unique about the BTS use of the cycle is that we emphasize doing many cycles in rapid succession. This rapid use of cycles that are carried out on a small scale maximizes learning and enables teams to achieve results more quickly. The PDSA cycle. In addition to the three questions, the model also contains an action component - the Plan, Do, Study, Act Cycle. This is where the real work of improvement begins�.putting your ideas into action. You may be familiar with the PDSA cycle. It is a simple yet powerful approach to moving from planning to action. What is unique about the BTS use of the cycle is that we emphasize doing many cycles in rapid succession. This rapid use of cycles that are carried out on a small scale maximizes learning and enables teams to achieve results more quickly.

6. Why Test? Increase the belief that the change will result in improvement Predict how much improvement can be expected from the change Learn how to adapt the change to conditions in the local environment Evaluate costs and side-effects of the change Minimize resistance upon implementation 1. Testing provides evidence that a change really does result in the improvement that was expected. Even though a change may sound like a good idea, you don�t know until you actually use it in practice. There are often multiple changes that are needed in order to produce the desired effect on your system. Testing a change, or a group of changes, gives you information about how much improvement can be expected from a change or set of changes. It allows you to evaluate whether you need additional changes to reach your aim. 3. Even though a change may have produced the desired effect in a different setting, you don�t really know how it will work in your particular environment until you try it. 4. Change sometimes produces unintended consequences. Testing allow you to observe the costs (resources, time, equipment, etc.) that the new process might involve as well as the side-effects that might accompany the change. For example, providing same-day access for clinic patients may affect the process for locating medical records. 5. It is often easier for people to agree to try a new way of doing something if the change is presented as a short-term, small scale trial. �Let�s just try it with the next three patients�� In this way, they don�t have to immediately abandon the old way of doing something. Testing often shows people that the new way is really better and they are then more willing to embrace the new process. 1. Testing provides evidence that a change really does result in the improvement that was expected. Even though a change may sound like a good idea, you don�t know until you actually use it in practice. There are often multiple changes that are needed in order to produce the desired effect on your system. Testing a change, or a group of changes, gives you information about how much improvement can be expected from a change or set of changes. It allows you to evaluate whether you need additional changes to reach your aim. 3. Even though a change may have produced the desired effect in a different setting, you don�t really know how it will work in your particular environment until you try it. 4. Change sometimes produces unintended consequences. Testing allow you to observe the costs (resources, time, equipment, etc.) that the new process might involve as well as the side-effects that might accompany the change. For example, providing same-day access for clinic patients may affect the process for locating medical records. 5. It is often easier for people to agree to try a new way of doing something if the change is presented as a short-term, small scale trial. �Let�s just try it with the next three patients�� In this way, they don�t have to immediately abandon the old way of doing something. Testing often shows people that the new way is really better and they are then more willing to embrace the new process.

7. Repeated Use of the Cycle This diagram shows the relationship between multiple cycles. The process is iterative with the learning building from one to the other. The slope of the ramp indicates that the cycles are also building in size and scope to increase one�s confidence that the changes will result in the desired improvement.This diagram shows the relationship between multiple cycles. The process is iterative with the learning building from one to the other. The slope of the ramp indicates that the cycles are also building in size and scope to increase one�s confidence that the changes will result in the desired improvement.

8. Repeated Use of the PDSA Cycle

9. PDSA Example: Sedation Vacation

10. Successful Cycles to Test Changes Plan multiple cycles for a test of a change Think a couple of cycles ahead Scale down size of test (# of patients, location) Test with volunteers Do not try to get buy-in, consensus, etc. Be innovative to make test feasible Collect useful data during each test Test over a wide range of conditions Teaching people to run small scale tests is critical. What about registry, everybody needs to be included? Coach to do small scale work.. We don�t need consensus here for tests How would you decide. Multivote? Argue? Let�s run a set of tests if people have more than one opinion. I like not to have consensus at test time, we can learn more from a range of tests. Consensus only needed at implementation time, when we believe we have a lot of evidence for our theory of how the system works. Teaching people to run small scale tests is critical. What about registry, everybody needs to be included? Coach to do small scale work.. We don�t need consensus here for tests How would you decide. Multivote? Argue? Let�s run a set of tests if people have more than one opinion. I like not to have consensus at test time, we can learn more from a range of tests. Consensus only needed at implementation time, when we believe we have a lot of evidence for our theory of how the system works.

11. Testing on a Small Scale Have others that have some knowledge about the change review and comment on its feasibility Test the change on the members of the team that helped develop it before introducing the change to others Incorporate redundancy in the test by making the change side-by-side with the existing system These are all tips to use in designing a test on a small scale. A small scale test does not mean that the test is insignificant. The test should be �big� in that it is based on an important idea for how the process can be improved. The scale is small to conserve resources, and to be able to work quickly to learn as much as possible in the quickest time. These are all tips to use in designing a test on a small scale. A small scale test does not mean that the test is insignificant. The test should be �big� in that it is based on an important idea for how the process can be improved. The scale is small to conserve resources, and to be able to work quickly to learn as much as possible in the quickest time.

12. Testing on a Small Scale Conduct the test in one facility or office in the organization, or with one patient Conduct the test over a short time period Test the change on a small group of volunteers Develop a plan to simulate the change in some way Additional ideas for planning small scale tests. Additional ideas for planning small scale tests.

13. Four parts of the cycle: Plan: Decide what change you will make, who will do it, and when it will be done. Formulate an hypothesis about what you think will happen when you try the change. What do you expect will happen? Identify data that you can collect (either quantitative or qualitative) that will allow you to evaluate the result of the test. Do: Carry out the change. Study: Make sure that you leave time for reflection about your test. Use the data and the experience of those carrying out the test to discuss what happened. Did you get the results you expected? If not, why not? Did anything unexpected happen during the test? Act: Given what you learned during the test, what will your next test be? Will you make refinements to the change? Abandon it? Keep the change and try it on a larger scale? Four parts of the cycle: Plan: Decide what change you will make, who will do it, and when it will be done. Formulate an hypothesis about what you think will happen when you try the change. What do you expect will happen? Identify data that you can collect (either quantitative or qualitative) that will allow you to evaluate the result of the test. Do: Carry out the change. Study: Make sure that you leave time for reflection about your test. Use the data and the experience of those carrying out the test to discuss what happened. Did you get the results you expected? If not, why not? Did anything unexpected happen during the test? Act: Given what you learned during the test, what will your next test be? Will you make refinements to the change? Abandon it? Keep the change and try it on a larger scale?

14. Structure to support learning refelction and keeping one foot ahead of theother �.. Always plan one more ot twomore ahead �. Structure to support learning refelction and keeping one foot ahead of theother �.. Always plan one more ot twomore ahead �.

15. Do Study Reasons for failed tests 1. Change not executed well 2. Support processes inadequate 3. Hypothesis/hunch wrong: Change executed but did not result in local improvement Local improvement did not impact access or efficiency Collect data during the Do Phase of the Cycle to help differentiate these situations. There are a number of reasons why tests may fail (not get the predicted results). It is important to emphasize that failed tests are often more important than successful ones, because the learning is often richer and deeper. Encourage the open discussion of failed tests and maximize the learning from them. Don�t let the team get discouraged, but always use the results of the test to move forward and plan the next test. There are a number of reasons why tests may fail (not get the predicted results). It is important to emphasize that failed tests are often more important than successful ones, because the learning is often richer and deeper. Encourage the open discussion of failed tests and maximize the learning from them. Don�t let the team get discouraged, but always use the results of the test to move forward and plan the next test.

16. This diagram illustrates how our hypothetical team that is trying to achieve improved access actually carries out tests in several different categories of changes. In order to effect improved access, the team probably cannot rely solely on reducing appointment types. Changes in other areas such as standardizing panel size, establishing protocols for scheduling, or maximizing all members of the care team should be considered. These multiple changes can be made simultaneously or can be folded in at planned intervals. We encourage teams to try �packages� of changes to achieve maximum results. At a later stage, specific changes can be removed to assess the impact of a particular change on the overall result. This diagram illustrates how our hypothetical team that is trying to achieve improved access actually carries out tests in several different categories of changes. In order to effect improved access, the team probably cannot rely solely on reducing appointment types. Changes in other areas such as standardizing panel size, establishing protocols for scheduling, or maximizing all members of the care team should be considered. These multiple changes can be made simultaneously or can be folded in at planned intervals. We encourage teams to try �packages� of changes to achieve maximum results. At a later stage, specific changes can be removed to assess the impact of a particular change on the overall result.

17. Measurement and Data Collection During PDSA Cycles Collect useful data, not perfect data - the purpose of the data is learning, not evaluation Use a pencil and paper until the information system is ready Use sampling as part of the plan to collect the data Use qualitative data rather than wait for quantitative Record what went wrong during the data collection Every PDSA cycle needs a feedback mechanism. During a cycle, we have global measures. We need something to tell us about the particular cycle. Some of the most important data are qualitative. Record what went wrong with the data collection. What the reactions are of the people involved in a test. Good question to ask�what�s wrong with these data? Data are even more useful when you know what is wrong with the data. Document what is wrong with the data. Every PDSA cycle needs a feedback mechanism. During a cycle, we have global measures. We need something to tell us about the particular cycle. Some of the most important data are qualitative. Record what went wrong with the data collection. What the reactions are of the people involved in a test. Good question to ask�what�s wrong with these data? Data are even more useful when you know what is wrong with the data. Document what is wrong with the data.

18. This is an example of an annotated run chart showing patient cycle time during a clinic appointment (from the time of arrival to the time of departure from the clinic). The chart contains boxes that explain the specific changes that were introduced in the clinic system to try to reduce the cycle time, including: - Using huddles to review each day�s schedule and plan for special patient needs, absent providers, etc. - New scheduling templates - Matching each patient with their primary care provider, etc. The team learned quickly that the initial changes that it made had some immediate effect on their cycle times, but that additional changes were needed to further reduce delays and sustain the improvement. This is an example of an annotated run chart showing patient cycle time during a clinic appointment (from the time of arrival to the time of departure from the clinic). The chart contains boxes that explain the specific changes that were introduced in the clinic system to try to reduce the cycle time, including: - Using huddles to review each day�s schedule and plan for special patient needs, absent providers, etc. - New scheduling templates - Matching each patient with their primary care provider, etc. The team learned quickly that the initial changes that it made had some immediate effect on their cycle times, but that additional changes were needed to further reduce delays and sustain the improvement.

19. This is an annotated run chart for the same team, showing reductions in delays in patients obtaining an appointment. The most important change was for the specific providers to begin working same day appointments into their schedules rather than putting those appointments off into the future. This allows the providers to reduce their backlog for future appointments and to begin the process of �doing today�s work today.�This is an annotated run chart for the same team, showing reductions in delays in patients obtaining an appointment. The most important change was for the specific providers to begin working same day appointments into their schedules rather than putting those appointments off into the future. This allows the providers to reduce their backlog for future appointments and to begin the process of �doing today�s work today.�

20. Accelerating Learning and Improvement What cycle can we complete by next Tuesday? Willing to compromise on scope, size, rigor, and sophistication, but the cycle must be completed by Tuesday. Teams are given the assignment to complete a test of a change by the next Tuesday following the first Learning Session. This forces the teams to think small in terms of scope and size. They should be encouraged to select the most exciting idea that they�ve heard during the Learning Session and plan a test for using that idea immediately. Teams report the results of their tests on the Collaborative listserv (or other communication system) by next Tuesday. The first conference call following the Learning Session can focus on discussing the tests, and using the examples to emphasize key points about designing and carrying out tests. Remember to encourage teams to report failures as well as successes! Teams are given the assignment to complete a test of a change by the next Tuesday following the first Learning Session. This forces the teams to think small in terms of scope and size. They should be encouraged to select the most exciting idea that they�ve heard during the Learning Session and plan a test for using that idea immediately. Teams report the results of their tests on the Collaborative listserv (or other communication system) by next Tuesday. The first conference call following the Learning Session can focus on discussing the tests, and using the examples to emphasize key points about designing and carrying out tests. Remember to encourage teams to report failures as well as successes!

21. References The Improvement Guide: A Practical Approach to Enhancing Organizational Performance. G. Langley, K. Nolan, T. Nolan, C. Norman, L. Provost. Jossey-Bass Publishers., San Francisco, 1996. Quality Improvement Through Planned Experimentation. 2nd edition. R. Moen, T. Nolan, L. Provost, McGraw-Hill, NY, 1998. �Understanding Variation�, Quality Progress, Vol. 13, No. 5, T. W. Nolan and L. P. Provost, May, 1990. A Primer on Leading the Improvement of Systems,� Don M. Berwick, BMJ, 312: pp 619-622, 1996. �Accelerating the Pace of Improvement - An Interview with Thomas Nolan,� Journal of Quality Improvement, Volume 23, No. 4, The Joint Commission, April, 1997.