Built to Care, Left to Break
Why the automation that used to work now fails every few weeks, and how to stop paying to patch something that should just run.
It was delivering. Referrals moved, letters went out, appointments reminded themselves, and nobody had to think about it. Now it breaks every few weeks. The referral routing has been quietly wrong for months. The scheduling dashboard costs real money every time someone fixes it, and it fails again anyway. You should not be paying, again and again, to keep something running that was supposed to simply run.
This guide is not a general reminder to keep your systems maintained. It sets out exactly why something that once worked well starts failing on a loop, why the fix that costs money each time never quite holds, and what genuinely stops the cycle, without pretending the answer is simply trying harder to remember to check it.
It did not suddenly break. It had been breaking for a while
A system that worked cleanly on the day it launched does not usually fail for no reason months later. Something around it changed quietly first, a referral form gained a new field, a system it depended on was updated, a new kind of case started appearing more often, while the automation itself stayed exactly as it was built. The visible failure, the referral that lands in the wrong place, the dashboard that will not load, is not the start of the problem. It is simply the moment the accumulated gap finally became too large to absorb.
A system rarely fails on the day it stops working. It fails on the day nobody was watching closely enough to notice it had already started.
The four things quietly wearing a working system down
Upstream changes nobody flagged
A connected system gets updated, a referral form changes, a supplier alters a file format. Nobody tells the team relying on it downstream, and an automation built to expect yesterday’s version of the world has no way of knowing today’s has moved on.
Exceptions that were tolerated, never actually handled
Every process has a handful of unusual cases it was never quite built to cover. While these stay rare, someone quietly absorbs them by hand. As they grow more frequent, that informal tolerance runs out, often without anyone noticing the volume had been climbing.
The person who understood it has moved on
A system built without proper documentation lives inside the memory of whoever configured it. When that person changes roles or leaves, the organisation loses its only real understanding of how it actually works.
Nobody was watching in between
Most systems get close attention at launch and steadily less afterwards. The gap between that early scrutiny and the day something visibly fails is exactly where all of this quietly accumulates.
Why the same fix keeps costing money and never holds
A dashboard that costs a meaningful sum every time it is fixed, and fails again within weeks, is not evidence that the problem is genuinely difficult. It is usually evidence that the fix is being applied in the wrong place. The visible symptom, a report that will not load, a referral in the wrong queue, is rarely where the fault actually lives. It is simply where it happens to become visible.
Patching the symptom repairs it for exactly as long as it takes the real cause, often something further upstream, to produce the next failure. Each fix looks entirely reasonable on its own. None of them explains why the same problem keeps returning, because none of them ever reaches the layer where it actually starts.
If the same system has needed the same category of fix more than once, that is not bad luck. It is a signal the fault sits somewhere other than where the money is being spent.
The maths of patching versus fixing it properly
| Approach | What it actually costs over time |
|---|---|
| Repeated patching | A fee paid again and again, on no fixed schedule, with the failure still likely to return each time |
| A proper fix at the right layer | A larger cost paid once, with the specific failure genuinely resolved rather than temporarily hidden |
Paid one invoice at a time, patching feels like the cautious, low commitment choice. Added up honestly over a year, it is very often the more expensive option, and the only one that never actually stops.
The ownership gap behind almost every case like this
Underneath most of these situations sits the same simple fact. The person who built the automation is not the person maintaining it, and quite often nobody is genuinely maintaining it at all. It was handed over informally to whoever happened to be nearby when something first went wrong, without the understanding, authority or time that role actually needs. A build has a natural end date. Staying reliable for years, through every quiet change nobody warns you about, does not, and needs a named owner precisely because of that.
Diagnosing which layer actually failed
- Start from the symptom, then ask what fed it. A wrong entry on a dashboard came from somewhere. Trace it back through every system that touched it first.
- Check what changed upstream, not what changed in the tool. The automation likely did exactly what it was built to do. Ask instead what changed in the systems feeding it.
- Look for a pattern across previous fixes. If the last few fixes all addressed the same symptom slightly differently, the actual fault has not been touched yet.
Why this carries extra weight in a clinical setting
DCB0160 does not treat clinical safety as a single sign off at go live. It requires ongoing post deployment monitoring, incident reporting and periodic safety reviews, with a hazard log kept current throughout the system’s use, reviewed at least annually and whenever the system changes. A system that keeps failing and being patched without that review happening is not simply an operational cost. It is very likely already behind the clinical safety obligations your organisation already holds.
This is also, quite simply, a trust question. A referral system that keeps failing does not just create rework. It creates a moment where a patient waits longer than they should, for a reason nobody outside the building will ever know was preventable.
How to make it stop happening again
- Give it a named, ongoing owner. Someone accountable for how the system performs day to day, not simply whoever built it or whoever picked up the last ticket.
- Monitor for drift, not just outright failure. Build alerts around the early signs, a rising rate of exceptions or manual corrections, so problems surface quietly before they become visible failures.
- Document how it actually works today. Capture the exceptions and quirks that have accumulated since launch, so understanding does not live in one person’s memory.
- Treat a second identical fix as an escalation. The moment the same category of problem returns, stop repeating the patch and properly investigate where the fault actually lives.
What good looks like instead
Teams who get this right rarely experience a dramatic failure at all. Drift gets caught quietly, by monitoring built for exactly that purpose, and addressed before it reaches a patient or a deadline. Ownership sits clearly with someone who understands the system as it runs today. And a repair, when one is genuinely needed, happens once, at the layer where the fault actually lives, rather than being paid for again every few months indefinitely.
None of that requires the original build to have been wrong. It requires treating what happens after launch as seriously as what happens before it, because that is where almost every one of these failures was actually decided.
