Risk Management Specialist

An FMEA for a classification algorithm follows the same structure as hardware FMEA, but the failure modes are functional rather than physical. Here's how to build it out for your ECG classification module.

FMEA Structure

Each row captures one failure mode using this column set:

FMEA Table: ECG Classification Module

Interpreting the Ratings

Row 1 (False Negative AFib) — RPN 45 is your highest priority. The severity is maximal (S5 — potential stroke or death from missed AFib) and it is moderately detectable only if the clinician reviews the raw trace. This row will require additional controls: for example, a secondary review trigger when confidence score is below threshold, or a mandatory "signal quality insufficient" output state that prevents classification rather than guessing.

Row 5 (Memory Overflow) — RPN 10 has low RPN but S5 severity. Watch for this pattern — low RPN with high severity often means you have good detection controls in place, but the severity justifies documenting those controls explicitly as risk mitigations.

Setting Severity for Diagnostic Software

For SaMD, severity is driven by clinical decision impact:

• S5: Output directly informs a high-stakes acute decision (e.g., shock/no-shock, emergency admission) with no secondary check
• S4: Output influences treatment planning; a wrong result leads to delayed or inappropriate treatment
• S3: Output is one input among several; clinical judgment provides a backstop
• S2: Output is advisory; no direct treatment consequence
• S1: Cosmetic or administrative impact only

Your cardiac arrhythmia classifier sits at S4–S5 for most failure modes because downstream clinical action is likely based on the output.

dFMEA vs. pFMEA

Design FMEA (dFMEA): What you are building here. Analyzes failure modes inherent to the product design — algorithm behavior, software architecture, input handling. This lives in your Risk Management File and is updated as the design evolves.

Process FMEA (pFMEA): Analyzes failures in your manufacturing or deployment process — incorrect build deployed, wrong model version installed, incorrect configuration pushed to production environment. For SaMD, pFMEA covers your CI/CD pipeline, release verification steps, and clinical site deployment process.

Both are required for a complete risk management system. Start with dFMEA for the algorithm module, then address pFMEA when you define your deployment and update process.

Next Steps

Once your FMEA rows are populated, link each high-RPN row to a specific risk control in your design (a requirement, a test, a constraint). The control is only a control if it's traceable — a general statement that "we validate the algorithm" does not close the loop.

Residual risk documentation is one of the most scrutinized sections of a technical file in a Notified Body review. Here's how to do it correctly.

Residual Risk vs. Initial Risk

Initial risk is the estimated risk before any controls are applied — the raw S × P estimate you assigned in your hazard log when you first identified the hazard.

Residual risk is the risk that remains after all implemented controls have been applied. For each control, you re-estimate the probability (and sometimes severity, if the control can limit harm extent) and record the post-control risk level.

The key principle: residual risk must be documented for every hazard, not just the ones that started unacceptable. A hazard that was initially broadly acceptable still needs a residual risk statement confirming it remains acceptable after design evolution.

Documenting Residual Risk: Row by Row

For each hazard in your log, add these columns after your controls are recorded:

For your false-negative AFib row: initial risk was S5/P3 (unacceptable). After implementing a confidence threshold gate, signal quality minimum, and clinician review workflow, you might re-rate probability to P1 (rare — the combination of good signal quality check and low model confidence detection catches most cases). Residual risk becomes S5/P1 — which most risk frameworks treat as broadly acceptable or ALARP for a device providing significant clinical benefit.

Benefit-Risk Analysis

ISO 14971 Clause 9 requires that when residual risk remains after all practicable controls, you justify acceptance by demonstrating that clinical benefit outweighs the risk.

A benefit-risk statement has three parts:

1. Clinical benefit characterization

• What clinical problem does the device address?
• What is the benefit to patients and clinicians?
• What is the magnitude and likelihood of that benefit?

Example: "The device enables timely detection of paroxysmal AFib in outpatient settings where continuous ECG monitoring is not feasible. Early detection reduces stroke incidence by an estimated 30–40% through timely anticoagulation initiation (per published clinical literature)."

2. Residual risk summary

• Quantified (or bounded) statement of residual risk for all significant hazards
• Reference to your controlled risk levels

3. Comparative conclusion

• The benefit must clearly and explicitly outweigh the residual risk
• This is a judgment, but it must be justified with evidence

Do not make this vague. "The benefits outweigh the risks" is not acceptable without supporting data. Cite published clinical evidence, your clinical validation study results, or comparator device performance where available.

Risk Management Report Requirements

The Risk Management Report (RMR) is required by ISO 14971 Clause 10 before commercial release. It must address:

• Confirmation that the Risk Management Plan was implemented (reference each plan requirement and its fulfillment)
• Summary of all identified hazards and initial risk levels
• Summary of all risk controls implemented
• All residual risks and their acceptability status
• Overall benefit-risk conclusion
• Statement that the methods and criteria in the Risk Management Plan were met

The RMR is a summary document — it references your hazard log and FMEA rather than repeating them. It should be short enough that a reviewer can read it in 30 minutes and follow every claim back to evidence.

The Auditor Question: How Did You Determine Acceptability Criteria?

This is the first question a Notified Body technical reviewer will ask, because everything downstream depends on it.

Your answer must be in your Risk Management Plan, documented before you started risk analysis. Acceptable responses:

• "We used a published industry standard as a reference — IEC 62304 annex, MDCG guidance on SaMD, or published risk acceptance matrices from comparable devices in literature"
• "We consulted with clinical advisors to establish harm thresholds appropriate for the clinical context"
• "Our criteria align with our intended use risk classification under IMDRF SaMD framework (Class III — high risk)"

What auditors do not accept: criteria that were set retroactively to make your residual risks pass, or criteria with no documented rationale.

Evidence Required for Notified Body Review

The clinical validation data is what makes your probability ratings credible. If you claim P1 for false negative AFib, you need performance data showing your false negative rate on a representative clinical population. Without that link, your residual risk acceptance is unsupported.