← All modules
Module 7

ISO 14971:2019 — Risk Management for Medical Devices

Advanced90 to 120 min

A self-study walkthrough of ISO 14971:2019 for digital mental-health products: planning, hazard identification, controls, and the risk management report — all illustrated through Kova, a fictional NHS IAPT waiting-list AI companion.

Common issues: Translating ISO 14971 into a defensible risk management file for a DMHT product, including the clinical hazards a technical team will not find on its own.

Progress: 0 of 10 sections complete0%
Framing note

Worked example used throughout this module

Kova is a conversational AI companion for young people aged 16 to 25 experiencing low mood and anxiety while on an NHS IAPT waiting list. Parents and carers can access a separate dashboard showing weekly mood check-in scores.

The AI adapts its responses based on ongoing conversation history and mood check-in data. It is deployed by NHS trusts as an adjunct to the waiting list pathway.

No diagnosis is made. No treatment decisions are taken by the AI.

What ISO 14971 is and why it matters

ISO 14971:2019 is the international standard defining how manufacturers of medical devices identify, assess and control risks across the product lifecycle. It is the foundation of clinical risk management in the UK regulatory framework.

DCB0129, the NHS clinical risk management standard, embeds the ISO 14971 process. The MHRA technical file requires an ISO 14971-compliant risk management file for all device classes.

An Approved Body reviewing a Class IIa+ technical file will examine the risk management file clause by clause.

Key distinction — ISO 14971 vs DCB0129 (do not conflate the matrices)

ISO 14971 and DCB0129 are not interchangeable: a 'score 12' under ISO 14971's multiplied scheme has no equivalent in DCB0129's categorical 1–5 scheme. For a DMHT product pursuing both MHRA certification and NHS procurement, the practical approach is one hazard log with two parallel columns: ISO 14971 numeric score for the Approved Body, and DCB0129 categorical risk level for the NHS Clinical Risk Management File.

Sequencing of mitigations is identical; only the scoring presentation differs.

ISO 14971DCB0129
What it isInternational medical device risk management standard.NHS clinical safety standard for health IT.
Legal basisRequired by the MHRA technical file for all device classes; reviewed clause by clause by an Approved Body at Class IIa+.Required for NHS deployment via DTAC and the Clinical Safety Case Report.
Scoring scheme5×5 grid where Likelihood (1–5) is multiplied by Severity (1–5) to produce a numeric risk score from 1 to 25. The manufacturer defines the Acceptable / ALARP / Unacceptable bands in the Risk Management Plan.Each Likelihood × Severity cell maps directly to a single categorical Risk Level from 1 (Very Low) to 5 (Very High) — no multiplied 1–25 score. Most NHS organisations treat Risk Level ≤2 as acceptable, 3 as requiring further mitigation, and 4–5 as unacceptable for release.
Output documentISO 14971 Risk Management Report (in the MHRA technical file).DCB0129 Clinical Safety Case Report (in the DTAC submission).
Who reviews itApproved Body (Class IIa+) as part of conformity assessment.NHS commissioning / DTAC reviewers as part of procurement.
Cost note

The standard itself must be purchased from BSI (~£180).

Risk management planning (clause 4)

Before any risk assessment begins, the manufacturer must produce a Risk Management Plan (RMP). It defines scope, methods, criteria for risk acceptability, and responsibilities.

This sequencing is mandatory, not advisory. The acceptability criteria are the most critical element: acceptable, ALARP (acceptable as low as reasonably practicable, with explicit justification), and unacceptable (controls mandatory before release).

For DMHT products serving vulnerable populations, the criteria should be tighter than a generic medical device matrix because harms in psychiatric populations are often irreversible.

Practical deliverable
Practical deliverable

A 3–5 page document containing: scope statement, risk acceptability matrix (5×5), likelihood scale definitions, severity scale definitions, named Clinical Safety Officer and responsibilities, review frequency, and reference to the post-market surveillance plan.

Likelihood scale
  • 1 Improbable — unlikely to occur during the product lifetime.
  • 2 Remote — could occur but rarely.
  • 3 Occasional — likely to occur sometimes.
  • 4 Probable — likely to occur frequently.
  • 5 Frequent — occurs regularly across the user population.
Severity scale
  • 1 Negligible — no injury, no clinical consequence.
  • 2 Minor — temporary distress, no lasting effect.
  • 3 Serious — significant psychological harm, temporary.
  • 4 Critical — serious lasting psychological harm, or significant delay in appropriate clinical care.
  • 5 Catastrophic — death, serious self-harm, or irreversible psychological harm.
Kova worked example
Worked Kova example — acceptability rule (illustrative internal company policy, not an MHRA or ISO requirement)

The bands below are an illustrative internal policy choice for the fictional Kova product. ISO 14971 does not prescribe specific numeric thresholds — manufacturers must define and justify their own bands in the RMP, calibrated to the intended population and harm profile.

  • Unacceptable — any cell with Severity 4 or 5 regardless of likelihood (reflecting the irreversibility of serious psychiatric harm in a young, vulnerable population), and any other score above 12.
  • ALARP — scores 6 to 12 excluding Severity 4 and 5 cells (controls must be applied and benefit explicitly justified).
  • Acceptable — scores below 6 excluding Severity 4 and 5 cells.
  • Clinical sign-off: appointed Clinical Safety Officer (DCB0129/0160 certified, GMC-registered psychiatrist).
  • Reviewed before each release and after any serious incident. A different manufacturer with a different population (for example a wellbeing journaling tool for general adults) could justifiably set looser bands; the requirement is that the bands are documented, justified, and consistently applied — not that they match this example.

Intended use and reasonably foreseeable misuse (clause 5.2)

Intended use is what the manufacturer designs the product to do, for whom, and in what context. Reasonably foreseeable misuse is use of the product in ways not intended but predictable given the design, the user population and the deployment environment.

For DMHT, misuse is particularly important because products are often used without clinical supervision, by people in distress, in contexts the manufacturer cannot control. Misuse does not require malicious intent.

Practical deliverable
Practical deliverable

A structured table with two sections. Intended use: use description, intended user, intended use environment, intended clinical context.

Foreseeable misuse: misuse description, why it is foreseeable, potential harm.

Kova worked example
Worked Kova example — intended use

AI-supported mood monitoring and conversational support for young people aged 16 to 25 on an NHS IAPT waiting list. Primary user: young person.

Secondary user: parent or carer (dashboard access only). Environment: home and community, smartphone or web browser.

Clinical context: adjunct to waiting list, not a standalone intervention.

Kova worked example
Worked Kova example — foreseeable misuse
  • Use during an acute mental health crisis or active suicidal ideation (contraindicated but foreseeable in this population). Harm: delayed access to emergency clinical intervention.
  • Reliance on Kova instead of attending an IAPT appointment when one becomes available. Harm: treatment abandonment, condition deterioration.
  • Parent accesses conversation history without consent by sharing login credentials. Harm: breach of confidentiality, damaged therapeutic relationship, disengagement from support.
  • Young person uses Kova to seek advice about GP-prescribed medication. Harm: incorrect medication management based on AI output outside its scope.

Hazard identification (clause 5.4)

A hazard is a potential source of harm; a hazardous situation exposes someone to it; harm is the resulting injury or psychological damage. The standard requires identification of all foreseeable hazards.

For DMHT products the most significant hazards are not technical failures — they arise from the product behaving exactly as intended in a vulnerable population. A conversational AI that successfully engages a young person in daily check-ins may be creating a dependency pathway.

These hazards require clinical expertise to identify; a technical team working alone will miss them.

The hazard log — standard columns
  • Hazard ID, hazard description, hazardous situation, potential harm.
  • Affected population.
  • Likelihood pre-control (1–5), severity (1–5), risk score.
  • Design controls.
  • Residual likelihood, residual severity, residual risk score.
  • Risk acceptability and clinical rationale.
Kova worked example
Worked Kova hazard log entry — K-003
Hazard ID
K-003
Hazard description
Conversational AI engagement feature with no session boundaries.
Hazardous situation
Young person with low mood and social isolation engages with Kova as primary source of social interaction, progressively reducing engagement with human relationships.
Potential harm
Pathological dependency on AI companion, social withdrawal, deterioration of real-world support network, delayed engagement with human therapeutic support when an IAPT appointment becomes available.
Affected population
Young people aged 16 to 25 with low mood and social isolation, particularly those with limited existing support.
Likelihood pre-control
3
Severity
4
Risk score
12 (ALARP)
Residual likelihood
2
Residual severity
3
Residual risk score
6 (acceptable)
Clinical rationale
Parasocial-dependency pathways are a foreseeable harm in socially isolated young people with low mood; controls reduce intensity of the dependency pathway and maintain the connection to the clinical pathway.
Design controls
  • Session time limits with gentle prompts to take breaks.
  • Weekly summary message encouraging connection with real-world support.
  • Kova explicitly redirects social-companionship-seeking toward human relationships.
  • IAPT appointment reminder integrated.

Risk estimation and evaluation (clauses 5.5 and 6)

Risk estimation assigns likelihood and severity to each identified hazard. Risk evaluation compares the estimated risk against the acceptability criteria in the RMP.

For DMHT products published incidence data is often unavailable for novel harm pathways — clinical judgement is the primary and legitimate input. A practising psychiatrist with current clinical experience of the target population is better placed to estimate the likelihood of a clinical harm pathway than any algorithm or database.

Severity is amplified by reversibility: a harm that delays appropriate clinical intervention in a young person at risk of serious self-harm should be assigned maximum severity regardless of probability.

Practical deliverable
Practical deliverable

Completed likelihood and severity ratings in the hazard log, with documented clinical rationale. "Assessed by the clinical team" is not acceptable rationale — the rationale must be specific enough that an Approved Body reviewer can assess whether the estimation is clinically justified.

Kova worked example
Worked Kova example — rationale for K-003

Likelihood pre-control: 3. Social isolation is prevalent in the intended population; the conversational AI format is specifically designed to be engaging, increasing likelihood of repeated use; literature on parasocial relationships in adolescents and young adults supports the plausibility of dependency development.

Severity: 4. Progressive social withdrawal in a young person with low mood constitutes lasting psychological harm and delays access to human therapeutic support.

The harm is potentially sustained over months if not detected.

Risk controls and residual risk (clauses 7 and 8)

For each unacceptable risk, controls must be applied in priority order: (1) inherently safe design — remove the hazard at source; (2) protective measures in the product — reduce likelihood or severity through design; (3) information for safety — warnings, contraindications, instructions. Controls at the first level are always preferable.

A warning as the sole control for a high-severity hazard is almost never acceptable. After controls are applied, residual risk is re-estimated and re-evaluated.

The overall residual risk must be judged acceptable in the context of intended clinical benefit — this is the benefit-risk determination, a clinical judgement only a registered clinician with relevant expertise can sign.

Kova worked example
Worked Kova example — controls for K-003
  • Level 1 (inherently safe design): the conversational format is intrinsic to the product, but session boundaries are a design choice and are introduced.
  • Level 2 (protective measures): weekly summary prompting connection with real-world support; Kova actively redirects companionship-seeking toward human relationships; IAPT appointment reminder integrated.
  • Level 3 (information for safety): onboarding states Kova is not a replacement for human relationships or clinical support; contraindication documented for users with severe social isolation as primary presenting problem.
  • New hazards introduced: none. Session time limits assessed for frustration / disengagement and judged acceptable given the clinical benefit of boundary-setting.
Why warnings rarely suffice

Information for safety is the weakest tier. ISO 14971 does not permit the manufacturer to bypass higher-level controls on cost grounds alone.

For a Severity 4 hazard in a vulnerable population, an Approved Body will expect strong justification for any decision to rely on a warning as the primary control.

The risk management report (clause 9)

Before the device is released, the manufacturer must produce a Risk Management Report confirming that the RMP has been implemented, the overall residual risk is acceptable, and post-market surveillance is in place. The report is signed by the appointed Clinical Safety Officer and reviewed by the Approved Body at Class IIa+.

It is not a hazard log summary — it is a formal declaration that the process is complete and the product is safe enough for its intended use with its intended population. It is a living document: updated whenever significant post-market information could affect the assessment, and reviewed before each new release.

Practical deliverable
Practical deliverable

A 2–4 page document containing: confirmation that the RMP has been implemented, summary of the risk estimation methodology, statement of overall residual risk acceptability, benefit-risk determination, reference to the PMS plan, and Clinical Safety Officer signature with date, GMC registration number, and DCB0129 certification reference.

Kova worked example
Worked Kova example — extract from the report

"Following completion of the risk management process for Kova v1.0, I confirm: the RMP has been fully implemented; all identified hazards have been assessed, controlled where required, and re-evaluated; the overall residual risk of Kova in its intended use as an adjunct to NHS IAPT waiting-list support for young people aged 16 to 25 is acceptable in the context of its intended clinical benefit; a post-market surveillance plan is in place with defined indicators, thresholds and escalation criteria. The clinical benefit of accessible, responsive support during NHS waiting periods is substantial given current waiting times of 6 to 18 months and the documented deterioration risk during this period."

Signed by the appointed Clinical Safety Officer (DCB0129/0160 certified, GMC-registered psychiatrist).

When the report must be reviewed
  • Before each new product release or major feature change.
  • Following any serious incident reportable to the MHRA.
  • When new post-market information could affect the risk assessment (new clinical literature, complaint patterns, etc.).

Benefit-risk determination — what 'acceptable' means in DMHT

The benefit-risk determination is the clinical judgement at the heart of the Risk Management Report. It cannot be delegated to a process: the appointed Clinical Safety Officer must be able to articulate, in writing, why the residual risk profile is proportionate to the intended clinical benefit for the intended population.

ISO 14971 (clause 8) and ISO/TR 24971 both expect this to be specific, not generic. 'The benefits outweigh the risks' is not a benefit-risk determination — it is a conclusion without working.

For a DMHT product on an NHS pathway, the determination should explicitly address the counterfactual (what happens to this population without the product, including current waiting times and documented deterioration risk during the waiting period), the population-specific harm profile, and the residual risks that remain after controls.

What an Approved Body expects to see
  • Population-specific clinical benefit, quantified where possible (e.g. PHQ-9 / GAD-7 reduction, IAPT engagement rate, time-to-treatment reduction).
  • Counterfactual statement: what the standard of care is today for this population, including NHS waiting time evidence.
  • Residual risks listed by category and severity, with the design controls that brought them to that level.
  • An explicit statement that no individual residual risk is unacceptable, and that the aggregate residual risk is proportionate to the benefit.
  • Subgroup considerations: where benefit or risk varies across user subgroups (age, comorbidity, ethnicity, language), the determination must address whether the benefit-risk balance holds for each.
Why 'no harm reported to date' is not a benefit-risk argument

Absence of post-market complaints is not evidence of acceptable residual risk, particularly for DMHT products where harm pathways (parasocial dependency, delayed help-seeking, subgroup miscalibration) are slow-onset and under-reported. The benefit-risk determination must be defensible on the underlying risk model, not on the post-market silence.

Post-market surveillance for evolving AI/ML models

ISO 14971 treats PMS as a closed loop into the risk file: real-world data must be collected, analysed, and used to re-evaluate residual risk. For static medical devices that loop runs on an annual cadence (PSUR).

For AI/ML products with adaptive or periodically-retrained models, the cadence is much tighter — performance and risk can drift between two annual reports. This module specifies what the PMS plan must do additionally for an evolving model, beyond the standard PMS plan covered in section 7.

AAMI TIR34971 is the application guide; the requirements below are increasingly expected by UK Approved Bodies at Class IIa+ even though no UK regulation yet mandates them by name.

Performance boundaries — define them in the Intended Purpose

The Intended Purpose statement must define the performance boundary within which the manufacturer guarantees the model's behaviour: input distribution (population, language, device, clinical context), acceptable performance ranges (sensitivity, specificity, calibration, subgroup parity thresholds), and the conditions under which performance is no longer guaranteed. PMS then monitors against this boundary.

A model that drifts outside its declared boundary is a reportable change, not a normal-operations event.

Drift monitoring — minimum signals for a DMHT product
  • Input drift: changes in input distribution vs the training population (age, presenting complaint mix, language patterns, device mix).
  • Output drift: changes in output distribution (alert rates, classification proportions, recommendation mix).
  • Performance drift: change in primary clinical metric (e.g. agreement with clinician, calibration error) measured against a held-out reference set or active labelling.
  • Subgroup parity drift: each of the above broken down by the subgroups identified in the AAMI TIR34971 risk file. A model whose overall performance is stable but which has degraded in a single subgroup is the most common AI/ML post-market failure mode for DMHT.
  • Safety-event signals: user-reported harms, abandonment patterns, escalations to crisis services, complaint clusters.
Thresholds and escalation — wire them into the PMS plan, not the dashboard

Each drift signal needs a defined threshold (warning level, action level) and a named escalation path. 'Clinical Safety Officer reviews monthly' is not a control; 'sensitivity for users aged 16–18 drops more than 5 percentage points → automatic Clinical Safety Officer notification within 24 hours → model rollback or freeze pending review within 5 working days' is.

Approved Bodies are increasingly auditing these thresholds for specificity at PSUR review.

PCCP routing — does this update stay inside the existing conformity assessment?

Every model update must be routed through the Predetermined Change Control Plan (covered in detail in the AAMI TIR34971 module). The PMS process is the trigger: post-market data identifies the need for change; the PCCP determines whether the change is pre-approved, requires internal Clinical Safety Officer sign-off, requires formal change-control assessment, or requires a fresh conformity assessment with the Approved Body.

Without a PCCP, every meaningful model update is theoretically a fresh conformity assessment — operationally untenable for any product retraining more than once a year.

Cadence — PSUR is necessary but not sufficient for evolving models

The annual PSUR remains mandatory at Class IIa+. For products with adaptive or periodically-retrained models the manufacturer should also run an internal model-performance review on a much tighter cadence (monthly is typical for production deployments), with full risk-file update before any model change is deployed.

The PSUR then aggregates these reviews for the Approved Body.

Kova worked example
Worked Kova example — drift triggers
  • Conversation-volume drift: weekly engagement per user up more than 25% vs baseline → review for dependency pathway signal (links to hazard K-003).
  • Subgroup performance drift: empathic-response rating from 16–18-year-old users drops more than 0.5 on the internal rubric vs the 19–25 cohort for two consecutive weeks → CSO notification, model frozen at last validated checkpoint pending review.
  • Crisis-signposting acceptance rate drift: drop of more than 10 percentage points vs the prior quarter → immediate CSO review of crisis-signposting copy and routing.

Resources

Free
Johner Institute — ISO 14971 guide

Covers the full clause-by-clause requirements and is the most practically useful free companion to this module; best read alongside sections 3 through 8.

Open guide
ISO/TR 24971

The official application guidance for ISO 14971; addresses benefit-risk determination and ALARP justification in more depth than the standard itself, relevant to sections 8 and 9.

Open overview
Paid
BSI — BS EN ISO 14971:2020

The standard itself must be purchased before submitting a technical file to an Approved Body; the current version is BS EN ISO 14971:2020.

Purchase standard
Next module

AAMI TIR34971 extends ISO 14971 for AI/ML medical devices. If your product has a conversational AI, an adaptive recommendation engine, or a predictive algorithm, that module is next.

Exercises

Form your own view first. Reveal the reference answer to compare reasoning.

Exercise 1 — ISO 14971 vs DCB0129

What is the relationship between ISO 14971 and DCB0129, and why might a DMHT product need both?

Which statement is correct?
Pick an option for each question to compare against the reference answer.

Exercise 2 — Score-only acceptability for a DMHT product

A manufacturer sets the threshold at score ≤10 = acceptable, >10 = unacceptable. A hazard is Likelihood 1, Severity 5 (score 5) and is classified as acceptable. Defensible for a DMHT product serving young people?

Verdict?
Pick an option for each question to compare against the reference answer.

Exercise 3 — Documenting only realised hazards

A developer says hazards should only be documented if they have already occurred in the product or in a comparable product. Correct under ISO 14971?

Correct?
Pick an option for each question to compare against the reference answer.

Exercise 4 — "No incidents in 6 months" likelihood

A manufacturer estimates likelihood as 1 (improbable) for all hazards because no serious incidents have been reported six months after launch. Valid?

Valid estimation approach?
Pick an option for each question to compare against the reference answer.

Exercise 5 — Warning as the sole control for a Severity 4 hazard

A manufacturer implements a user-facing warning as the only control for a Severity 4 hazard, citing redesign cost. Acceptable under ISO 14971?

Acceptable?
Pick an option for each question to compare against the reference answer.

Educational resource. Not formal regulatory or legal advice.