Electronic health records, e-prescribing, patient portals, telehealth platforms, scheduling tools, imaging viewers, and lab interfaces run on servers, databases, load balancers, APIs, and network connections. This has allowed records to follow patients across facilities, let clinicians review information remotely, and reduced errors from illegible handwriting. It has also made clinical care dependent on web availability.

 

Clinical effects of EHR downtime

  • Medication safety. Nurses use the medication administration record to determine what to give, when, and how much. Without it, they rely on printed lists that may be hours old, or on memory. The risk of missed doses, double doses, and dangerous interactions rises.
  • Diagnostics. Results may exist in the lab system but not be visible to the clinician.
  • Orders. Computerized order entry includes allergy checks and dose limits. Paper and verbal orders bypass many of these safeguards.
  • Handoffs. Shift changes depend on current information. A system failure during handover can result in lost context.

 

Evidence

The closest evidence comes from ransomware research, which examines loss of access to digital tools during care.

  • Volume and mortality. Researchers at the University of Minnesota linked attack records to Medicare claims. Hospital volume fell 17-26% in the first week of an attack and recovered within about three weeks. In-hospital mortality rose 35-41% among patients already admitted when the attack began.
  • Emergency services. A JAMA study of California hospitals, reported by Healthcare Dive, found emergency visits and admissions fell by more than 8% in the first week after an attack and by over 16% in the second.
  • Spillover. The same California Hospitals study found nearby unattacked hospitals saw rising emergency visits for up to four weeks. The researchers concluded that “the consequences of such attacks are broader than the targeted hospitals.”
  • Cardiac arrest. A University of California San Diego team, publishing in Critical Care Explorations, studied 78 cardiac arrests at two academic hospitals adjacent to a ransomware-hit organization. They concluded that such neighboring hospitals may see worse outcomes for out-of-hospital cardiac arrest.
  • Frequency. NPR reported that healthcare ransomware attacks more than doubled between 2016 and 2021, forcing ambulance diversions and surgery delays.

 

Common causes of outages

Many outages do not involve an attacker:

  • A software patch not tested against production workloads
  • A single server with no failover
  • An expired certificate
  • A full disk
  • Capacity planning that did not account for peak usage or traffic spikes
  • A third-party service failure affecting a dependent system

An e-commerce site can tolerate an hour of downtime. A clinical system cannot.

 

Precautionary shutdowns

Systems are sometimes taken offline deliberately. Two critical vulnerabilities in PHP, which underlies a large share of the web, prompted this. After a fix was released, cyber-security agencies in the UK, US, EU, Japan and Australia urged organizations that could not patch promptly to consider taking affected systems offline. The UK’s National Cyber Security Centre advised that organizations should consider taking the system offline “until it can be fully mitigated.”

Finland temporarily shut down its public government web services. The Dutch national cyber-security agency took its own website offline. The Wikimedia Foundation took several systems down as a precaution.

CERT-EU stated that the risk scores indicate potential for unauthenticated remote code execution. The US National Security Agency stated that such vulnerabilities often provide a direct path to a server’s file system or database. Wiz, one of the firms that discovered the flaws, estimated that roughly 70% of the internet is affected.

In a hospital, leaving a vulnerable system online risks a breach or ransomware, with the clinical effects described above. Taking it offline causes the disruption itself. The decision requires preparation:

  • Inventory. Maintain a current list of systems and their components, including embedded and third-party software.
  • Classification. Define which systems can be shut down immediately (for example, a public marketing site), which need a short planned window, and which must remain online under compensating controls such as network isolation, restricted access, or a web application firewall until patched.
  • Authority. Agree in advance who can order a shutdown, what the fallback procedure is, and the maximum tolerable downtime for each system.
  • Compromise checks. After patching, check for signs that an attacker has already gained access. Patching does not remove an existing foothold.

 

Design for failure

No system achieves perfect availability. The objective is to prevent a crash from becoming a clinical event.

  • Redundancy. Critical systems should not depend on a single server, data center, or network path. Failover should be automatic and regularly tested.
  • Monitoring. Alerts should reflect clinical impact, not only technical thresholds. A slow medication ordering system warrants higher priority than a slow internal newsletter site.
  • Downtime procedures. Each unit should hold current paper forms, printed patient summaries, and written instructions for operating without the system. Staff should practice them.
  • Drills. Hospitals commonly rehearse fire evacuations and mass casualty events but often do not simulate an extended EHR outage. Drills should cover both planned shutdowns and unplanned failures.
  • Recovery. Information recorded on paper during an outage must be reconciled with the digital record. Errors during this step are common.

Read also: Security awareness training

 

FAQs

What is EHR downtime?

It is any period when electronic health record systems are unavailable, whether from a technical fault, a cyberattack, or a deliberate shutdown.

 

Can patients still be treated during a system outage?

Yes, hospitals use paper records and manual procedures, though care is slower and carries more risk.

 

Who is responsible for keeping hospital IT systems running?

Typically a hospital’s IT and information security teams, working with clinical leadership and outside vendors.

 

Is cloud-based hosting safer than on-site servers for medical records?

Neither is automatically safer, as security and reliability depend on how well each is designed, configured, and maintained.