In plain language
Risk management is how medtech teams think ahead about possible harm, reduce that harm through design and controls, and keep watching after the product is used in the real world. It is not only a spreadsheet. It is a decision process that connects product design, clinical workflow, software behavior, hardware reliability, labeling, training, and postmarket feedback.
What this page helps you decide
This page helps teams turn safety concerns into a practical lifecycle process. Risk work is not just scoring; it is the discipline of identifying hazards, reducing harm through design, verifying controls, and learning from real-world feedback.
Use it whenever a product could influence clinical action, patient understanding, data quality, device behavior, or operational response.
Lifecycle model
Practical risk process
- Identify hazards and hazardous situations.
- Estimate severity and probability.
- Apply risk controls in design, information for safety, and process controls.
- Evaluate residual risk and benefit-risk balance.
- Monitor real-world signals and update controls.
Cross-functional ownership
Safety risk is not just QA or regulatory work. Product, software, firmware, clinical, and operations teams all contribute controls and evidence.
Hazards versus hazardous situations
A hazard is a potential source of harm (for example incorrect drug dose calculation). A hazardous situation is circumstances where people, property, or the environment are exposed to that hazard. Founders should push teams to describe scenarios in plain language: who is using the device, what assumption fails, and what happens next.
Starter hazard workshop
For one workflow, write five plain-language rows before debating scoring methods. Name the user, the hazardous situation, the possible harm, the current control, and the evidence that the control works. This keeps the risk conversation grounded in reality instead of abstract severity numbers.
- What could be wrong, late, missing, confusing, inaccessible, or misinterpreted?
- Who would notice first, and how quickly?
- What design choice reduces the risk before relying on training or warnings?
- What test or field signal would show that the control is effective?
Risk controls hierarchy
Prefer inherent safety by design, then protective measures in the product, then information for safety (labeling, training), and finally process controls where still needed. If you jump to warnings without fixing design, reviewers and clinicians will notice—and residual risk may be unacceptable.
ISO 14971 and IEC 62304
Software safety class and software anomalies connect to risk: hazardous situations drive software requirements, verification depth, and release criteria. When AI components change, update both the risk file and software configuration management records. Use the requirements and risk templates together.
Usability-linked hazards
Use errors (wrong tap sequence, ignored alarms, confusing units) are safety risks. Link usability engineering files to ISO 14971 line items so formative and summative studies update the same hazard analysis the regulatory team submits.
Post-market feedback loop
Complaints, vigilance reports, and internal telemetry may reveal new hazards or ineffective controls. Define how feedback enters CAPA and whether retraining or labeling changes require regulatory action—especially for ML devices with PCCP bounds.
Official references
Curriculum page last reviewed: 2026-04-22.
Summaries are for learning only; risk management files must reflect your device and jurisdiction.
- FDA — Division of Standards and Conformity Assessment (entry point for recognized consensus standards)
- Health Canada — Medical devices (risk evidence in licensing)
Practical next step
Run a mini hazard workshop for one workflow and capture at least five rows with hazard, hazardous situation, harm, control, and evidence.
- Template or worksheet: risk matrix template.
- Glossary terms: hazard, risk control, residual risk.
- Pathway links: IEC 62304 lifecycle, Threat modeling.