EHRs Fail to Account for the Unexpected, a Constant in Healthcare

While getting breakfast this morning in the hospital's cafeteria I again marveled at Manny¹, the short-order cook, First of all, Manny remembers what most of the "regulars" order and, when we are near the front of the line he starts cooking our food. He usually has three or four custom omelets, a grilled cheese sandwich, and a pancake going simultaneously. He never overcooks anything and wastes very few steps. Needless to say, the line moves quickly and everyone is grateful.

Fortunately for Manny, he gets time off, but unfortunately for us, when he is off other kitchen staff tend to the grill. Things come to a virtual standstill. The orders are prepared one at a time and the preparation doesn't begin until we get to the head of the line and try to explain (over the din) what we want.

The technorati have a name for a group of actions that must be carried out get a job done - they call it "workflow." Manny's workflow is efficient but unpredictable. It's efficient because he is talented and motivated, not because someone worked out a precise series of steps for him to follow. Give him a job and he gets done and done efficiently.

The other cooks are neither talented nor particularly motivated. They tackle the tasks in sequence with little or no overlap. Their work could be precisely scripted and dictated to them by a computer.

The organization that runs this cafeteria is gearing up to install an EHR - one of the big, expensive ones. I spent the afternoon with a colleague that has experience installing this product. As it was explained to me, the system revolves around hundreds of pre-defined workflows (or more?). Each workflow is a detailed, step-by-step procedure spelled out for every little thing, such as providing a wipe for a patient to use before collecting a urine specimen. Each workflow is assigned to a specific role such as a nursing attendant. Since not every nursing attendant is allowed or expected to do everything, the role definitions must be refined and many new variants created so that there is an appropriate role for each staff member - one that allows them to do everything they may ever need to do but nothing they are never allowed to do. It is anyone's guess as to how to handle those situations, such as emergencies, that invariably arise but were never anticipated. Reports in the literature, such as the one from "a large university hospital"¹ about unexpected mortality in the ICU after installing this product, suggest that what happens is that patient care suffers and patients may even die.

But wait… it's even more complicated than that. Before the roles can be defined, all of the supplies, tasks, and who knows what else must be defined in a "dictionary." Those assigned the task of defining the dictionary are expected to do their work at a time when they have no experience using the system. As a result, they have no clue about how the definitions they are creating will affect what kind of workflow can be specified or how it might affect the user experience.

A doctor's (or nurse's) day is much like that of our short-order cook. The work lines up like people waiting for breakfast. Every problem is different and urgent in someone's view. Doctors respond to this in the same way Manny does - they start several things in parallel, shepherd them along and try not to let any "burn."

The kind of EHR that I believe people imagine is one that would help clinicians manage this chaos. Such systems are as rare as hen's teeth. Another kind views medical practice as a production line that can be reduced to a series of steps that conform exactly to some imaginary view of care delivery. Large organizations are often fond of these because they provide an illusion of "control." A third kind is largely neutral, scripting a few operations such as ordering and medication administration, but generally neither interfering with clinician's decisions about timing and sequence nor helping to manage the chaos.

Systems, like the one my institution is adopting, are intrinsically brittle (fragile, to use Nassim Taleb's term). Their success depends on a myriad of unrealistic assumptions. They fail to account for the unexpected and have little ability to absorb anything that was not explicitly anticipated by the implementers or designers. In short, when put under the stress of real life, rather than bending gracefully, they shatter.

Would you commit a billion (or a thousand) dollars to a system like this?

What chance is there that the ultimate cost of a system like this will be anywhere close to the amount budgeted? Historically, the cost of these large, fragile systems skyrocket out of control as reality, and the unexpected, rear their ugly heads.

[^1] Names have been changed to protect the innocent