I see the article making one clear point: hospitals may look digital and advanced, but many still depend on a few shared weak spots. When EHR access, identity systems, DNS, WAN, wireless, cloud regions, or a major vendor goes down, the hit can spread from the IT stack into meds, labs, imaging, scheduling, billing, and bedside care.

A few numbers make that plain:

  • Healthcare now averages $9.8 million per data breach
  • A bad July 2024 CrowdStrike update cost the sector about $1.94 billion
  • 71% of surveyed healthcare groups reported poor patient outcomes tied to cyberattack delays
  • 12% reported higher mortality after a cyberattack
  • U.S. healthcare ransomware incidents went up 128% from 2022 to 2023
  • The Change Healthcare attack disrupted 30% to 40% of U.S. electronic healthcare transactions

If I boil the piece down, it says you should focus on four things:

  • Map dependencies across clinical systems, cloud tools, networks, and vendors
  • Find shared choke points like one identity provider, one cloud region, or one clearinghouse
  • Set downtime tolerances based on patient care and business impact
  • Test recovery and manual workflows before the next outage forces staff onto paper

The article also ties those ideas to recent events, including Change Healthcare, Ascension, CrowdStrike, and Mass General Brigham, to show how one weak link can stall care, claims, prescriptions, and staff access at the same time.

In short: the issue is not just cyber risk or old systems. It is the gap between what looks safe and what still fails together under stress.

Healthcare Cyber Risk by the Numbers: The Cost of Operational Fragility

Healthcare Cyber Risk by the Numbers: The Cost of Operational Fragility

Samantha Jacques on Cyber Risk Mitigation in Healthcare

Where fragility comes from: hidden dependencies across the care stack

Healthcare systems get fragile when new tools are stacked on top of old ones without a full map of what depends on what. That’s when operational fragility shows up: one outage can hit several clinical and business workflows at the same time.

The clearest case is the EHR, because it sits in the middle of day-to-day clinical work.

EHR platforms as the central dependency for clinical work

The EHR sits at the center of almost every clinical workflow. Medication histories, allergy alerts, physician orders, nursing documentation, and clinical decision support all move through it. When the EHR goes down, clinicians don’t just lose software - they lose the shared record that keeps ordering, documentation, and care lined up across departments.

During outages, staff fall back to paper and reconcile records later. That slows care and adds transcription risk. In many cases, staff become the manual link between systems that don’t share data cleanly. One missed medication entry or one misread handwritten note can affect a patient in a very direct way.

And the weak point isn’t always the EHR itself. If WAN, wireless, or DNS fails, clinicians can lose access to the EHR even when the application is still intact. These Tier 0 systems must be working before any clinical application can be restored or reached [1].

That weakness doesn’t stop at the chart. It reaches into connected devices and the networks underneath them.

Devices, networks, and cloud services that extend the blast radius

Connected medical devices add another layer of dependency. In connected settings, a single misconfigured firewall or a bad software update can trigger hospital-wide downtime because EHRs, imaging repositories, and telemetry are linked together [3]. Cybersecurity teams also often lack authority over biomedical devices, which creates segmentation blind spots. In plain English, connected medical equipment can stay exposed to network-wide disruptions because no one fully owns the whole picture [3].

As Nallan (Sri) Sriraman noted, shared control planes can make "redundant" cloud regions fail together. Health systems often don’t know which hyperscaler region their SaaS vendors run on until the outage is already happening [1].

The same concentration risk shows up in third-party platforms used for scheduling, billing, and telehealth.

Third-party vendors embedded in scheduling, billing, and telehealth

Beyond the EHR and devices, health systems depend on vendor-hosted tools for scheduling, billing, and telehealth. These tools are woven so deeply into daily operations that when they fail, the disruption is immediate and hard to miss.

The February 2024 Change Healthcare ransomware attack made that plain. Encrypted clearinghouse systems stopped claims processing and prescription workflows across the country. Hospitals had to switch back to manual faxing for prescriptions, which increased medication error risk, while weeks of lost revenue piled up across the sector [3]. The attack showed how much of the healthcare revenue cycle runs through a single vendor chokepoint.

The October 2024 outage at Mass General Brigham drove home the same point. When the health system's employee benefits enrollment site went dark on the final deadline day, the cause was traced to a SaaS partner running in a hyperscaler region that went offline - an exposure that had not been mapped before the incident [1]. That led CTO Sriraman to start a formal SaaS vulnerability mapping project to document exactly which hyperscaler and region each major vendor uses [1]. That blind spot helps explain why many health systems still don’t have a full map of their SaaS dependencies.

The next step is figuring out which of these dependencies can stop care, revenue, or access when they fail.

How single failures become enterprise-wide disruption

In healthcare, one failure can ripple through shared infrastructure, outside vendors, and day-to-day clinical work. That’s what makes operational fragility so dangerous: the harm almost never stays in one place.

How ransomware can halt normal hospital operations

The May 2024 Ascension ransomware attack shows how fast one intrusion can turn into system-wide disruption. The attack hit 140 hospitals across 10 states for weeks, cutting off EHR access and pushing clinicians back to paper workflows. Without bedside scanners, medication safety checks stopped. Lab results were delayed or missing, and staff had to track orders and results by hand across departments.

Hospitals can’t scale manual work fast enough during a full outage. Backlogs show up right away, and delays pile on. Ransomware isn’t just a data issue - it directly disrupts care delivery.

How vendor or integration outages stall access and scheduling

The same pattern shows up when the failure starts outside the hospital. The February 2024 Change Healthcare ransomware attack hit a third-party EDI clearinghouse and still affected an estimated 30% to 40% of all U.S. healthcare electronic transactions [4]. Providers lost eligibility checks, prior authorizations, and claims submission. Some hospitals reported revenue losses above $1 million per day, and full restoration of all services took until November 2024 - nine months after the initial attack [4].

Even providers that didn’t use Change Healthcare directly were affected because payers relied on it for transaction processing.

How device connectivity failures delay treatment at the bedside

When core network services fail, everything built on that network can go down with them [1]. Bedside monitoring, smart infusion pumps, handheld medication scanners, and VoIP communications all rely on the same base network. The result is missed alerts, disconnected devices, and bedside work that grinds to a halt.

The table below shows how each failure type spreads across systems, workflows, and patient safety:

Incident Type Affected Systems Disrupted Workflows Patient Safety Impact
Ransomware EHR, Lab, Imaging (PACS) Triage, medication admin, diagnostic review Medication errors, delayed treatment, increased mortality [2]
Clearinghouse Outage RCM, EDI Gateways Eligibility checks, prior auth, claims submission Delayed non-urgent surgeries, revenue loss [4]
Connectivity Failure WAN, DNS, Wireless Bedside monitoring, smart infusion pumps, handheld medication scanners, VoIP comms Missed alerts, inability to sync device data [1]

The next step is to find these choke points before they fail.

How to identify critical points of failure and concentration risk

Finding fragility takes more than a vendor list. You need to map systems to workflows, concentration points, and the dependencies hiding in the background. The point isn't to build an inventory for its own sake. It's to find the one failure that can stop care, cut off access, or halt revenue.

Map critical services to clinical workflows and downtime tolerance

Once you've identified the main failure patterns, map them to the services and workflows they can interrupt.

Start with core systems such as EHR modules, lab systems, blood bank, PACS, pharmacy dispensing, identity and access management, and telehealth platforms. Then connect each one to the clinical workflows that rely on it. An ED triage workflow, for instance, may depend on the EHR, the identity provider, and the wireless network at the same time. If any one of those goes down, the workflow can grind to a halt.

After that, assign a downtime tolerance to each system in hours. This should not be an IT-only call. Clinicians and emergency preparedness teams need to own it. Mass General Brigham uses a six-layer recovery tiering model for this work [1].

Tier 0 covers base infrastructure, including WAN, DNS, wireless, and identity. Those services have to come back first, because no clinical application works without them. Tier 1 comes next and includes clinically necessary systems such as the EHR, lab, blood bank, and PACS. Everything else is restored in sequence after that [1].

Measure vendor, cloud, and regional concentration risk

Once systems are tiered, the next step is to ask where several critical services share the same failure domain. A single AWS region, a shared identity provider like Okta, or one clearinghouse can quietly become the place where several systems that look separate all meet [5][6].

Document each SaaS vendor's primary region, failover region, and failover owner. Some cloud hyperscalers rely on shared control planes across regions. That means a problem in one region can also knock out the failover region [1]. A simple place to begin is a structured questionnaire for every major SaaS partner. Ask for their hyperscaler, exact hosting region, failover sequence, and who is in charge of triggering that failover [1].

The table below shows how concentration risk can be mapped across critical services.

Critical Service Primary Provider Upstream Dependency Known Weakness Tolerated Downtime
EHR Access Epic / Cerner AWS (us-east-1) Shared control plane across regions < 1 hour
Claims Processing Change Healthcare Clearinghouse API No manual batch-submit option 24 hours
Clinician Auth Okta / Azure AD DNS / ISP Single point of failure for all logins < 15 mins
Pharmacy Dispensing Omnicell Drug Interaction DB Sync-only API, no local cache 2 hours
Telehealth Teladoc / Amwell Cloudflare (CDN) Regional routing congestion 4 hours

Use structured healthcare risk management to expose hidden dependencies

Automated discovery tools such as CMDBs, API gateway logs, VPC flow logs, and IAM/SSO configurations can help surface external calls to CDNs, identity providers, and ISPs [5][6]. That's where hidden trouble often sits. The aim is to find dependencies that can shut off orders, dispensing, billing, or user access. When you turn that inventory into a dependency graph, shared chokepoints become much easier to spot, especially when many clinical applications rely on the same upstream service [5].

Machine learning models can help here too. By looking at network traffic patterns and change logs, they can infer hidden dependencies and flag single points of failure that manual audits may miss [5]. That includes fourth-party risk. A pharmacy system may appear fine on the surface, but if its upstream drug interaction database fails, clinicians may not be able to use the system at all [6].

Once those links are mapped, resilience work can focus on the chokepoints with the most risk.

What resilience looks like in practice

Build downtime plans that hold up during extended disruption

Once you’ve found the choke points, the next job is simple to say and hard to do: make sure the organization can still run when those points fail.

That’s where many teams get exposed. They have downtime procedures on paper, but people haven’t practiced them when the pressure is high and the clock is ticking.

Downtime plans need to cover whole workflows, not single systems in isolation. That means role-based steps for medication ordering, lab requests, registration, and manual claims backup. A read-only EHR setup can also help staff keep access to clinical data when the main system is down. And communication plans matter just as much as the technical side. Auto-initiating incident management calls for priority-one or priority-two events can cut mean response time by up to 60 minutes [2].

One more point matters here: the call on incident severity shouldn’t sit with IT alone. The emergency preparedness team should make that decision so the response is driven by clinical impact, not just infrastructure status [1].

Reduce blast radius with segmentation, restoration testing, and vendor oversight

Recovery is only part of the job. Containment matters too.

Network segmentation helps limit how far a failure or attack can spread. If medical devices and other critical systems are separated from the broader network, the odds drop that one compromised endpoint turns into an enterprise-wide crisis [1]. But here’s the catch: segmentation only helps if it’s tested.

A good example is periodically switching production EHR operations between two different data centers on a set schedule. That kind of restoration testing helps keep both environments in a known working state [1].

Vendor oversight needs the same level of discipline. Teams should require vendors to disclose:

  • Hosting region
  • Failover sequence
  • Failover owner

When procurement surfaces those details before an incident instead of during one, the gap between assumed resilience and actual resilience gets a lot smaller [1].

Make resilience a continuous governance process

Controls don’t stay useful on their own. They need upkeep.

Resilience is a continuous governance task, not a one-time project. Dependency maps, concentration risk reviews, and downtime procedures should be checked again on a fixed schedule as vendors are added, workflows shift, and cloud providers change their architecture.

The governance that works brings IT, security, clinical, and compliance leaders into the same conversation, with a shared view of risk. That means reassessing dependency maps, downtime plans, and vendor concentration on a recurring cadence - before the next incident exposes the weak spots.

FAQs

What is operational fragility in healthcare?

Operational fragility in healthcare is the systemic instability caused by hidden dependencies across a hospital’s tech ecosystem.

Here’s the issue: clinical workflows rely on EHRs, connected devices, cloud services, and third-party vendors. So when one piece fails, the fallout can spread fast.

Flat networks, undocumented integrations, and shadow IT make that risk worse. What starts as a small, isolated problem can ripple into an enterprise-wide clinical and operational crisis.

Which hidden dependencies create the most risk?

The biggest risks often come from hidden connections between systems that look separate on the surface but depend on the same underlying setup.

For example, shared cloud regions, control planes, and identity providers can knock out multiple applications at the same time. One issue underneath the hood, and suddenly several tools go down together.

The same thing happens with concentration risk in third-party services. EDI clearinghouses, pharmacy automation vendors, and managed IT providers can turn into single points of failure. When one of them has a problem, the impact can spread fast across clinical workflows, revenue cycles, and patient identity verification.

How can hospitals reduce outage impact?

Hospitals can cut the damage from outages by moving past reactive, paper-based plans and putting more attention on visibility and resilience.

That starts with a clear inventory of assets, integrations, and vendors. Why? Because hidden dependencies are often where outages spread and care gets disrupted.

It also helps to segment critical systems so one problem doesn’t ripple across everything at once. From there, teams should set recovery priorities with tiered restoration, so the most important clinical services come back first instead of treating every system the same.

Downtime plans need testing, too - but not just in theory. They should be tested in real clinical conditions, where staff can see what works, what breaks, and what needs to change under pressure.

Vendor oversight matters just as much. Hospitals should build in redundancy and set clear requirements for security, uptime, and incident response, so third parties don’t become a weak link during a crisis.

Related Blog Posts