Medical Device Risk Management Tools

Meet the device

Every part of this guide uses the same fictional product, the Orvelo patch, invented for this guide. Any resemblance to a real device is unintended. Using one device throughout means you can see how the tools connect rather than learning each one in isolation.

That mix of skin contact, a battery, lay users, wireless data and an algorithm is why one device needs nearly every tool in this guide.

One process, many tools

ISO 14971:2019 is the international standard for medical device risk management, and regulators in the US, EU and most other markets expect it.^[1] It defines a single process. The tools in this guide are methods for carrying out parts of it, and none of them is a risk management process on its own. A DFMEA spreadsheet, however thorough, is not a risk management file.

Some hazard areas also have their own specialist evaluations, such as biological safety under ISO 10993-1 and electrical and mechanical safety under IEC 60601-1. Their results feed the same risk management file. This guide focuses on the tools that tie everything together.^[3]

Hazard, hazardous situation, harm

ISO 14971 separates three ideas that everyday speech blurs together. A hazard is a potential source of harm, such as heat, electricity or a wrong number on a screen. A hazardous situation is the circumstance in which someone is exposed to it. Harm is the injury or damage that can follow. Risk is the combination of how severe that harm is and how likely it is to happen.^[1]

Between a hazard and a harm is a sequence of events. Two probabilities matter along that chain: P1, the chance the hazardous situation occurs, and P2, the chance it then leads to harm. ISO 14971 illustrates this chain in its Annex C.^[1] Pick an Orvelo example to see it.

Scoring risk: severity, probability and your policy

To evaluate a risk you need two scales, severity and probability, and a rule for which combinations are acceptable. ISO 14971 doesn't supply those criteria. It requires top management to set a policy for establishing them, and the risk management plan to define them for each product.^[1] The matrix below uses example scales. Click any cell to change its zone: your edits carry through to every matrix in this guide.

Which tool, when?

Most tools are used at more than one stage, but each one is strongest at a particular point. Pick where you are to see the tools that apply.

What hazard analysis is for

A hazard analysis works from the top down. Instead of asking how each part can fail, it asks what could hurt someone and how it could happen. Early in a project it's often called a preliminary hazard analysis (PHA): a first list of hazards drawn from the intended use, similar devices and known problems, made before the design is detailed. As the design matures, the same document grows into the full hazard analysis, with probabilities, controls and verification evidence on every chain.^[4]

The most reliable way to build the list is to walk through hazard categories systematically, rather than brainstorming freely.

Estimating risk with P1 × P2

For each chain, multiply the probability the hazardous situation occurs (P1) by the probability it leads to harm (P2). The product is the probability of harm, which is what goes on the probability axis. Then add risk controls and watch where each one acts: some lower P1, others lower P2.^[1]

Notice how little the warning label changes the result. That's not a quirk of the example: information for safety is the weakest kind of control, which is why ISO 14971 puts it last in the order of preference. More on that in Part 9.

The Orvelo hazard analysis, at a glance

Here are five chains from the Orvelo analysis, scored against your policy from Part 1. Edit your policy and this table updates. Notice that the top two rows by severity aren't the top two by probability: you need both to decide where to spend effort.

Getting the numbers right

How a DFMEA works

Failure mode and effects analysis goes component by component, or function by function. For each one you list how it could fail (the failure mode), what that failure would cause (the effect) and why it could happen (the cause). The standard for the method is IEC 60812:2018, and ISO/TR 24971 lists FMEA among the techniques that support ISO 14971 risk analysis.^[8][4]

Each row usually gets three ratings, often on 1–10 scales: severity of the effect, occurrence of the cause, and detection, meaning how likely your design controls are to catch the problem before the design is released. Multiplying them gives the risk priority number, or RPN.

The trouble with RPN

ISO 14971 defines risk as the combination of the severity of harm and the probability of that harm occurring. Detection isn't part of it.^[1] In a DFMEA, a good detection rating means your verification testing is likely to catch the problem in development. That's valuable, but it doesn't make the released device any safer: if the problem is caught, you fix the design, and then the occurrence rating should go down. Counting detection again in the RPN rewards the same work twice, and lets a severe failure mode hide behind a high detection score.

The automotive industry reached a similar conclusion. The AIAG-VDA FMEA Handbook of 2019 replaced RPN with an "action priority" approach that gives severity more weight.^[9] Try it yourself: edit the ratings and compare the two rankings.

With the starting ratings, the two failure modes that could seriously injure a patient, a battery short and a DC current path through the electrodes, sit at the bottom of the RPN list because they're rare and easy to detect in testing. Ranked by severity first, they rise to the top, which is where a regulator would expect to see your attention.

Linking the DFMEA to the hazard analysis

The hazard analysis works top-down, from hazard to hazardous situation to harm. The DFMEA works bottom-up, from a cause in one component to its effect on the device. They meet where a DFMEA row's end effect is a hazardous situation. Link the row there, and the failure mode and its cause become part of the sequence of events that leads to that hazardous situation.^[1][4]

Notice that the DFMEA above uses a 1–10 severity scale while the hazard analysis in Part 2 uses five levels. That is common, and it's exactly how the two documents end up disagreeing. Once a row is linked, its severity should come from the harm in a shared harms table, not be scored again.

1. Pick the end effect from a shared list

   Keep one list of hazardous situations, each with an ID, and one harms table that sets each harm's severity once. The DFMEA's end-effect column picks from that list instead of free text.

2. Expect many-to-many links

   One hazardous situation usually has several causes from the DFMEA, the PFMEA, the URRA and software. One failure mode can also lead to more than one hazardous situation.

3. Record "no safety impact" as a decision

   Rows with no safety-related effect stay in the DFMEA as reliability or quality items. Mark them explicitly, with a short rationale, so a reviewer can tell the row was judged rather than forgotten.

4. Carry occurrence across, not detection

   A cause's occurrence feeds P1 for the hazardous situation. Detection by testing or inspection doesn't lower patient risk, so it stays a verification question. Detection by the device itself, such as an alarm, is different: it's a protective measure and belongs in the hazard analysis as a risk control.

5. Keep one record per risk control

   If current limiting appears in both the DFMEA and the hazard analysis, it should be the same control with one verification link. Two copies drift apart, and then there are two verification stories for one control.

Walk the process, step by step

A PFMEA follows the process flow. For each step it lists how the step can go wrong, what that does to the product, why it might happen, and the controls that prevent or detect it. The severity of each effect should come from the DFMEA and hazard analysis, so the whole risk file uses one view of how bad an outcome is. Click an Orvelo process step.

Prevention, detection and what reaches the patient

Here the detection column means something different from the DFMEA. In production, an inspection that catches a bad unit before it ships really does lower how often a defect reaches a patient, and ISO 14971 recognizes protective measures in the manufacturing process as a form of risk control.^[1] But detection has to be validated, and it is never perfect. Prevention stops the defect being made at all. Try both.

The escape rate is a direct input to P1 in the hazard analysis. If the production line changes, so does the risk estimate, which is why process changes need a risk review. In the root cause analysis guide, the same weak-lamination defect came from a new laminator running below its validated pressure.

From PFMEA to control plan

The control plan lists what is checked at each step, how, how often, and what happens when a check fails. Every control the PFMEA relies on should appear in it, and every line in it should trace back to a PFMEA row. If a control isn't in the control plan, nobody is required to do it.

Use errors are a design problem

IEC 62366-1 defines a use error as a user action, or failure to act, that leads to a different result than the manufacturer intended or the user expected. It's distinct from abnormal use, a deliberate act that goes against normal use and is beyond reasonable design control.^[10] Use errors are foreseeable, so they belong in the risk analysis like any other hazard source.

FDA's human factors guidance defines a critical task as one that, “if performed incorrectly or not performed at all, would or could cause serious harm”; FDA's human factors guidance counts compromised medical care as harm.^[11] Critical tasks are what summative (validation) testing has to cover. In May 2026, FDA finalized its guidance on the human factors content of marketing submissions, which sorts submissions into three categories through a series of decision points about the user interface and its critical tasks.^[12]

Build the URRA

Here are eight Orvelo tasks, from opening the pouch at home to a clinician reading the report. Severity drives whether a task is critical. Then choose a risk control for each: notice that only a design change that removes the task altogether takes it off the critical list. Everything else still has to be shown to work in validation testing. In this example, Serious and above count as serious harm; map your own severity scale to FDA's definition in your plan.

FDA's example URRA table also records the hazardous situation for each use error and how the effectiveness of each control will be validated.^[12] The analysis is a living document: formative testing usually turns up use errors nobody predicted, and each one goes back into the table.

Where the URRA links in

A use error is one more cause on the way to a hazardous situation, so URRA rows link to the hazard analysis, to the same hazardous situations and harms the DFMEA links to, with severity from the same harms table. FDA's example URRA table has columns for the hazardous situation and the harm for this reason.^[12] Most teams still keep the URRA as its own document, because it has to stand on its own in the human factors report.

The link to the DFMEA is indirect, and it runs through risk controls. When a use error is fixed by changing the design, the new design feature can fail too, and that failure belongs in the DFMEA. ISO 14971 calls this checking for risks introduced by risk controls.^[1] Switch between the two designs to see it.

Which human factors submission category?

FDA's 2026 guidance asks a short series of questions to decide what human factors information a submission needs. This simplified version follows its logic; check the guidance itself for the full decision points and examples.^[12]

Why software is scored differently

A software defect is a design flaw: given the same inputs, it fails every time. There's no meaningful failure rate to put on the probability axis. IEC 62304, the software lifecycle standard, deals with this by assuming the probability of a software failure is 1 when assigning a software safety class.^[13] The class depends on the worst harm that could result after considering risk controls outside the software system, such as an independent hardware cutoff:

IEC 62304:2006 with Amendment 1:2015 is still the current edition. A second edition is in development, so check its status before relying on any draft text.

Classify the Orvelo software

Pick a software item and answer the questions. Watch what happens to the patch firmware when you add an independent hardware thermal cutoff: a control outside the software can lower the class, which can save a great deal of development effort.

FDA documentation level: a different question

For US submissions, FDA's 2023 guidance on device software functions asks for Basic or Enhanced documentation. Enhanced applies where a software failure “could present a hazardous situation with a probable risk of death or serious injury”, and the risk is assessed before any risk controls are applied. It also recommends Enhanced for some device types, including Class III devices.^[14]

Why security risk needs its own analysis

Random failures have rates you can estimate. Attacks don't: whether someone attacks your device depends on motive, opportunity and how easy the attack is, and that changes as new vulnerabilities are published. FDA's premarket cybersecurity guidance therefore treats security risk management as a separate process from safety risk management, and recommends assessing exploitability (how easily a vulnerability could be used) instead of probability.^[15] AAMI TIR57 and AAMI SW96 describe how to run that process alongside ISO 14971.^[16][17]

The two processes meet at the point of harm. If a threat could cause a hazardous situation, such as a patch that silently stops recording, it goes into the hazard analysis and is scored there like any other cause. Threats that only affect privacy or business operations stay in the security risk assessment, where they still need controls.

Score the Orvelo threats

Five threat scenarios for the patch, its app and its cloud service. Each is placed by exploitability and impact. Turn on security controls and watch the scenarios move. The scenarios marked with a heart could affect a patient, so they also go into the hazard analysis.

The scales and zones here are illustrative. Define your own security risk acceptance criteria in your security risk management plan, separately from the safety criteria in Part 1.

A CVSS score is not a risk score

When a vulnerability is published in a component you use, it usually comes with a CVSS score. CVSS describes how severe the vulnerability is in general; it doesn't know how your device uses the component or what a patient would experience.^[21] FDA has recognized CVSS v4.0 as a consensus standard, and a rubric developed by MITRE adapts the earlier CVSS v3.0 for medical devices.^[22][23] Either way, the score is an input to your risk assessment, not the answer.

FDA's postmarket cybersecurity guidance asks manufacturers to decide whether the risk to essential clinical performance is controlled (acceptable residual risk) or uncontrolled. The answer decides how quickly you must act and whether customers and FDA need to be told.^[24]

Making it work in practice

What changes with machine learning

ISO 14971 still applies to AI-enabled devices. In June 2026, ISO published ISO/TS 24971-2, guidance on applying ISO 14971 to machine learning. It builds on AAMI TIR34971 and covers hazards that come from data and from the way people use model outputs. It excludes large language models and generative AI.^[25][26] Typical sources of harm include:

• Performance trade-offs: the decision threshold sets how many true cases are missed and how many false alarms are raised.
• Data problems: training data that doesn't represent the people or conditions the device will meet in use.
• Automation bias: users trusting the output too much, or ignoring it after too many false alarms.
• Change over time: performance drifts when patients, sensors or software around the model change.

Choose the AF detection threshold

The Orvelo cloud model gives each recording a score from 0 to 1 for how likely it is to show atrial fibrillation (AF). Recordings above the threshold are flagged for a clinician. Move the threshold and watch the two kinds of error trade off. Then switch to the subgroup with noisy, low-amplitude signals, which were scarce in the training data.

Each kind of error leads to a different harm. A missed AF episode can delay anticoagulation and leave stroke risk untreated; a false alarm costs clinician time and can cause anxiety or unnecessary tests. The risk analysis should state which error matters more, set an acceptance criterion for each, and check it in every relevant subgroup, not just overall.

The score distributions are simulated for illustration and don't describe any real algorithm. Each curve shows the shape of the scores for its group; the counts assume 10% of recordings contain AF.

Watch for drift after release

In this example, a phone operating system update in month 10 changes how the app compresses ECG data before upload. The model was never trained on the new signal, and its sensitivity starts to slide. How quickly would you notice? Choose how often you compare model results with clinician-confirmed diagnoses.

Three kinds of control, in order of preference

ISO 14971 asks manufacturers to consider risk control options in a fixed order, and to use them in that order where they're practicable.^[1] The EU MDR sets out the same order in Annex I, section 4.^[6] The order reflects how much each kind of control depends on people doing the right thing.

The order is not “use only one kind.” Most serious hazards end up with controls from more than one category, as the bow-tie at the end of this part shows. What the order rules out is reaching for a warning label when a design change was practicable.

Which kind of control is it?

The boundaries trip people up, especially for controls in manufacturing and for training. Sort these nine Orvelo controls.

Run a control option analysis

For each hazardous situation, the file should show which options you considered, which you chose and why. Pick a hazardous situation, choose controls, and watch the residual risk, the verification you now owe, and any new risks the controls bring with them. The probabilities and their reductions are illustrative.

Verify implementation and effectiveness

ISO 14971 asks for two different things for every control: evidence that it was implemented, and evidence that it is effective in reducing the risk.^[1] Teams often have the first and assume the second.

Effectiveness evidence for information for safety usually comes from human factors work: knowledge-task questions and observed behavior in summative testing, which is why the URRA in Part 5 and this step are so closely linked.

Check the controls themselves

See every barrier at once: the bow-tie

An FMEA spreads one hazard across many rows. A bow-tie pulls it back together, which makes it a good final check on the controls for your most severe hazards.

IEC 31010, the general standard on risk assessment techniques, describes the bow-tie as a diagram centered on an unwanted event. Threats that could cause the event sit on the left, with preventive barriers between them and the event. Consequences sit on the right, with mitigative barriers that limit how bad the outcome gets.^[33] The left side reads like a simplified fault tree and the right side like an event tree.

A bow-tie doesn't produce a risk score. Its strength is communication: in a design review, anyone can see which paths have two independent barriers and which have one, or none.

The central event is the Orvelo circuit producing excess heat while the patch is worn. Click any barrier to remove it or put it back. Then make the thermal cutoff firmware-controlled and see what happens to the firmware path.

Getting value from a bow-tie

Residual risk, one hazardous situation at a time

After controls are in place, re-estimate each risk with the same method you used before, and evaluate it against the criteria in your plan. If it's not acceptable, apply more control. Only when further control isn't practicable does ISO 14971 let you turn to a benefit-risk analysis for that risk; if the benefits don't outweigh it, it stays unacceptable.^[1] Walk a residual risk through the decision.

When does reducing a risk stop? That depends on which principle your policy follows, and the answer has changed over the past 25 years. The next section explains.

ALARP, AFAP and how the rules evolved

Three phrases describe how far risk reduction has to go. They sound alike and lead to different files.

The “No” for AFAP is the prevailing EU interpretation, which comes from the harmonized standard's annexes and notified body practice; the MDR itself doesn't mention cost.^[35] Many risk matrices have three zones because of ALARP: broadly acceptable, a middle region where risk is reduced “as low as reasonably practicable”, and unacceptable. Under AFAP, the middle region is no longer a place where you can stop on cost grounds, and even the green zone needs evidence that the risk was reduced as far as possible.

The seven deviations, then and now

The 2012 European edition of ISO 14971 kept the 2007 text but added annexes (Annexes Z) listing seven points where the standard fell short of the directives. Notified bodies and industry associations published a consensus paper in 2014 on how to apply them.^[35] The headings below are shortened from those annexes. Most of the friction has since been resolved by the MDR's wording and the 2019 edition, but the ideas behind the deviations still shape what EU reviewers expect.

Many companies apply AFAP everywhere, so one risk management file serves every market. Whatever you choose, state it in the policy and apply it consistently.

Benefit-risk analysis

Benefit-risk shows up twice in ISO 14971: for an individual residual risk that can't be reduced further, and for the overall residual risk of the device, which is always weighed against the benefits of the intended use.^[1][4] A benefit has to be a positive impact on health: a better diagnosis, a better outcome, better patient management, backed by clinical data. A feature or a lower price isn't a medical benefit.

FDA's benefit-risk guidance for PMA and De Novo decisions lists the factors reviewers weigh, and it's a useful checklist for any device:^[37]

Try it for the Orvelo, compared with the alternative it would replace: a 24-hour Holter monitor. All figures are illustrative and per 1,000 patients monitored.

The worksheet structures the comparison; it doesn't make the decision. The conclusion is a documented judgment by people with clinical knowledge, based on the clinical evaluation.

Overall residual risk

Individually acceptable risks can add up. Clause 8 of ISO 14971 asks you to judge the device's overall residual risk against the benefits of its intended use, considering how all the residual risks combine, with a method and criteria fixed in advance in your plan.^[1] ISO/TR 24971 offers several possible approaches, including reviewing data on similar devices already on the market and judgment by a cross-functional team with relevant clinical knowledge, and notes that the criteria for overall residual risk can differ from those for individual risks.^[4]

Disclose significant residual risks

ISO 14971 asks you to inform users of significant residual risks in the accompanying documentation, and the MDR requires manufacturers to inform users of any residual risks.^[1][6] Disclosure is different from information for safety: it describes what can still happen, so users and patients can make informed decisions. Information for safety tells them what to do.^[4]

The risk management review and report

Before commercial release, ISO 14971 requires a review of how the risk management plan was carried out. At a minimum, the review confirms three things, and its results are recorded as the risk management report:^[1]

1. The plan was implemented

   Every activity in the risk management plan was done, by the people and at the points it named, and the records exist.

2. The overall residual risk is acceptable

   The clause 8 evaluation is complete, with its benefit-risk conclusion and the significant residual risks identified for disclosure.

3. Production and post-production methods are in place

   There's a working way to collect and review information from production, complaints, service and the literature, and to feed it back into the analysis. Part 11 shows that loop in action.

The report isn't the end of the file. It's a snapshot that's updated whenever the risk picture changes: a design change, a new hazard from the field, or a change in the state of the art.

Which tool answers which question

Is the field telling you something?

The hazard analysis estimated how often patients would be burned. Complaints show how often it actually happens, at least the cases people report. ISO 14971 requires you to collect and review this information and act if a risk estimate no longer holds.^[1] Enter a year of field data and compare.

When the field rate is higher than the estimate, the reason matters as much as the number. The Pareto analysis and fault tree analysis chapters of our root cause analysis guide show how to find it, and the findings go back into the hazard analysis and FMEAs.

Risk management file checklist

A quick self-check against the main clauses of ISO 14971:2019. Tick what your file already has; the gaps list shows what's left.^[1]

The thread that runs through it all

Every tool in this guide ends the same way: a hazardous situation, an estimate of its risk, a control, and evidence that the control works. Keep those links intact, from the first hazard to the latest complaint, and the risk management file becomes a working tool for design decisions rather than a document assembled before a submission.