A digital health product qualifies for DiGA listing if it is a CE-marked medical device of low risk class, its primary purpose is detecting, monitoring, treating, or alleviating disease or compensating for injury or disability, its core medical function is driven by digital technology, and it can demonstrate positive care effects to the German statutory health insurance population. Each of these four gates must be passed separately. None can be inferred from the others, and Tibor's honest framing is that none of them is as easy as the marketing materials suggest.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • DiGA qualification has four high-level gates: CE mark, low risk class, digital core function, and demonstrable positive care effects.
  • The CE mark prerequisite is non-negotiable. Without a valid CE certificate under MDR, a fast-track application cannot proceed.
  • DiGA is restricted to low-risk classes. Most listed products are Class I or Class IIa under MDR Annex VIII Rule 11.
  • The product's primary medical purpose must be delivered by digital technology, not by attached hardware or incidental software features.
  • Tibor's sharpest warning: "It is not as easy as it sounds." A qualification screen is not approval. Qualification opens the door to the real work.

Why this matters

Felix has sat in pitch rooms where a founder says "We are a DiGA" the same way a founder says "We are a SaaS." The sentence is meant to communicate confidence and maturity. What it usually communicates, to anyone in the room who has actually taken a product through BfArM, is that the founder is a year or two away from discovering what DiGA qualification really involves.

DiGA is not a label a startup gets by intending to apply. It is a listing in the BfArM directory, awarded after a structured application under the German Digital Healthcare Act. Before the application arrives at BfArM, the product must already have passed MDR conformity assessment. Before that, it must already meet the qualification conditions BfArM uses to screen applicants.

Tibor's framing from the most recent interview rounds is deliberately cautious. He has not personally taken a product through DiGA, and he is upfront about that limitation. What he has seen, repeatedly, is founders arriving at regulatory gates they did not know existed because they read qualification criteria as a checkbox exercise rather than a discipline.

This post walks through those gates at a level a founder can act on. Where the information is firm, it is stated firmly. Where it depends on DiGAV detail that changes, it is flagged for verification.

What DiGA actually screens for

BfArM's DiGA fast-track screens applicants against a set of qualification conditions that can be grouped into four gates. Each gate is covered in more detail below. Throughout this section, the legal basis sits in the Digital Healthcare Act and the DiGA Regulation (DiGAV), not in MDR.

Gate 1. Is the product a medical device, and is it CE-marked?

BfArM cannot list a product that is not a CE-marked medical device. The assessment starts with the MDR definition in Article 2(1). If the intended purpose is wellness, lifestyle, or fitness, the product is not a medical device and cannot be a DiGA, no matter how digital or well-designed it is.

Assuming the product is a medical device, it must then hold a valid CE certificate or, for Class I self-declared products, a signed declaration of conformity and a complete technical file. Tibor has seen startups arrive at this gate with a draft technical file, an unsigned declaration, and an assumption that "we are working on CE" will be accepted as equivalent. It is not.

Gate 2. Is the product in a risk class eligible for DiGA?

DiGA is restricted to low-risk classes under MDR. Most listed products are Class I or Class IIa.

For a startup, this gate sharpens Rule 11 anxiety. Under MDR Annex VIII Rule 11, read with MDCG 2019-11 Rev.1, a software product that drives therapy or diagnosis decisions can land in Class IIa or even higher. A product that informs clinical decisions where a wrong decision could cause serious harm is out of Class I. The same product that breaches the DiGA ceiling by being classified Class IIb is no longer a DiGA candidate at all.

Tibor's practical guidance: classification is destiny for DiGA candidacy. Get the classification right before building the DiGA business case.

Gate 3. Is the main medical function delivered by digital technology?

DiGA is not a channel for any medical device that happens to have an app. The primary medical purpose, the reason the product qualifies as a medical device in the first place, must be delivered through digital technology. A piece of hardware with a companion app is not a DiGA if the companion app is a secondary feature.

The Subtract to Ship test Felix uses with coaching clients: remove the hardware from the product in a thought experiment. If the medical purpose still stands, the digital core function is real. If the medical purpose evaporates, the product is a medical device with digital features, not a digital medical device.

Gate 4. Can the product demonstrate positive care effects?

This is the gate founders underestimate most consistently. A DiGA must support the patient's care in one of two structured ways: a medical benefit, or a patient-relevant structural and procedural improvement.

Medical benefit generally means a measurable improvement in the patient's health state, such as reduced symptoms, improved disease management, or better clinical outcomes. Structural and procedural improvement generally means a patient-relevant gain in the care process, such as better adherence, faster access to care, reduced coordination burden, or improved patient empowerment. Both categories require evidence. Neither is accepted on theoretical grounds.

Qualification does not yet mean the evidence has been produced. It means the applicant has made a credible case that evidence is planned, designed, and within reach. The evidence itself is demanded in the main fast-track application, not in qualification. Startups that reach qualification and then stall on trial design are common.

A worked example

A two-person startup in Munich has built a smartphone app that guides patients through structured breathing exercises for chronic obstructive pulmonary disease. The founder walks through the four gates with Tibor.

Gate 1. Intended purpose: support patients with diagnosed COPD in managing breathing exercises prescribed as part of their care plan. This is a therapy-support purpose. The product is a medical device under MDR Article 2(1). No CE mark yet, no technical file, no QMS. Gate 1 is not passed. Before any BfArM conversation, the startup needs MDR conformity assessment.

Gate 2. Under Rule 11 with MDCG 2019-11 Rev.1, the app supports therapy decisions. Tibor's reading is Class IIa, which is within the DiGA ceiling but requires a notified body engagement. The founder was hoping for Class I. Gate 2 is passable but not at the class the founder assumed, and cost and time go up as a result.

Gate 3. The primary medical function, guided breathing exercise delivery and adherence tracking, is delivered by the digital technology itself. No external hardware. Gate 3 passes cleanly.

Gate 4. The founder intends to claim a patient-relevant structural and procedural improvement, specifically better adherence to prescribed breathing exercise regimes. Evidence plan: a prospective study comparing adherence and patient-reported outcomes in the intervention group versus usual care in the statutory insurance population.

Total realistic timeline from day one to DiGA listing: two to three years, dominated by the clinical study, the notified body CE certificate, and the fast-track application itself. The founder leaves the session with a different plan than the one brought in.

The Subtract to Ship playbook

Felix walks DiGA candidates through a short discipline before anyone writes a single line of application text.

Subtract the false starts. Remove from the plan any reliance on Class I self-certification before Rule 11 is read in writing. Remove any language that treats DiGA and CE marking as interchangeable. Remove any slide that promises DiGA listing within twelve months of incorporation.

Write the intended purpose. One sentence. Physician-readable. Tested against MDR Article 2(1). If the purpose is wellness, the product is not a DiGA candidate, and the whole conversation changes. If the purpose is medical, continue.

Classify under Rule 11. Work through Annex VIII Rule 11 and MDCG 2019-11 Rev.1 in writing. If the output is Class IIa, budget for a notified body. If the output is Class IIb, the DiGA door closes and a different reimbursement route is needed.

Design the evidence once. Plan a single clinical study that can serve both the MDR clinical evaluation under Article 61 and the DiGA positive care effects dossier under DiGAV. Running two studies back to back is how runway evaporates.

Sequence the submissions. CE mark before DiGA, always. DiGA application before pricing negotiations, always.

Subtract to Ship means none of these steps is skipped in the name of speed. Each skipped step returns as an expensive rework later.

Reality Check

  1. Can the product's intended purpose be written as a medical purpose in one physician-readable sentence?
  2. Has MDR Annex VIII Rule 11 been applied in writing with MDCG 2019-11 Rev.1 in hand, not from memory?
  3. Is the expected classification Class I or Class IIa, and does the business case assume the correct class?
  4. Does the primary medical function of the product survive a thought experiment where all hardware is removed?
  5. Is there a written positive care effects hypothesis, a target population, and a study design, or only an intention to "do a trial"?
  6. Has the team priced both the MDR notified body engagement, if applicable, and the clinical study in the same budget?
  7. Is the sequence CE mark first, DiGA second, reflected in the timeline, or are the two tracks running in parallel on the slide deck?
  8. Has the team spoken directly to at least one founder who has actually completed a DiGA fast-track application?

Frequently Asked Questions

Is every digital health app a DiGA candidate? No. Wellness and lifestyle apps are not medical devices under MDR and cannot be DiGAs. Medical devices above the DiGA class ceiling are excluded too. Qualification is a narrow gate, not an open category.

Can a Class I self-declared product apply for DiGA? Yes, provided the Class I classification is correct and defensible, and the technical file, declaration of conformity, and clinical evaluation under MDR Article 61 are complete. Tibor's warning: many products currently self-declared as Class I would fail a serious Rule 11 review. Check first.

What counts as positive care effects? A medical benefit or a patient-relevant structural and procedural improvement. Both require structured evidence, usually from a prospective study in the German target population.

Can a startup apply for DiGA while CE marking is still in progress? No. A valid CE mark is a prerequisite for fast-track application. Running the two processes in parallel leads to applications stalled at intake.

Is DiGA the only reimbursement path for digital health in Europe? No. Other EU countries operate different reimbursement schemes with different evidence expectations. A startup that builds its entire business case on DiGA alone is betting on a single market, a single payer environment, and a single regulatory regime.

Why is Tibor cautious about DiGA advice? Because he has not personally taken a product through BfArM and respects the difference between framework understanding and first-hand execution. His clear recommendation: talk to founders who have actually completed a DiGA fast-track application and listen to their honest experience.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 2, Article 52, Annex VIII.
  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. Digitale-Versorgung-Gesetz (DVG) and Digitale Gesundheitsanwendungen-Verordnung (DiGAV), German Federal Ministry of Health.
  5. BfArM fast-track guidance for DiGA applicants.