Risk management and product safety

The situation

Risk management is the file most often described as complete and least often actually complete. It exists in most companies as an FMEA spreadsheet, a plan copied from a template and a report that says the residual risks are acceptable without saying against what criteria. It reaches a reviewer attached to a file that depends on it — the electrical-safety test plan, the biological evaluation, the software hazard analysis, the clinical evaluation — and the reviewer, finding the foundation thin, starts doubting everything built on it.

What goes wrong when this is handled late

Three failures account for most findings. Acceptability criteria decided after the risks were estimated, so that every risk falls just inside the line. Hazards identified from the parts list rather than from the intended use and its foreseeable misuse, so that the hazards a clinician would name first are absent. Risk controls listed but never verified in writing, so that the file claims a control exists without evidence that it works. A fourth is becoming common: software and cybersecurity risks kept in a separate document that never reconciles with the main file.

The late fix is a rewrite under notified-body time pressure. The timely fix is a review that tests the method, not just the content.

What Authentcare does

Assess. Review the risk management plan, the hazard analysis, the FMEAs and the report against ISO 14971:2019 and ISO/TR 24971:2020, and against what the MDR's general safety and performance requirements and the FDA QMSR expect of them. Test the file's method: where the acceptability criteria came from, where the hazards came from, whether each control has verification evidence, whether the benefit-risk reasoning would survive a clinician's reading.

Develop. Build or rebuild the file: the plan with criteria the manufacturer has decided; hazard identification from intended use, use environment and misuse; dFMEA, pFMEA and use-related risk analysis as tools inside that structure; software and cybersecurity risk analysis integrated rather than appended; controls, verification, residual risk, benefit-risk and the report. Build the traceability matrix that links each hazard to its controls, their verification, the labelling that discloses residual risk and the post-market signals that will monitor it.

Coordinate. Run the hazard-identification workshops with your engineers, clinicians and users. Reconcile the risk file with the electrical-safety test plan, the biological evaluation, the software lifecycle records and the post-market surveillance plan, so that the five files tell one story. Prepare the risk-management summary a reviewer expects to read first.

The chain below is the one every risk file should let a reviewer follow, and the one most do not.

What you receive

• Risk management plan with acceptability criteria the manufacturer has decided and can defend
• Hazard identification and hazard analysis, including reasonably foreseeable misuse
• Design FMEA, process FMEA and use-related risk analysis, each tied back to the hazard analysis rather than run in isolation
• Software and cybersecurity risk analysis integrated with IEC 62304 and IEC 81001-5-1 records
• Risk control implementation and verification records, cross-referenced to the verification evidence
• Residual-risk evaluation and overall benefit-risk analysis
• Risk management report and the production and post-production monitoring plan
• Traceability matrix linking hazards, controls, verification, labelling and post-market signals

Frameworks and editions

Applicability is device-specific. Which of these apply, and in what combination, depends on device type, intended purpose, classification and target market; the applicability assessment at the start of every engagement settles it in writing.

What this engagement excludes

• Deciding risk acceptability; the criteria and the decisions are the manufacturer's, documented with Authentcare's support
• Design changes that risk controls may require; recommendations are made, design is the manufacturer's
• Clinical data generation for benefit-risk; where it is needed it is scoped separately