On 3 June 2024, a ransomware attack hit Synnovis, a pathology company that processes blood tests for several NHS trusts in south-east London. Surgeries were cancelled within days. With routine blood matching disrupted, demand for O-negative blood strained national stocks and the NHS appealed for donors. More than 10,000 appointments and procedures were eventually postponed, including cancer treatments and organ transplants. Full service was not restored until December.
The hospitals themselves were not the entry point. Their pathology supplier was.
Four months earlier, the same pattern had played out at a much larger scale in the United States. Change Healthcare, a claims and payment processing company owned by UnitedHealth Group, was hit by ransomware in February 2024. Pharmacies struggled to process prescriptions, practices went weeks without payment, and the company eventually told federal regulators that data on about 192.7 million people had been affected, the largest health data breach ever reported to the US Department of Health and Human Services.
These two cases point to an uncomfortable conclusion. Health cybersecurity is still largely framed as a hospital IT problem. The biggest patient-safety risks increasingly sit in the shared suppliers that dozens or hundreds of hospitals depend on at once.
Downtime is a clinical event
It is tempting to think of ransomware as a data breach: stolen records, identity theft risk, regulatory fines. That harm is real. But the more direct danger is what happens to care when systems go dark.
Economists at the University of Minnesota have tried to measure this. In a working paper that drew wide attention in 2023, Hannah Neprash, Claire McGlave and Sayeh Nikpay linked a database of hospital ransomware attacks to Medicare claims. They found that patient volume dropped by 17% to 24% in the week of an attack, and that in-hospital mortality among patients already admitted when the attack began rose by roughly 20% to 35%.
Those estimates come from observational data and carry uncertainty. But the mechanism is not mysterious. Clinicians lose access to medication histories, allergy lists, imaging and lab results. Orders go back to paper. Results arrive late or by phone. Ambulances get diverted, adding travel time for patients in the surrounding area. Every one of these is a known patient-safety risk. Ransomware just triggers them all at once.
The incentive problem: concentration is efficient until it fails
Why does risk pool in suppliers? Because consolidation makes sense on almost every other dimension.
A single pathology network serving several trusts can buy better analysers, run tests more cheaply and standardise quality. A single claims clearinghouse processing transactions for a large share of the market is efficient for payers and providers alike. Nobody chooses these arrangements because they want a single point of failure. They choose them because they are cheaper and, day to day, work well.
The cost of that efficiency only shows up on the day it fails, and it shows up across every organisation that depended on the supplier. Individual hospitals have little leverage over a large vendor’s security practices and limited visibility into them. Procurement teams are rewarded for price and performance, rarely for resilience.
This is a classic externality. The supplier captures the savings from scale. The shared risk is spread across patients and providers who never had a say.
What changes when you treat it as a safety issue
If cyberattacks are a patient-safety problem, a few practices follow naturally. Most are familiar from other kinds of clinical risk:
- Rehearse downtime like a major incident. Paper ordering, manual blood matching, handwritten medication charts. Staff who have practised them will make fewer errors on the day.
- Map clinical dependencies, not just IT assets. Which suppliers, if they went dark for three weeks, would stop surgery, transfusion, dialysis or chemotherapy? That list is the real risk register.
- Build contingency capacity across suppliers. Agreements with alternative laboratories or processors, tested in advance, turn a crisis into a disruption.
- Put security requirements in contracts. Minimum standards, audit rights and notification timelines for critical suppliers should be a normal part of procurement.
- Report and learn from incidents like clinical events. Near misses and harms during downtime should flow into the same safety learning systems as any other incident.
None of this replaces basic security hygiene, such as multi-factor authentication, patching and segmented networks. It complements it by acknowledging that some attacks will succeed.
The regulatory gap
Hospitals are regulated for clinical safety. Many of the suppliers whose outages cause the most clinical harm are regulated mainly as businesses or data processors. That mismatch means the organisations best placed to prevent system-wide disruption often face the weakest safety obligations.
Closing that gap does not necessarily require new bureaucracy. It could start with a simple principle: if a supplier’s failure can stop clinical care at multiple hospitals, it should be treated as part of critical health infrastructure, with the expectations that come with that.
A worked scenario: the first 72 hours
It helps to walk through what an attack on a shared supplier looks like from inside a hospital that did nothing wrong.
Hour zero. Staff notice that laboratory results have stopped arriving. The laboratory information system is unreachable. IT confirms that the problem is at the supplier, not locally. Nobody yet knows whether it will last an hour or a month.
Hours one to six. The hospital’s own downtime procedures assume a short outage of its own systems. They do not cover the loss of an external laboratory. Urgent samples are sent by courier to another site, which quickly becomes overwhelmed. Clinicians begin rationing tests: only results that will change management today. Blood transfusion becomes the most urgent problem, because cross-matching depends on the laboratory systems.
Day one. Elective surgery lists are reviewed. Operations that might need a transfusion are cancelled. Cancer patients due for chemotherapy, which depends on pre-treatment blood counts, are called one by one. Some are deferred. The emergency department slows because every patient who needs bloods waits longer.
Days two and three. A regional response is organised. Neighbouring hospitals take some work but have their own patients. Staff rewrite rotas to cover manual processes. Communication with patients becomes a major task in itself. Clinicians begin to worry about the results that were in transit when the systems went down: abnormal findings that nobody saw.
At no point in this sequence was the hospital’s own network compromised. Every decision it had to make was a clinical one. And every hour of delay in activating a pre-planned alternative translated directly into cancelled care.
The mechanism: why suppliers are attractive targets
From an attacker’s point of view, a shared supplier is an efficient target. A single successful intrusion can disrupt many organisations at once, which increases the pressure to pay a ransom quickly. Suppliers often hold large volumes of sensitive data from many clients, which raises its value. And the complexity of their connections, to hospitals, practices, pharmacies and payers, offers many possible entry points.
Suppliers also face a difficult trade-off. Their business depends on being easy to connect to. Every new client means new interfaces, accounts and data flows. Security controls that slow down integration can cost contracts. The commercial pressure runs toward openness, while security requires friction.
Health care’s operating model adds another problem. Systems often run for many years, and replacing them is expensive and disruptive. Older software and devices that cannot easily be patched stay in use because the clinical service depends on them. That legacy footprint is a persistent weakness that no single organisation can quickly fix.
The strongest counterargument
Some would argue that framing cyberattacks as a patient-safety issue risks overreach. Mortality estimates from observational studies are uncertain. Most attacks cause disruption and cost rather than death. Treating every IT risk as a clinical emergency could divert attention and money from other safety priorities with stronger evidence, such as infection control or medication safety. And heavier regulation of suppliers could raise costs and slow the adoption of useful technology.
This argument partly holds. Not every IT failure is a safety crisis, and resources for resilience compete with other needs. The mortality estimates should be treated as a signal of plausible harm rather than precise figures.
But the patient-safety framing matters less for the headline number than for the response it triggers. Safety frameworks bring practices that IT security frameworks often lack: rehearsed contingency plans, clinical leadership during incidents, systematic learning from near misses and clear lines of accountability to the board. Those practices do not depend on knowing the exact number of deaths an attack causes. They depend on accepting that care is disrupted, which is not in doubt.
Second-order effects to watch
Insurance. Cyber insurance premiums and exclusions are shaping which organisations can afford cover and what security controls they must adopt. Insurers may end up setting de facto standards faster than regulators.
Ransom economics. Every payment funds further attacks. But for an organisation facing weeks of disrupted care, the pressure to pay is intense. Policies that prohibit payment without providing support for recovery could leave organisations with no good options.
Consolidation feedback. Smaller providers that cannot afford robust security may be pushed toward larger groups or shared services, which increases concentration and the scale of the next failure.
Workforce. Health care competes poorly with other sectors for cybersecurity staff. Without investment in skills, many organisations will remain dependent on vendors whose own security they cannot assess.
What this means for different players
Hospital boards should receive cyber risk reports framed in clinical terms: which services would stop, for how long, and what the plan is. A list of patched servers is not an answer a board can act on.
Clinical leaders should own downtime procedures for their services and rehearse them. The people who will run manual transfusion or paper prescribing on the day are best placed to design how it works.
Procurement teams should weigh resilience alongside price and include security obligations, incident notification timelines and contingency support in contracts with critical suppliers.
Ministries and regulators should map which suppliers are critical to care across the system, set proportionate security expectations for them and fund regional contingency arrangements that no single provider can build alone.
Funders supporting digital health in lower-income countries should build security and downtime planning into programmes from the start. Systems deployed without them create new dependencies with no fallback when they fail.
What to watch next
Watch whether health regulators begin designating critical suppliers and setting safety expectations for them, as some countries do for energy and finance. Watch whether published peer-reviewed estimates of attack-related harm grow more precise. And watch whether health systems begin reporting cyber incidents through clinical safety channels, which would be the clearest sign that the patient-safety framing has taken hold.
The takeaway
Cybersecurity in health care is no longer mainly about protecting one hospital’s network. It is about managing shared dependencies that can take out care across a region, or a country, in an afternoon. The patient-safety toll is measurable, and it falls on patients who have never heard of the company whose servers failed.
The question every health system should be able to answer is simple: which supplier’s outage would hurt our patients most, and what is our plan for the day it happens?
Has your organisation run a full downtime drill that included a critical supplier going offline? We’d like to hear what it revealed.
