ISO 14971 Risk Management

Risk management protects people through better decisions

ISO 14971 provides a systematic process for managing risks associated with medical devices, including in vitro diagnostic devices and software as a medical device. It applies throughout the lifecycle—not only during design and not only immediately before a regulatory submission.

The process connects the device's intended purpose, reasonably foreseeable misuse, safety-related characteristics, hazards, sequences of events, hazardous situations and possible harms. It then requires the manufacturer to evaluate risks, implement suitable controls, assess the remaining risk and monitor whether the conclusions remain valid.

MTL-102 establishes the purpose, people and environments that frame the analysis. MTL-103 explains how risk controls become design inputs, while MTL-104 shows how their implementation and verification become controlled evidence.

The ISO 14971 process

Start with policy and a device-specific plan

Top management establishes a policy defining how risk acceptability will be determined. The policy should be based on applicable regulations and standards, the generally acknowledged state of the art and relevant stakeholder concerns. It provides the basis from which device-specific criteria are derived.

The risk-management plan then makes the process operational for a particular device or family. It should evolve when the product, evidence or development strategy changes.

• Scope, device configurations and lifecycle phases covered.
• Responsibilities, authority, competence and required independence.
• Activities, methods, records and planned risk-management reviews.
• Criteria for accepting individual risks and the overall residual risk.
• Methods for evaluating overall residual risk when direct numerical addition is inappropriate.
• Verification of risk-control implementation and effectiveness.
• Activities for collecting and reviewing production and post-production information.
• Interfaces with usability, clinical, biological, electrical, software, cybersecurity, manufacturing and supplier activities.

Risk analysis begins with a clear device definition

The analysis must identify the device and the scope being assessed. Variants, accessories, consumables, software versions, interfaces and external services can change the risk picture and should not remain implicit.

Document the intended purpose and reasonably foreseeable misuse, then identify characteristics that could affect safety. These include energy sources, materials, delivered substances, measurements, alarms, data, software, network connections, usability, environmental exposure, maintenance, shelf life and the consequences of loss or degradation of performance.

Follow the complete chain from hazard to harm

Keeping these concepts separate improves both analysis and control selection. “Software failure” is usually a cause or event, not a harm. “Electric shock” may describe a hazardous situation or harm depending on the wording. The analysis should state clearly what happens, who is exposed and what injury or damage may result.

Probability may need to consider the chance that the initiating event occurs and the chance that exposure then results in harm. Where probability cannot be estimated credibly, the uncertainty should be made visible rather than hidden behind an unsupported number.

Use complementary analysis methods

No single tool reliably finds every important risk. Select methods according to the device, development stage, technology and available evidence, then connect their findings into one controlled risk-management system.

FMEA is useful but starts from failure modes. It can overlook hazards present during normal operation, combinations of events, use-related risks and systemic interactions. A credible analysis therefore begins with hazards and harm scenarios, not with an FMEA spreadsheet template.

Estimate and evaluate risk consistently

Risk combines the probability of occurrence of harm with the severity of that harm. Categories and matrices can support consistent decisions, but they are models—not measurements of truth. Their definitions, boundaries and assumptions must be clear enough for different competent reviewers to reach comparable conclusions.

• Define severity in terms of harm, not inconvenience to the project or likelihood of detection.
• Use available data, but state uncertainty and the limits of extrapolation.
• Avoid assigning precise-looking numbers when the evidence only supports an ordinal judgement.
• Do not use detectability to redefine ISO 14971 risk; use it to inform the scenario or the effectiveness of a control where appropriate.
• Evaluate each identified risk against criteria approved in the risk-management plan.
• Apply additional regulatory requirements where they differ from or extend the standard.

A risk matrix should not create a “safe by scoring” culture. If a serious harm can credibly occur, the team should still ask whether further practicable risk reduction is available and whether the design reflects the state of the art.

Control risk in the required priority order

Risk-control options are considered in a hierarchy. The aim is to remove or reduce the source of risk through design before relying on protective measures, and to use information for safety for residual aspects that cannot reasonably be controlled by the first two options.

Risk controls should become controlled requirements and design outputs with traceability to their verification evidence. A label or warning is not an adequate substitute when a practicable design measure could prevent the hazardous situation.

If a risk remains unacceptable and further control is not practicable, a documented benefit–risk analysis may determine whether the medical benefit outweighs that residual risk. Benefit–risk analysis is not a routine shortcut around the control hierarchy.

Make residual-risk decisions at two levels

After controls are applied, evaluate each individual residual risk against the criteria in the plan. Where residual risks need to be communicated, the information supplied should accurately describe their nature and relevant consequences without using labelling to claim risk reduction that has not occurred.

The manufacturer must also consider the overall residual risk of the device. This is not normally achieved by adding risk scores. Interactions, cumulative exposure, uncertainty, the balance of benefits and risks, and the combined burden of warnings or protective measures can create a picture that is different from the individual rows.

Review the process and maintain the risk-management file

Before commercial release, an appropriately authorised review should confirm that the risk-management plan has been carried out, the overall residual risk is acceptable and suitable arrangements exist to collect and review production and post-production information.

The risk-management file is the set of records and references that demonstrates the process for the device. It does not need to be one physical document, but its traceability should make the reasoning understandable.

• Approved plan, scope, policy-derived criteria and responsibilities.
• Device description, intended purpose, foreseeable misuse and safety-related characteristics.
• Hazards, sequences of events, hazardous situations, harms and risk estimates.
• Risk-evaluation decisions and rationale.
• Selected controls and analysis of the control hierarchy.
• Traceability to implementation and effectiveness evidence.
• Individual and overall residual-risk conclusions.
• Risk-management review and arrangements for lifecycle monitoring.
• Changes, post-market signals and updated assessments.

Production and post-production information closes the loop

The manufacturer should actively collect information relevant to safety from production and post-production sources. This includes nonconformities, process trends, supplier issues, servicing, complaints, vigilance, post-market surveillance, clinical or performance follow-up, literature, public information about similar devices, security vulnerabilities and changes in the state of the art.

Relevant information is reviewed for previously unrecognised hazards, changed probabilities, changed acceptability of risks, effectiveness of controls and effects on the overall residual risk. Necessary actions may include investigation, corrective action, design change, updated labelling, customer communication, regulatory reporting or field action.

The loop is not complete until the risk-management file and connected technical documentation reflect the conclusion. A complaint database and a periodic report do not by themselves maintain the risk analysis.

Risk management connects specialist disciplines

MTL-301 explains how this cross-functional evidence is controlled through the quality-management and design-control system. ISO 14971 can be applied without an ISO 13485 QMS, but in a medical-device organisation the two processes should operate as a connected system.

Worked example: missed dose in a connected injector

Consider a connected injection system that records whether an injection occurred and presents adherence information to the user. One potential harm is deterioration in the patient's condition following a missed required dose.

A credible sequence might involve incomplete mechanical engagement, failure to detect that state, presentation of an incorrect “dose complete” indication, the user relying on that indication and no replacement dose being taken. The hazardous situation is the patient being without the required therapy while believing it was delivered.

Controls could include an architecture that measures the relevant physical event rather than inferring it from a button press, plausibility checks, clear differentiation between detected injection and data synchronisation, fault indication, verification across representative injector tolerances and usability validation of the feedback. The analysis must also consider risks introduced by false alarms or repeated dosing.

Post-market monitoring then looks for complaints, log patterns, service findings and clinical consequences that challenge the assumed event probabilities or control effectiveness. A firmware, app or injector change reopens the relevant analysis rather than inheriting the earlier conclusion automatically.

Common misconceptions