Medical device Hazard Analysis under ISO 14971

A Hazard Analysis is a systematic identification of the foreseeable hazards of a medical device, the situations in which a person is exposed to them, and the harms that can follow. Each row carries an estimate of how severe that harm would be and how likely it is to happen. It is the foundation of a risk management file under ISO 14971, the International Organization for Standardization standard for applying risk management to medical devices.

A row is not a single sentence about something going wrong. It is a chain: a hazard exists, a foreseeable sequence of events brings a person into contact with it, that contact is the hazardous situation, and the harm is what the person suffers. rmForge models the sequence as up to four steps from an initiating cause, where the cause is one of design, hardware, software, process, packaging, labeling, or the user.

These three are the most commonly confused terms in the whole discipline, and getting them wrong is what makes a risk file fall apart under review. If you want the long version with a worked example, read hazard vs hazardous situation vs harm.

• Hazard. A potential source of harm. Electrical energy is a hazard. It is a property of the device or its use, and it exists whether or not anyone is ever hurt.
• Hazardous situation. A circumstance in which a person is exposed to that hazard. An exposed conductor during defibrillation is a hazardous situation.
• Harm. The injury or damage itself. An electrical burn is a harm. So is an equipment fire, because harm covers damage to property as well as injury to a person.

A row that names a hazard but never reaches a harm has not finished the job, and a row whose sequence of events simply restates the harm has skipped the middle of the chain.

A normal condition is the device working as designed, with nothing broken. A fault condition is a single component failure or a single-fault state. Both have to be considered, because a device that is safe when everything works can still injure someone when one part fails.

rmForge keeps a strict separation between the two: every row is one or the other, never both. Fault rows assume single-fault conditions. Cascading faults are not written as single rows; they call for a separate analysis.

Hazards are enumerated from a controlled set of categories rather than invented row by row, so two analyses of the same device do not end up looking nothing alike. rmForge uses four top level categories: energy; biological and chemical; performance; and information and security, which covers data and cybersecurity hazards. They follow the hazard examples in Annex C of ISO 14971.

Each row is also tagged by how the device was being used: intended use, misuse through use error, or misuse through abnormal use. That distinction comes from IEC 62366-1, the International Electrotechnical Commission standard for usability engineering of medical devices.

Two probabilities are estimated for every row. P1 is the chance the hazardous situation happens at all. P2 is the chance that, once it exists, harm actually follows. Each is scored from 1 to 5. Severity of the harm is scored the same way.

P1 and P2 are then combined into Po, the probability that harm occurs, by reading a fixed table rather than by multiplying. Severity and Po together give the Risk Level by reading a second fixed table. There are four levels: Low, Medium, High, and Unacceptable.

Nothing anywhere in that path is multiplied, and no Risk Priority Number is produced. Ordinal multiplication lets a rare severe harm and a frequent minor one collapse to the same number, which is exactly the case a reviewer cares most about. In the table rmForge uses, a harm rated Severity 4 or 5 never lands in Low, so it always calls for a risk control.

Acceptability itself is not something a tool decides. ISO 14971 puts the criteria for acceptable risk in the manufacturer's risk management plan. The tables rmForge ships are a default starting point, printed on the Risk Region tab of the workbook so your team can check them against your own plan.

A risk control that never becomes a requirement may never be built into the device. It cannot be verified, so the harm it was meant to prevent can still reach the patient. A control is only finished when three things exist and point at each other: the requirement, which is a design input; the implementation, which is a design output; and the verification, which is design verification and validation, process validation, or inspection.

rmForge proposes at least one Risk Control Measure for every row, including Low rows, with its implementation and verification, for your team to review and complete. You can see a full chain, requirement through implementation through test report, in the sample workbook excerpt on the demo page.

The delivered workbook carries 32 columns per row, covering hazard identification, risk estimation, risk control, and residual risk. The same reference tabs appear on every Hazard Analysis run: a Cover Page, the Risk Region tables, the Scales, Column Descriptions, the Hazard Questionnaire, and a Disclaimer. The Hazard Analysis sheets print on Tabloid paper; the reference sheets print on Letter. Every column is explained, one by one, in the Hazard Analysis template.

Residual risk is the risk left after the controls are applied, together with any new risk the controls themselves introduce. Your team fills those columns in once the controls are verified. rmForge starts the revised harm as the row's own harm and New Risk at N; the revised scores wait for your team.

When the design changes, the analysis has to change with it. Revising an rmForge Hazard Analysis returns the next revision with every change marked in the cells and listed on a Change Summary tab, so a reviewer can see what moved rather than comparing two files by eye.

A Hazard Analysis is top down. It starts from the harm a person can suffer and traces back to the device. A Failure Mode and Effects Analysis (FMEA) is bottom up: it starts from a component or process failure mode and traces forward to the effects. Both are useful, and they answer different questions. A file full of failure modes does not by itself show that every foreseeable harm was considered. The differences are set out side by side in Hazard Analysis vs FMEA.

rmForge drafts the Hazard Analysis with you in a working session, from your Instructions for Use and product requirements, and delivers the workbook for your team to review. The risk math is read from the fixed tables above rather than judged by a language model, and every row is checked against the rules: a row that cannot pass is flagged for review, and three kinds of row are left out instead. How rmForge works lists which parts are fixed rules, which are done by artificial intelligence (AI), and what your team decides.

Today, once the Hazard Analysis is finished, rmForge can build a Design FMEA or a Process FMEA from it, each in its own workbook.

Each workbook is a draft. It requires qualified cross functional review and approval by your team, and rmForge does not determine regulatory compliance or guarantee that a submission is accepted.