In a merged health system, the network decides which hospitals go to paper

The week

In early October 2022, nurses and doctors at a number of American hospitals reached for paper. Screens that normally showed patient charts, medication orders and test results were unavailable. Staff wrote notes by hand, ran orders between departments on foot, and in some places sent ambulances elsewhere. At other hospitals belonging to the very same organization, work went on as usual.

The organization was CommonSpirit Health, one of the largest nonprofit health systems in the United States. In early October 2022 it reported an IT security incident that began around October 2. Hospitals operating under several regional names, including in Washington, Tennessee, Iowa and Nebraska, lost access to electronic health records and other systems for up to several weeks. The electronic health record, or EHR, is the digital patient chart at the center of modern hospital work.

The first public statement, issued on October 4, described only an “IT security issue” affecting some facilities. By the week of October 10, the picture had not changed much for the hospitals involved. The affected facilities were still working under downtime procedures. Patient portals, the websites patients use to see results and message their doctors, were also offline in several markets. Appointment scheduling was disrupted, and patients were told to call their provider’s office directly.

The disruption was reported across several of the system’s regional brands. They included Virginia Mason Franciscan Health in Washington state, CHI Memorial in Chattanooga, Tennessee, CHI Health in Nebraska and Iowa, MercyOne in Iowa and St. Luke’s Health in Houston. Local news outlets in each market carried their own version of the story, often with little detail beyond the fact that records were down and staff were coping.

Some hospitals reported delayed care and ambulance diversions, meaning ambulances were directed to other hospitals because the affected ones could not safely take new emergency patients. Other facilities in the system were not affected.

CommonSpirit later confirmed that the incident was ransomware. Ransomware is malicious software that criminals use to lock up an organization’s computer systems, usually by scrambling the data so it cannot be read, and then demand payment to restore access. Often the attackers spend days or weeks inside a network beforehand, gaining access to as many systems as possible so that the damage is widespread when they strike.

The confirmation that it was ransomware came later. Early statements described the event in general terms. That caution is normal while forensic work is under way, but it frustrates for clinicians and patients who are trying to plan around an outage with no end date. Later notification letters said an unauthorized party had been inside part of the network from September 16 to October 3, 2022. It amounted to roughly two and a half weeks of access before the systems went dark.

CommonSpirit had taken systems offline as a precaution while it investigated and restored them. That is a common and often sensible step: disconnecting systems can stop the attack spreading, but it also means healthy systems go dark along with damaged ones.

A November update on the system’s website put the outline on the record. Impacted facilities had followed existing protocols, including taking the EHR and patient portals offline. Clinic and patient care systems at Dignity Health, Virginia Mason Medical Center, TriHealth and Centura Health facilities had not been affected. By then, providers in most markets had EHR access again.

The organization’s history matters to the story. CommonSpirit had been formed in 2019 by combining two large Catholic health systems, Dignity Health and Catholic Health Initiatives, each with its own long history of acquisitions. It was a system built from many systems, with all the technology that comes with that.

The CommonSpirit outage did not happen in isolation. Health care had been a frequent ransomware target throughout the pandemic, and federal agencies were issuing warnings aimed squarely at hospitals. A few days after this week, on October 21, 2022, CISA, the FBI and the Department of Health and Human Services published a joint advisory on a group called Daixin Team. It described a gang that had been attacking health care organizations, encrypting EHR and imaging systems and stealing patient data. The advisory did not link Daixin to CommonSpirit, and CommonSpirit did not publicly attribute its attack to any group. The timing shows how live the threat to hospitals was that autumn.

Take the president of a community hospital that belongs to a large health system, on a busy Monday in October. Her own technology team has seen nothing unusual. Then a message arrives from headquarters: systems are being taken offline across several regions while an incident is investigated. Within the hour, her emergency department is working from paper, the pharmacy is checking orders by phone, and nursing supervisors are pulling out downtime binders that have sat on a shelf for years. She did not make the call, and she may not know who did.

The sections below trace how that happens. They start with why one part of a merged system goes dark while another carries on, and walks through how a ransomware attack moves. They then take the three layers that set how far one attack spreads: shared identity, shared network paths and shutdown authority. They close with what a wide spread costs, what better-protected systems have in place, and the questions to settle before the next connection is made.

Why some hospitals went dark and others did not

UHS in 2020, where unit leaders carried the load, and Scripps in 2021, where four weeks on paper tested downtime plans, showed what long downtime does at the bedside. CommonSpirit raises a question those cases did not raise as sharply. Why did some of its hospitals go to paper while others, in the same system, did not?

The answer in any merged health system lies in architecture inherited from deals. “Architecture” here simply means how the technology is put together: which systems connect to which, who can log into what, and where the data lives. Mergers combine hospitals faster than they combine technology. A merger can be signed in a day; joining two sets of computer networks, login systems and clinical applications takes years.

For years afterward, the organization runs a patchwork: some regions on a shared directory and network, others on their own, with connections added for each integration project. That patchwork, not the corporate org chart, decides which hospitals an intruder can reach and which a precautionary shutdown will take down.

What the public record shows

CommonSpirit has not published a technical account of how the attack spread, so no outsider can say which accounts or connections were involved. The public record does show the shape of the outcome. The brands reported as disrupted included Virginia Mason Franciscan Health, CHI Memorial, CHI Health, MercyOne and St. Luke’s Health in Houston. Most of them came from the Catholic Health Initiatives side of the 2019 merger. The system’s own update said Dignity Health, the other half of the merger, was not affected. Nor were Virginia Mason Medical Center, a Seattle system that had joined more recently, or jointly operated affiliates such as TriHealth in Cincinnati and Centura Health in Colorado.

That pattern fits the general explanation, though it cannot prove it. Organizations that kept their own directories, networks and EHR environments came through. Organizations that shared a technology estate with the affected side went down together. Whether the line was drawn by the attacker’s reach or by the precautionary shutdown, it followed the technology, not the brand on the building.

Three kinds of combined system

Health systems combine in different ways, and the blast radius differs with each:

• The holding company. The parent owns the hospitals, but each region keeps its own directory, network and EHR. One attack tends to stay in one region, but the parent struggles to set common controls, and small regions may run thin security teams.
• The half-integrated system. Some services are shared, such as email, the directory or a data center, while others stay local. This is where most merged systems spend years, and where dependencies are hardest to see.
• The fully consolidated system. One directory, one network and one EHR instance. Controls are consistent and visibility is good, but a compromise of the shared core reaches everything unless the design limits it from inside.

Smaller arrangements create the same exposure in miniature. A community or critical access hospital may run its EHR on a larger partner’s instance, through the hosted affiliate programs that major EHR vendors offer. A physician group bought by a hospital system may be moved onto the system’s directory within weeks. In both cases the smaller organization inherits the larger one’s blast radius, usually without any say over its controls.

Security professionals call this the blast radius: how far the damage from one incident can spread. Three layers set the blast radius:

1. Shared identity: who can log into what, and how far one set of credentials reaches.
2. Shared network paths: the digital roads connecting one hospital’s systems to another’s.
3. Shutdown authority: who can order a shutdown that affects many hospitals at once.

How a ransomware attack moves through a hospital network

To see why those three layers matter, follow a typical ransomware attack. The details vary, but the general shape is well established.

Getting in. Attackers first gain a foothold, often through a convincing email that tricks an employee into entering a password on a fake site, a stolen password, or an unpatched weakness in an internet-facing system. At this point they control one account or one computer.

Moving sideways. Next comes what security teams call lateral movement: the attackers explore the network, looking for more powerful accounts and more systems to reach. Every shared login and every open network connection is a potential route. This phase can last days or weeks, and the organization may notice nothing.

Gaining the keys. The prize is administrative control, ideally over the directory itself, because that unlocks almost everything else. With it, attackers can switch off protections, reach backups and push their software to many machines at once.

Striking. Finally, the ransomware is launched, scrambling files and systems across every place the attackers could reach. Increasingly, attackers also copy data out beforehand, so they can threaten to publish it as well.

Disabling recovery. Before launching, most modern crews go after the means of recovery. They delete or encrypt backups they can reach, remove the local snapshots that Windows keeps, and target the virtualization hosts on which many servers run. Encrypting one virtualization host can take dozens of servers down at once. Backup consoles joined to the main directory are especially exposed, because the same stolen administrator account opens them.

CommonSpirit’s own disclosures give a sense of timing. The intruder had access from September 16 to October 3, about seventeen days. That length is typical of human-operated ransomware, and it matters for the blast radius argument. Seventeen days is long enough to map a network, collect credentials and find every trust and open connection that leads somewhere useful.

Seen this way, the blast radius is set long before the attack, by decisions about how far one account can reach and how freely traffic can move. A merged system with one directory and wide connections between regions offers attackers a much larger playing field than one with separated regions and narrow, controlled paths.

What downtime looks like on the floor

A hospital without its electronic record slows at every step. Medication orders are handwritten and carried or phoned to the pharmacy. Lab and imaging results arrive on paper or by phone, slowing every decision that depends on them. Staff cannot easily see a patient’s history, allergies or recent tests. Every task takes longer, so fewer patients can be safely seen, which is why emergency departments may divert ambulances. When systems return, someone must enter all the paper records into the electronic chart. The longer the outage, the heavier each of these burdens becomes.

Downtime also has a long tail that boards rarely see. Barcode scanning at the bedside, which checks that the right patient gets the right drug, may not work without the EHR. Automated medication cabinets may have to run in override mode, with more manual checks. Charges captured on paper must be entered later before bills can go out, so cash arrives weeks late. Hospitals that print regular summaries of each inpatient’s medications and allergies to dedicated downtime computers cope far better in the first hours. Those printouts go stale, though, and after a few days staff are working from information that is days old.

Shared identity: one directory, one compromise

Every organization keeps a central list of who its users are and what each is allowed to do. This is called a directory. When a nurse logs into a workstation, the directory checks her password and decides which systems she can open. It works like the master key cabinet in a large building: it holds the keys for every door and records who can take which one.

Why integration starts here

Integration usually starts with identity. Leaders want one email system, one set of accounts and single sign-on to shared applications. Single sign-on means staff log in once and gain access to all the applications they need, rather than juggling separate passwords. These are reasonable goals: they save money, make collaboration easier, and reduce frustration for staff who move between facilities.

Directory trusts or a consolidated directory make that possible. A “trust” is an arrangement in which one directory agrees to accept logins vouched for by another. They also mean that an attacker who gains administrative control of the directory gains a path to every hospital that trusts it. If the master key cabinet serves every building, whoever controls the cabinet controls every building.

How directory trust works, and fails

Most hospital systems run Microsoft Active Directory on premises, often synchronized with a cloud identity service for email and software subscriptions. After a merger, the usual first step is a trust between the two organizations’ directories. A trust lets users from one side sign in to resources on the other without a second account. Trusts can be one-way or two-way, and they can be scoped narrowly with settings such as selective authentication, which limits who from the other side can use them. Under deadline pressure, many are set up broadly and left that way.

Directory compromise is also unusually hard to undo. An attacker with full control of Active Directory can forge credentials that remain valid after passwords are reset, unless the directory’s own master secrets are reset too, in a set order. Microsoft publishes a forest recovery guide for exactly this case. Following it takes careful planning and, in a large organization, days. Every hospital that depends on that directory waits for the work to finish.

The cloud side adds its own path. The server that synchronizes on-premises accounts to the cloud directory usually holds powerful rights in both. If an attacker takes it, the compromise can cross from the local network to cloud email and file storage. Treating that server as a top-tier asset, with the same protection as the directory itself, is one of the cheaper controls on this list.

Limiting how far one key reaches

Merged systems can keep the benefits while limiting that reach:

• Separate administrative accounts for each region, so a domain administrator in one region is not one in all. An administrator is a user with powerful rights to change settings, create accounts and install software.
• A hardened tier for the most privileged identities, protected by phishing-resistant authentication, such as physical security keys that cannot be tricked into working on a fake website, and used only from dedicated workstations kept for that purpose.
• Review of trusts between legacy directories, removing those that integration no longer needs.

Each of these adds administrative overhead in accounts, steps and devices, which central IT teams resist. That overhead is the price of keeping one compromised credential from becoming a multistate outage.

The case for one directory, and its limits

The strongest objection to all this is fair. A single, well-run directory may be safer than five neglected ones. Small regions with their own directories often lack staff to patch them, watch them or protect their administrators. Consolidation brings them under one security team, one monitoring tool and one standard. Several large attacks on health care have begun in exactly the kind of under-resourced corner that consolidation is meant to fix.

The answer is to separate two things that integration programs tend to bundle together. Consolidating operations, meaning one security team, one monitoring platform and one set of standards, is usually a gain. Consolidating privilege, meaning one set of administrator accounts that reaches everywhere, is where the blast radius grows. A system can run one directory and still divide administrative rights by region and tier. What matters is how far a single stolen credential reaches, not how many directories appear on the diagram.

The payoff in recovery

Separation also pays off in recovery. When identity is tiered by region, a region with no sign of compromise can be validated and restored on its own schedule. When everything trusts one directory, every hospital waits until that directory is rebuilt and proven clean. The difference can be measured in days of paper charting.

Service accounts deserve the same scrutiny. These are accounts used not by people but by software: system-wide applications, backup tools and monitoring agents. They often hold broad rights everywhere, rarely change their passwords and are seldom watched. They are among the first things an intruder looks for. A forgotten service account with rights in every region is, in effect, a master key nobody remembers handing out.

What an auditor or examiner would ask to see

Evidence for identity controls is concrete. It includes a list of every account with administrative rights in more than one region, with an owner and a business reason for each. It includes a record of trusts between directories, the date each was last reviewed and the decision to keep or remove it. It covers proof that the most privileged accounts use phishing-resistant sign-in and can log on only from dedicated machines, and a service account inventory with owners and password change dates. A health system that can produce those four documents in an afternoon is in a better position than most.

Shared network paths: integration links as attack routes

If identity decides who can get in, the network decides where they can go next. Every integration project leaves network connections behind. They include links between data centers, shared clinical applications reached across regions, and file shares used by system-level departments such as finance and revenue cycle, the function that handles billing and payment.

Many were opened broadly during a deadline and never narrowed. A project team needing finance staff in one region to reach a system in another may have opened a wide connection to meet a go-live date, intending to tighten it later. Later rarely comes. Multiply that by every integration project since the merger and the result is a web of connections nobody fully mapped.

Why hospital networks end up flat

Hospital networks are unusually hard to divide. They carry clinical applications, office systems, building controls, guest Wi-Fi and thousands of connected medical devices. Infusion pumps, imaging machines, lab analyzers and patient monitors often run old operating systems that cannot be patched quickly, because changes may need the manufacturer’s validation. Many of these devices need to talk to central systems, and the vendors that maintain them often need remote access too.

Integration engines add another layer. These are the systems that pass messages between the EHR, lab, pharmacy, radiology and billing, usually in a standard health data format called HL7. In a merged system, one integration engine may route messages for several regions. That makes it a natural crossroads, and a natural path for an attacker who reaches it.

What segmentation means

Segmentation turns those links into controlled paths. It means dividing a network into separate zones and controlling exactly what can pass between them. In a segmented design:

• Regions and major hospitals become separate zones.
• Traffic between zones is limited to named applications and protocols, logged, and reviewed.
• Clinical systems such as the electronic record, imaging and lab are isolated from general office networks, so an infected office laptop cannot easily reach the systems that keep patients safe.

The goal is a design in which losing one zone is serious but survivable for the others, and in which isolating a zone is a planned action rather than an improvised one.

The cost and the trade-offs

Segmentation is not free. Every rule between zones must be designed, tested and maintained. Tightening an old, broad connection can break an application nobody remembered depended on it, and in a hospital that can mean a lab result that fails to arrive. Network teams therefore move cautiously. They watch traffic for weeks, build allow lists from what they see, switch to blocking in stages, and keep a quick rollback plan.

The work also needs owners outside IT. Clinical engineering knows the devices, application teams know the interfaces, and vendors know their own remote access needs. A segmentation program that is run only by the network team tends to stall at the first broken interface. One with a clinical sponsor and an agreed change window tends to keep moving. Finer-grained approaches, sometimes called microsegmentation, can isolate individual servers, but they cost more and demand better application knowledge. Most systems start with coarse zones between regions and between clinical and office networks, and refine from there. Coarse zones deliver most of the blast radius benefit for a fraction of the effort, which makes them the sensible first milestone.

Mapping dependencies

Measuring this is straightforward in principle. For each hospital, the architecture team can list which other zones it depends on to deliver care, and which zones could reach it if compromised.

The first list often surprises executives. Hospitals that depend on a shared data center for their electronic record will go down with that data center, however well segmented their local network is. Segmentation protects against spread; it does not help if the thing you depend on is the thing that is switched off.

The same applies to shared vendors. A remote support tool or managed service provider with access to every region is a path across zones that no firewall rule between regions will show. A managed service provider is an outside company that runs part of an organization’s technology on its behalf; if it can reach everything, so can anyone who compromises it.

Knowing that in advance tells leaders which hospitals need local read-only copies of critical data and which need independent downtime capability. A read-only copy is a regularly updated snapshot of key information, such as current medication lists and allergies, that staff can look at even when the main system is down.

Suppose a health system has three regions. Region A runs its own EHR in its own data center. Regions B and C share an EHR hosted in Region B’s data center, and all three share a single directory. If an attacker compromises the directory, all three regions are exposed. If Region B’s data center is taken offline, Region C goes to paper too, even if not a single computer in Region C was touched. A one-page map showing those facts would tell that system’s board more about its real risk than any number of policy documents.

The evidence for network controls

An auditor or board committee looking at this layer would ask for a current network diagram showing zones and the paths between them. They would also want the rule sets between regions, with an owner and a review date for each rule, and logs showing that traffic between zones is recorded. The last item is a list of every third party with remote access, showing how that access is granted and how it is cut off. The metric that matters most is simple to state: the share of traffic between zones that travels on a named, approved path. In a system that has never measured it, the first answer is usually sobering.

Shutdown authority: one decision, many hospitals

Taking systems offline as a precaution is often the right call in a ransomware incident. It stops spread and preserves evidence, the digital traces investigators need to understand what happened and confirm the attacker is gone. In a merged system, it is also a decision made centrally that lands on hospitals with different patient loads, different downtime readiness and different local exposure.

Writing down who decides

That calls for written decision rights, settled in advance: who can order a system-wide disconnection and who can isolate a single region; what clinical input is required before a shutdown, and within what time; and when a hospital with no sign of compromise can reconnect, and who decides.

The plan should specify the evidence needed to bring a zone back, such as clean scans of its servers and rebuilt credentials, so reconnection is not delayed by uncertainty or rushed by pressure. Without agreed criteria, two failure modes compete: cautious technical teams keep healthy hospitals offline far longer than necessary, or anxious leaders push to reconnect before it is safe and risk reinfection.

Who is in the room

A ransomware incident in a large health system brings in more parties than the IT team. Outside counsel usually leads the investigation so that findings can be handled under legal privilege. The cyber insurer often requires the use of firms from its approved panel. Law enforcement is notified. Each party has its own priorities, and none of them is responsible for a particular hospital’s emergency department.

Hospitals already have a structure for emergencies of other kinds. Many use the Hospital Incident Command System, a framework for running disasters such as mass casualty events, with defined roles for operations, logistics and planning. Linking the cyber incident plan to that command structure gives clinical leaders a familiar place in the response. Diversion also has limits that the plan should respect. A hospital on ambulance diversion still has duties under EMTALA. That federal law requires hospitals to screen and stabilize anyone who arrives at the emergency department, so walk-in patients still need a safe pathway.

Giving regional leaders a seat

Regional hospital leaders need a seat in those decisions. A precautionary shutdown that protects nine hospitals may cut the tenth off from its electronic record during a busy week. That trade-off is legitimate, and leaders should make it knowingly, with ambulance diversion and transfer agreements ready for the hospitals that bear it.

In practice, that means the incident plan names a clinical leader from each region who is reachable at any hour, and a short, rehearsed call in which the technical team explains what it proposes to disconnect and the clinical leaders say what that will mean for patients. The decision may not change, but the hospitals affected will be ready for it.

Different structures, different authority

Decision rights are simple when one organization owns and runs every hospital. They are harder in the arrangements common in health care. A system may manage a hospital under contract without owning it. Hospitals in a joint venture may share an EHR with a partner but have separate boards. An academic medical center may run the IT for affiliated community hospitals. In each case the plan should state, before any incident, who can disconnect whom, and what the smaller party is told and when. Contracts for hosted EHR and managed IT services are the natural place to write that down.

What a wide blast radius costs

In a merged or growing health system, the stakes are concrete:

• Patient safety. Delayed care and ambulance diversions are the human cost of a wide blast radius.
• Money. Weeks of downtime mean lost revenue, overtime, recovery costs and delayed billing.
• Community trust. A hospital that diverts ambulances for weeks is noticed by every family that depends on it.
• Regulators. Health privacy regulators expect organizations to protect patient data, and an attack that exposes records triggers notification duties and scrutiny.
• Deal value. An acquisition that connects a new hospital to the whole system without controls may also connect the whole system to the new hospital’s weaknesses.

The regulatory consequences

For a HIPAA covered entity, ransomware triggers specific duties. The HHS Office for Civil Rights addressed this in 2016 guidance. When ransomware encrypts protected health information, a breach is presumed unless the organization can show a low probability that the information was compromised. Breaches affecting 500 or more people must be reported to HHS and, in most cases, to prominent media in the affected states. Individuals must be notified without unreasonable delay and no later than 60 days after discovery. State laws add their own notice rules, and state attorneys general can bring their own actions.

A multistate system faces all of those at once. One incident can produce notification duties in many states, investigations by several attorneys general and class action lawsuits in more than one court. Such multiplication follows directly from the blast radius. An attack confined to one region produces one region’s worth of regulatory and legal work.

Diligence before the deal closes

Acquisitions are where blast radius is decided, so diligence is the cheapest moment to manage it. A buyer can ask for the target’s recent security assessments, its incident history, its backup and recovery tests, and its list of third parties with remote access. More cautious buyers keep the acquired organization on a separate network for a period after closing, connected only through narrow, monitored paths. They connect it more widely only after it meets the parent’s standards. That slows the realization of savings, and finance teams resist it. It also stops a weakness in the newly acquired hospital from becoming a path into every other one.

Merger plans can include all three layers. Integration roadmaps typically count consolidation as progress: one directory, one network, one email system. Adding blast radius as a measure, reported to the board alongside cost savings, makes the security consequence of each integration step visible before it is taken.

Who pays when the radius is wide

The costs do not fall evenly. The parent organization carries the recovery bill and the legal exposure. The affected hospitals carry the operational strain: overtime for staff charting by hand, cancelled procedures, and patients sent elsewhere. Neighboring hospitals that receive diverted ambulances carry part of the load too, without any say in the decisions that caused it. Patients carry the rest, in delayed results, rescheduled appointments and, at worst, slower emergency care.

That uneven distribution is one reason the trade-off between savings and blast radius rarely gets made explicitly. The people who capture the savings from consolidation, mostly at the system level, are not the people who bear the strain of a long outage, mostly at the hospital level. A board that sees both figures in the same report is in a better position to weigh them than one that sees only the savings. Regional hospital presidents, who will be the ones running emergency departments on paper, have good reason to ask for that view before each integration step is approved.

What the better-protected systems have in place

A health system that has absorbed these lessons keeps administrative accounts separated by region, with the most powerful identities held in a hardened tier, and an inventory of service accounts with owners, limited rights and regular review. Its network is divided into zones, with named, logged paths between them and clinical systems kept apart from office networks. Every hospital has a dependency map showing what it needs from elsewhere to deliver care, and local read-only copies of critical clinical data where it depends on a shared data center. Shutdown and reconnection rules are written down and include clinical voices, and integration plans report blast radius alongside savings.

Metrics a board can track

• The number of identities, human and software, with administrative rights in more than one region, and the trend over time.
• The share of traffic between zones that runs on named, approved paths.
• The time taken to isolate one region in the most recent exercise, measured, not estimated.
• The number of hospitals that would lose their EHR if a single shared data center went offline.
• The date of each hospital’s most recent downtime drill, and what it found.

Producing these figures needs no new tool. Each needs an owner and a habit of reporting it, ideally in the same pack as the integration program’s savings.

The usual failures run the other way. Consolidation is treated as automatically good, though one directory is cheaper to run and also one target to attack. Links opened for a project deadline stay open and become permanent attack routes. Software accounts and vendors are forgotten, though they often reach further than any person. Shutdown decisions are improvised, and deciding who decides in the middle of an incident costs hours. And segmentation is assumed to protect a hospital that depends on a shared system, which it cannot do if the shared system is the one that goes dark.

Before the next connection is made

1. If an attacker took control of one administrator account, how many of our hospitals could they reach?
2. How many service accounts have rights across all regions, and when were their passwords last changed?
3. Which hospitals would go to paper if a single shared data center were taken offline?
4. Who can order a system-wide shutdown, who can isolate one region, and have they rehearsed it with clinical leaders?
5. For our last integration project, did anyone report how it changed our blast radius?

With hindsight

CommonSpirit restored its systems over the following weeks. It later reported that data on more than 620,000 people had been affected, and in early 2023 it put the attack’s financial impact at about 150 million dollars, later raising the estimate to about 160 million. Those figures put a price on a wide blast radius that boards can readily understand, and they sit alongside the harder-to-price costs of delayed care and diverted ambulances.

The data side of the story became clearer in December 2022. Filings with HHS put the number of affected people at about 623,000, and notification letters said the exposed files held details such as names, addresses, phone numbers and dates of birth. By then CommonSpirit was describing the attack as ransomware, and it did not publicly name the group responsible. Proposed class action lawsuits followed on behalf of patients whose information was exposed.

Attacks on large, multistate systems continued. In 2024 ransomware at Ascension disrupted electronic records across many of its hospitals for weeks. The pattern was familiar: a large organization assembled over time, a single incident, and widespread downtime.

Other incidents tested different parts of the blast radius argument. In August 2023 a ransomware attack on Prospect Medical Holdings disrupted hospitals it owned in California, Connecticut, Pennsylvania and Rhode Island. In 2024 the Ascension attack was traced to an employee who downloaded a malicious file, and the system later reported that data on about 5.6 million people had been affected. A small initial foothold again became a system-wide outage.

The attack on Change Healthcare in February 2024 extended the argument in a different direction. Change, a unit of UnitedHealth Group, processes claims and payments for much of American health care. UnitedHealth’s chief executive told Congress that attackers had entered through a remote access portal that lacked multifactor authentication. Hospitals and practices that had never shared a directory or network with one another found their billing stalled together, because they shared a vendor. That confirmed the earlier point about shared vendors. A dependency map that stops at an organization’s own walls misses some of the widest blast radii of all.

Regulators moved too, if slowly. HHS published voluntary cybersecurity performance goals for health care in January 2024, setting out recommended practices for hospitals and other organizations. It proposed updates to the HIPAA Security Rule, including network segmentation, in early 2025; their final form remains uncertain.

Enforcement developed as well. In October 2023 the HHS Office for Civil Rights announced its first settlement of an investigation into a ransomware attack, with a medical management company. Later settlements returned to a familiar finding: organizations that had not carried out an accurate, thorough risk analysis. The proposed Security Rule changes went further, calling for an asset inventory, a network map and the ability to restore critical systems within a set time.

Consolidation in health care has continued. By 2026 more health systems treat segmentation and identity tiering as integration requirements, and boards of acquisitive systems more often ask how far a single incident could spread.

What did not hold up as well is the assumption that segmentation alone limits downtime. The cases since 2022 show that dependency, not reachability, often decides how long a hospital stays on paper. Hospitals untouched by malware still went offline because they relied on a shared EHR, a shared directory or a shared vendor. The better-prepared systems responded by investing in local downtime capability and tested restoration, alongside segmentation, rather than treating any single control as sufficient.

That shift in the board’s question is the most useful legacy of the CommonSpirit attack. Integration has long been measured by savings and speed: how quickly systems were combined and how much duplication was removed. Those measures remain important. But each step that joins two organizations’ technology also joins their risks. A leader overseeing a merger, in health care or any other sector, can reasonably ask for both numbers side by side: what this step saves, and how much further a single attack could now reach. Asking before the connection is made is far cheaper than discovering the answer during an incident, when the hospitals bearing the cost are already working on paper.