Bigger network, thinner safety net: Ascension’s outage hit every sister hospital at once

The week

On May 8, 2024, Ascension, one of the largest nonprofit health systems in the United States, noticed something wrong. Its security teams detected unusual activity on the network, and the organization took systems offline to contain it. It later confirmed a ransomware attack. Ransomware is criminal software that locks up an organization’s computers and files so they cannot be used, usually followed by a demand for payment.

The effects reached far beyond a single building. Ascension operates about 140 hospitals across 19 states, and its electronic health record went down across most of them. The electronic health record, or EHR, is the digital patient chart: medications, allergies, test results, doctors’ notes and orders, all in one place and shared across departments. Pharmacy systems and other clinical applications went down too. Nurses, doctors and pharmacists who had spent years working on screens moved to paper and manual processes. Some hospitals diverted ambulances for a period, meaning paramedics were asked to take patients to other hospitals instead.

News reports linked the attack to the Black Basta ransomware group, a criminal ransomware operation, though Ascension did not confirm that attribution. In June, the organization explained how the intrusion began. An employee had downloaded a malicious file believing it was legitimate. It is a reminder of how ordinary the start of these events can be: one click, by one person doing their job, at one of the largest health systems in the country.

Recovery was slow and deliberate. Access to the electronic health record was restored market by market through May and June, rather than everywhere at once. On June 14, Ascension said clinical workflows were functioning much as before.

What makes the Ascension case instructive is its shape. In a large system, hospitals normally lean on one another when one is in trouble. They take each other’s patients, lend each other staff and share central services such as pharmacy and billing. This time every one of those sister hospitals was struggling at the same moment, because they all ran on the same shared technology. The network that was supposed to be the backup had gone down together.

Extended downtime had already hit UHS, Scripps and CommonSpirit, and its unit-level lessons were familiar: paper skills, clinical ownership of downtime procedures and the backlog that piles up afterward. Ascension added a system-level problem, one that boards of large health systems should understand clearly.

A large health system’s resilience plan implicitly assumes that if one hospital is in trouble, the others are not. Sister hospitals take diverted patients, central teams send staff, and shared services keep running. That assumption is usually sound, because most problems are local: a flood, a power failure, a surge of flu patients in one city. Shared technology platforms change the picture. They mean a single intrusion can switch off all three forms of help at once. The exposure splits into three areas: patient capacity, people and shared services.

Why shared platforms make one problem everyone’s problem

Over the past two decades, health systems have grown by merging and acquiring hospitals, and they have consolidated their technology at the same time. Instead of each hospital running its own patient record, pharmacy software and billing system, a large system typically runs one of each, centrally, for everyone. In the jargon these are “shared platforms” or “shared services.”

The business case is strong. One record means a patient’s history follows them from a clinic in one city to a hospital in another. One pharmacy system means consistent safety checks. One billing operation is cheaper to run than a hundred small ones. Central teams can buy better security monitoring than any single small hospital could afford.

The trade-off is concentration. A city might move every household onto one water main because it is cheaper and cleaner than a thousand private wells. On an ordinary day, that is a clear improvement. On the day the main breaks, every tap runs dry together. A computer network works in a similar way. When attackers get into one part of a connected system, they can often move sideways into others, and when the organization pulls the plug to stop them, it pulls the plug everywhere the system reaches.

Security specialists use the phrase “blast radius” for this: how far the damage spreads from a single point of failure. Centralization tends to make the blast radius bigger. The answer is to decide, deliberately, how big a blast radius the organization is willing to accept, and to plan for the day it is tested, rather than to abandon centralization.

What “going to paper” means inside a hospital

Executives who have never worked a clinical shift may not know what changes when the electronic record goes dark. Hospitals keep “downtime procedures” for exactly this moment: printed forms, binders of instructions and, ideally, regularly refreshed printouts of each patient’s current medications and care plan. Most are designed for short outages, a few hours of planned maintenance or an unexpected glitch. They are rarely built for weeks.

On paper, a medication order that once flowed from a doctor’s screen to the pharmacy and then to a barcode scanner at the bedside becomes a handwritten order, carried or faxed to the pharmacy, checked by hand and recorded on a paper chart. Lab results arrive by phone or courier rather than appearing in the record. Imaging reports may be read aloud. Every one of these handoffs takes longer, and each is a point where something can be misread or missed. Safety checks that the software performed automatically, such as warnings about allergies or dangerous drug combinations, now depend on people remembering to look.

Behind the scenes, the strain is just as real. Admissions staff register patients by hand. Bed managers track occupancy on whiteboards. Billing teams cannot record charges in the usual way, so the money the hospital will eventually be owed becomes harder to capture. And when the systems return, everything written on paper has to be entered back into the record so the patient’s history is complete. That reconciliation can take weeks of its own.

In a single hospital, this is hard but manageable, because help is nearby. A sister hospital keeps its record running, so complex patients can be transferred there. Central teams send experienced staff. Shared pharmacy and supply services keep working. The question Ascension raised is what happens when that help is suffering from the same outage at the same time.

Patient capacity: where diverted patients go

Diversion plans in multi-hospital systems usually point first to other hospitals in the same system. That makes sense. Transfers are easier when beds, physicians and records sit under one roof. Doctors know each other, the paperwork is familiar and the patient’s chart is already on the screen.

When every hospital in a market is on paper, that pathway loses most of its value. The receiving hospital is working without its electronic record too, and a transfer adds a paper chart to a paper chart. Moving a patient from one struggling hospital to another struggling hospital helps no one much.

The workable alternative is regional. Emergency medical services agencies, regional health care coalitions (groups of hospitals, public health agencies and emergency services that plan together for disasters) and competing hospitals make the diversion decisions that matter in a market-wide outage. That needs groundwork, because these are not conversations to start in the middle of a crisis. Systems can agree in advance with neighboring hospitals and EMS on how a cyber-driven diversion will be declared, how long it can last and how it will be lifted. They can also agree what clinical summary travels with a diverted patient when the sending hospital cannot print from its record: the medications, allergies and key findings a receiving doctor needs in the first hour.

The trade-off is commercial. Sending patients to a competitor costs revenue, and some leaders delay diversion for that reason. Pre-agreed clinical triggers take that decision out of the moment and give it a documented basis. Examples include losing medication administration records, the system nurses use to track which drugs each patient has received, or losing access to imaging results for a set number of hours. When the trigger is met, diversion follows, without a debate about market share at two in the morning.

Five hospitals, one record, a new diversion plan

Suppose a health system has five hospitals in one metropolitan area, all on one shared record. Its old plan said that if any hospital had to divert, ambulances would go to the nearest sister hospital. After a tabletop exercise (a structured, discussion-based rehearsal of a crisis) built around a system-wide ransomware attack, the team realized that plan collapsed on day one. They met with the county EMS agency and two independent hospitals in the area and agreed three things: the clinical triggers that would start a cyber diversion, a one-page handwritten transfer summary, and a daily call to review whether diversion should continue. The cost was a few meetings. The benefit was a plan that did not depend on the very systems that had failed.

People: who comes to help

Large systems handle local staffing shortfalls by moving people around. Float pools (nurses who work wherever they are needed), travel staff, central nursing resources and clinical informatics teams can all be sent where demand spikes. Clinical informatics staff are the people, often nurses or pharmacists by training, who understand both clinical work and the software that supports it.

In a system-wide outage, every market needs those people at the same time. There is no spare hospital to borrow from. Worse, central informatics staff, who know both the record and the downtime forms, are pulled toward restoration work just as the hospitals need them most. The same handful of experts is wanted at the bedside and in the recovery room for the computer systems.

Two adjustments reduce the strain. First, systems can define in advance which central roles stay with hospital operations and which move to recovery, so the same experts are not double-booked. Second, staffing agencies and contract labor arrangements can include terms for a cyber event, with response times and the skills required, including experience with paper charting. Many younger clinicians have never worked a full shift on paper. These arrangements cost money in uneventful years, and that is the decision a board has to make knowingly.

Help can also come from unaffected health systems. Clinical informatics staff and nurses familiar with the same record vendor can shorten the learning curve, especially during restoration and reconciliation, the painstaking work of entering everything recorded on paper back into the electronic record. Arranging that in the middle of an incident raises questions about credentialing (confirming that a clinician is qualified and authorized to work in a given hospital), liability, privileged access to systems and confidentiality. Settling them in a standing agreement beforehand, with counsel involved, turns a favor into a plan.

Communication is also a people resource. Front-line staff need a single source of current downtime procedures for their market, refreshed each shift. A central command structure that issues one set of instructions for nineteen states will miss local differences in forms, lab couriers and pharmacy routes. A completely decentralized response loses coordination. Market-level command posts with clear authority, coordinated centrally, fit an outage of this shape better than either extreme.

Shared services: what stops everywhere

Centralization put more than the clinical record on shared platforms. Pharmacy systems, scheduling, patient portals (the websites and apps patients use to see results and message their doctors), supply chain and revenue cycle typically run as shared services across a large system. Revenue cycle is the full process of turning care into payment: registering the patient, recording what was done, coding it, billing insurers and collecting. Ascension’s own disclosures pointed to pharmacy and other clinical systems as well as the record, and its fiscal 2024 results cited delays in revenue cycle processes caused by the incident.

Each shared service needs its own answer to the question of what happens when it is unavailable in every market at once. For pharmacy, that means verified paper or standalone workflows for dispensing and controlled substances, and arrangements with outside pharmacies for discharge prescriptions. For supply chain, it means par levels (the minimum stock of each item a unit keeps on hand) and manual ordering routes that do not depend on the shared platform. For revenue cycle, it means a documented way to capture charges during downtime and a plan for the billing backlog that follows, because every day of paper care is a day of bills that someone will have to reconstruct.

Architecture choices sit underneath all of this. Segmenting shared platforms by region, so a problem in one area cannot spread freely to all the others, limits the damage. Keeping read-only copies of key patient data available per market lets clinicians look up a medication list even when the main record is down. Isolating identity systems (which control who can log in) and backup systems from the main network makes it harder for attackers to disable the very tools needed to recover. All of these reduce the blast radius.

Each adds cost and complexity, and centralization’s efficiency case rarely prices in the scenario where everything fails together. A useful exercise is to list every shared service, ask whether its loss in all markets for three weeks is survivable, and record who decided the answer. The record matters as much as the answer. A risk someone has looked at and accepted is a management decision. A risk nobody has examined is a surprise waiting to happen.

Five measures a board already watches

For a board or executive team, the Ascension case connects technology directly to the measures they care about most.

Patients and quality. Paper processes are slower and leave more room for error, particularly with medications. Diverting ambulances changes where people in a community receive emergency care. These are patient safety questions first.

Money. Revenue cycle delays mean cash arrives late. Restoration and remediation are expensive. A plan that relied on sister hospitals to absorb lost volume will find that volume goes to competitors instead.

Staff. Weeks of paper charting, double documentation and reconciliation are exhausting. Organizations that prepared their people, and arranged outside help, protect both their workforce and their recovery timeline.

Regulators and the community. A health system that diverts ambulances across a region becomes a matter of public concern. Regulators, local officials and the press will want to know what the plan was and whether it worked.

Strategy. Every health system pursuing scale is, knowingly or not, making a bet about concentration risk. Naming that bet explicitly, and funding the safeguards, is part of good governance.

Planning for everything failing together

Well-prepared systems plan for the scenario where everything shared fails together, as well as the one where a single hospital has a bad day. They have diversion agreements with neighbors and EMS that do not assume sister hospitals are available. They know which experts go where when the systems go down. They have tested paper workflows for pharmacy, supply chain and billing. And they can point to a list of shared services with a recorded decision on each.

The usual failures follow from the old assumption:

• Planning for one hospital at a time. Downtime plans written for a single site often name sister hospitals as the backup.
• Double-booking experts. Assuming central informatics staff can both support the wards and lead recovery.
• Leaving outside help to goodwill. Hoping other health systems or agencies will lend staff, without settled terms on credentialing and liability.
• One-size instructions. Issuing a single central set of downtime procedures that ignores local forms, couriers and routes.
• Treating segmentation as optional. Deferring regional separation and local data copies because they add cost, without anyone formally accepting the risk.

What the next system-wide outage will test

• If every hospital in our system lost its electronic record on the same morning, where would ambulances go, and who would decide?
• Which of our central experts stay with the hospitals during a system-wide outage, and which move to recovery?
• Do we have standing arrangements with other health systems to lend staff, with credentialing and liability already settled?
• For each shared service, from pharmacy to billing, could we survive three weeks without it in every market at once? Who made that judgment?
• Can clinicians in each market see a read-only copy of key patient data if the main record is down?

Scale itself is not the problem. A large system can buy expertise, monitoring and recovery capacity that small hospitals cannot. Planning should simply stop treating the network as the backup for itself.

With hindsight

Electronic health record access was restored across Ascension’s markets by mid-June 2024, about five weeks after the attack. Five weeks is a long time to run hospitals on paper, and the financial picture reflected it. Ascension reported an operating loss of about $1.8 billion for its fiscal year ended June 30, 2024, and its filings cited revenue cycle delays and remediation costs from the incident among the factors behind that result.

The data side became clearer later in the year. In December 2024 Ascension reported to HHS, the federal Department of Health and Human Services, that data on about 5.6 million people had been affected. According to the company, that data was taken from a small number of file servers rather than from the clinical record itself. It is a useful distinction for leaders: the systems that hold the most sensitive data are not always the ones attackers reach, and the systems that stop operations are not always the ones that leak.

Other large health systems and their regulators took the multi-market scenario more seriously afterward. HHS’s proposed update to the HIPAA Security Rule, published in January 2025, included a 72-hour restoration expectation for critical systems. That sharpened a question many systems had not asked directly: can our shared platforms actually be restored market by market, quickly, or are they built as one indivisible whole? An expectation measured in hours sits uneasily beside a recovery measured in weeks.

The underlying tension remains. Centralization lowers cost and improves consistency, and it raises the stakes of a single compromise. Neither side of that trade-off is wrong. What matters is that someone owns it explicitly: a named executive who can say which shared services the organization could lose everywhere at once, for how long, and what would carry the load in the meantime. Boards can ask to see that list, and treat regional segmentation, local data copies and outside partnerships as part of the price of scale rather than optional extras.