Three words used almost interchangeably in casual conversation — and three legally distinct, separately documented concepts in every medical device risk file.
ISO 14971, the international standard for applying risk management to medical devices, is precise about a chain of cause and effect that everyday language blurs together. A hazard is a potential source of harm — it can exist in a device for its entire service life without ever hurting anyone. Harm is the actual physical injury, damage to health, or damage to property that results if a hazard is realized. Risk is not either of those things — it's a combination of two numbers: the probability that a given harm occurs, and the severityof that harm if it does. Confusing these three terms isn't just imprecise language; in a Design History File and risk management file, each one is a separately required, separately traceable field, and treating them as synonyms produces a risk analysis that regulators will reject.
The reason ISO 14971 insists on keeping these terms separate is that risk management is fundamentally a predictive activity — it has to estimate, before a device ever reaches a patient, how bad things could get and how often. A hazard is identified during design (a pinch point, an electrical leakage path, a software defect, an alarm that could be missed). Whether that hazard ever causes harm depends on a hazardous situation actually arising — the hazard, plus some sequence of events or circumstances that bring a person into contact with it. Only when a hazardous situation actually occurs and goes uncorrected does harm result. Risk is the manufacturer's estimate of how likely that whole chain is, and how bad the harm would be if it completes — computed and documented long before, and independent of, whether any harm has actually happened yet. A device can carry substantial estimated risk and never harm a single patient, if the risk controls work; conversely, a rare unlucky event can produce real harm even from a hazard whose estimated risk was assessed as low.
No — severity is only one of the two inputs to risk, and it is fixed once the harm is defined (death is death; it doesn't become more or less severe based on how the device is used). Risk also depends on probability, which is where most engineering risk-control effort actually goes. A hazard capable of causing death has maximum severity no matter what, but if the design includes robust risk controls — a hardware interlock, a redundant sensor, a fail-safe default state — the probabilityof that severe harm actually occurring can be engineered down to an acceptable level, making the overall risk acceptable even though the severity classification never changes. This is exactly why ISO 14971 risk control strategy prioritizes reducing probability and, where possible, eliminating the hazard's ability to reach the patient at all (inherent safety by design) over relying solely on warnings or labeling, which reduce probability the least reliably of any control category.
Explains the three distinct terms at the core of ISO 14971 medical device risk management: hazard (a potential source of harm that may never be realized), harm (the actual physical injury or damage that results if a hazard is realized through a hazardous situation), and risk (the combination of the probability of harm occurring and the severity of that harm) — three separately documented fields in every risk management file, not interchangeable synonyms.
In everyday speech, "that's risky," "that's dangerous," and "that could cause harm" all express roughly the same idea, so engineers new to formal risk management often use hazard, harm, and risk interchangeably too. ISO 14971 does not allow that: a Design History File's risk management file requires a hazard identification list, a documented hazardous-situation analysis connecting each hazard to a foreseeable sequence of events, an estimate of the resulting harm's severity, an estimate of probability, and a resulting risk level plotted against pre-defined acceptability criteria — five distinct, separately traceable pieces of documentation, not one blended judgment call.
Hazard: a potential source of harm. A hazard can exist in a device design indefinitely without ever causing an incident — a sharp edge, a possible software calculation error, an electrical leakage current path, an alarm condition that could go unnoticed. Hazardous situation: a circumstance in which people, property, or the environment are exposed to one or more hazards — the hazard plus some sequence of events or exposure that brings it into contact with a person. Harm: physical injury, damage to health, or damage to property or the environment, that actually results when a hazardous situation is not adequately controlled. Risk: the combination of the probability of occurrence of harm and the severity of that harm — expressed together, usually as a position on a risk matrix, never as a single number derived from either factor alone.
Risk control strategy under ISO 14971 follows a mandated hierarchy: inherent safety by design (eliminate or reduce the hazard itself, or make the hazardous situation impossible), protective measures (guards, alarms, interlocks, redundancy), and information for safety (labeling, warnings, training) as the least preferred and least reliable option, used only for residual risk that can't be reduced further by the first two categories. Confusing hazard with risk leads to the common design mistake of trying to "fix the risk" by adding a warning label to a hazard that could instead have been engineered out entirely — technically reducing documented risk on paper while leaving the underlying hazard, and a meaningful residual probability of harm, untouched. Post-market surveillance closes the loop: real-world harm reports (actual incidents) are fed back to validate or correct the original probability estimates used in the pre-market risk analysis, since probability is inherently an estimate until enough field data exists to check it.
Yes, as long as the resulting risk — after applying appropriate risk controls — is judged acceptable against the manufacturer's pre-defined risk acceptability criteria, and the overall benefit-risk analysis for the device remains favorable. ISO 14971 does not require eliminating every hazard, which is often impossible; it requires reducing risk as far as reasonably practicable and ensuring the residual risk is outweighed by the device's clinical benefit.
It is the probability of the harm occurring — which folds together the probability of the hazardous situation arising at all and the probability that, given the hazardous situation, harm actually results (sometimes a hazardous situation occurs but no harm follows, because of chance, a user intervention, or another safeguard). ISO 14971 allows either estimating this as one combined probability or, in a more detailed analysis, breaking it into the probability of the hazardous situation and the probability of harm given that situation, and multiplying them.
Yes — a rigorous hazard analysis (commonly performed via FMEA, fault tree analysis, or a structured hazard identification checklist against IEC/TR 60601 or ISO 14971 Annex guidance) is expected to be exhaustive at the identification stage. A hazard can always be screened out later as negligible risk once probability and severity are estimated, but skipping identification because a hazard "seems fine" defeats the purpose of a systematic analysis and is a common audit finding.
Once every identified hazard's risk has been estimated and, where possible, reduced through risk controls, the residual risks that remain are summed into an overall residual risk picture for the device. Regulatory clearance requires that this overall residual risk be acceptable when weighed against the device's clinical benefit — a device with meaningfully higher residual risk can still be cleared if its benefit (treating an otherwise fatal condition, for instance) is judged to outweigh it, which is why benefit-risk determination is a distinct, final step in the risk management file, not just a restatement of the risk matrix results.
Try our Biomedical Engineering
More calculators, simulators, and guides for this discipline.
Applied Biomedical Engineering Professional Program
✨ Premium ContentA structured, paid professional training program for this discipline.