Digital Mental Health Product Regulation in the UK: A Founder's Map

What you actually need to ship a clinically safe, NHS-ready digital mental health product. MHRA, DTAC, DCB0129, NICE ESF, and UKCA marking, in plain English.

Key Takeaways

Building a digital mental health product in the UK looks simple from the outside. Build the app, run a pilot, sell to the NHS or to private clinics. The reality is that you are entering one of the most heavily regulated software markets in Europe, with overlapping requirements from the MHRA, NHS England, NICE, and the ICO. Founders who treat regulation as a launch problem rather than a design problem usually rebuild the product twice.

This guide maps the four regulatory frameworks every UK digital mental health builder needs to understand: MHRA medical device classification, DCB0129 clinical safety, the NHS Digital Technology Assessment Criteria, and the NICE Evidence Standards Framework. It also covers UKCA marking and how the recent MHRA guidance on digital mental health technologies changes the picture.

Step 1: Is Your Product a Medical Device?

The first question every founder must answer is whether the MHRA considers their product a medical device. The answer turns on intended purpose. If your product is intended to diagnose, prevent, monitor, predict, treat, or alleviate a mental health condition, it is a medical device under regulation 2 of the UK Medical Devices Regulations 2002.

In June 2025 the MHRA published specific guidance for digital mental health technologies, alongside its broader guidance on software and AI as a medical device. The new guidance gives worked examples for chatbot therapy, mood trackers, CBT delivery apps, and AI screening tools. It is the single most useful document UK mental health founders can read.

The wellness exemption is narrower than most founders think. A meditation timer with no medical claim is not a device. A meditation app that promises to reduce symptoms of generalised anxiety disorder almost certainly is. If in doubt, write down your intended purpose statement and test it against the MHRA examples. If the language drifts towards clinical outcomes, you are in scope.

Step 2: Classify Your Device Risk Class

The UK currently operates under the Medical Devices Regulations 2002, which mirrors the EU MDD framework, with transition to the new UK MDR underway. Software is classified using rule 11 in most cases. Under MDR rule 11, software intended to provide information used for decisions with diagnostic or therapeutic purposes is at minimum Class IIa, rising to Class IIb or III if those decisions could cause serious deterioration in health or death.

Class I

Low risk. Symptom logging with no clinical interpretation, basic education content. Self-certified, registered with the MHRA.

Class IIa

Most clinical mental health apps. Guided CBT, structured assessment tools, decision support that influences but does not determine treatment. Requires UK Approved Body conformity assessment.

Class IIb

Higher risk software. Active treatment delivery for moderate to severe conditions, autonomous triage with clinical consequences. Conformity assessment plus enhanced clinical evaluation.

Class III

Highest risk. Software intended to influence decisions where errors could cause death or irreversible deterioration, including some autonomous diagnostic AI in high-risk populations.

The risk class drives every downstream cost and timeline. A Class I product can ship in months. A Class IIa product needs an Approved Body audit, a quality management system to ISO 13485, and clinical evaluation evidence. Plan accordingly.

Step 3: DCB0129 Clinical Risk Management

DCB0129 is the NHS information standard governing clinical risk management for health IT manufacturers. It is mandatory for any health IT system deployed in the NHS in England, regardless of whether the product is also a medical device.

DCB0129 has three core requirements. First, you must appoint a Clinical Safety Officer who is a registered healthcare professional with clinical risk training. Second, you must produce and maintain a Clinical Safety Case Report documenting hazards, controls, and residual risks. Third, you must keep a live Hazard Log that captures every clinical risk identified across the product lifecycle, including post-market issues.

The companion standard, DCB0160, is the deploying organisation's responsibility, not yours. But your DCB0129 outputs feed directly into their DCB0160 work, so the quality of your Safety Case affects how easily NHS trusts can adopt your product.

Step 4: DTAC, the NHS Procurement Gateway

The Digital Technology Assessment Criteria is the standard NHS organisations use to assess digital products before procurement. It covers five domains: clinical safety, data protection, technical assurance, interoperability, and usability and accessibility.

DTAC is a self-assessment, not a certification. You complete the questionnaire and provide supporting evidence including your DCB0129 Clinical Safety Case, Data Protection Impact Assessment, ISO 27001 or Cyber Essentials Plus certification, and accessibility testing results. NHS England refreshed DTAC in early 2026 to reduce the number of questions and align it more closely with NICE evidence standards, making the process slightly more digestible for smaller suppliers.

In practice, every NHS commissioner, integrated care board, or trust will request a completed DTAC before deployment. Treat it as a continuous artefact, not a launch document. Our DPIA generator in the compliance toolkit produces evidence that maps directly into the DTAC data protection section.

Step 5: NICE Evidence Standards Framework

The NICE Evidence Standards Framework defines what clinical and economic evidence digital health technologies need to demonstrate value to the NHS. NICE updated the framework in 2022 to include AI and adaptive algorithms and aligned classifications with MHRA regulatory tiers.

Mental health products typically fall into Tier B (informing clinical management or behaviour change for chronic conditions) or Tier C (active treatment, diagnosis, or guiding clinical management). Tier C requires high-quality evidence of clinical effectiveness, usually from randomised controlled trials or comparable real-world studies. Tier B needs comparative evidence against current practice. Funders increasingly use ESF tiers as a procurement filter.

Step 6: Data Protection and Clinical Information Governance

Mental health data is special category personal data under UK GDPR Article 9. You need an Article 9 lawful basis on top of your Article 6 basis, which usually means explicit consent for direct-to-consumer products or healthcare provision (Article 9(2)(h)) for clinical contexts. A Data Protection Impact Assessment is mandatory because mental health data processing meets the ICO's high-risk thresholds.

Build privacy into the design. Use end-to-end encryption for any free-text input, separate identifiers from clinical content where possible, and log every access for audit. Hosting must be UK or EU-based unless you have completed a Transfer Impact Assessment. Our guide to special category data covers the detail.

Step 7: Clinical Evidence and Safety Monitoring

Class IIa and above devices need a clinical evaluation that demonstrates the product performs as intended and is safe. For mental health products, that usually means a feasibility study followed by a comparative or RCT-grade trial. Feasibility work should use validated outcome measures, typically PHQ-9 for depression, GAD-7 for anxiety, or CORE-OM for general distress. See our guide to outcome measurement for the full picture.

Post-market clinical follow-up is not optional for Class IIa+ devices. You must monitor adverse events, update your Clinical Safety Case, and report serious incidents to the MHRA Yellow Card scheme. Mental health products need particular vigilance for clinical deterioration, suicidal ideation, and disengagement risks.

Sequencing It All

The mistake we see most often is treating these frameworks as a checklist run sequentially after build. They are interlocking. Your intended purpose statement determines MHRA classification. Classification determines the conformity route and your evidence burden under NICE ESF. Both feed into your DCB0129 Safety Case, which feeds into DTAC. Your DPIA sits across all of it.

In practice, plan regulation alongside product design. Appoint a Clinical Safety Officer in month one, even fractionally. Write your intended purpose statement before you build a single screen. Pull together your Quality Management System early if you are heading for Class IIa or above. The cost of doing this in parallel is a fraction of the cost of retrofitting it after launch.

A Realistic Timeline

Months 0-3

Define intended purpose. Confirm MHRA classification with a regulatory consultant. Appoint Clinical Safety Officer. Begin Quality Management System if Class IIa+. Draft initial DPIA.

Months 3-9

Run feasibility study with validated outcome measures. Build core product. Maintain Hazard Log alongside development. Complete first DCB0129 Clinical Safety Case Report.

Months 9-15

Approved Body conformity assessment for Class IIa+. Complete DTAC self-assessment. Run pilot with NHS or private partner. Gather Tier B or C clinical evidence.

Months 15-24

UKCA mark. Launch. Establish post-market clinical follow-up. Build evidence base towards NICE ESF Tier C. Refresh Safety Case quarterly.

We help digital health founders sequence this work pragmatically, often alongside a fractional Clinical Safety Officer. If you are at the planning stage and want a regulatory roadmap before you commit to a build, our AI strategy and digital health startup work covers exactly this territory.

Frequently Asked Questions

Is my mental health app a medical device under UK law?

It probably is if it has a medical purpose, such as diagnosing, monitoring, treating, or preventing a mental health condition. The MHRA's 2023 guidance on digital mental health technologies and its general guidance on Software as a Medical Device set out how to determine intended purpose, qualification, and risk classification under the UK Medical Devices Regulations 2002. Wellness apps with no medical claim usually fall outside the regime, but the line is narrower than founders assume. If your app uses CBT to reduce symptoms of anxiety or depression, it is almost certainly a medical device.

What is DTAC and do I need it to sell into the NHS?

The Digital Technology Assessment Criteria is the NHS baseline standard for digital products entering health or care settings. It covers clinical safety, data protection, technical assurance, interoperability, and usability. DTAC is not a legal requirement, but every NHS buyer will ask for it during procurement. There is no DTAC certificate. You complete a self-assessment and provide supporting evidence, including DCB0129 clinical risk management documentation and DPIA outputs.

What are DCB0129 and DCB0160 and which one applies to me?

DCB0129 is the clinical risk management standard for manufacturers of health IT systems. DCB0160 is the equivalent standard for the NHS organisations deploying those systems. As a digital health product builder, DCB0129 is your responsibility. You must appoint a Clinical Safety Officer who is a registered healthcare professional, produce a Clinical Safety Case Report, and maintain a Hazard Log throughout the product lifecycle. NHS buyers will not deploy your product without DCB0129 evidence.

How does the NICE Evidence Standards Framework work?

The ESF defines what evidence digital health products need to demonstrate value, scaled by risk and intended use. NICE classifies products into evidence tiers from Tier A (system services) through Tier C (active clinical management). Mental health apps that influence treatment decisions or deliver therapy typically fall into Tier B or C and need higher standards of clinical and economic evidence. NHS commissioners increasingly use ESF tiers when reviewing pitches.

Do I need UKCA marking before launching in the UK?

If your product is a medical device, yes. Class I devices can be self-certified and registered with the MHRA. Class IIa and above need a UK Approved Body conformity assessment. Most clinical mental health software is at least Class IIa under the new MDR rules. CE marking is currently still accepted in Great Britain under transitional arrangements, but you should plan for UKCA in the long term.