Medical-device Risk Management

Risk management is a development activity—not a spreadsheet

Medical-device risk management is the structured process through which a manufacturer identifies possible harm, decides what controls are needed, confirms that those controls work and keeps the conclusions current as the product and available information change.

The formal process is established by ISO 14971, but effective risk management happens through everyday engineering decisions: defining intended purpose, choosing an architecture, allocating requirements, designing interfaces, selecting components, controlling suppliers, planning verification and responding to field information.

MTL-302 — ISO 14971 Risk Management explains the detailed standards framework. This core topic concentrates on how development teams put that framework to work.

The practical risk-management loop

The loop is repeated at increasing levels of detail. Early analysis guides the concept and architecture. Later evidence checks the implemented controls. Post-market information tests whether the assumptions remain true in real use.

Use precise language from hazard to harm

Teams often write failure modes where hazards should be, or stop the scenario before exposure and harm are described. “Motor stalls” is a technical event. “Thermal energy” may be a hazard. “The patient touches an overheated surface” is a hazardous situation. “Skin burn” is a harm.

Clear chains help teams identify better controls. If the chain is vague, it is difficult to decide whether a proposed measure actually interrupts it.

Find risks by examining the complete system and lifecycle

Risk discovery is not a single brainstorming meeting. It uses multiple perspectives and methods because different analyses reveal different weaknesses.

MTL-102 — Intended Purpose, Users and Use Environments provides the boundary conditions for this work. A change in users, patients, claims or environment can create new sequences of events even when the technical design appears unchanged.

Risk estimation supports judgement—it does not replace it

Risk estimation considers the possible severity of harm and its probability. Probability may include the likelihood that a sequence reaches a hazardous situation and the likelihood that exposure then results in harm. Data may come from testing, complaints, literature, comparable devices, process capability, reliability evidence or justified expert judgement.

Numerical scores and matrices are useful communication tools, but they can create false precision. Category definitions, exposure assumptions, detectability, user behaviour, common-cause failures and uncertainty must remain visible.

• Describe the harm and severity independently of whether the team believes it is likely.
• Separate evidence from assumptions and identify important uncertainty.
• Use the same approved definitions across analyses and disciplines.
• Avoid multiplying arbitrary ordinal numbers and treating the result as measured risk.
• Do not use a low estimated probability to avoid a practicable design control.
• Give additional attention to severe harms, weak data and rapidly changing technology.
• Revisit estimates when testing or field information challenges an assumption.

Choose controls in the preferred order

The hierarchy does not mean every conceivable control must be implemented. The team considers applicable regulations and standards, generally acknowledged state of the art, technical feasibility, benefit and the risk introduced by the control itself. The rationale for rejecting an apparently practicable control should be recorded.

Warnings do not make a product inherently safe. Their effectiveness depends on users noticing, understanding and acting correctly under the actual conditions of use.

A risk control becomes real through requirements and design outputs

A phrase such as “software will prevent overdose” is not yet an implementable control. The team must specify the permitted dose range, data source, authority, checking logic, response to invalid inputs, fault behaviour, user feedback and acceptance criteria.

MTL-103 — User Needs and Design Inputs explains how risk controls become approved, measurable design inputs. MTL-104 — Design Controls and Technical Documentation follows those inputs through implementation, review, verification, validation, transfer and change.

Allocate each control to an owner and system element

Risk controls frequently cross disciplines. A safe dose may depend on mechanical travel, motor control, sensor accuracy, software limits, manufacturing calibration, user confirmation and labelling. Treating one line in the risk table as one control can hide these dependencies.

Every control should have a responsible owner, controlled requirement, implementation evidence and verification route. Shared ownership must not become absent ownership.

Verify both implementation and effectiveness

Implementation verification asks whether the control was built as specified. Effectiveness verification asks whether it actually reduces the intended risk within the relevant scenario.

A software limit may be present in code, but effectiveness also depends on whether all commands pass through it, corrupted data are rejected, updates preserve it and the system responds safely if the limit mechanism fails. A warning may be printed correctly, but usability evidence may show that users do not see or understand it.

• Trace each control to one or more objective verification activities.
• Test boundary, fault and abnormal conditions—not only nominal operation.
• Identify the hardware, software, data and environment configuration tested.
• Verify assumptions about independence and external controls.
• Record deviations, anomalies and the effect on residual risk.
• Confirm that the control has not introduced new hazards or changed other risks.
• Use system-level tests when effectiveness depends on several components or disciplines.

Residual risk decisions occur at two levels

After controls are implemented and verified, each individual residual risk is estimated and evaluated. Significant residual risks may need to be communicated to users, but disclosure does not itself reduce risk.

The manufacturer also evaluates the overall residual risk of the device. This is not simply the sum or average of matrix scores. It considers the complete pattern of risks, uncertainty, interactions, cumulative exposure and the expected medical benefits of the intended use.

Benefit-risk analysis should not become a routine justification for weak control. It is relevant when residual risk remains unacceptable after all practicable control measures have been applied and the medical benefit may nevertheless justify proceeding.

Use risk evidence at every development gate

MTL-101 — The Medical-device Development Lifecycle shows how these decisions fit within the wider flow from unmet need to supported product.

Use connected records rather than one overloaded table

The risk-management file is the organised set of records that demonstrates the process for the device. It may reference rather than duplicate documents. The structure should let a reviewer follow a scenario from its source through controls, implementation, verification and residual-risk decision.

No single tool reliably finds every risk. The records must be consistent, controlled and traceable without forcing every specialist analysis into an unreadable master spreadsheet.

Every meaningful change asks a risk question

Changes to components, software, suppliers, production processes, claims, users, accessories, environments or service arrangements can alter risk. Change control should identify affected scenarios, controls, assumptions, verification and post-market obligations before approval.

Production and post-production information provide the same challenge from the field. Complaints, nonconformities, servicing, trend reports, vigilance, literature, comparable devices, security vulnerabilities and changes in the state of the art may reveal new risks or show that an earlier estimate was wrong.

Risk records should therefore represent the current supported product configuration—not only the configuration submitted at initial market entry.

Risk ownership belongs to the organisation

A risk manager or quality specialist can coordinate the process, but cannot personally supply all the clinical, engineering, manufacturing, usability and service knowledge required. Competent representatives from the relevant functions must own their analysis and decisions.

• Management establishes policy, resources, responsibilities and escalation routes.
• Project leadership integrates risk work into plans, reviews and development gates.
• Clinical and user experts describe consequences, workflow, benefit and real-use conditions.
• Engineers identify failure mechanisms, design controls, interfaces and verification evidence.
• Manufacturing and supplier teams address variation, process controls and purchased-item risks.
• Quality and regulatory teams maintain process integrity and applicable market expectations.
• Post-market, service and cybersecurity teams feed new lifecycle information into review.

Risk acceptance should be made by people with appropriate authority and competence. It should not be silently inherited because a spreadsheet cell turned green.

Worked example: loss of a high-priority alarm

Consider a portable patient monitor used during transport. A clinically significant deterioration should produce a high-priority alarm. One harm is delayed clinical intervention leading to serious patient deterioration.

Credible sequences include a detached sensor not detected by software, alarm audio obscured by ambient noise, depleted battery, a frozen user interface, an incorrect threshold, electromagnetic disturbance or a user silencing the alarm without understanding the patient state.

Controls are distributed across sensor diagnostics, plausibility checks, alarm logic, visual and audible presentation, protected settings, battery monitoring, power-loss behaviour, interface design, EMC robustness, self-test, maintenance and user training.

Each control becomes a requirement with an owner and verification method. Software lifecycle evidence is provided through MTL-303 — IEC 62304 Software Lifecycle. Electrical and EMC evidence is connected through MTL-304 — IEC 60601 Electrical Safety and EMC.

System validation then examines whether intended users can recognise and respond to the alarm in representative transport conditions. The residual-risk conclusion draws on the complete control set—not on the successful unit test of one alarm function.

Common failure patterns

A practical review checklist

• Is the intended purpose and supported configuration unambiguous?
• Are hazards, sequences, hazardous situations and harms described distinctly?
• Have normal use, foreseeable misuse, faults, security and lifecycle conditions been considered?
• Are estimates supported by evidence and important uncertainty visible?
• Were risk controls considered in the preferred order?
• Has each control become an owned, measurable requirement?
• Are implementation and effectiveness both verified?
• Have new or changed risks introduced by controls been assessed?
• Are individual and overall residual-risk decisions authorised and supported?
• Do gates, change control and post-market processes use the current risk evidence?