Module 2 · MHRA SaMD Classification
A self-study guide to MHRA SaMD classification
16 primary sources, standards, and guidance documents — plus interactive case studies for practising classification judgement. Track your progress as you go.
Important — read first
This guide is educational content for digital health founders, regulatory advisors and Clinical Safety Officers. It is not regulatory advice, not a substitute for an Approved Body opinion, and not a substitute for engagement with the MHRA. UK SaMD law and guidance is changing — always verify against the current MHRA, NHS England and BSI publications before relying on anything here for a real classification decision. Worked examples (notably “Kova”) are fictional illustrative scenarios; figures, thresholds and acceptability bands shown are internal company policy choices for the example, not MHRA or ISO requirements.
0 of 16 completed
0%
1
Foundation: the regulatory architecture
Read in order. These establish the legal and conceptual framework everything else depends on.UK MDR 2002 (SI 2002 No 618) — Part II and Annex IX classification rules
The primary legislation. Focus on the general provisions and the Annex IX classification rules, specifically Rule 10a (active diagnostic software), Rule 11, and Rule 12. You do not need every article.
Primary legislation60 to 90 min
Key question: what makes something a medical device under UK law, and which classification rules apply specifically to software?
MHRA DMHT guidance v1.2 (July 2025)
The most important document for anyone classifying a digital mental health product in the UK. Read it cover to cover at least once. The two-gate qualification test, the functionality categories A through G, and the worked examples are the core reference for every classification decision.
Core MHRA guidance3 to 4 hours
Key question: which A-G functionality category does a given product fall into, and does it meet gate one (intended to influence clinical management) and gate two (SaMD under UK MDR)?
MHRA software borderline and classification guidance
Broader than DMHT. Covers all software classification, including products on the borderline between wellness and SaMD. The worked examples are essential reading for developing classification judgement.
Classification guidance2 hours
Key question: where is the line between a wellness app and a SaMD, and what specific claims or functions push a product across it?
IMDRF SaMD N12: definition and framework
Short (17 pages) and foundational. The IMDRF 3x3 risk matrix classifies SaMD by state of healthcare situation and significance of information provided. Referenced in UK guidance and used by Approved Bodies globally.
International framework45 min
Key question: how does the IMDRF 3x3 matrix map onto UK MDR classification, and where do they diverge?
2
Clinical safety standards
Your core professional territory. Consolidate and formalise what you already know.DCB0129 standard and implementation guidance
The mandatory NHS clinical risk management standard for manufacturers. Read the standard itself and the implementation guidance. The hazard log, CRMP, and CSCR structure flows directly from this document.
NHS mandatory standard2 to 3 hours
Key question: what are the mandatory deliverables, what does the appointed Clinical Safety Officer specifically sign off, and what constitutes an acceptable residual risk?
ISO 14971:2019 — risk management for medical devices
The international standard underlying both DCB0129 and the MHRA technical file requirements. Understand the full risk management process: hazard identification, risk estimation, risk evaluation, controls, and residual risk. The standard requires purchase but extensive free guidance exists.
ISO standard3 to 4 hours
Key question: how does ALARP apply in practice, and what is the distinction between risk estimation, risk evaluation, and risk control?
AAMI TIR34971 — ISO 14971 applied to machine learning
Essential for any AI or ML product. Extends ISO 14971 to cover ML-specific risks: data drift, model failure modes, opacity of decision-making. Directly relevant to AI chatbots and DMHT products more broadly.
AI/ML standard2 hours
Key question: how do you identify and document foreseeable failure modes in an AI model that you cannot fully inspect?
Going deeper
Worked examples and AI/ML application
Two dedicated modules apply ISO 14971 and AAMI TIR34971 to digital mental-health products — practical hazard-log guidance, worked Kova examples, and the AI/ML extensions Approved Bodies now expect — in the Advanced Modules.
3
Clinical evidence and conformity assessment
For Class IIa and above. This is where classification decisions carry the most consequence.UK MDR 2002 Annex X and Schedule 2A — clinical evidence requirements
The legal basis for what clinical evidence is required and what forms it can take. Schedule 2A modifies Annex X for the UK post-Brexit context. Understand the distinction between clinical evidence and clinical investigation.
Primary legislation45 min
Key question: when is a prospective clinical investigation required, and when is literature-based clinical evaluation sufficient?
MEDDEV 2.7/1 rev 4 — clinical evaluation guidance
The EU guidance that UK practice closely follows for clinical evaluation reports. Defines the CER structure, equivalence assessment, and what state-of-the-art assessment means in practice. Not UK law but accepted by UK Approved Bodies.
EU guidance (accepted in UK)3 hours
Key question: what are the specific requirements for demonstrating equivalence, and how do you structure a CER for a novel SaMD with no direct comparator?
MHRA conformity assessment and UKCA mark guidance
Explains which conformity assessment route applies to each device class, how UK Approved Bodies work, and the UKCA marking process. Essential for understanding timeline and cost implications of a given classification.
MHRA guidance1 hour
Key question: what does an Approved Body actually review at each class, and what triggers a full QMS audit versus a design dossier examination?
NHS DTAC framework documentation
The procurement-facing framework that wraps DCB0129 plus data protection, cybersecurity, and interoperability. Understanding how DTAC relates to MHRA classification is essential for mapping the full pathway to NHS deployment.
NHS framework1 to 2 hours
Key question: what is the relationship between DTAC, DCB0129, and MHRA SaMD classification: which is required for what, and in what order?
4
AI, children's code, and emerging regulation
Directly relevant to DMHT products and the frameworks emerging around them.EU AI Act — Annex III and Article 6 (high-risk AI systems)
Not UK law but increasingly referenced by clients and Approved Bodies. AI systems intended to influence clinical decisions in health fall under high-risk classification. The overlap with SaMD regulation is directly relevant to AI chatbot and DMHT products.
EU regulation (informational)2 hours
Key question: which AI systems in digital mental health fall under EU AI Act high-risk classification, and how does this interact with CE and UKCA marking obligations?
ICO Age Appropriate Design Code (Children's Code)
Mandatory for any product likely to be accessed by under-18s. 15 standards covering data minimisation, profiling, and nudge techniques. Standard 13 on nudge techniques is the most significant for DMHT.
ICO mandatory code2 hours
Key question: which of the 15 standards create the highest risk exposure for a digital mental health product targeting or foreseeably accessed by children?
MHRA AI Airlock for DMHT (Planned, in development)
Announced November 2025: MHRA and NICE secured £2m from Wellcome to establish a digital mental health technology AI Airlock — a regulatory sandbox specifically for AI-enabled DMHT products, separate from the broader AI Airlock programme (which covers diagnostics, clinical note-taking, and other AI medical devices). It will be a pre-deployment assessment pathway letting developers test AI mental health tools with MHRA, in a controlled environment with regulatory oversight, before wider NHS roll-out; outputs will inform future MHRA guidance on AI in mental health applications. Launch date not yet announced — expected mid-to-late 2026 based on the Phase 2 reporting timeline (Summer 2026). Eligibility criteria, application process, assessment scope, required documentation, cost, and whether participation is mandatory or voluntary are all not yet published. Monitor the MHRA DMHT collection page; this entry will be updated when the call opens.
MHRA programme30 min
Key question: what does the MHRA assess in the AI Airlock, and what documentation would a product need before applying?
MHRA recorded webinars — DMHT regulation series
Watching two or three MHRA webinars gives you a sense of how the regulator frames classification questions in practice, which differs from reading the guidance text. The gap between the written guidance and the regulator's live reasoning is where classification judgement lives.
Video3 to 4 hours across sessions
Key question: what worked examples does the MHRA use to illustrate the SaMD boundary, and how do they map onto real DMHT products on the market today?
MHRA DMHT guidance — full PDF (device characterisation, qualification, classification)
The complete published PDF of the DMHT guidance. Useful as a single offline reference once you have read the web version. Worth a second pass with the worked examples in front of you.
Core MHRA guidanceReference
Key question: which worked examples in the PDF most closely resemble the DMHT products you are trying to classify?
Reference
Common classification pitfalls for DMHT and AI tools
Pitfalls we see most often in pre-submission reviews. Each one shifts a product's likely classification — usually upwards — or invalidates the underlying assessment.
- Treating disclaimers as classification controls. A “not a medical device” or “not for diagnosis” disclaimer does not change classification if the intended purpose, claims, marketing or product mechanics point to a medical purpose. Intended purpose is assessed from the totality of evidence, not the disclaimer.
- Treating clinician-in-the-loop as a classification reduction. Human review is a residual-risk control in the hazard log, not a downgrade mechanism. Rule 10a / Rule 11 ask what the output could directly cause if acted on; clinician oversight reduces likelihood, not severity.
- Conflating wellness framing with regulatory scope. Marketing a product as “wellbeing” does not exempt it from the medical device rules when the actual mechanism diagnoses, monitors or treats a condition. The MHRA assesses function, not category language.
- Bundling a Class I module with a Class IIa+ module without separation. The whole product takes the highest-risk classification. Where the modules are genuinely independent, see the Multi-Modular Minefield module for the separation patterns Approved Bodies accept.
- Using only Rule 10a for a dual-market product. UKCA and CE classifications must be assessed independently. Rule 11 + MDCG 2019-11 will frequently push the EU outcome above the UK Rule 10a outcome.
- Static intended purpose for an adaptive AI/ML product. If the model adapts or is periodically retrained, the intended purpose must define the performance boundary within which the manufacturer guarantees behaviour, and a Predetermined Change Control Plan (PCCP) must define which changes stay inside the existing conformity assessment vs trigger a new one. Approved Bodies increasingly expect this at Class IIa+.
- Classifying on representative-user performance only. Subgroup performance (age, ethnicity, comorbidity, language) is a foreseeable harm pathway for DMHT and a frequent post-market surveillance failure. AAMI TIR34971 expects subgroup validation as part of the risk file, not as a post-launch nice-to-have.
- Crisis signposting treated as a classification floor. Signposting to a crisis line is a Level-3 (information-for-safety) control, not a reason to assume a function cannot cause serious harm. Rule 11 is severity-based; the worst foreseeable incorrect output still drives the class.
These pitfalls reflect common patterns in pre-market reviews. Each product is assessed on its own facts — treat this as a checklist for self-review, not a determinative test.
Progress is stored locally in your browser and not transmitted anywhere. Clearing your browser data will reset it. This resource is provided for informational and educational purposes; always verify against current MHRA and NHS England publications.