Independent learning for medical-device professionals
SearchCommentaryConsulting
LearningMTL-215 · LEARNING BY ROLE

Risk Management Teams in Medical-device Development

How risk specialists facilitate rigorous safety decisions, connect hazards to engineering controls and maintain a living risk-management system across the device lifecycle.

What you will learn

By the end of this topic, you should be able to define the risk team’s facilitating and assurance roles; apply the organisation’s risk policy consistently; develop system-level hazardous sequences; select and verify risk controls; maintain traceability; integrate specialist analyses; conduct meaningful reviews; support benefit–risk conclusions; and feed production and post-production information back into the risk file.

01

The risk-management team’s role

Risk specialists provide process expertise, facilitation, challenge and coherence. They help multidisciplinary teams reason from hazards through sequences of events to hazardous situations, harms and controls. They do not own every risk or replace the technical and clinical experts who understand the product.

Facilitator

Bring the right disciplines together and make assumptions visible.

Method steward

Apply policy, terminology, criteria and records consistently.

Safety integrator

Connect system, software, usability, biological, electrical and cybersecurity risk.

Lifecycle monitor

Reassess risk when design, production or field information changes.

02

Establish governance before scoring risks

The risk-management plan should define scope, responsibilities, competent participants, review points, acceptability criteria, verification arrangements, overall residual-risk evaluation and methods for collecting production and post-production information. Criteria must reflect the manufacturer’s policy and applicable regulations; a project team should not adjust thresholds to make an uncomfortable result acceptable.

Use MTL-114 — Medical-device Risk Management and MTL-311 — ISO 14971 Risk Management as the process foundations.

03

Analyse how harm can occur

Start with intended purpose, reasonably foreseeable misuse, characteristics related to safety, known hazards and clinical context. Develop credible sequences of events that lead to hazardous situations and harms. Estimate risk using available evidence and explicit assumptions. Techniques such as preliminary hazard analysis, FMEA, fault trees, use-related analysis and threat modelling are complementary views—not substitutes for the complete risk process.

Keep system-level reasoning connected to MTL-105 — Systems Engineering, Architecture and Interfaces.

04

Drive controls into the design

  • Prefer inherent safety by design where practicable.
  • Use protective measures in the device or manufacturing process next.
  • Use information for safety for residual risk that cannot be adequately controlled otherwise.
  • Define each selected measure as a testable requirement.
  • Verify implementation and effectiveness.
  • Assess whether the control introduces new hazards or changes existing risk.
  • Re-evaluate residual risk using the approved criteria.

A warning is not a convenient replacement for feasible design control. Risk specialists should challenge weak control choices and record the rationale for decisions.

05

Maintain a connected risk-control chain

HazardPotential source of harm
SequenceForeseeable events and conditions
Hazardous situationExposure to the hazard
HarmPossible injury or damage to health
ControlSelected design, protection or information measure
EvidenceImplementation and effectiveness verification

The chain should link into approved design inputs, outputs, verification and residual-risk conclusions. A risk file full of cross-references is useful only when those references resolve to controlled evidence.

06

Integrate specialist risk analyses

Electrical, mechanical, software, usability, biological, clinical, privacy and cybersecurity specialists may use different methods and terminology. The central risk process must integrate their safety conclusions, dependencies and controls. Avoid isolated “risk files” that never reconcile at system level.

In particular, connect safety and security through MTL-109 — Medical-device Cybersecurity and user interaction through MTL-110 — Usability and Human Factors.

07

Review risk at decision points

Risk review should ask whether the analysis reflects the current design and intended use, controls are implemented and effective, residual risks meet criteria, new risks have been assessed, and unresolved evidence could change the conclusion. Conduct reviews before architecture commitment, formal verification, transfer, release and significant lifecycle change—not only when the risk report needs approval.

08

Use benefit–risk analysis carefully

Benefit–risk analysis is not permission to avoid practicable controls. Use it when required after risk-control options have been applied, drawing on credible clinical benefit and residual-risk evidence. State the affected population, magnitude and probability of benefit, nature of harm, uncertainty, alternatives and supporting information. Overall residual-risk evaluation then considers the device as a whole.

09

Make the risk file learn from production and use

Define sources such as nonconformities, supplier issues, process trends, complaints, vigilance, service records, cybersecurity vulnerabilities, literature and comparable devices. Assess relevance, emerging hazards, changed probability or severity, control effectiveness and benefit–risk conclusions. Feed actions into CAPA, change control, labelling, field action and future design.

Connect this loop to MTL-127 — Post-market Support.

10

Communicate risk so people can make decisions

Use concise system views, clear assumptions and decision-focused summaries alongside detailed analyses. Escalate unacceptable risk, missing controls and material uncertainty plainly. Avoid presenting a single risk number without the hazardous sequence, harm, evidence and control context needed to interpret it.

11

Common misconceptions

“The risk manager owns all product risks.”

Risk managers own important process responsibilities; technical and business owners remain accountable for decisions and controls.

“FMEA is the risk-management file.”

FMEA is one analysis technique and may not express system hazards, hazardous situations and harms adequately.

“Low occurrence makes a severe hazard safe.”

Risk evaluation follows approved criteria and evidence; severe outcomes still demand careful control and uncertainty assessment.

REFERENCES

Authoritative starting points

KEY TAKEAWAY

Risk management is a multidisciplinary decision system—not a scoring exercise

The risk team makes hazards, assumptions, controls and evidence coherent, while accountable specialists and leaders retain ownership of the decisions.