The risk file: hazard, situation, harm — with examples.

One record, the whole lifecycle.

ISO 14971:2019 requires a risk management file: the single, traceable record of every hazard you identified, the situations that expose people to it, the harms that could result, the controls you applied, the residual risk you accepted and why — plus the plan and the criteria the whole thing runs on. It spans the device's life, from first architecture sketch to post-market data, and it's cited by your technical file (Annex II §5), your GSPR matrix, and — via ISO 13485 — the FDA QMSR.

What it is not: an FMEA spreadsheet with severities attached. FMEA analyses component failures; ISO 14971 also covers hazards present when the device works exactly as designed — use error, foreseeable misuse, environment, biocompatibility. FMEAs feed the file. They don't constitute it.

Hazard → hazardous situation → harm.

Three terms, precisely defined, and the discipline of the whole file is keeping them apart. A hazard is a potential source of harm. A hazardous situation is the circumstance in which people are exposed to it — usually reached through a sequence of events. Harm is the injury or damage to health that can result. Risk is estimated on the situation, because the same hazard creates different risks in different situations.

The second example is the one FMEA-only teams never write — and the kind reviewers look for first, because it shows the analysis went beyond the failure modes.

Split the probability where the controls act.

Probability of harm is usefully decomposed — as the standard's guidance suggests — into P1, the probability that the hazardous situation occurs, and P2, the probability that the situation leads to harm. The split isn't pedantry; it's where control strategy lives. A design change that eliminates the unit-conversion path attacks P1. The out-of-range alert attacks P2. Estimating them separately, before and after each control, shows exactly what each control bought you — which is precisely the evidence "risk reduced as far as possible" needs behind it.

Severity and probability land on the scales defined in your risk management plan, against acceptability criteria you set under a top-management policy. Reviewers rarely challenge the criteria themselves; they challenge criteria applied inconsistently, or quietly relaxed when a risk wouldn't pass.

Design first. Warnings last. In that order, provably.

ISO 14971 prescribes the priority of risk controls, and the MDR's GSPRs repeat it:

• 1 · Inherent safety by design. Remove the hazard or the path to it — the canonical-units redesign. Always the first question, and the file should show it was asked.
• 2 · Protective measures. Guards, interlocks, alarms — in the device or its manufacture. The hard-stop dose alert lives here.
• 3 · Information for safety. Warnings, labeling, training. Legitimate, last, and weak — a residual-risk disclosure in the IFU is not a substitute for the first two levels, and files that lean on it read as exactly that.

Each control becomes a requirement in your requirement tree and is verified like any other — the hazard ↔ control ↔ requirement ↔ test loop is the first trace chain auditors pull. And under EN ISO 14971 as applied to the MDR, "as far as possible" means what it says: economic convenience is not a defence, and a residual risk above your criteria survives only on a documented benefit-risk analysis with clinical or technical grounds.

Clause 10: the loop back from the field.

Production and post-production information — complaints, service reports, PMS findings, literature — must be collected, reviewed for safety relevance, and fed back into the file. A complaint that reveals a new sequence of events reopens the affected risk; a frequency estimate contradicted by field data gets revised; a new control goes back through verification. The risk file you submit at conformity assessment and the one your post-market process maintains are the same document — and a file untouched since certification is, to a reviewer, a finding announcing itself.

Common questions.