Cybersecurity Is Patient Safety

A ransomware incident in a hospital is reported as a data breach. Records exposed, notifications issued, a regulatory filing, a number in a press release.

The experience inside the building is a different event. The emergency department goes on divert. Imaging turnaround collapses because the reporting system is unavailable and studies are being carried on discs. The electronic medication administration record is down, so administration moves to paper, and the safeguard that used to catch a wrong-dose entry is now a second nurse reading handwriting under time pressure. Elective lists are cancelled. Discharges slow, so the wards fill, so the department backs up, so ambulances wait.

None of that appears in the incident metric. All of it is the actual harm.

Availability is the clinical security property

Confidentiality, integrity, availability are usually taught as equal legs of a triad, and in most sectors the ordering is roughly right — a leak is generally worse than an outage.

Healthcare inverts it. A disclosed record is a serious harm to one person, and it is a harm that arrives slowly, in a letter, with recourse. An unavailable system is a harm to everyone currently in the building, and it arrives immediately, in the form of clinical decisions made with less information than they should have been.

This is not an argument that confidentiality does not matter. It is an argument that a security programme optimised almost entirely around disclosure — because that is what regulation historically counted, and what insurers price — will be well prepared for the less consequential failure.

Downtime is a workload, not a state

Every hospital has downtime procedures. They exist, they are documented, and they are usually written for an outage measured in hours: a planned upgrade, a server failure, a network fault overnight.

Contemporary incidents last weeks. At that duration the procedures behave differently. Paper forms run out. The staff most fluent in paper charting have retired. Order sets that existed only in the electronic system have no paper equivalent, so clinicians reconstruct them from memory. The backlog of unentered documentation grows into a second project that must be worked through after restoration, while the clinical work continues.

Testing a downtime procedure for two hours establishes that the first two hours are survivable. It establishes very little about week three, which is where the outcomes data tends to show the effect.

A system does not need to fail completely to change an outcome. It only needs to be unavailable at the moment a decision is being made.

The dependency map is clinical, not technical

Ask IT which systems are critical and the answer arrives tiered, ordered by recovery objective, and organised around applications.

Ask a charge nurse what stops working and the list is different and more specific: the pneumatic tube that moves specimens and blood products; the printer that produces patient wristbands, without which nothing can be safely administered; the paging system; the one workstation that talks to the blood bank; the fridge with the network-dependent temperature log. Several of these are unglamorous, none of them are tier one, and each has a clinical process built on the assumption that it works.

This is the ordinary shape of a dependency that nobody owns. It is also the reason dependency mapping in a clinical setting is not a technical exercise that clinicians are consulted about. It is a clinical exercise that requires technical input.

Devices are the hardest part

Connected infusion pumps, monitors, ventilators, imaging modalities, and point-of-care analysers frequently sit on networks alongside general IT, run software that cannot be patched without revalidation, and have service lives measured in a decade or more.

The result is an estate where the ordinary remedy — update it — is not available, and where the fallback controls are segmentation, monitoring, and procurement decisions made years earlier. The most consequential security decision about a device is usually taken by whoever wrote the tender.

What this changes in practice

Four things follow, none of them exotic.

Model the consequence in clinical terms. Risk assessments that terminate in “records exposed” should be extended to “care delayed, and by how long, for whom”. That reframing changes prioritisation immediately, because it moves availability of unglamorous systems above confidentiality of glamorous ones.

Exercise downtime at realistic duration. A drill that runs long enough to exhaust the paper forms produces information that a two-hour drill cannot.

Build the dependency map with clinical staff. The people who know what stops working are the people who work around it already.

Treat security incidents as patient-safety incidents. Where an organisation has a mature safety-investigation culture — and healthcare mostly does — that machinery is better suited to examining how an outage changed clinical decisions than an information-security process designed to establish what left the building.

The underlying point is not that healthcare security is harder, though it is. It is that the metric most commonly used to evaluate it measures the wrong failure.