Exercise 1 — ISO 14971 vs DCB0129
What is the relationship between ISO 14971 and DCB0129, and why might a DMHT product need both?
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.
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.
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.
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 14971 | DCB0129 | |
|---|---|---|
| What it is | International medical device risk management standard. | NHS clinical safety standard for health IT. |
| Legal basis | Required 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 scheme | 5×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 document | ISO 14971 Risk Management Report (in the MHRA technical file). | DCB0129 Clinical Safety Case Report (in the DTAC submission). |
| Who reviews it | Approved Body (Class IIa+) as part of conformity assessment. | NHS commissioning / DTAC reviewers as part of procurement. |
The standard itself must be purchased from BSI (~£180).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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).
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.
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.
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.
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.
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.
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.
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.
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 →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 →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 →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.
Form your own view first. Reveal the reference answer to compare reasoning.
What is the relationship between ISO 14971 and DCB0129, and why might a DMHT product need both?
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?
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?
A manufacturer estimates likelihood as 1 (improbable) for all hazards because no serious incidents have been reported six months after launch. Valid?
A manufacturer implements a user-facing warning as the only control for a Severity 4 hazard, citing redesign cost. Acceptable under ISO 14971?
Educational resource. Not formal regulatory or legal advice.