The plan is still necessary

Start with the part that too many technology arguments skip: hospitals cannot operate without plans. Schedules, pathways, forecasts, targets, and a hundred quieter assumptions are how a large, interdependent organization coordinates itself before the day begins. Without them, there is no shared expectation to work from. A plan is not a liability. It is the precondition for coordinated work at all.

So nothing here is an argument against planning, or against the systems that produce better plans. Better forecasting and scheduling are genuinely valuable, and they reduce the size and frequency of the gaps we are about to describe. The point is narrower and more honest: even excellent planning leaves a gap, because a plan is a description of the future written in the past.

The problem is not always the plan

When a hospital’s day goes sideways, the instinct is to interrogate the plan. Was the forecast wrong? Sometimes, yes. But frequently the plan was reasonable when it was made, and the operating environment simply moved after it was set. A plan built at seven in the morning cannot account for the thing that happens at ten.

This distinction matters because the two problems have different remedies. If the plan was bad, you fix planning. If the plan was fine but reality diverged, better planning will not save you — what you need is a better way to recover once the divergence appears.

Expected state versus actual state

There is the expected operating state — how the next several hours are supposed to go. And there is the actual operating state — how they are in fact going, right now. For most of a normal day these track closely enough that no one thinks about the difference. Then something moves, and the two pull apart. Crucially, that gap can open without anyone doing anything wrong. It is the ordinary physics of running a complex operation in real time.

Why small changes spread

If hospitals were made of independent parts, a local deviation would stay local. They are not. A change in one place becomes a constraint somewhere else. The initial deviation may be minor; the propagation is where the cost lives. By the time the consequence is unmistakable, it is often several steps removed from where it started — which is part of why it is so hard to trace and so easy to under-count.

The work that begins after divergence

Once the gap opens, someone has to notice which change matters, reconcile conflicting accounts, understand the local constraints, find the people with authority to act, coordinate a response, and check whether the condition actually improved. That work has a name worth using plainly: operational recovery. It usually works, because experienced operators are very good at it — but it is largely invisible to the organization, hard to support, and hard to reuse.

The objective

The goal is not a perfect plan that never breaks. There is no such plan, and chasing one quietly starves the part of the operation that actually determines how bad a rough day gets. The goal is to become better at recovering when reality changes — more consistent, more governed, more measurable, more able to learn. Planning tells the hospital where it intends to go. Recovery is how it gets there anyway when the day has other ideas.

Hospitals have become much better at seeing

It is worth being generous about how far hospital visibility has come. Systems of record capture what happened. Analytics surface patterns that would have been invisible a decade ago. Alerts fire when a threshold is crossed. Dashboards and command centers put a live picture on a wall. Taken together, this is a real achievement. The difficulty is not a shortage of signal. It is what happens in the minutes and hours after the signal arrives.

The alert creates work

An alert is often treated, implicitly, as a resolution. The dashboard turns red, the notification goes out, and there is a sense that the system has done its job. In one sense it has: the problem is now visible. But visibility is the start of the work, not the end of it. The moment the alert lands, people begin to move — not the system, people — assembling a response the alert itself cannot assemble.

Someone must reconcile reality

The first thing a person has to do is work out what is actually true. Alerts and dashboards describe the situation from the vantage point of the data they hold, and those vantage points do not always agree. Before anyone can respond well, someone has to reconcile them into a single account of the operating condition they can trust enough to act on. It is skilled work, and it leaves almost no trace once it is done.

Someone must navigate constraints

Knowing what is happening does not tell you what you are allowed to do about it. The response has to fit within policy, within the authority of whoever is deciding, within the resources that actually exist, and within the dependencies pulling in other directions. A response that is correct in the abstract can be unavailable or unsafe in the specific context in front of the person.

Someone must coordinate and close

Even a correct response is not self-executing. Coordination is where a great deal of elapsed time goes, and it is almost entirely manual. Then there is the step skipped most often: confirming that the response actually worked. Intervention is not the same as recovery. Without a deliberate check, teams assume resolution because something was done — and sometimes they are wrong in ways that only surface later.

The missing capability

Reconcile, navigate constraints, coordinate, and confirm — this is a coherent body of work, and at most hospitals it has no system of its own. That gap between seeing and recovering is a category, not a feature. Naming it is the first step to supporting it — which is precisely the work that should not have to live on a charge leader’s phone.

Watch what happens when the plan stops working

Stand in a hospital on a difficult afternoon and watch what happens when the plan stops describing reality. The people on the floor do not freeze. A charge nurse notices that the shape of the day has changed. A phone call happens. A resource is found, or negotiated for. An escalation is made a little earlier than it strictly had to be. Within minutes, a response is underway. That response is a recovery system. It has no dashboard and appears on no architecture diagram — but it is doing exactly the work a recovery capability is supposed to do.

Informal does not mean unimportant

Because this system is informal, it is easy to treat as a stopgap. That framing is backwards. The informal recovery system is often the most sophisticated operating capability in the building. The trouble is not that it is informal in spirit. It is that being unsupported and unrecorded imposes real costs: it depends heavily on specific individuals, it is invisible to the wider organization, and it does not accumulate.

Judgment carries context software does not have

Human operators carry context: which policy applies here, which exception is acceptable, what the numbers on the screen are missing, who needs to be consulted before a move. This is not a soft point about the human touch. A recommendation generated without that context can be confidently, precisely wrong — correct on paper and unworkable on the unit.

The scalability problem

So why build anything? Because “good, but…” is the whole story. It is good but uneven — quality depends on who is on. Good but fragile — it concentrates in a few people. Good but opaque — leaders cannot see where it strains. And good but forgetful — the lesson from today’s hard save leaves with the person who made it.

What software should strengthen — and not erase

The job of software becomes clear and appropriately modest: help assemble a shared account of the condition, reduce the manual coordination load, make governance easier to honor, support genuine closure, and retain what worked. Every item is about supporting judgment, not supplanting it. The corresponding list of things software should not do is shorter and just as important: it should not relocate authority away from the people who hold it, blur accountability, or flatten the local judgment that makes a response correct here.

The goal

The aim is not to automate operators out of recovery. It is to take the capability they already provide — skilled, adaptive, today largely invisible — and make it more consistent, supported, governable, and durable. Keep the judgment at the center. Build the scaffolding it never had.

Activity is easy to count

When something goes wrong operationally, it is reassuring to be able to say what was done. A call was made. A resource was moved. An escalation was raised. These are visible, countable, and satisfying, and they accumulate into a comforting record of responsiveness. The problem is that a record of action is not a record of outcome. Counting interventions tells you the hospital responded. It does not tell you whether the response worked.

Action is not recovery

A response succeeds when the operating condition is back where it needs to be and stays there. Not when a task was completed. Not when a box was checked. When the operating reality actually came back. Held to that standard, a lot of recorded activity turns out to be ambiguous. The intervention is documented. Recovery is assumed.

Recovery requires closure

Closure is the deliberate act of asking, after a response, whether the condition has genuinely returned to acceptable — and being willing to find out that it has not. We are being deliberately conceptual about how one would judge that: the point is not a particular metric or threshold, but the discipline of confirming, rather than assuming, that the condition recovered.

Why it matters

Skipping closure has a specific, recurring cost. A problem that was only partially resolved does not announce itself; it recedes, and then it comes back — often larger, often somewhere adjacent so the connection is easy to miss. Over enough of these, an operation can be extremely busy and not especially stable. There is a second cost, slower but larger: without closure, the organization cannot learn. Every recovery is judged by whether it looked reasonable, not by whether it succeeded.

A better question

The common question is some version of “Did someone act?” — easy to answer and almost always yes. The better question is “Did the operating condition actually recover?” — harder, sometimes uncomfortable, and far more honest. Organizations that ask the first optimize for visible activity. Organizations that ask the second optimize for actual recovery — and, over time, get quietly better at the problems that used to keep returning.

Hospital operations involve real authority

It is easy to talk about operational decisions as if they were optimization problems waiting for a better solver. In a hospital they are not. Decisions about how to respond when conditions change are bound up with authority: who is permitted to make a given call, under which policy, accountable to whom. These are not incidental details around the “real” decision. They are part of what makes a decision legitimate.

A recommendation is not authority

There is a meaningful difference between suggesting a course of action and being entitled to take it. Software can be very good at the first. The second belongs to people. A system that surfaces a strong recommendation, defaults to it, and makes overriding it inconvenient has quietly begun to make decisions while leaving the accountability with a human who is now rubber-stamping. Good design keeps the recommendation clearly on the input side of that line.

Local context matters

A response that is correct in general can be wrong in the specific circumstances of a particular unit at a particular moment — because of a constraint, a dependency, or a piece of operating reality the model never saw. The role of automation is not to overrule contextual judgment but to inform it: bring more of the relevant picture into view faster, then let the person who can see the local reality make the call.

Human approval should be real, not theater

“A human is in the loop” can describe two very different things. In one, a person genuinely evaluates a proposed action, with enough context and time and real freedom to say no. In the other, a person is presented with a decision already effectively made, and clicks approve. The test is simple: does the human have what they need to actually disagree? If saying no is realistic and sometimes happens, the oversight is real.

Good automation removes coordination burden

Where should automation’s energy go? Toward the burden around the decision rather than the decision itself — assembling the picture, reaching the right people, tracking follow-through, confirming closure. That work is genuinely tiring for people and well-suited to software. Remove it and you get human operators freed to spend their judgment where judgment is actually required.

The goal

The goal is not an autonomous hospital that runs itself while people watch. It is stronger operational capability: human judgment kept firmly at the center, freed from the coordination burden that currently surrounds it, operating inside governance that is respected by design. AI that strengthens operators is far more useful, and far more appropriate to a hospital, than AI that tries to replace them.