Being Bumpable

This week we have a paper that is more of a story from Dr. Richard Cook, published in Proceedings of the Fourth Conference on Naturalistic Decision Making.

It’s about an event at a teaching hospital that takes place in the ICU. Though the story takes place in a medical setting, there’s still lots to take away for software systems

Being Bumpable
Cook uses this story that happened in this ICU to very clearly demonstrate that both technical and organizational issues are at play when experts are making decisions. The story also gives us a chance to think about these stories in our own organizations that are not being told.

It also demonstrates the complex interconnectedness between domain knowledge and practice that is often unregarded or poorly qualified during investigations of accidents.

He points out that just telling this story to us requires a massive amount of backstory. And this is the shortened version of the story. And in it, there is really no especially complicated medical jargon or anything like that. You don’t need to be a surgeon to understand it. But what makes this story at least somewhat difficult to tell, and the reason it takes over 10 pages and almost 30 steps to do so, is that it can be difficult to set all of the organizational context in place for us to benefit from this story.

Language is technical and organiational

This is partly because in addition to organizational features shaping the decision making of experts, it also shapes the language they use and the coded lingo they develop. That language communicates technical things of course, but also speaks to something about the organization.

Further, many of the terms and conditions described by Cook, mean different things to different people. This is true even in that same hospital come even amongst departments. Let alone across other hospitals and other departments.

What are the different types of ICUs? Why can’t you just set up an ICU anywhere on a consistent basis? Even as small as “what is a bed?” (Its rarely, though sometimes about a physical object in which someone lays down, both in this tory and in my experience in other ERs).

This is reflected in not only the decisions we can see being made in the story, but also in the language these practitioners are using. Even the phrase from the title, “bumpable” is a judgement call that takes into account the patient and the hospital departments and does not have a solidly defined criteria, yet decisions are continually being made about it.

The story

Here’s my even more shortened version of the story:

• An ICU “bed” (collection of resource) was needed
• To help plan for this someone is given the role of bedmeister to keep track of who might be able to be “bumped”
• Being bumped is a judgement call on who could be transfered elsewhere that may no longer need ICU care
• Elective (non-emergent) surgeries that will require ICU post operative care are required to be booked
• An ICU of sorts can be improvised in a different room, but it is very expensive since it blocks other procedures from taking place.
• There end up being two patients who are undergoing procedures who need space in the ICU. One is going to get it, the other, will have to wait an improvised ICU.
• A bed that is large enough to transfer the patient and equipment is brought down to the operating room. It is brought by a new employee who didn’t know the convention and places it closer to the operating room for the patient who would normally have to wait
• This is seen as an indicator they no longer have to wait
• As a result an improvised ICU area has to be setup, which causes a room and extra resources to be taken up.

Ultimately, the incident got chalked up to “human error” on the part of the newer patient care technician who placed the bed.

No revisting of the policies or conditions that led to the hiding of resources being normalized, no reconsidering the roles, for example, whether or not it makes sense for the bedmeister role to be occupied by someone who has patient care duties

And while, as outsiders, its easy to sort of scoff at this and say that we wouldn’t do that, I think often times, in various software organizations we do.

Even if we (or they) are not sactioning the person, the “resolution” is simply to have more training or experience on that persons’ part.

Learning from marginal events

Because this system typically runs at or near capacity, it is the marginal events and circumstances that are the focus of attention, that threaten to saturate resources, that generate disputes, rancor and confusion, and that elicit expertise

This is the value of these stories, a chance to learn about the “marginal events”.

Another interesting thing about this sequence of events, is that it reveals optimizations being made to try and preserve adaptive capacity. As you may remember from our previous discussions about the adaptive universe, these are mostly local optimizations that may be hurting the system as a whole (working at cross purposes).

This is especially true in the case of not telling the department that the bed was freed, but keeping “just in case”.

Not only do expertise keep organizational shape and issues in mind when making decisions, but the organizational factors, not just the technical factors also affect and refine that expertise.

First vs Second stories

Cook also mentions an important concept, the idea offirst vs second stories. The first story is typically a shallow, sometimes knee jerk reaction that we might tell about an event. It’s important to get past this first story and tell or hear the second story. This second story is where real leanring can take place.

In this case the first story is:

A patient needed care in an intensive care unit after surgery. The patient was unable to be moved directly to the intensive care unit after surgery because there was no bed available in that unit. The patient was taken first to the recovery room and later transferred to the intensive care unit

That’s it. Is it wrong? No, it doesn’t say anything untrue, nor does it say anything helpful though. The second story, what takes the remaining 10 or so pages to tell is what’s important.

Takeaways:

• Its important to tell and listen to second stories
• Expertise is shaped by both technical and organizational factors
• As a result, the coded language we use as experts reflects both technical and organizational ideas at once.
• Telling richer second stories can be difficult, because it can be easy to think of them as just another day on the job, but if we can step out of this, there is a lot to learn.
• When you reach a point in an investigation where you find “human error,” this is a chance to do dig deeper and find out what features of the organization or situation may have contributed.