The Word That Sits Between Hazard and Harm: ISO 14971 Clause 3, Explained

# The Word That Sits Between Hazard and Harm: ISO 14971 Clause 3, Explained

In the spring of 1986, a radiation therapy machine in Tyler, Texas delivered a dose of radiation that was somewhere between four hundred and several thousand times what the patient was prescribed. The machine, a Therac-25, had been cleared for clinical use. Trained staff were operating it. Everything about the setup looked correct. The treatment began, and then it didn't.

The investigation took multiple accidents before anyone understood what they were looking at. The cause was a software race condition: two processes in the control system could interfere with each other if an operator entered commands inside a very specific timing window. When that happened, the machine fired its high-energy electron beam directly, without the scanning magnet that would have spread it safely across the treatment field, while showing a minor error code on the screen.

Here is the part that matters for everything below. That race condition had been in the code for some time before anyone was hurt. Devices were deployed at multiple facilities. Staff operated them. Nothing happened, because the flaw on its own was not enough to cause harm. It needed something else. It needed an experienced operator, someone who had cleared error messages so many times that the sequence was muscle memory, fast enough to land inside the timing window. The very thing that made that person good at the job was the thing that activated the hazard.

A hazard. A sequence of events. A hazardous situation. And then harm. That chain is the foundation of ISO 14971 Clause 3, and it is the vocabulary that separates a risk file that survives an audit from one that does not.

The two-step trap

Most engineers who have been through occupational health and safety training learned a model with two terms. Hazard: anything that can cause harm. Risk: how likely that harm is, combined with how bad it would be. Two steps, P times S. For slips, chemical exposure, and machine guarding, that model works. It has been refined over decades and it is adequate for what it was built to do.

Medical devices break it. When your device can deliver the wrong drug concentration, generate a fault current, or fail during a sterile procedure, the two-step model does not give you enough resolution to document what you actually know. You know more than "hazard exists, therefore P times S." You know how the hazard becomes a harm. You have a path. The two-step model has nowhere to put the path.

I'm Dave Saunders. I've spent more than thirty years in medical devices and regulatory affairs, a good share of it in audit rooms watching risk files get evaluated. The gap between how general safety vocabulary works and what ISO 14971 actually requires is real, it shows up in real risk files, and it is correctable once you see it clearly. ISO 14971 closes it by adding a third term between hazard and harm: the hazardous situation. The rest of this piece is about what that term does, and why the standard needed it.

Clause 3: thirty-one terms, one architecture

Clause 3 is the terms-and-definitions clause. It defines 31 terms precisely enough that the rest of the standard can use them without ambiguity. They cluster into four groups. The chain: hazard, hazardous situation, harm, risk, probability, severity. The process: risk management, analysis, estimation, evaluation, control, monitoring. The context: intended use, reasonably foreseeable misuse, use error, life cycle. And the foundations: safety, state of the art, benefit, objective evidence, verification.

You don't need to memorize all 31. You need to understand the eight or nine that drive everything downstream, and you need to know where to look for the rest. The chain is where we go deep, because those terms are the structure your risk analysis is built on. Misunderstand them and your probability values measure the wrong thing.

Hazard: a property, not an event

ISO 14971 defines a hazard, in Clause 3.4, as "a potential source of harm." Five words, and the word potential is doing real work. A hazard hasn't caused harm yet. It is a property of the device, or of the energy, material, or process associated with it, that has the capacity to cause harm under the right circumstances.

The high-pressure spring in a delivery mechanism is a hazard. The current through a circuit board is a hazard. The sharp edge of a scalpel is a hazard. None of them has hurt anyone. That framing matters when you write the file: when you record "hazard: high-pressure reservoir," you are making a claim about the device's physical state, not yet about who might be hurt or how likely it is. The hazard column is where you inventory the potential energy in the device.

ISO/TR 24971, the technical report that supports the standard, gives you hazard categories as a starting checklist: energy hazards, biological, chemical, and use-related. The categories are not a closed taxonomy. They are a prompt to make sure you haven't missed a whole class. And the standard asks you to analyze both normal and fault conditions, because hazardous situations can arise even when the device works exactly as designed.

For our running example, WearPump, a wearable subcutaneous insulin pump for Type 1 diabetes, four hazards anchor the analysis: the pressurized insulin reservoir, holding up to 3 mL under tension; the concentrated insulin itself; the electrical energy in the battery, motor, and Bluetooth subsystem; and the skin-adhesive and infusion interface. Four hazards. Not four risks. Not four harms. Four potential sources of harm that we now trace through the chain.

Hazardous situation: where probability lives

Clause 3.5 defines a hazardous situation as "a circumstance in which people, property, or the environment is exposed to one or more hazards." The load-bearing word is circumstance. A specific set of conditions, a specific hazard, and a specific person or thing exposed to it. The hazard is a property of the device. The hazardous situation is what happens when a person comes into contact with that hazard through a specific sequence of events.

This is the structural answer to the question the whole module opens with. Probability does not attach cleanly to a hazard. A pressurized reservoir is either under tension or it isn't. Probability attaches to a sequence of events: the chain of circumstances that brings the hazard and a person together in a way that could cause harm. The hazardous situation is where that chain ends, and that is where your P value belongs.

Go back to the Therac-25. The race condition is the hazard. The hazardous situation is not "race condition exists in the code." It is the specific circumstance: an experienced operator clears the malfunction message during the timing window, the machine fires the high-energy beam without the scanning magnet, and the patient is in the treatment position receiving it. That is the exposure. That is the probability you care about, not whether the code has a flaw, but whether that sequence occurs during a treatment session.

A single hazard can lead to several hazardous situations through different sequences, and each deserves its own entry, because each has a different probability, a different population, and a different severity. When an auditor asks how you arrived at a P value, the sequence of events is the answer. If the path isn't documented, the number is an assertion, not an estimate.

Harm, and the spectrum of severity

Clause 3.3 defines harm as "injury or damage to the health of people, or damage to property or the environment." Three things are worth noting. It is not limited to physical injury; the standard includes psychological harm. The 2019 revision made damage to property and the environment explicit. And harm reaches people, plural, not only the primary patient: caregivers, clinicians, and bystanders can all be exposed through the same hazardous situation.

Severity, Clause 3.27, is a measure of the possible consequences, and it is not a binary. For WearPump, an unintended insulin delivery ranges from a mild glucose dip the patient corrects with a snack, all the way to severe hypoglycemia with unconsciousness, seizure, and a potentially fatal outcome. You document the full range, tied to the specific hazardous situation. Severity divorced from the situation is just a guess. There is a time dimension, too: some harms hit in seconds, others surface over 24 to 48 hours, and that latency changes whether anyone can intervene before the harm becomes serious.

The chain, and what Clause 5.4 actually requires

Put the four together and you have one continuous narrative. Here is what the device carries (hazard), here is how that thing reaches a person (sequence of events), here is the moment harm becomes possible (hazardous situation), and here is what happens (harm). Four concepts, four columns in your risk analysis table.

This is not just a teaching frame. Clause 5.4 of the standard requires you to "identify the sequences of events that could result in a hazardous situation." Not identify hazards and estimate risk. Identify the sequences of events. The chain is the clause's requirement expressed as a data model, and your risk analysis is the populated instance of it. When an auditor reviews your file, they run structural checks: does every hazardous situation trace to a named hazard, does every harm trace to a named hazardous situation, is the sequence of events written out specifically enough that someone else could evaluate the probability. Those are not judgment calls. A "no" is a finding.

In Module 5 we'll populate the chain with two complementary tools. FMEA starts at the device's failure modes and traces forward toward hazardous situations. Fault tree analysis starts at an undesired harm and traces backward, through logical gates, to the combinations of events that could produce it. Forward from failures, backward from harms; together they cover the chain from both ends.

Risk: the probability of what?

Clause 3.18 defines risk as "the combination of the probability of occurrence of harm and the severity of that harm." P times S. Severity is the tractable half, a defined scale we'll build for WearPump in Module 3. Probability is the subtle half, and the real question is not "what is the probability" but "probability of what?" If you answer "probability that this component fails," you have attached your P to the wrong place in the chain. The standard says probability of occurrence of harm, which means the probability of the whole chain running to completion.

For WearPump's reservoir hazard, the wrong P is the probability that an occlusion occurs. The right P is the probability that an occlusion occurs and pressure builds to failure and a drug bolus is delivered and the patient experiences clinically significant hypoglycemia. An occlusion is relatively common; an occlusion that runs all the way to harm is much less so. One useful way to hold this is two components: P1, the probability that the hazardous situation occurs, and P2, the probability that, once it does, harm results. Your file's P is the product of both. Miss P1, which is common, and you are only measuring the danger of the exposure, not the likelihood of getting into it.

ISO/TR 24971 has an annex on probability estimation that lists the evidence you can draw on: published failure-rate data for comparable components, field data from similar devices, human factors results from usability testing, fault tree or Markov analysis, and structured expert judgment. For a new device without field history, your estimates will be semi-quantitative, and the standard accepts that, as long as you document the rationale, tie it to the specific hazardous situation, and update it as real-world data arrives.

The rest of the vocabulary

Safety, Clause 3.26, is "freedom from unacceptable risk." Not zero risk, not the absence of hazards. You cannot remove insulin concentration from an insulin pump; safety means the risks that flow from that hazard, through their documented situations and paths, fall within your acceptability criteria. Risk management itself is four sequential tasks, analysis, evaluation, control, and monitoring, and the course follows that arc across the remaining modules. Two terms people use interchangeably are precise here: risk analysis produces the estimates, and risk assessment means analysis plus evaluation. There is always residual risk; the question is whether it is acceptable and outweighed by clinical benefit.

The context terms set the boundaries. Reasonably foreseeable misuse is use that results from readily predictable human behavior, like wearing WearPump past its 72-hour limit while traveling. A use error is an honest mistake with no intent to deviate, such as programming a dose one decimal place too high. Intended use sets the outer edge of the whole hazard analysis; when it is vague, the boundary is vague, and your hazard identification has no principled place to stop.

WearPump's first four risk entries

Here is the deliverable, the format every future entry follows.

Entry 1. Pressurized reservoir. Hazard: mechanical energy stored under tension. Sequence: an occlusion develops, the pump keeps delivering, pressure builds, the cannula fitting fails. Hazardous situation: a sudden unintended subcutaneous bolus. Harm: hypoglycemia, from a mild dip to loss of consciousness. Entry 2. Concentrated insulin. Hazard: pharmacological energy. Sequence: air enters the tubing during a cartridge change, the set isn't fully primed, an air gap precedes the next dose. Hazardous situation: the patient receives no insulin while believing delivery is normal. Harm: hyperglycemia or diabetic ketoacidosis, developing over hours. Entry 3. Electrical energy. Hazard: battery and motor drive current. Sequence: a component fault creates a current path to the housing, a person contacts the surface while the device is active. Hazardous situation: an unintended electrical shock. Harm: a localized burn, arrhythmia, or ventricular fibrillation. Entry 4. Skin interface. Hazard: adhesive and subcutaneous cannula. Sequence: extended wear in a high-moisture environment degrades the adhesive while the cannula irritates the site. Hazardous situation: prolonged irritation at the skin boundary. Harm: contact dermatitis, skin breakdown, or infection over 24 to 48 hours.

Four hazards, each with a documented sequence, a named hazardous situation, and a harm with a severity range. In Module 5 we'll run a systematic identification and expand this to a dozen or more, but every entry will follow the same chain, because the chain is what Clause 5.4 requires.

The short version

A hazard is a property of your device. A hazardous situation is the circumstance in which a person is exposed to it, reached through a documented sequence of events. Harm is the consequence, at some severity. Risk is the probability of that harm times its severity, and the probability belongs to the sequence, not to the hazard. Get that one distinction right and the rest of the risk file becomes logical instead of procedural. Get it wrong, and an auditor will find the broken P column, every time.

If this was useful, Module 3 builds the risk management plan, where the acceptability criteria and the severity scale get defined. More on product strategy, roadmaps, and fractional CPO work is at baserealitygroup.com, and if you want the written version of this work in your inbox, the newsletter is The Build, at davesaunders.net.

Dave Saunders is the founder of Base Reality Group and a Fractional CPO for hard-tech founders. He was a founder and operator at Galen Robotics, where the surgical-robotics platform earned FDA De Novo authorization in 2023, and he managed a 35-patent portfolio licensed from Johns Hopkins. He wrote Founders Who Finish and publishes The Build. More about Dave →