Let’s face it…patient care documentation is not the most enjoyable aspect of clinical care delivery. It takes time, the electronic medical record isn’t user friendly, and caregivers have a lot going on. It’s no surprise improving clinical documentation is a common improvement opportunity for a project.
On a recent coaching call, leaders were sharing their improvement work. One presented a project to improve the timeliness and completeness of the medical record following a patient encounter. This was apparently a chronic issue and he was keen to fix it. Here’s how he framed his thinking: “Getting people to document right after they see the patient and to do it thoroughly is always a problem. They just don’t do it. My staff is pretty competitive by nature, so as a change idea I’m going to test posting data on individual compliance and reward the top performers and see if that helps.”
Whenever a change idea is suggested, I always want to understand the theory behind it? What do you think the underlying causes might be and walk me through your thinking as to how this will fix it?
Compliance, accountability, competition, reminders, memos, and education are all common initial change ideas people propose. No surprise there. A common theme you hear with these interventions is the assumption the process is designed to achieve the desired result and it’s people that are the quality issue. What’s being proposed does not improve the process. It focuses on the user as the opportunity for improvement.
I shouldn’t be surprised but it can be striking how common this happens with novice improvers at the start of a project. This is where improvement science can be a game-changer in shifting perspectives on how to change and get results. As we start to see the results we have are linked to the design of the process we have, wouldn’t it make sense to start with the process if we want to get a different result?
The User’s Journey
How can we quickly learn how a process is set up and working? The first step is to follow the user’s journey. What’s it like for them as they move through the process? Imagine you are that leader trying to improve documentation. Watching a caregiver journey through a patient encounter will yield valuable information about how documentation occurs, when it happens, the experience of using the physical hardware and software platforms, and where issues exist.
Using the PDSA cycle for data gathering is great here. What learning questions do you have before you look? What do you predict you will see? Returning to these as you study what actually happened enhances the learning.
You can also begin to sketch out the steps of the process and early observations. What do you see happening at each step? What’s not clear? What are the barriers? Where is there a built-in opportunity to vary or make an error? Are there multiple ways things happen? A simple pencil and paper are all of you need to capture these valuable insights.
Many times just following a small sample of encounters will yield enough information that the system is not where it needs to be to get reliable results. It’s also very hard to unsee the improvement need when you’ve witnessed it with your own eyes. Want to get a different result? We need to change the system.
How do we learn what to do?
When I was a novice improver, one of my first QI projects was to improve paramedic use of an evidence-based protocol to assess a patient’s risk of spinal cord injury after a traumatic event. This was a major shift in practice at the time and individual case “errors” were reported daily to review and “coach” caregivers.
As case reviews continued to come in, we decided we better look at the process as a whole before we talked to individual caregivers about their adherence to it. We started with a sample of the next thirty patients that fit the criteria for the protocol. We barely made it to thirty before a pattern of issues made it obvious the clinical care process was not designed to get the desired results. This was not a caregiver issue.
A sample of thirty is a great place to start. Jay Arthur calls this the “Dirty Thirty” process for breakthrough improvement. Looking at thirty cases offers several advantages.
First, when collecting data, a good rule of thumb is to collect just enough and not too much. I’m not sure who to attribute that bit of wisdom to, but it’s very true. Thirty cases frequently are plenty to achieve data saturation. This is a qualitative data concept known as the point at which no new data or themes emerge.
Second, thirty is just enough data to create a Pareto Chart and look at the frequency of defects occurring. This helps you sift out the issues that are contributing most to the problem which is a great place to start and to make the biggest impact.
Third, thirty is a perfect amount of data to display over time and create a Shewhart SPC chart with confidence the special cause rules will apply.
Finally, thirty is a reasonable investment in time and resources. A review of thirty can be done quickly and with a limited number of people. It efficiently supports figuring out what’s happening so you can pivot your time and energy on changes that will result in improvement.
Following the user’s journey through the process and looking at a manageable sample of thirty cases provides you a better understanding of how it works and what specifically needs to change.
Now you can use a framework like the Model for Improvement to set an aim for what you want good to look like, to define a set of measures linked to the process you now better understand, and to propose change ideas to test. PDSA cycles with users will help you refine the process and the measures will aid you to know when your changes are working. To implement your changes, you may need to update documentation and education, but now it’s with the intent of providing new knowledge about an improved system. A system, which is now built to get the results you want.
If this was helpful, share and include me @DaveWilliamsATX. Subscribe to receive a monthly curated email from me that includes my blog posts and Improvement Science resources I think you’d appreciate.