Why buying the same software as your neighbors removes your fallback

The week

On August 4, 2022, a software company most patients had never heard of found itself at the center of a health care emergency. Advanced, a supplier to the UK’s National Health Service (NHS), detected a ransomware attack that took several of its hosted products offline.

Ransomware is malicious software that criminals use to lock up an organization’s computer systems, typically by scrambling its data so it cannot be read, and then demand payment to unlock it. Increasingly, attackers also copy data before locking it, so they can threaten to publish it.

“Hosted products” means software that the supplier runs on its own servers and that customers use over the internet, rather than installing it on their own computers. This model is often called software as a service, or SaaS. It is convenient for customers, but it means that when the supplier goes down, every customer goes down with it.

The affected products mattered. They included Adastra, used by NHS 111 and by out-of-hours urgent care services for patient records and call handling. NHS 111 is the phone line people in England and Wales call for urgent medical advice that is not a 999 emergency. They also included Carenotes, used by mental health and community care providers to keep patient records. Other products, including ones used by care homes and for staff scheduling, were also taken offline.

Advanced isolated its health and care systems to contain the attack, which meant switching off products that had not themselves been encrypted. That is a standard containment step. It also meant customers lost services whether or not those specific services had been touched. The company brought in outside incident response specialists, and the UK’s National Cyber Security Centre and NHS England worked with it on the response.

When the systems went dark, affected services, including NHS 111 in England and Wales, fell back to paper and manual processes, some for weeks, while the supplier restored systems in stages. Advanced warned customers early on that full restoration would take weeks. Clinicians who were used to seeing a patient’s history on screen had to work from handwritten notes and phone calls, which is slower and leaves more room for error.

The effects ran beyond the call line. Out-of-hours services use the same records to pass information to a patient’s own general practitioner the next morning. With the system down, those handoffs moved to email, phone and paper. Mental health services that relied on Carenotes lost electronic access to care plans and risk assessments, which are central to safe community care. Restoring those records, and entering the paper notes made during the outage, would take longer still.

The UK data protection regulator, the Information Commissioner’s Office, later found that personal data had been taken, adding a privacy dimension to the operational disruption. Its findings, published in 2025, said the attacker had entered through a customer account that lacked multi-factor authentication. Personal information of 79,404 people was taken. It included details of how to gain entry to the homes of 890 people receiving care at home.

The timing added strain. Urgent and emergency care in England was already under heavy pressure that summer, with long ambulance waits and crowded emergency departments widely reported. NHS 111 is meant to steer patients away from those departments when another route fits. With its records system down, call handlers had less information to make those decisions, and the services they referred patients to were working on paper too.

The regulatory frame matters for reading the case. Under UK data protection law, Advanced acted as a processor, handling data on behalf of the NHS bodies and care providers that controlled it. NHS organizations and their suppliers also complete an annual self-assessment, the Data Security and Protection Toolkit, as a condition of handling patient data. Neither arrangement guaranteed that a supplier would have multi-factor authentication on every route in.

One fact stands out above the others. The providers that lost their systems had not been attacked themselves. Their own networks, staff and security were not the point of entry. Their shared supplier had been attacked. Because so many of them relied on the same product, a single breach became a problem for a large part of the health service at once.

Suppose you run urgent care for a region of a million people. On a normal day, if one of your services has a problem, a neighboring service picks up the slack. Calls are rerouted, patients are seen across the border, and the system bends without breaking. Then one morning your systems go down, you call your neighbor for help, and their systems are down too, for exactly the same reason. The Advanced incident was instructive for that reason.

When one hospital loses its systems, its neighbors usually absorb the overflow. Ambulances divert, calls reroute, patients are seen elsewhere. That informal mutual aid is the health sector’s oldest resilience mechanism. The Advanced incident showed how shared software defeats it. Urgent care services that might have leaned on one another found that their neighbors ran the same platform and were down too.

U.S. health systems buy on the same model every day: hosted electronic health records for smaller hospitals and clinics, revenue cycle and clearinghouse services, scheduling and telehealth platforms, behavioral health and lab systems. For a buyer, the episode raises three distinct procurement questions. The first is how concentrated each critical service is across peers, which determines whether neighbors can help. The second is what the contract obliges the supplier to do before and during an incident. The third is what fallback the health system pays for that depends on neither the supplier nor its peers.

The analysis below has five parts. It starts with the systems health providers now rent, because the questions depend on what is being bought. It then takes the three questions in turn: concentration, the contract and fallback. It closes by weighing the whole: what a shared failure costs, the strongest case for shared software, and how a health system can keep score.

The systems health providers now rent

First, the kinds of systems involved, since they are not always visible from the executive floor.

An electronic health record, or EHR, is the digital version of a patient’s chart: diagnoses, medications, allergies, test results and clinicians’ notes. Large hospitals often run their own; smaller hospitals and clinics increasingly use a hosted version run by the supplier.

Revenue cycle services handle the business side of care: registering patients, checking insurance, coding what was done and billing for it. A clearinghouse is an intermediary that passes insurance claims between providers and insurers, translating them into the formats each side needs. If it stops working, claims stop moving and cash stops coming in. Under HIPAA, a health care clearinghouse is itself a covered entity, with its own privacy and security duties, when it performs that translation.

Telehealth platforms run video and phone appointments. Scheduling systems manage appointments and referrals. Behavioral health systems hold the records of mental health and addiction services, which carry particularly strict privacy protections; federal rules on substance use disorder treatment records add to HIPAA there. Laboratory systems manage test orders and results.

Why hosting spread

What these have in common is that many are bought as hosted services. The supplier runs the computers, applies updates and handles backups. The health system pays a subscription and logs in. That model has real advantages: smaller organizations get capabilities they could never build themselves, and the supplier can invest in security at a scale no single clinic could match.

The economics pushed hard in that direction. Running an EHR in-house means a data center or colocation space, database administrators, backup systems, upgrade projects and a security team. For a critical access hospital or a community health center, hiring those skills is difficult and costly. A hosted option turns them into a predictable subscription. Federal incentives for certified EHR adoption after 2009 accelerated the spread of a few certified products, and hosted delivery brought them within reach of smaller providers.

The same model also means that the health system’s ability to deliver care depends on a supplier’s systems that it cannot see, control or restore. Ten restaurants that each cook in their own kitchen can survive one kitchen fire. Ten restaurants that share a single kitchen cannot.

Hosted, managed and shared are different

Three arrangements are often lumped together. In a hosted service, the supplier runs a separate instance of the application for each customer, often on shared infrastructure. In a multi-tenant SaaS service, many customers share one application and database, separated by software controls. In a managed service, the supplier operates systems the health system owns or licenses, sometimes in the health system’s own data center.

The difference matters in an incident. A multi-tenant service usually fails for every customer at once. A hosted service with separate instances may fail for all customers too, if the shared infrastructure or the supplier’s management network is compromised. Advanced’s decision to isolate its whole health and care environment showed that point: products went offline because they shared an environment, whether or not each was directly affected. A managed service run in the customer’s own environment can still be exposed through the supplier’s remote access, which is how many attacks on managed providers spread.

Concentration: when peers share the failure

Healthcare software markets are concentrated by design. In many specialties a handful of suppliers serve most providers, which brings shared investment, common workflows and easier data exchange. It also turns one supplier’s failure into a regional event.

Concentration one layer down

The same is true one layer down. Several suppliers may host on the same cloud region or depend on the same managed service provider, so diversity at the contract level can hide concentration underneath. Asking suppliers where they host and who operates their infrastructure is part of the same picture.

Two terms there need unpacking. A cloud region is a cluster of data centers in one geographic area, run by a large cloud provider, where many companies rent computing capacity. A managed service provider is a company that runs IT operations on behalf of others, such as monitoring servers or managing remote access. If three of your “different” suppliers all run in the same cloud region, or all use the same managed service provider, they may fail together.

Shared components go deeper still. Many suppliers use the same remote access products, identity services, endpoint security tools and payment processors. A flaw or outage in one of those can reach many suppliers at once, with or without an attacker involved. Mapping every such dependency is impractical. Mapping the handful that sit under the most critical clinical and revenue services is achievable, and suppliers can usually answer if asked in writing.

Building a concentration view

A health system’s third-party risk program assesses its own suppliers. It rarely asks which peers in its region depend on the same platform, and so it cannot see when its diversion plan points at hospitals that will fail at the same moment. A concentration view adds that column. For each critical hosted service, it records the supplier and an estimate of how many nearby providers share it, drawn from regional coalitions, health information exchanges and the supplier’s own reference lists.

A health information exchange is an organization that lets providers in a region share patient records electronically; it often knows which systems its members use. Reference lists are the customer names suppliers share with prospective buyers to show they are well established. They double as a rough map of who would be affected if the supplier failed.

Regional health care coalitions are another source. In the United States, federally supported coalitions bring together hospitals, public health, emergency management and emergency medical services to plan for disasters. They are a natural place to share which platforms members rely on, since they already plan for surge and diversion. Members may be reluctant to disclose suppliers for competitive reasons. A coalition can aggregate the answers so that no member’s details are exposed while the concentration still shows.

What changes when a service is systemic

Where the share is high, the service should be treated as systemic. That changes the scenario plan: assume regional partners are down, and test whether emergency department diversion, transfer agreements and call handling still work.

It may also change sourcing. A second supplier for a narrow function, such as an independent telehealth or patient messaging tool kept warm for emergencies, can restore a channel when the primary platform and its peers are dark. The cost is a second license and some training. The benefit is a route that does not share the failure.

Take a health system with four hospitals and a network of clinics. Its concentration view shows that its hosted scheduling and patient messaging platform is used by most providers within a hundred miles. Its diversion plan assumes it can send patients to two neighboring systems, both of which use the same platform. Once that is visible, the board can make a deliberate decision. It might keep a separate, simple messaging tool licensed and tested, so that if the main platform fails, the system can still tell patients which appointments are cancelled and where to go.

Correlated incidents strain the response itself

A shared failure also strains the people and services that respond to it. When hundreds of customers lose the same platform on the same morning, they all call the same supplier support line, the same incident response firms and often the same cyber insurers. The supplier’s status updates become the main source of information for everyone, and they tend to be cautious and slow.

Customers also face a decision of their own: whether to cut their connections to the affected supplier. After the Change Healthcare attack in 2024, the American Hospital Association advised members to consider disconnecting from the affected systems, and many did. Reconnecting then required assurance that the supplier’s environment was clean, which took time. A health system should decide in advance who can order a disconnection, what evidence it needs before reconnecting and which interfaces matter most.

Those decisions belong in the incident response plan with named owners. Without them, disconnection and reconnection get decided by whoever is on call, under pressure, with incomplete information.

How it differs by type of provider

Concentration bites differently across provider types. A large academic health system often runs its own EHR instance and has negotiating power, but it relies on shared clearinghouses, lab networks and specialty systems like everyone else. An ambulatory network or physician group is more likely to use a hosted EHR and a hosted practice management system from the same supplier, so one failure takes out both clinical and billing functions.

A rural or critical access hospital may have no realistic alternative supplier and no neighbor within easy reach. For it, concentration risk is largely about fallback, since diversion is already hard. A behavioral health provider faces a further constraint: its records carry stricter rules, so improvised workarounds such as emailing records between sites may create compliance problems of their own. Federally qualified health centers often share platforms through networks that serve many centers, which concentrates risk among organizations that serve the same vulnerable populations.

The contract: what the supplier owes before and during

Hosted software contracts in healthcare focus on functions, uptime percentages and HIPAA business associate terms. A business associate agreement covers privacy obligations. It does not, on its own, require the supplier to restore service by any particular time.

That gap surprises many executives. A business associate agreement is the contract HIPAA requires when a supplier handles patient information on a provider’s behalf; it deals with how the data is protected and what happens if it is breached. An uptime percentage promises how often the service will be available in normal months, and usually offers modest service credits if it is not. Neither is designed for a ransomware event in which the service may be gone for weeks.

Terms that matter in a ransomware event

Renewals are the moment to add terms that matter in a ransomware event:

• Incident notice. Notice within a short, defined period of any security incident affecting the service, including those that fall short of a confirmed breach.
• Evidence of controls. Annual evidence of security controls, including multi-factor authentication on every remote and customer access path. The UK regulator later found that the attacker entered Advanced through a customer account without it.
• Recovery objectives. Recovery time objectives for the service as a whole, tested and reported.
• Data export. A right to export the health system’s data in a usable format at any time, including during an outage.
• Restoration order. A commitment on how restoration is sequenced across customers, so a large system knows whether it waits behind hundreds of others.

A few definitions. Multi-factor authentication means requiring something more than a password to log in, such as a code from a phone app or a physical key, so that a stolen password alone is not enough. A recovery time objective is the target time within which a service must be restored after a disruption. Restoration sequencing matters because a supplier with hundreds of customers cannot bring them all back at once. Someone decides the order, and it is better to know in advance where you stand.

Evidence that means something

Assurance reports are the usual evidence. Many suppliers provide a SOC 2 Type II report, an independent auditor’s opinion on whether controls operated over a period, or a HITRUST certification. Both are useful. Both depend on scope. A report may cover the supplier’s corporate network but not the platform’s support access paths. It may test multi-factor authentication for staff but not for customer accounts. Such a report can be accurate and still miss the route an attacker uses.

A health system’s vendor risk team should read the scope section first, then the exceptions. It should ask for a bridge letter covering the gap since the report period ended, and should follow up on any exception touching remote access, privileged accounts, backup or patching. The ICO’s findings against Advanced cited gaps in multi-factor authentication, vulnerability scanning and patch management. Those are the controls to test hardest.

The customer’s own accounts

The route into Advanced was a customer account. That detail turns part of the question back on the buyer. Health systems create and manage many of the accounts their staff use on supplier platforms, and those accounts are only as strong as the customer’s own practices.

Three practices reduce that exposure. The first is connecting supplier platforms to the health system’s own identity service through single sign-on, so that its multi-factor authentication and sign-in policies apply. The second is removing access promptly when staff leave or change roles, which is harder when accounts are created by hand on each platform. The third is reviewing accounts with administrative or broad data access at least quarterly. A supplier can require multi-factor authentication. Only the customer can make sure that a former employee’s account no longer works.

Data export and the Cures Act

U.S. providers have a regulatory hook for the export right. The 21st Century Cures Act’s information blocking rules restrict practices by health IT developers, health information networks and providers that unreasonably interfere with access to electronic health information. Certified EHR developers were also required to offer an export of a patient’s or a whole population’s electronic health information, under a certification criterion with a deadline at the end of 2023.

Those rules do not guarantee export during a ransomware outage, when the supplier’s systems may be offline. They do make it harder for a supplier to refuse a routine, scheduled export, which is what feeds the local extracts discussed below. Contract language should still state the format, frequency and delivery method, since the regulations set a floor rather than an operating procedure.

Exit and substitution

Some services can be replaced quickly in an emergency, and some cannot. A patient messaging tool can be swapped in days. A clearinghouse cannot, because each provider must enroll with each payer to submit electronic claims and receive payments through a new route. Enrollment can take days to weeks per payer. Providers that switched clearinghouses in a hurry during 2024 learned this firsthand.

A health system can shorten that path in advance. Maintaining an active enrollment with a secondary clearinghouse for its largest payers costs some administrative effort and possibly a fee. In exchange, the switch becomes a configuration change instead of a multi-week project. Contracts with primary suppliers should also include transition assistance and a defined data handover if the relationship ends, including after a security incident.

Price and bargaining power

Each term has a price. Suppliers charge more for tested recovery and data export features, and smaller providers have little bargaining power alone. Group purchasing organizations and regional coalitions can negotiate common terms that individual clinics cannot. How incident, breach and business associate obligations interact in a particular agreement is a question for the health system’s lawyers.

Timing matters too. Contract terms can only be changed at renewal or when the supplier wants something, such as a new module or a price increase. A health system that keeps a list of desired terms for each critical supplier, and raises them at every such moment, will get further over three years than one that attempts a single renegotiation. Suppliers also tend to standardize terms that many customers ask for, so coordinated requests through a coalition have effects beyond the coalition’s own members.

Fallback: capability that depends on no one else

The UK services that coped best had practiced paper processes, kept recent data available offline and could add staff for slower manual work. A hosted service changes what that preparation looks like, because the health system cannot restore the system itself and does not know how long it will wait.

Three items belong in the budget for any critical hosted service. The first is a periodic local extract of the data needed to operate: patient lists, active orders, medication information and open referrals, readable on a device that does not depend on the supplier. The second is downtime procedures and forms that staff have actually used in a drill, with a named clinical owner. The third is a reconciliation plan for entering paper records once the system returns, which in a long outage can take longer than the outage itself.

Local extracts

A local extract is a regularly refreshed copy of a small, carefully chosen set of data. It is saved somewhere the health system controls, such as a secured laptop or server in each department, and is readable without the supplier’s software. It does not need to be the full record. It needs to answer the questions clinicians ask in the first hours and days. Who is on our list today, what are they taking, what was ordered and who is waiting to be seen.

A health system that sets up such extracts should test them the way it tests fire alarms, by actually opening the file on the device during a drill. An extract that has stopped refreshing without anyone noticing gives false comfort. The extract is also sensitive data in its own right. It needs encryption, access control and an owner, or it becomes a new privacy risk while solving a resilience one.

Many large EHR platforms offer a built-in downtime reporting feature that pushes key reports to designated workstations. Hosted customers should confirm that such features work when the hosted service itself is unreachable, since a feature that depends on the same platform may fail with it.

Downtime procedures and drills

Downtime procedures are the paper forms, phone trees and decision rules staff use when systems are unavailable. Most hospitals have them for short, planned outages. Few have practiced them for an outage of weeks, in which paper volumes grow, staff rotate and the forms run out. A drill that lasts a single shift tests the start of an outage. It does not test the third week.

U.S. hospitals already have a framework for this. The Medicare conditions of participation require hospitals to maintain an emergency preparedness program, with plans, policies, communication arrangements, training and exercises. A prolonged supplier outage is a reasonable scenario to include. Running it as a tabletop exercise with clinical leaders, revenue cycle and communications teams shows quickly where the gaps are.

Communications when the channel is down

Many health systems now run patient communication through the same hosted platforms that hold appointments and records. When those fail, so do appointment reminders, portal messages and sometimes the call center’s view of who is booked. Staff communications may depend on the same identity systems.

A fallback communications plan names channels that do not share the failure. Examples include a public website update process, a phone message script and a list of key contacts held offline. It also needs a way to reach clinical leaders off the corporate network. Patients need to know whether to come in. Staff need to know which procedures are in force. Both messages fail if they rely on the platform that is down.

Reconciliation

Reconciliation deserves a word of explanation, because it is the most often forgotten. During an outage, clinicians record care on paper. When the system returns, every one of those records must be entered, checked and matched to the right patient, so that medication histories, test results and billing are complete.

In a short outage this is a nuisance. In an outage lasting weeks it is a major project, competing for staff with normal work, and errors made in a hurry can affect patient safety and revenue for months. A reconciliation plan names who enters what, in what order, and how quality is checked. It also decides which records must be entered in full and which can be scanned and attached, a choice with clinical, legal and billing consequences.

Counting the cost

These costs are easy to leave out of a SaaS business case, because the vendor’s price looks complete without them. A total cost of ownership that includes extracts, drills and reconciliation staff gives a truer comparison between suppliers, and between hosted and self-run options. A supplier that makes local extracts easy is cheaper to own than one that makes them hard, even at the same subscription price.

Weighing the cost of shared software

Supplier risk can feel like a procurement detail. In health care, it is a patient safety issue with financial, legal and reputational consequences. This final part weighs what a shared failure costs, the strongest case for shared software and how a health system can keep score.

What a supplier outage costs

Patients. When records disappear, clinicians lose sight of allergies, medications and recent results. Paper processes work, but they are slower, and in urgent care slower can matter.

Staff. Long outages exhaust clinical and administrative teams, who must do the same work by hand and then re-enter it afterward.

Money. If revenue cycle or clearinghouse services fail, claims stop flowing and cash flow follows. Reconciliation after an outage adds cost and delays billing further.

Regulators and privacy. When a supplier is breached, the health system may still have obligations to patients and regulators. Under HIPAA, a business associate must notify the covered entity of a breach, and the covered entity generally remains responsible for notifying patients and HHS. Contract terms on notice and cooperation shape how quickly it can meet those duties.

Reputation. Patients see their own provider’s name, not the supplier’s. A system that could not see patients or answer phones bears the public consequences even if it was never the target.

The case for shared software

The strongest counter-argument is that shared platforms are safer on average. A large supplier can afford a security team, round-the-clock monitoring and tested backups that a community hospital never could. Many hospitals that ran their own systems were themselves hit by ransomware. Moving to a well-run hosted platform may cut the chance of an outage even as it raises the chance that an outage is shared.

That argument has force, and it is the reason this analysis does not recommend leaving shared platforms. Common software also makes data exchange, clinician training and interoperability easier, which improves care on ordinary days. The point of the three questions is narrower. A shared platform changes the shape of the risk, from many small independent failures to fewer, larger correlated ones. Plans built for independent failures, such as diversion to a neighbor, stop working against correlated ones.

A second objection is cost. Smaller providers, already short of money and staff, cannot afford second suppliers, extracts and drills for every service. They do not need to. The register below ranks services, and most providers will find that two or three hosted services carry most of the clinical and financial exposure. Fallback spending belongs there first.

A third objection is that procurement terms do not stop attackers. True again. A contract cannot prevent an intrusion. It can require the controls that make one less likely, give the health system early warning, and set expectations on restoration and data access that shape how the outage unfolds.

What insurance does and does not cover

Cyber insurance is often assumed to cover supplier outages. Many policies offer contingent or dependent business interruption cover for losses caused by an outage at a supplier. That cover is frequently subject to sublimits, waiting periods and definitions of which suppliers count. Some policies distinguish between malicious attacks and system failures, which matters for an event like a faulty update.

A health system’s risk manager should read the dependent business interruption terms against the register of critical hosted services. If a clearinghouse or hosted EHR outage of several weeks would exceed the sublimit, the gap belongs in the board’s risk discussion. Brokers can model likely losses. The decision to buy more cover, or to spend the money on fallback instead, is a trade-off the board should see explicitly.

The register, the contract and the drill

A well-prepared health system keeps a register of critical hosted services. For each, it shows the supplier, where the service is hosted, roughly how many regional peers share it, and the fallback the system can run on its own. Its contracts include incident notice, evidence of multi-factor authentication, tested recovery objectives, a data export right and clarity on restoration order. It takes regular local extracts of the data needed to keep operating, drills downtime procedures with named clinical owners and budgets for reconciliation. And its diversion plans have been tested on the assumption that neighbors may be down too.

Useful measures follow from the register. They include the number of critical hosted services with a current concentration estimate and the share with the five contract terms in place. They also include the share with a tested local extract and the date of the last multi-week downtime exercise. Those measures suit a board risk committee report, because each one is a count rather than a judgment.

The gaps tend to show up in the same places:

• Assuming neighbors will help. Mutual aid plans that never check whether partners use the same platform.
• Treating the business associate agreement as resilience. It covers privacy, not recovery.
• Relying on uptime percentages. Monthly availability targets say little about a multi-week outage.
• Paper procedures that live in a binder. Downtime forms that no one has used in a drill will not work smoothly on the day.
• Forgetting reconciliation. Planning to go to paper without planning how to come back.
• Comparing suppliers on subscription price alone. Ignoring the cost of extracts, drills and recovery staff.
• Negotiating alone. Smaller providers accepting standard terms when a coalition could secure better ones.
• Reading assurance reports for the opinion only. Skipping the scope and exceptions, where access gaps show up.

Questions on concentration, contract terms and local copies

• For each critical hosted service, how many providers in our region use the same supplier, and does our diversion plan rely on any of them?
• What do our contracts actually require a supplier to do in a ransomware event: how quickly must they tell us, how fast must they restore service, and in what order relative to other customers?
• Can we export our data in a usable format at any time, including during an outage, and have we ever tried?
• Do we hold a recent local copy of the patient lists, orders, medications and referrals we would need to keep operating?
• Who would re-enter paper records after a long outage, how long would it take, and is that in the budget?

Asking them takes no technical expertise. Each tests whether a convenient subscription has become a single point of failure for patient care.

With hindsight

Advanced restored its services over the following weeks and months. For the urgent care and mental health services involved, that meant an extended period of manual working and, afterward, the slow task of bringing records back up to date.

The regulatory reckoning took longer. In August 2024 the UK Information Commissioner’s Office announced a provisional fine of about 6.09 million pounds. In March 2025 it fined Advanced about 3.07 million pounds, in a settlement Advanced agreed not to appeal. The regulator said the reduction reflected Advanced’s engagement with the National Cyber Security Centre, the National Crime Agency and the NHS after the attack, among other steps. It cited gaps including the lack of multi-factor authentication on the account the attacker used, incomplete vulnerability scanning and inadequate patch management.

That finding underlines why multi-factor authentication on every access path belongs in supplier contracts and assurance reviews. A single account without it was enough to open the door.

The UK saw a second shared-supplier failure in June 2024, when ransomware hit Synnovis, a pathology services provider to several London hospital trusts. Blood testing was disrupted, and thousands of appointments and procedures were postponed. The pattern was the same: the hospitals were not the point of entry, and the supplier’s outage became theirs. In late 2025 the UK government introduced a Cyber Security and Resilience Bill in Parliament, which would extend the country’s network security regulations to cover managed service providers.

The U.S. counterpart arrived in February 2024, when ransomware at Change Healthcare disrupted claims, pharmacy and authorization processing for providers nationwide for weeks and prompted emergency federal funding arrangements. That made the concentration argument impossible to ignore. American providers, many of which had never thought of a clearinghouse as critical infrastructure, discovered how much of their cash flow and patient service ran through a single shared supplier.

The details echoed Advanced closely. UnitedHealth Group’s chief executive told Congress in May 2024 that the attackers had used stolen credentials to enter through a remote access portal that lacked multi-factor authentication. He also confirmed that the company had paid a ransom. UnitedHealth later estimated that the personal information of roughly 190 million people may have been affected, which made it the largest health data breach reported in the United States. The Centers for Medicare & Medicaid Services offered accelerated and advance payments to affected providers to bridge the cash gap.

A non-malicious event made the same point in July 2024. A faulty update to CrowdStrike’s endpoint security software crashed Windows computers worldwide, and many hospitals had to fall back on downtime procedures for hours or days. No attacker was involved. A single shared dependency failed, and every customer that relied on it failed with it.

Federal policy moved too. In January 2024, HHS published voluntary cybersecurity performance goals for the health sector, which put multi-factor authentication and vendor risk among the essential practices. At the turn of 2025, HHS proposed a substantial update to the HIPAA Security Rule. It would make multi-factor authentication an explicit expectation and ask covered entities to obtain written verification of business associates’ safeguards. Whatever its final form, the proposal showed regulators moving toward the supplier-assurance questions this article raises.

By 2026, more health system contracts include incident notice, recovery and data export terms, and more organizations hold offline copies of critical data. Concentration itself has not declined much, so contracts and practiced fallbacks remain the main defense.

Buying the same software as your neighbors is often a sensible choice, but it changes what resilience means. Asking whether your own systems are secure, or whether a partner could take your patients for a day, no longer covers it. The questions are whether the services you share with your peers can fail all at once and what your supplier has promised to do if they do. A third is whether your staff could keep caring for patients without them. Health systems that can answer those questions plainly are the ones best placed for the next shared failure.