| | JUNE - 20239UTLOOKHealthcare Tech harm. We need to challenge our thinking, specifically about the daily realities of healthcare delivery. We would do well to understand and apply concepts from the discipline of resiliency engineering to advance a different strategy to safe, particularly with regard to mitigating the risks of medical errors. It is unreasonable to expect to get the intended correct outcome, and avoid errors the first time (reliability) and expect process reliability from a system with true irreducible complexity, where the risks are additive, parts of the system are poorly defined, and/or interact in ways that are unpredictable, is an insufficient model to deal with the truth about patient safety and what happens at the point of care delivery. While process reliability is a reasonable frame to advance quality improvement, it is a poor model for capturing the challenges to delivering safe care. To impact patient safety going forward, we need to shift our focus on system reliability to system resiliency. Our clinical operational systems should be engineered and designed to identify errors early, and rescue patients from errors turning to failure. And if failure is already present, then restricting spread and containing it from turning into catastrophic harm. Our effort should be to build more resilient systems, that learn from errors and near misses, that make it easier to do the right thing, and harder to do the wrong thing (a system property called Anti-fragility), Here is a good example. Consider the use case of a Central Line Associated Blood Stream Infection (CLABSI). No one intends to miss a daily CHG Bath for a patient with a central line, that can lead to a CLABSI. We expect that there is a duty to produce the outcome of a daily CHG Bath. But then reality happens. Imagine a floor where a nurse is covering an extra two patients, because of a call out. There happens to be a code on the floor that day. There is a new nursing student on the floor that day that has a lot of questions. Its change over day for the hospitalist team. And there is a unexpected emr downtime that day. The work as imagined is that we will do an CHG bath, regardless of those constraints. But that is an improbable outcome. The work as done is dictating a different reality, that demands more adaptability and resiliency to get the CHG Bath done. Missing a daily CHG bathing on a 12-hour nursing shift, is an omission error, not yet a CLABSI. As an isolated event, the omission error is not a failure, as if we can recognize the missed CHG Bath at handoff, and can rescue the patient from the omission error on the next twelve hour shift. If we do recognize this error, we can reassign the bath and we will likely prevent that error from turning to partial failure (no CHG bath in 24 hours), or full failure (CLABSI), or spreading failure (Line sepsis), or catastrophic failure (death). We need to appreciate that the daily unit level work driving patient safety is unlike a production line were concentrating on process reliability alone will get us to safe. There is too much out of our control impacting the best of our intentions. We need to recognize the irreducible complexity in healthcare, which means that we will not "process improve" our way to safe; we will not "culture" our way to safe; we will not "educate" our way to safe; we will not "policy" our way to safe. We will get to safer care only by not oversimplifying the many parts of our system and how they interact, applying the right improvement model, methods, tools, and tactics largely from the disciplines of Human Factors and Systems engineering, that account for the limitations of human capability and capacity to do work. If we are successful at integrating resiliency engineering principles and practices into our system tools and process to anticipate, identify and rescue errors from turning into failure, we may have a better model for dealing with our brave new world, and deliver on the promise of care that our patients expect from us. HTModern safety science has shown that it is the operating systems that define the culture of safety. Not the other way around
< Page 8 | Page 10 >