---
title: Digital Therapeutics (DTx) Under MDR: Software-Based Treatments
description: Digital therapeutics DTx MDR path: qualification, Rule 11 classification, clinical evidence, and the CE-marking spine every DTx startup must build.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: Digital therapeutics DTx MDR
canonical_url: https://zechmeister-solutions.com/en/blog/digital-therapeutics-dtx-mdr
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Digital Therapeutics (DTx) Under MDR: Software-Based Treatments

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Digital therapeutics are a category of software that delivers a therapeutic intervention, not just information. Under MDR Article 2(1), almost every DTx qualifies as a medical device. Under Annex VIII Rule 11, most DTx land in Class IIa or higher, which means a Notified Body, a clinical evaluation under Article 61, a PMCF plan, and the full QMS spine under EN ISO 13485:2016+A11:2021. The regulatory path is well defined. The clinical evidence bar is where most DTx founders underestimate the work.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- A digital therapeutic is software whose intended purpose is to deliver a therapeutic intervention, typically for a defined clinical indication.
- Under MDR Article 2(1), DTx qualifies as a medical device if its intended purpose includes treatment or alleviation of disease. Most do.
- Under MDR Annex VIII Rule 11, a DTx intended to drive therapeutic decisions is typically Class IIa, and Class IIb where the therapeutic impact may cause serious deterioration.
- The Notified Body pulls in a full clinical evaluation under Article 61 and Annex XIV Part A, a PMCF plan under Annex XIV Part B, and the full QMS under EN ISO 13485:2016+A11:2021.
- The evidence bar for DTx tends to approach pharmaceutical clinical trial standards, not software usability testing. A randomised controlled trial with a credible comparator is often what Notified Bodies and payers expect.
- This is the MDR path. DiGA and other national reimbursement pathways sit on top. The CE-marking work is the shared spine.

## Why this matters for MedTech founders

Felix has coached founders who believed a DTx was "just an app with clinical content" and who planned to self-certify as Class I. Tibor has reviewed the same plans from the notified body side and watched the classification assumption collapse under the first hour of a Rule 11 conversation. The pattern is consistent across sectors: insomnia CBT apps, chronic pain programmes, addiction support tools, post-surgical rehabilitation software. Each team arrives with a clinical story and a software mindset. The MDR requires both at full strength.

The mismatch is not because DTx founders are careless. It is because the regulatory category sits in an unusual place. A DTx is a software product by architecture, a clinical intervention by intended purpose, and a consumer product by user experience. Each of those three facets pulls the team toward a different set of disciplines. The MDR integrates them, but only if the team reads the MDR carefully and applies it early.

This post walks through the standard MDR path for DTx. It does not cover DiGA-specific or national reimbursement pathway details, which are separate posts. It covers what the MDR requires, which is the same across every member state and is the non-negotiable starting point.

## What MDR actually says about qualification

MDR Article 2(1) defines a medical device as any instrument, apparatus, appliance, software, implant, reagent, material, or other article intended by the manufacturer to be used for human beings for one or more specific medical purposes. The list of medical purposes explicitly includes diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease.

A DTx is software. Its intended purpose is to treat or alleviate disease, for example cognitive behavioural therapy delivered by an app for chronic insomnia, or a guided programme for tinnitus management. That intended purpose is a listed medical purpose in Article 2(1). The consequence is direct: the DTx is a medical device under the MDR.

MDCG 2019-11 Rev.1 (June 2025) is the authoritative interpretation for software qualification and classification. It walks through the decision tree for qualification and the Rule 11 classification path and includes worked examples that map closely to DTx scenarios.

Founders sometimes try to avoid qualification by framing the DTx as "wellness" or "lifestyle support". The test is not the marketing language. The test is the intended purpose as specified by the manufacturer, per MDR Article 2(12): the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation. If the label, the IFU, the app store description, the investor deck, or the clinical evaluation says "treats chronic insomnia", the device is a medical device. Attempts to rewrite the marketing while keeping the clinical claim inside the product almost always fail under a competent NB review.

## Classification under Rule 11

MDR Annex VIII Rule 11 is where most DTx classification conversations end.

Rule 11 states that software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, except if such decisions have an impact that may cause death or an irreversible deterioration of a person's state of health (Class III) or a serious deterioration of a person's state of health or a surgical intervention (Class IIb). Software intended to monitor physiological processes is Class IIa, except where it monitors vital physiological parameters whose variations could result in immediate danger (Class IIb). All other software is Class I.

For a typical DTx, the therapeutic intervention is driven by software output that patients act on directly. That maps cleanly onto "information which is used to take decisions with therapeutic purposes". The default is Class IIa. The DTx moves to Class IIb if a failure of the therapy could cause serious deterioration of the patient's state of health. For a chronic insomnia CBT app with no safety-critical decision logic, Class IIa is typical. For a DTx managing treatment in a condition where mistreatment can cause serious harm, Class IIb becomes the credible read.

The practical consequence of Class IIa or higher is that a Notified Body is required for conformity assessment. MDR Article 52 defines the conformity assessment routes. A DTx at Class IIa will typically go through a combination of Annex IX (full QMS plus assessment of technical documentation on a sampling basis) or Annex XI. For Class IIb, the technical documentation scrutiny is more extensive.

## What the Notified Body actually expects

Once Notified Body involvement is triggered, the DTx file needs to meet the full MDR expectations, not a slimmed-down software version. In Tibor's experience on the audit side, five areas are where DTx files are most often underweight.

First, the clinical evaluation under MDR Article 61 and Annex XIV Part A. A DTx is a clinical intervention. The clinical evaluation must demonstrate that the intended therapeutic benefit is real, that the risk-benefit ratio is acceptable, and that the state of the art is properly characterised. A narrative literature review of similar apps does not meet this bar. For most DTx, a prospective clinical investigation with a credible comparator is the realistic evidence baseline.

Second, the risk management file under EN ISO 14971:2019+A11:2021 and MDR Annex I GSPRs 1 to 9. A common failure mode is treating the risk file as a software bug list. DTx-specific hazards are clinical: treatment non-response, worsening of symptoms, false reassurance, disengagement from conventional care, comorbidity missed by the DTx. These are the hazards the file must surface, not "app crashes".

Third, the software lifecycle under EN 62304:2006+A1:2015 and MDR Annex I §17.2. Classification of software safety class (A, B, or C) under EN 62304 must be justified. A DTx where failure could lead to serious deterioration is not class A. Configuration management, SOUP tracking, and the full verification and validation chain apply.

Fourth, usability engineering under EN 62366-1:2015+A1:2020 and MDR Annex I §5 and §22. DTx are used by patients, often unsupervised, often at home, often for long periods. Formative and summative usability evaluation with representative users matters more here than for most other device categories. Tibor's point from audit experience is blunt: testing with engineers and friendly volunteers is not summative. Real summative means recruited representative users, real or simulated use environment, recorded observations, documented outcomes.

Fifth, cybersecurity under MDR Annex I §17.2 and §17.4, MDCG 2019-16 Rev.1, and EN IEC 81001-5-1:2022. A DTx processes patient health data and often runs on unmanaged consumer devices. Threat modelling, penetration testing, and SBOM discipline are not optional. The lifecycle point from MDCG 2019-16 applies directly: a DTx secure at launch can become insecure within months as SOUP libraries publish CVEs. The SBOM, drawn from the EN 62304 configuration item list, needs to be live.

## A worked example

A team builds a guided CBT app for adult chronic insomnia. The founder's first instinct is Class I and self-certification, on the grounds that the app "just delivers therapy content" and "does not diagnose".

Rule 11 read: the software provides information (the CBT programme structure, nightly recommendations, next-step guidance) that the user acts on for a therapeutic purpose (treating insomnia). That places the device in Class IIa as the default. There is no credible read that moves it to Class I.

Consequences. Notified Body involvement. Full clinical evaluation under MDR Article 61 and Annex XIV Part A. In the current state of the art for insomnia CBT, a randomised controlled trial against a credible comparator is the expected evidence standard. Annex XIV Part B PMCF plan post-launch. QMS under EN ISO 13485:2016+A11:2021. Usability engineering under EN 62366-1. Software lifecycle under EN 62304. Cybersecurity under EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1.

The founder's question becomes: how long does this take, and how much does it cost? The honest answer is 18 to 30 months from a standing start, with clinical trial costs that dominate the budget. Skipping any of the above is not a faster route. It is a rejected file.

## The Subtract to Ship playbook

Start from intended purpose. Write the intended purpose statement first, before the marketing copy. Every downstream decision (classification, clinical evaluation, risk management, usability) traces back to it.

Classify early and document the justification. Annex VIII Rule 11 plus MDCG 2019-11 Rev.1 plus the intended purpose gives the classification. Write the justification as its own document. It will be the first thing the NB reads.

Plan the clinical evaluation as a pharmaceutical-adjacent activity, not as a software QA exercise. For most DTx, the evidence bar is closer to a Phase III drug study than to a usability test. Budget accordingly.

Build the QMS minimal but real. EN ISO 13485:2016+A11:2021 is the anchor. A QMS that is lean but complete beats a QMS that is comprehensive in ambition and incomplete in practice.

Integrate usability and risk from day one. DTx-specific hazards are clinical, not technical. Surface them early, with multidisciplinary input. Tibor's usability principle applies directly: test with recruited representative users or expect pushback at audit.

Treat cybersecurity as a lifecycle discipline. Build the SBOM into the EN 62304 configuration item list and update it on every release. Plan for CVE response before launch.

Only after this CE-marking spine is in place should the team start the separate conversation about DiGA, PECAN, mHealthBelgium, or other national reimbursement pathways. Those are distinct from the MDR work and cannot substitute for it.

## Reality Check

1. Have you written an intended purpose statement for your DTx that is consistent across the label, the IFU, the app store description, the investor deck, and the clinical evaluation?
2. Have you classified the device under MDR Annex VIII Rule 11, with a documented justification that references MDCG 2019-11 Rev.1?
3. Is your clinical evaluation plan designed to the standard the Notified Body will expect, or to the standard your team finds comfortable?
4. Does your risk management file under EN ISO 14971 surface clinical hazards (non-response, worsening, missed comorbidity, disengagement), not just software defects?
5. Does your summative usability evaluation use recruited representative users in a real or credibly simulated environment, with documented observations?
6. Does your cybersecurity file cover threat modelling, penetration testing, SBOM, and a lifecycle CVE response plan per MDCG 2019-16 Rev.1 and EN IEC 81001-5-1:2022?
7. Has the budget for the CE-marking clinical trial been modelled honestly, including comparator costs, site costs, and timeline slack?
8. Are the DTx regulatory work and the DTx reimbursement work running in parallel, with the CE-marking spine as the shared foundation?

## Frequently Asked Questions

**Is every digital therapeutic a medical device under MDR?**
If the intended purpose includes treatment, alleviation, or monitoring of disease as listed in MDR Article 2(1), yes. Almost every product marketed as a DTx meets this test. A small number of wellness-only products may not, but the label, IFU, and marketing all need to be consistent with that positioning.

**Can a DTx be Class I?**
Rarely. Rule 11 usually pushes DTx into Class IIa or higher because the software drives therapeutic decisions. A Class I DTx would have to not drive therapeutic decisions, which for most DTx definitions is a contradiction.

**Is Notified Body involvement always required?**
For Class IIa, IIb, and III, yes. Only Class I devices conduct self-certification without Notified Body involvement, and most DTx are not Class I.

**What clinical evidence is expected?**
For most DTx, the credible evidence bar is a prospective clinical investigation with a credible comparator, large enough to demonstrate the claimed therapeutic effect. Literature review alone of similar apps does not usually meet the bar under Article 61 and Annex XIV Part A.

**How does this relate to DiGA?**
DiGA and other national reimbursement pathways are separate from the MDR CE-marking path. All of them presume CE marking as a medical device first. The MDR work described in this post is the shared spine that every reimbursement conversation sits on top of.

**Is EN 62304 software safety class A acceptable for a DTx?**
Only if the failure of the software could not lead to any injury or damage to health. For most DTx, where a therapeutic failure can cause non-trivial health consequences, class B or C is the honest classification.

## Related reading
- [What is software as a medical device under MDR](/blog/what-is-software-as-medical-device-samd-mdr) for the SaMD definition that a DTx sits inside.
- [MDR classification Rule 11 for software](/blog/mdr-classification-rule-11-software) for the classification gate every DTx must pass.
- [MDR classification software Rule 11 deep dive](/blog/mdr-classification-software-rule-11-deep-dive) for worked examples close to DTx scenarios.
- [Clinical evaluation for SaMD](/blog/clinical-evaluation-samd) for how Article 61 applies to software-based interventions.
- [Complete SaMD regulatory path for startups](/blog/samd-complete-regulatory-path-startups-2026) for the end-to-end CE-marking programme a DTx team should plan around.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 2(1), Article 2(12), Article 61, Annex VIII Rule 11, Annex XIV Parts A and B, Annex I §5, §17.2, §17.4, §22.
2. MDCG 2019-11 Rev.1 (June 2025). Qualification and classification of software under MDR and IVDR.
3. MDCG 2019-16 Rev.1 (December 2019, Rev.1 July 2020). Cybersecurity for medical devices.
4. EN ISO 13485:2016+A11:2021, EN ISO 14971:2019+A11:2021, EN 62304:2006+A1:2015, EN 62366-1:2015+A1:2020, EN IEC 81001-5-1:2022.

---

*This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*