Most Risk Management Files don't fail their first review because the engineering was wrong. They fail because three words got mixed up.
Hazard. Hazardous situation. Harm.
ISO 14971 treats these as three distinct things. Most teams treat them as roughly the same thing. A Notified Body reviewer or a CDSCO assessor flipping to your hazard analysis can spot the conflation in under sixty seconds — and once they spot it, they stop trusting the rest of the file. The queries that come back aren't just about the three columns you got wrong. They're about everything downstream: your risk controls, your residual risk evaluation, your benefit-risk justification. All of it gets re-examined, because if the team didn't understand the inputs, the reviewer assumes they didn't understand the outputs either.
This article is the fix. By the end of it, you'll have a clean mental model of the three terms, a worked example from a real medical device that walks through all three, and a four-question test you can run against any row in your hazard analysis to catch the most common mistakes before a reviewer does.
1. The three terms, in one sentence each
Let's get the definitions out of the way before going anywhere near a real example.
A hazard is a potential source of harm. It's something latent — energy, a chemical, a software output, a sharp edge — that could cause damage under the right conditions, but hasn't yet. Heat from a radiant warmer is a hazard. Electrical current inside a defibrillator is a hazard. A misinterpreted output from a diagnostic algorithm is a hazard.
A hazardous situation is a circumstance in which a person, the environment, or property is exposed to a hazard. This is the key word: exposed. The hazard exists whether or not anyone is near it. The hazardous situation is the specific moment something or someone gets close enough that harm becomes possible. The radiant warmer's heating element is a hazard whether the warmer is plugged in or sitting in a warehouse. The hazardous situation only arises when an infant's skin is under the warmer and the temperature drifts above a safe threshold.
A harm is the actual physical injury, damage to health, damage to property, or damage to the environment that results. A thermal burn. An electrical shock. A delayed diagnosis. A contaminated batch.
2. What links them together: the sequence of events
A hazard sitting in a device doesn't spontaneously turn into harm. Something has to happen — usually several somethings, in a specific order — to take a latent hazard and turn it into a real hazardous situation, and then into actual harm.
ISO 14971:2019 calls this the sequence of events, and it expects you to write it down.
Read that left to right. You start with the latent hazard. Some sequence of foreseeable events — a sensor fails, an alarm gets muted, a user misuses the device, software returns a wrong value — exposes someone to that hazard. That exposure is the hazardous situation. From there, depending on the patient population and the duration and the severity, the hazardous situation either dissipates without consequence or it progresses to harm.
The probability splits into two pieces in ISO 14971:2019: P1 is the probability that the sequence of events occurs and produces the hazardous situation, and P2 is the probability that the hazardous situation, once it exists, actually leads to harm. (There's a separate article coming on P1 and P2 specifically; for now, know that they live at different points in the chain.)
Most teams skip the sequence of events entirely. They write a hazard, write a harm, and leave the middle blank. The reviewer reads that and thinks: they haven't actually analyzed how this device fails. And they're usually right.
3. A worked example: the neonatal radiant warmer
Abstract definitions are forgettable. A worked example sticks. Let's walk through a real one.
A radiant warmer is a piece of equipment used in neonatal wards to keep newborn infants warm during examinations, procedures, and the first hours after birth. It works by using an overhead infrared heating element — usually around 600 watts — to warm the infant from above while leaving the baby accessible for clinical care. A skin temperature sensor is taped to the infant's abdomen, and a controller modulates the heater output to keep skin temperature in a target range (typically 36.0 to 37.0 °C).
Here's how the three terms map for this device:
| Element | Value |
|---|---|
| Hazard | Thermal energy. The heating element radiates roughly 600 W of infrared energy downward toward the infant. |
| Sequence of events |
|
| Hazardous situation | An infant whose skin is exposed to a radiant surface temperature exceeding 41 °C for longer than ten minutes, with no clinical intervention to interrupt the exposure. |
| Harm | First- or second-degree thermal burn to the infant's skin. Possible systemic hyperthermia depending on duration. |
The hazard — thermal energy — is always present whenever the warmer is plugged in and operating. That's just the nature of an overhead radiant heater. The hazard doesn't go away. We can't design it away, because the device's whole purpose is to deliver controlled thermal energy to a vulnerable patient. The risk management strategy has to assume the hazard is permanent and design controls around exposure and detection.
The sequence of events is the heart of the analysis. Five steps, each one foreseeable: a sensor adhesion failure, a measurement that goes off-axis, a control loop that responds to bad data, an alarm that fires, and a human in the middle of a busy clinical moment who silences it. Notice that no single one of those steps is a "design flaw" — sensors do peel off, alarms are silenced during resuscitations, controllers do what their inputs tell them. The hazardous situation emerges from the combination, which is exactly why the sequence has to be written out. If you list only one step ("sensor fails"), you've missed four other places to put a control.
4. The three mistakes RA teams make most often
The hazardous situation is quantitative: surface temperature above 41 °C, duration over ten minutes, no compensating clinical action. Those numbers matter. A reviewer reading "the baby gets too hot" learns nothing. A reviewer reading "skin exposed to >41 °C surface for >10 minutes without intervention" learns exactly when your device crosses the line from safe to harmful — and they can immediately check whether your controls (a redundant skin temperature sensor, a non-defeatable alarm escalation, a temperature soft-limit) actually prevent that specific situation.
The harm is specific to the patient population. A neonate's skin is thinner and more thermally vulnerable than an adult's. A harm statement that just says "thermal injury" misses this. A harm statement that says "first- or second-degree thermal burn to neonatal skin, with possible systemic hyperthermia" forces the reviewer (and you) to think about whether the severity rating you assigned matches the actual clinical reality.
If you read enough RMFs — and I've read more than I'd like — three patterns of conflation come up over and over.
Mistake 1: Calling the harm the hazard
"The hazard is the baby getting burned." No. The burn is the harm. The hazard is the energy source that — through some sequence of events — could cause the burn. This is the most common mistake, and it's an easy one to spot in your own RMF: if your hazard column reads like a list of bad outcomes, you've written harms where hazards should be. Hazards are sources; harms are consequences. If your hazard column has more verbs than nouns, look again.
5. A four-question test for your own RMF
Mistake 2: Skipping the sequence of events entirely
Going directly from "thermal energy" to "burn" with no intermediate steps tells the reviewer you haven't thought about how the hazard becomes a harm. It also breaks your ability to apply risk controls intelligently — controls live in the sequence of events, not in the hazard itself. You can't redesign thermal energy out of a radiant warmer, but you can put a control on step (2) of the sequence (sensor placement verification), step (3) (independent over-temperature sensor and shutoff), and step (5) (non-defeatable alarm escalation). If you don't articulate the sequence, those control opportunities are invisible.
Mistake 3: Writing one hazardous situation per hazard
A single hazard typically produces multiple hazardous situations. Thermal energy in a radiant warmer can produce: an infant exposed during normal operation with a failed sensor, an infant exposed during a transport handoff when the warmer is left on, an infant exposed when a clinician uses the warmer for prolonged phototherapy alongside the radiant heating, an infant exposed during cleaning when the warmer is accidentally activated. Each of these is a separate row in the analysis, with its own sequence of events, its own controls, its own P1. Teams who write one row per hazard are under-analyzing their device, and the reviewer notices.
Open your current hazard analysis. Pick any row. Run it through these four questions.
If your answer is no — if the hazard itself, by its mere existence, means someone has been harmed — then you've written the harm in the hazard column. Hazards are latent; if they were inherently harmful, every device that contains them would already be killing patients. The fact that radiant warmers, defibrillators, and infusion pumps exist proves that thermal energy, electrical current, and pharmaceuticals can be hazards without being harms.
One-step sequences ("the heater fails") almost always indicate the team stopped thinking too early. Real failures cascade. Three steps is the minimum that forces you to consider failure mode interactions, alarm responses, and human factors. If your sequence is one step, ask: what would have to happen before that step? And what would have to happen after it, for the harm to actually occur?
"The baby gets too hot" is not a hazardous situation; it's a vague concern. "Surface temperature exceeds 41 °C for more than ten minutes" is a hazardous situation, because it can be measured, controlled, and verified. Reviewers want thresholds because thresholds are testable. Without them, your verification evidence has nothing to verify against.
6. How MedMI handles this
"The device overheats" is a device state. "The infant sustains a thermal burn" is a harm. If your harm column describes what happened to the device, you've documented a failure mode, not a harm. ISO 14971 is about consequences to people and property, not consequences to the device itself.
Four questions. If you can answer all four affirmatively for every row, your analysis is in good shape. If you can't, you have homework — and now you know exactly which rows to fix and what's wrong with them.
7. Further reading
Inside MedMI, the hazard analysis table enforces the structure described in this article. Hazard, sequence of events, hazardous situation, P1, P2, severity, and harm are separate columns — you can't write a hazard without articulating the sequence of events that connects it to a hazardous situation, and you can't fill the harm column with a device state. The AI-assisted draft generation produces multi-step sequences by default, not one-liners, because that's what reviewers expect to see.
If you'd like to try it on your own device, you can generate your first hazard table free — no credit card needed.
For the formal definitions, the source is ISO 14971:2019 on iso.org, with implementation guidance in ISO/TR 24971:2020.
If you want to go deeper on related concepts, two follow-on articles cover the parts that come right after this one:
- How to write a P1 and P2 probability in ISO 14971, with examples — what the two probability values mean and how to estimate them defensibly.
- CDSCO risk management file requirements: what India actually expects — how to package this analysis for an Indian regulatory submission.
And if you've found this article useful, the four-question test is also available as a one-page PDF checklist — paste it next to your monitor while you work through your hazard analysis. Download it here.