Don’t Just Do Something – Sit There!
Hospital and medical dramas are ubiquitous on TV (For some of my younger readers, I’ll point out that TVs are things that we used to use to watch Netflix and Amazon Prime shows back before we had Netflix and Amazon Prime shows. See my OK Boomer! post for more details.) A staple of the hospital drama is the attending physician wearing scrubs and a white coat running into a patient’s room during a Code Blue. Most of us know that Code Blue (or for the cool and hip among us, simply a “code”) is an alert that goes out throughout the hospital notifying clinicians that a patient’s heart has stopped beating. When a code is called via the overhead speakers, assorted clinical folks rush into the room to start CPR, insert a breathing tube, and give medications to try to revive the patient. It’s quite intense.
As a third-year medical student, I was taught three important lessons about responding to and managing a code. First, never run to a code. Sure, it looks cool to run through the hospital and up the stairs to attend to a patient who is clinically dead. Especially as a trainee, the rush of adrenaline and belief that you look like a young George Clooney is appealing. But once you get to where you’re going, you are in no position to think clearly. I learned this after being awake for 24 hours, having just eaten breakfast in the basement cafeteria, and running up five flights of stairs. I was trying to not vomit by the time I got up there; that was bad. I was not helpful.
Second, I was instructed that the initial procedure you should perform at a code is to check your own pulse. Don’t get me wrong; checking the patient’s heart rate is a good thing! (Of course, if the code was called accurately, the patient doesn’t have a heart rate at this point, but I digress.) By checking your own pulse, you are reminded to calm down and begin to think clearly about the problems at hand. There are many reasons for a hospitalized patient to be found pulseless, so ensuring that the caregiver can think clearly is of utmost importance.
And finally, a wizened professor taught her students something a bit counterintuitive: at a code, don’t just do something – sit there! No, this isn’t a typo. If a non-clinician were in a room watching a code unfold, I’m quite confident the observer would be mentally giving the opposite advice: don’t just sit there – do something. The patient is dying and something . . . anything . . . must be done. Yet, experience and reason prove the opposite is true. Barking out random physician orders without forethought can cause more harm than good. During a stressful situation like a code, it’s essential to keep your wits about you and proceed through a well-rehearsed and thoughtful series of interventions. Further, when the patient isn’t responding as you’d predict, take a time out and reconsider the situation. Perhaps assumptions that you made are no longer true or were never true in the first place.
This final piece of advice can be helpful for those of us in information technology (IT) or clinical management leadership roles. If we find ourselves in a sticky situation and our usual toolbox of tricks isn’t working, the best thing to do is stop and just sit there. Quietly contemplate the situation. Rethink your strategy and how you got to where you now find yourself. Did you make assumptions at the beginning of a project that just are no longer true? Did you misunderstand the real incentives underlying why some folks act as they do? Are you open to different ways of thinking to solve a problem?
A few years ago (or maybe more than a few), I was assisting a physician leader as his hospital implemented an electronic health record (EHR). I was experienced at doing large IT implementations, and my colleague was . . . not. While he took much of my advice to heart, he pushed back on my recommendation around order set build. I told him that when most hospitals move from paper to an EHR, they create way too many order sets. Since each order set can take many hours of subject matter expert (SME) and technical expert time, it’s important to get the biggest bang for your buck. My suggestion was to go live with a small number of order sets, let doctors use them, and after a few months, you’ll be able to truly identify any actual needs. Suffice to say, this hospital didn’t listen and built a ton of order sets.
At a post-live visit, my physician leader friend and I toured the hospital floors, randomly talking to docs. When he approached one physician and asked him how the XYZ order set was working out, the doctor looked confused for a moment. Then he replied, “Oh yeah. I know we thought we really needed that order set, but truthfully, I hardly ever use it.” After this doctor walked away, I scowled at my friend and asked him if he now regrets his decision to do so much unnecessary build. He replied, “No way. I’d do the same thing again. You don’t understand our organizational culture. I gave some of these docs tools I knew they wouldn’t use so I could get him on my side. Further, once I gave them what they asked for, they couldn’t complain about other aspects of the project. That wouldn’t be tolerated by our leadership. That time and money was well worth keeping them from exploding, even if they were wrong.” I made certain assumptions about that IT project that weren’t quite accurate, at least at that hospital. The next time that happened, I sat down and reconsidered where I had been, where I was going, and how best I could get there!
Have you averted disaster by just sitting there and not doing anything? Reach out to me and tell me about it.