Welcome to our session on Spreading Quality Improvement Changes. In this session we'll focus on moving beyond the one test of change. It's a many test of change, and eventually spreading your ideas in lessons learned. I'm Melody Malone, a Quality Improvement Consultant with TMF Health Quality Institute, and I'm happy to present to you this session on Spreading Quality Improvement Changes. But we before we begin, let's remember that I we use data, as we work to the model for improvement, and as we work to spread our changes to get sustainable improvement, we are learning about our mistakes and our errors, and we must never forget the potential human tool as a result of clinical error and errors in our business practices. Even though we will speak a lot about data and our quality improvement work we must always remember that every piece of data may actually represent a hurt to human being, or has the potential to hurt someone, every resident matters, every guess matters, every staff member matters. As we move into this concept of spreading changes this is assuming that we've already completed our Root Cause Analysis, and address what human factor has played a part in our problem. This is the assessment component of our clinical process. Our critical thinking skills are vital to a thorough and complete Root Cause Analysis. So we complete Root Cause Analysis and then we move to the model from improvement, and to address those three questions of quality improvement; what are we trying to accomplish, how we will know that a changes and improvement, and what changes can we make that will result in an improvement. Really launches our quality improvement process and moves us into the Plan-Do-Study-Act Cycle, which we called a test of change. And hopefully by now, you're already gotten to this point but you maybe asking yourselves, "Why do we test?" Well, keep in mind in Quality Improvement we know that ideas are great, but it really the "how" that are on trial. How we will implement this? How we will insure that we can get to a sustainable level of Quality Improvement? Will that change that we want to make that great idea actually result in an improvement? So let's think about an idea such as for pressure ulcer prevention, we decide to pick cushion in a wheelchairs, but this caused an increase in falls. Well, why? Because the chair is no longer fit the resident. We learned that rehab needed to be involved for proper fit, better cushion selection, and perhaps a different program as well, such as wheelchair pushups or walking program. But in this case the facility bought too many cushions that they couldn't use, and not enough for the ones that did need. So their "how" was on trial. They had a great idea wheelchair cushion, but they hadn't work through the quality improvement process to ensure that they can get to a sustainable level improvement. And then, another reason to test is to determine how much improvement will we really get. Well it may work for some or on others not all. So, in quality improvement we test so we have more learning. We test, so we can share failures with others. We test because I'm convinced this work, but I just don't know how much. We test because it will work in my organization. And it helps us build a business case. A business case for a quality improvement that it's worth the effort, it's worth the purchase such as the wheelchair cushion. So why not start with implementation? Well, there's a difference between testing and implementing. Testing let's you work the bugs out. Implement requires finalizing policy and procedure. You may have to completely rewrite some job description or entire processes in order to make this works. In test, there will be volunteers, but some people may never implement, but they will test, but they never get convince. So, we always want to test so we can get to that sustainable improvement. And we test because test is in a few days we can accomplish something. Implementation may not take weeks or months. The other benefit of testing is we gain confidence in our new process through our test of changes. This helps us get our continued compliance and helps us move out of a model of in and out of compliance, which is what I always think of when I hear someone say, "We're getting ready for survey." Well, if we're always working in compliance with our policy, or procedures, our quality processes, it will always survey ready. So we test, we learned, and we gained a commitment of other who will then began implementation. But in order to get to successful sustainable improvement we do have to do the cycles of testing and adapting our changes. And how quickly you run your first cycle of chang, determines how successful you really will be. You do need to do a successful plan ahead of time, that's why you do your deep Root Cause Analysis, so you try to identify all your possible changes you can make. But when we're doing testing, we always scale down. We're doing small number residents, or staff, a small location, and as we grow our test of change for this single idea, then we grow that to more people involved, more location. But one thing to keep in mind in doing our test of changes, we're not trying to do research here, so we're not trying to collect oodles and oodles of data. We want to collect just in case data. We want to collect just a data we need to prove our case or disapprove. So keep in mind that as your testing changes, you're going to do multiple test of change. So you eventually, you can roll up to implementation in a sustainable level of quality improvement. Now, remember I keep talking about cycles of testing changes. What I meaning is the Plan-Do-Study-Act Cycles of the model for improvement. So we may have multiple cycles. We may do six cycles of testing changes, because we are working on a quality improvement process. So for example, let's look at our resident a concern in a facility on fall risk. So you may start with one resident who is a frequent faller. We learn and gain confidence from that resident, then we need to move a cycle too where we can involve more residents that have fallen, maybe residents on his unit. Then we move cycle three, which could be all residents who fallen in a facility. The cycle four maybe to all new admit. And then our next cycle might be to the preadmission hospital setting, and give them some ideas of how they can handle residents without restraints who are fallen. And then our last cycle might even be to move out into the community to get involve of people who haven't even thought of fallen yet, at least not like fallen like we think. That will be how our doing multiple test of change. Now, this repeated use of cycle allows to move from the bottom left of this model, from Hunches theories and ideas, where we're doing very small scale test of change, to up to the top right where we actually get to a point where we are in full implementation and we're spreading our changes, our changes that resulted in improvement. So it kind of start up with; "I have an idea. I'd like to make it work. I'd like to improve this process." So we do that small test of change continuing to do followup test, learning, reworking, adapting our process, to wide or test of change, more difficult situations maybe residents that are bit more challenging, residents from different culture, different providers, different situation like some weekend, some holidays, challenging times. And then eventually, we get to the point where we spread things on a wider scale to hospital or the ambulance companies, or other nursing homes in your company, or your community, or even on the TMF Website, in our foreign, or innovations.
^M00:10:01 You could spread to the entire community. This is not one test, but many test of change. And it's like when you're trying to learn a new instrument, a new tool, or new skill. You keep learning and gaining confidence because you do a lot of learning. Think back to when you are learning something new, maybe in school when you are leaning how to take a blood pressure or something like that. You didn't just do it ones and get it. You did it multiple times. You learn how to do it differently. You learned in different setting. You learn on different individual. That's just like the quality improvement process. Being sure that we deal with special circumstances will help insured that we when get to our full implementation and spread that this is become a full prove process. Another way to look at this is to think about your team that's working in the Root Cause Analysis may have come up with several issues. So for example, in this facility this--they want to maintain their zero facility acquired pressure ulcer status. And they want to sustain this over a long period of time, and they determine that they had family involvement that needed to be worked on, that they needed to work on Braden Assessment Accuracy, DNA daily skin sheet, dietary strategies and laundry services. So they have multiple teams working to one goal and zero facility acquired pressure ulcer status. But it's through the multiple test of change that they get to a sustainable level of improvement. So this might be a better mental model for you is multiple team working to one outcome. Now, you may not always have multiple teams working on a quality improvement process. But this will give you an idea if you do have a complex problem such as facility acquired pressure ulcers and trying to get to and sustain that zero status. Keep in mind, the work sheet for testing change is a method for you to document your model for improvement. So each one of your test of change will be documented, which gives you a way to share that quality improvement throughout your organization, so that we become a learning organization. To be a learning organizations, we have track our quality improvement efforts, we have to learn from our test of change and we have to share that information. The only thing not documented on the worksheet for testing change is your Root Cause Analysis. But that would be companion piece to this, or any other form you may choose to document your test of change. Oftentimes if you ask someone when they can get that done whatever that maybe their quality improvement process. They will push out the timeframe as far as possible. Well, keep in mind we're not doing research here, so we don't need to take a year just to get a test of change done. So, if you have a project in mind, shorten your timeframe for what you thought it might take to get it done. Drop it down by at least two timeframes. So if you thought that you are going to do within a year, then this turned into month. Or if you started thinking you could do it in a quarter, maybe you'd been thinking you can do it next week. If you heard your team say, we can do that in a month then you should say what we can do by the next day. It's possible to try things quickly with a few number of people. Remember, we're starting small and learning to add, and add more people to the process. So always get your timeframe as sort as possible. The faster you do your test of change, the more successful you will be. And I want you all to be a successful. And if there's one thing I can get you to do, it would be to do your first PDSA cycle as quickly as possible. And in order to get it done remember, we're willing to compromise. We're going to compromise on scope. We don't need a lot of people involved to do one death. So we're going compromise on a little bit of sickness and a little bit sophistication that will come as we build our test of change. Remember your goal, is testing our death in a change. Eventually, implementing an improvement and then spreading improvements to the rest of your organization and to the world. So, determine your first test of change and go do it. What can you do by tomorrow? Then, do the next test just as quickly as possible. Learn, learn, and learn some more and spread changes and get to implementation and then share it with us on our Website. We're here to help you. Feel free to contact us if you have any question, and I applaud your effort in quality improvement. Get on with your model for improvement in running your PDSA cycles.