You Can't Fix a People Problem With Technology

You can’t fix a people problem with technology. Most pitches a hospital leader hears start with the unstated assumption that you can fix a people problem with technology. I would rather be honest, agree that not every problem needs a tech solution, and then we can focus on problems where technology actually helps.

Discharge is human work. It is a case manager on hold with the plan of care in their head, a social worker finding the one facility that will take a patient with a wound vac and a complicated payer situation, a physician deciding whether today is really the day it is safe for someone to go home. It is chasing, judgment, advocacy, and an enormous number of phone calls. A tool that promises to automate the humanity out of that deserves the eye-roll it gets, and clinical leaders are right to give it one.

When I walked this idea through the IT and clinical staff at a large academic system recently, the first question back to me was whether discharge management is a technical problem to solve at all, or a communication problem wearing a technical costume. The person putting it to me had watched, in his words, a lot of solutions that promise to solve a non-IT problem with IT. He was being accurate. And he described how discharge actually works today in a way I have not been able to improve on since: people eventually get where they need to go, but it is a mess, and it takes an enormous amount of people power to get there.

The people are definitely not the problem. The skill is real, the effort is real, and no software is going to replace the judgment or the advocacy that a good discharge takes. If that is where the conversation ends, the skeptic wins, and should. The trouble is that “it’s a people process” almost never gets used to end the conversation. It gets used to justify leaving the process exactly as it is.

”It’s a people process” is not a reason to leave it alone

Here is one comparison, inside a single health system, that is enough to show why that stance doesn’t always hold true.

Two community hospitals, same system, comparable in size, running the same EHR, with similar case mix index. Same system, same caliber of clinicians, same kind of patients. The only real structural difference is that one of them has built a coordination scaffold for discharge and the other had not. At the first hospital, the chief medical officer has turned discharge into a tracked, milestone-by-milestone process inside the hospital’s EHR. The interdisciplinary team rounds on every patient, sets an estimated discharge date, names what has to happen before that date, puts a due date on each of those things, and flags the responsible person when something has not happened. The CMO reviews patients that haven’t been discharged by their EDD and asks hospitals to explain why. The second hospital ran discharge the way most hospitals do, on memory, secure chats, and good intentions.

The hospital with the scaffold holds length of stay far tighter to what its patients’ conditions predict. Its variance between actual and expected length of stay runs close to zero, while the comparable community hospital in the same system runs about 1.7 days behind. Same patients, same clinicians, but different infrastructure, and different outcomes.

This is obviously not a controlled trial. It is one hospital operator looking at his own facilities and telling me that only one of the two had built this process, and that it was, as he put it, proof of concept, that they knew it was going to win. That is exactly what makes it land. It is someone with no reason to flatter the software, watching the same kind of patient get a different result across town. The variable is not the clinicians or staff. It’s whether anyone has built the system that holds the process together on the days the people are stretched.

The word doing the damage is “technology”

The objection sounds unanswerable, and I think it is mostly the fault of one word. Technology conjures something that arrives from outside and overrides the clinician, an algorithm that believes it knows better than the nurse at the bedside. Of course you cannot fix a people problem with that. Nobody wants that, and I would argue against it too.

But a system is not that. A system is just the scaffolding around how work gets done, and technology is one of the ways you build the scaffolding. The moment you replace “add technology” with “fix the system,” the objection loses its grip, because nobody who works in a hospital believes a broken system should be left alone on the grounds that good people work inside it. That is the opposite of what they believe. They live inside the broken system every day, and they are the ones asking for it to be fixed.

Healthcare has had a version of this argument before, and it settled it. For a long time, medication errors were treated as a failure of individual carefulness. The remedy was exhortation, telling clinicians to be more careful, to check the five rights, and to concentrate harder. When something went wrong, the reflexive question was who had not been paying attention. In 1999, the Institute of Medicine report reversed that diagnosis. The harm, it argued, was not a property of clinicians’ competence, their good intentions, or how hard they worked. Good people were working in bad systems. The evidence behind that shift traced roughly three quarters of adverse drug events to systems failures rather than to individual mistakes.

I want to be precise about what that precedent proves, because it is easy to overclaim it. The old fight was “blame the person vs. fix the system”. It was never a fight about whether you could use technology in medicine, and I am not going to pretend the doubters were arguing against software and lost. What was reversed was the diagnosis, from a people problem to a system problem, and that reframe is the entire lesson I am borrowing.

What moved the numbers afterward was infrastructure. Computerized order entry, which pulled the prescription out of handwriting and ambiguous verbal orders and put it into a structured system, roughly halved medication errors. Barcode verification at the bedside did the same. I am deliberately saying errors and delays, not lives, because the mortality evidence for health IT is mixed and I am not going to dress it up as something it is not. The narrower claim is the solid one: the infrastructure reduced the errors.

Barcode scanning is the example I keep returning to, because of the line it draws between what it did and what it did not do. The five rights, right patient, right drug, right dose, right route, right time, were a protocol that lived in a nurse’s head and depended on their vigilance through hour eleven of a twelve-hour shift. Barcode verification took that protocol and moved it into the system. It did not replace the judgment about the patient in front of them. It stopped asking nursing memory to do a system’s job. That distinction is the whole thing, and it is what the word technology hides.

What a system does that effort alone cannot

So let me name what a system does, because infrastructure is not a synonym for software and it is worth being concrete about it. Infrastructure does four specific jobs, and human effort cannot hold any of them reliably at scale:

• It remembers, so the state of a discharge lives somewhere other than in one coordinator’s head and survives her day off
• It surfaces, so that everyone is working from the same picture of the patient instead of five partial pictures held in five different places
• Then it assigns, so that a task has a name attached to it instead of being everyone’s diffuse responsibility and therefore no one’s
• And finally it routes, so that the next step arrives in front of the right person as a task rather than as something they have to go hunting for.

None of those four is a clinical decision. Every one of them is something people are currently doing with memory, effort, and heroics, which is exactly why the whole thing breaks the moment a good person has a bad day.

The healthcare software category has failed at exactly this before, and the failures are worth studying rather than hiding. In 2005, a well-known piece of research cataloged the ways computerized order entry could create brand new errors, and it found two causes. One was fragmented information, the system showing part of the picture and concealing the rest. The other was software whose demands did not match how the work was organized, so that people had to fight the tool to do their jobs.

The most cited cautionary tale in this whole area is the drug interaction alert, and it is cited for good reason: clinicians override those alerts something like ninety percent of the time. I raise it on purpose, because it is the proof of my own point rather than a hole in it. Surfacing information is not the same as fixing the system. An alert that fires and gets waved away has changed nothing. If what you build does not land as a specific, credible next action for a specific person, you have built a dashboard, and the skeptic is completely right to distrust it. Of the four jobs a system has, the fourth one, routing, is the one that counts, and the first three are worth nothing if it does not work.

What this feels like on the floor

None of this is abstract if you have stood on a unit and watched it happen. Today the process finds the physician one interruption at a time, a page here and a text there and a “can you sign this” in the hallway, a message basket that refills faster than it empties, a case manager physically walking the floor to find the one person who can answer one question. Nobody wants to be hunted all day for single items, and no good clinician wants to be the item somebody else is spending their morning hunting for.

What people on the floor want is the reverse of that. They want their personal discharge tasks pooled in one place they can clear in a few minutes, on their own rhythm, instead of being pulled out of a patient’s room five separate times for five separate things. That same chief medical officer put the goal to me plainly. He did not want the tool to think for him. He said he wanted to know where people are, because that is how you drive the action. Visibility, for him, was the thing that let him send a specific human being to the next action that mattered.

When I have shadowed discharge teams, the relief on their faces comes when they can see the two or three trickiest cases that need eyes and deal with those, rather than reconstructing the entire board from memory every morning. A study out of UCLA looking at structured discharge coordination found that it improved coordination, tracking, and notification, and improved provider workflow rather than adding to it. That last part is the one I care about most, because the standing fear on any floor is that a new system is simply one more thing to feed. Here the finding ran the other way.

Infrastructure makes people durable, not redundant

Here is where I land, and it is the mirror image of a point I have made before about hiring.

Start with durability instead of heroics. The well-run manual process, the one the chief medical officer built inside his EHR, works. But it works through constant manual effort, and it breaks the instant something slips. That is exactly what he meant when he told me it works but requires a tremendous amount of coordination, and that you throw a grain of sand in there and it becomes a microchip that can malfunction. Discipline is what makes the good version run today. Infrastructure is what lets it survive a bad day, a short-staffed weekend, a coordinator out sick, and then repeat on Monday without a hero holding the whole thing together by hand.

Then there is the payoff I did not anticipate and now think is the most valuable one. What a coordination layer does best is reveal where the humans are under-resourced. That same doctor told me the biggest use of his data was telling him which areas he was not resourced for appropriately. Sometimes, he said, it does not matter how many AI bots you have. You still need a doctor to do one specific thing, and no one is doing it, because there is no one free to do it. When a clinician truly is the bottleneck, the system should be able to show that with data instead of anecdote, so that a leader can staff for it rather than blame the frontline for a gap that was never theirs to close. A coordination layer that does this makes the people more legible and more defensible, not more replaceable.

This is the whole argument: You cannot hire your way out of a broken information layer, and you cannot automate the people away either. What you can do is give the people a better system, one that remembers, surfaces, assigns, and routes the next action to the right person at the right time. The UCLA researchers who studied structured discharge coordination proved the concept and then pointed at the obvious next step, which is to automate the coordination itself so that it no longer depends on someone being heroic. That next step is the part we are building at Caremaze. If you are the person inside a hospital who has been holding this together on your own, with your own discipline and your own memory, I would like to talk, mostly because you already understand the problem better than any pitch ever will.