The EHR Is Only as Good as the Workflow Around It

Every few years a hospital spends a fortune on a new electronic health record and expects care to get better. Sometimes it does. Often it doesn't — and the software gets the blame. After years of documenting in Epic on a busy floor, then stepping into the operations side to evaluate these systems, I've become convinced the problem is almost never the software. It's the workflow no one designed around it.

An EHR is not a solution. It's a surface. It faithfully reflects whatever process you point it at — including a broken one, only faster and with more clicks. When a rollout fails, it usually failed at the workflow layer long before anyone opened the application.

Technology inherits the process it's given

If a discharge process is ambiguous on paper, digitizing it doesn't make it clear — it hard-codes the ambiguity into a screen that fifty people now have to fight. If two units document the same event three different ways, the EHR won't reconcile them; it will preserve all three and quietly corrupt the data everyone downstream depends on.

This is the part decision-makers underestimate. Buying good software is easy. The hard, unglamorous work is mapping how care actually flows — who does what, in what order, under what time pressure — and fixing the process first. Skip that, and you've spent seven figures to automate your dysfunction.

The people who use it were rarely asked how

The clinician at the bedside is the system's real user, and is almost always the last person consulted about its design. So we get well-meaning features that add three clicks to a task done four hundred times a shift, mandatory fields that don't match how care unfolds, and alerts so frequent that staff learn to dismiss all of them — including the one that mattered.

Alert fatigue isn't a personal failing. It's a design failure. When a system cries wolf a hundred times a day, ignoring it becomes the rational, survival-level response. The fix isn't to lecture staff about vigilance; it's to build systems worth paying attention to.

What "optimization" should actually mean

In health tech, "optimization" often means adding features. I think it should mean the opposite: removing friction. A few principles I hold onto:

Count the clicks on the tasks that repeat. A two-click improvement on something done four hundred times a day is worth more than a flashy new module used twice a week. Optimize the common path, not the demo.

Design for the interruption. Clinical work is not a clean linear flow. It's constantly interrupted and resumed. Systems that assume an uninterrupted user are systems that will be worked around — and the workarounds are where errors hide.

Treat every workaround as a signal, not a violation. When staff route around the "correct" process, they're not being difficult. They're telling you, precisely, where the design fails reality. That's free, high-quality product research — if you're willing to listen instead of writing another policy.

Why this is a public-health question, not just an IT one

It's tempting to file EHR usability under "IT." But the data these systems capture becomes the evidence base for quality measures, population-health analytics, and eventually policy. If the frontline is documenting inconsistently because the workflow forces it, then every dashboard, every trend line, every data-driven decision built on top is standing on sand.

Good health technology, designed around how care is actually delivered, isn't a convenience. It's the foundation for everything we later claim to know about a population's health. Get the workflow right at the bedside, and you get trustworthy data at the system level. Get it wrong, and no amount of analytics will save you.

The best health-tech decisions I've seen didn't start with the software. They started with someone who had done the work, standing in the room, asking a simple question: how does this actually happen today? That question is the whole job.