DiGA approval and CE marking are two different regulatory processes, stacked on top of each other. The CE mark, obtained under MDR, proves the product is a lawful medical device in the EU. The BfArM DiGA listing, obtained separately under German digital health law, proves the product deserves statutory reimbursement in Germany. Each path has its own evidence bar, and DiGA's bar for clinical and economic evidence sits visibly higher than MDR Class I.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • DiGA listing by BfArM is not a substitute for a CE mark under MDR. A product needs both to be reimbursed as a DiGA in Germany.
  • Many DiGA candidates qualify as software as a medical device and are Class I self-certified under MDR Annex VIII Rule 11.
  • A Class I self-declaration under MDR requires a technical file, a QMS aligned with EN ISO 13485:2016+A11:2021, and a clinical evaluation under MDR Article 61. DiGA then adds a separate evidence layer on top.
  • The DiGA clinical and economic evidence bar is higher than the minimum MDR Class I bar. Tibor has seen founders underestimate this gap repeatedly.
  • Founders who treat DiGA as a shortcut to revenue ship products that clear CE but fail the BfArM fast-track trial. The two processes must be planned together from day one.

Why this matters

In Tibor's coaching sessions, one sentence comes up more than any other from digital health founders who have just raised a seed round: "We will go DiGA, because Germany is the biggest market." The logic is tidy on a slide. Build a Class I software product, self-declare under MDR, list with BfArM, and revenue starts flowing from statutory health insurance.

The logic is also wrong in almost every meaningful way.

Felix has watched startups burn eighteen months of runway on this misreading. They read one or two conference talks about the Digital Healthcare Act, assume DiGA and CE marking are either the same thing or that one automatically triggers the other, and build their entire regulatory roadmap on that assumption. The first real awakening usually arrives during a call with BfArM or a fast-track application review, when someone on the other side of the table asks for clinical evidence that the startup never planned to produce.

The purpose of this post is to separate the two tracks cleanly. What MDR does. What DiGA does. Where they touch. Where they do not. And what the honest evidence bar looks like on each side.

What MDR actually says

The MDR, Regulation (EU) 2017/745, governs whether a product is a medical device and, if so, under what conditions it may be placed on the EU market. Software that meets the definition of a medical device under MDR Article 2(1) is a medical device. The classification of that software is then determined by MDR Annex VIII, with Rule 11 as the dominant rule for software as a medical device.

Rule 11, read together with MDCG 2019-11 Rev.1, tells a founder where their software sits: Class I, IIa, IIb, or III, depending on the intended purpose and the clinical decisions the software informs. Many pure-wellness-adjacent digital therapeutics and digital coaching tools land in Class I. Some do not. Tibor has audited DiGA-adjacent products that were wrongly self-declared as Class I when Rule 11 clearly pushed them into Class IIa.

For a Class I software medical device, MDR Article 52(7) permits self-certification without a notified body. The manufacturer must still hold:

  • A quality management system aligned with EN ISO 13485:2016+A11:2021
  • A technical file meeting MDR Annexes II and III
  • A clinical evaluation under MDR Article 61 and Annex XIV
  • A software development lifecycle under EN 62304:2006+A1:2015
  • A risk management file under EN ISO 14971:2019+A11:2021
  • A post-market surveillance plan under MDR Articles 83-86

None of this is a shortcut. It is a full MDR file. What is missing, compared to Class IIa and above, is the notified body audit of that file. The declaration of conformity is signed by the manufacturer alone.

This is the CE mark path. Nothing in MDR mentions DiGA. Nothing in MDR mentions BfArM. The regulation is silent on reimbursement entirely.

What DiGA actually is

DiGA (Digitale Gesundheitsanwendung) is a category created by German law, not by the MDR. It is grounded in the Digitale-Versorgung-Gesetz (Digital Healthcare Act) and the Digitale Gesundheitsanwendungen-Verordnung (DiGAV), and it is administered by the Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM).

A DiGA is a digital health application listed in the BfArM directory. Inclusion in that directory is what triggers statutory health insurance reimbursement. The evidence required to get into the directory is set by DiGAV, not by MDR.

Crucially, DiGAV requires that the product already be a CE-marked medical device of Class I or Class IIa before it can apply. The CE mark is the entry ticket. It is necessary, but it is not sufficient.

On top of the CE mark, DiGA requires:

  • Proof of positive care effects, which can be a medical benefit or a patient-relevant structural and procedural improvement
  • Data protection and data security compliance under GDPR and the German BSI requirements
  • Interoperability with the German telematics infrastructure
  • Transparency on pricing and usage data

The positive care effects requirement is where most founders hit the wall. An MDR Class I clinical evaluation can sometimes lean heavily on equivalence to existing devices, literature review, and a small amount of post-market data. A DiGA positive care effects dossier typically expects a prospective comparative study conducted on the German target population. Tibor has heard from multiple DiGA-approved manufacturers that the gap between their MDR file and their BfArM file was larger than they estimated at the outset.

A worked example

Consider a Berlin-based startup building a cognitive behavioural therapy app for patients with moderate depression. The intended purpose, written carefully, is to support a diagnosis established by a physician by delivering structured CBT exercises and progress tracking.

Under MDR:

  • The app meets the definition of a medical device under Article 2(1) because its intended purpose is therapy for a specific medical condition.
  • Under Annex VIII Rule 11 and MDCG 2019-11 Rev.1, the app provides information used for decisions with therapy purposes. Because the consequences of a wrong decision are not life-threatening and no serious deterioration is expected from a software failure alone, the founder and Tibor agree the device is Class IIa, not Class I. A notified body is required under MDR Article 52.

So step one of the founder's plan, "self-declare Class I and skip the notified body", is already impossible. The CE mark will require a notified body engagement, a full technical file, and a clinical evaluation that reflects the therapeutic claim.

On top of that, step two, DiGA listing, requires a fast-track application to BfArM with positive care effects data. The founder will likely need to design a prospective randomised controlled trial on depressed patients in the German statutory health insurance population, measuring a patient-relevant clinical endpoint over a defined period.

Total timeline, honestly estimated: two to three years from incorporation to DiGA listing. The CE mark might arrive in year one. The DiGA listing, with the trial complete and accepted, arrives later.

The founder who planned for "DiGA in twelve months" is not wrong about ambition. They are wrong about the stacking of two regulatory paths.

The Subtract to Ship playbook

Felix uses a four-step sequence with founders who want to land in the BfArM directory without wasting the first half of their runway.

Step 1. Decide whether you are a medical device at all. The MDR definition in Article 2(1) is the first gate. If the intended purpose is pure wellness, lifestyle, or fitness, the product is not a medical device and cannot be a DiGA. If the intended purpose touches diagnosis, therapy, monitoring, or prediction of disease, it is likely a medical device. Tibor's test: write the intended purpose in one sentence that a physician would find useful, then ask whether a physician would base a clinical decision on it.

Step 2. Classify under Rule 11 honestly. Do not assume Class I. Read MDR Annex VIII Rule 11 together with MDCG 2019-11 Rev.1 and work through the decision tree. If the product drives therapy decisions, the floor is Class IIa. Only informational and administrative software stays in Class I in practice.

Step 3. Build the MDR file to the level the clinical claim demands, not the level the class requires. A Class IIa device can be certified on a thin clinical evaluation if the claim is thin. A DiGA requires a substantial positive care effects study. Plan the MDR clinical evaluation and the DiGA study as one integrated clinical strategy, not two. The same trial can serve both files if it is designed for the higher bar from the start.

Step 4. Sequence the two submissions. CE mark first, DiGA second. The CE mark is a prerequisite for BfArM fast-track application. Any attempt to run them in parallel ends with a DiGA application blocked on the missing CE certificate.

This is where Subtract to Ship becomes concrete. Subtract the false belief that DiGA is a second-class regulatory path. Subtract the assumption that Class I self-declaration protects the founder from clinical investment. Subtract the theatre of "DiGA-ready" marketing language before the evidence exists. Ship the smallest real clinical study that can credibly support the positive care effects claim, then build the MDR file and the DiGA file from that one dataset.

Reality Check

  1. Can the founder state the product's intended purpose in one sentence that maps cleanly onto the MDR Article 2(1) definition of a medical device?
  2. Has the founder worked through MDR Annex VIII Rule 11 and MDCG 2019-11 Rev.1 in writing, or is the Class I assumption inherited from a pitch deck?
  3. Is there a written clinical strategy that addresses both MDR Article 61 and the expected DiGA positive care effects evidence, or are these two separate plans?
  4. Does the founder understand that the CE mark is a prerequisite for DiGA fast-track application, not a parallel track?
  5. Has the team budgeted for a prospective study on German patients, or is the financial plan built on literature review plus optimism?
  6. Does the post-market surveillance plan under MDR Articles 83-86 already integrate the usage data BfArM will later request for DiGA reporting?
  7. Is there a realistic two-to-three-year timeline from product launch to DiGA listing, or is the plan still speaking in months?

Frequently Asked Questions

Is DiGA listing the same as CE marking? No. DiGA listing is a German reimbursement process administered by BfArM under the Digital Healthcare Act. CE marking is an EU-wide regulatory process under MDR. A product needs the CE mark first, and only then can it apply for DiGA listing.

Can a product skip CE marking if it applies for DiGA directly? No. Every DiGA in the BfArM directory is, by definition, also a CE-marked medical device under MDR. Without the CE mark there is no eligibility for DiGA fast-track review.

Are all DiGAs Class I under MDR? Not all. Many are, because of how Rule 11 interacts with low-risk digital therapeutics and patient information tools. But a therapy-oriented app that drives clinical decisions can easily reach Class IIa, which requires a notified body. Tibor recommends classification review before any DiGA strategy is priced out.

Does DiGA approval cover the whole EU? No. DiGA listing delivers statutory reimbursement in Germany only. Other EU countries operate their own reimbursement schemes with different evidence expectations. The CE mark is EU-wide. The DiGA listing is not.

Is DiGA a faster path to revenue than traditional reimbursement routes? Sometimes, compared with the slowest national reimbursement processes in other EU countries. But it is not fast in absolute terms. Tibor has heard from multiple DiGA-approved manufacturers that the initial reimbursement rate falls over time as payers negotiate harder, and that the long-run economics were less attractive than the initial projections.

What is the biggest mistake founders make with DiGA? Treating it as an MDR alternative rather than an MDR addition. The CE mark and the DiGA listing stack. The evidence bar for DiGA sits on top of the MDR bar, not beside it. Budgeting, timelines, and clinical strategy must reflect both at once.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 2, Article 52, Article 61, Annex VIII, Annex XIV.
  2. MDCG 2019-11 Rev.1 (June 2025), Guidance on qualification and classification of software in Regulation (EU) 2017/745.
  3. EN ISO 13485:2016+A11:2021, Medical devices, Quality management systems, Requirements for regulatory purposes.
  4. EN 62304:2006+A1:2015, Medical device software, Software life cycle processes.
  5. Digitale-Versorgung-Gesetz (DVG) and Digitale Gesundheitsanwendungen-Verordnung (DiGAV), German Federal Ministry of Health.