A DiGA (Digitale Gesundheitsanwendung) is a CE-marked medical device software listed in the directory maintained by Germany's Federal Institute for Drugs and Medical Devices (BfArM) and reimbursable by statutory health insurance under specific conditions. It is a reimbursement pathway on top of a CE mark, not a substitute for it.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • DiGA stands for Digitale Gesundheitsanwendung, a category of low-risk digital health applications reimbursable by German statutory health insurance.
  • The framework was introduced through the Digitale-Versorgung-Gesetz (DVG), which entered force in 2019 .
  • A valid CE mark under MDR is a prerequisite for DiGA listing. DiGA approval does not replace CE marking and does not lower the MDR bar.
  • The BfArM maintains the official DiGA directory and runs the application process .
  • Tibor has not taken a product through DiGA himself. Every first-hand DiGA claim in this post is sourced from manufacturers already in the directory and is flagged where verification is needed.
  • Reimbursement rates decline over time in the system according to multiple DiGA-approved manufacturers Tibor has spoken with, and the path is harder than the marketing story suggests.

Why founders keep asking about DiGA

Tibor hears the same question every month. A founder has built a digital health app, wants to monetise in Germany, has read that DiGA is a fast-track to statutory reimbursement, and assumes the path looks like this: get a CE mark, submit to BfArM, enter the directory, collect revenue.

The real path is less linear. Tibor has guided more than fifty companies through MDR certification. He has not personally guided a product through the full DiGA process, and he is careful to say so. What follows is the framework as he understands it from published sources and from conversations with DiGA-approved manufacturers who did walk the path. Founders with specific DiGA questions should always seek out peers who have first-hand experience with BfArM applications.

Felix coaches founders on sequencing decisions. The DiGA question is almost always a sequencing question disguised as a regulatory question. The right answer depends on whether a founder understands what DiGA is, what it is not, and where it sits in the broader German healthcare reimbursement landscape.

What the DiGA framework actually is

The DiGA framework was created through the Digitale-Versorgung-Gesetz (DVG), the Digital Healthcare Act, which introduced reimbursable digital health applications into the statutory health insurance (Gesetzliche Krankenversicherung, GKV) system . Before DVG, there was no legal mechanism for a statutory health insurer to reimburse a patient-facing app as a prescribed benefit. After DVG, there was.

The framework has three components that founders often conflate:

Component 1: the underlying medical device. A DiGA candidate must be a CE-marked medical device under Regulation (EU) 2017/745 (MDR). For most apps this means classification as Class I or Class IIa under Annex VIII Rule 11 of the MDR, depending on what the software does and how it contributes to clinical decisions. The classification is driven by the device's intended purpose in the sense of 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.

Component 2: the BfArM listing. BfArM maintains the DiGA directory. Applications for listing are submitted to BfArM, and BfArM assesses whether the product meets the DiGA-specific requirements that sit on top of the CE mark .

Component 3: the reimbursement relationship. Once listed, a DiGA can be prescribed by a German physician or, under certain conditions, requested by a patient, and the statutory insurer reimburses the manufacturer. Rates are negotiated between the manufacturer and the association of statutory health insurers .

Tibor's framing for founders: component 1 is MDR territory and he can speak to it in detail. Components 2 and 3 are BfArM and statutory insurance territory, and founders need first-hand DiGA advisors there.

CE mark first, DiGA second. Never the other way around.

The most expensive misconception Tibor hears is that DiGA approval somehow substitutes for a CE mark, or that the DiGA process can run in parallel with MDR certification in a way that saves time. It does not.

From Section 4 of Tibor's follow-up interview: founders confuse DiGA approval with CE marking. Many DiGA candidates are Class I self-certified. The founder signs their own EU Declaration of Conformity under Article 52 of the MDR and assumes BfArM will accept the same evidence package. The problem, as Tibor has heard repeatedly from DiGA-approved manufacturers, is that the DiGA clinical evidence bar sits above minimal MDR Class I evidence. A Class I manufacturer who did only what the MDR minimum required will usually discover their clinical evaluation is insufficient for BfArM. The cost of that discovery is months of rework and a delayed listing.

The sequence Tibor recommends to founders:

  1. Decide the intended purpose in the MDR Article 2(12) sense.
  2. Classify the software under Annex VIII Rule 11. Do this properly. Reference MDCG 2019-11 Rev.1 for the rule interpretation.
  3. Build the quality management system to EN ISO 13485:2016+A11:2021 and the software lifecycle to EN 62304:2006+A1:2015.
  4. Complete the clinical evaluation under MDR Article 61 and Annex XIV Part A.
  5. Obtain the CE mark.
  6. Only then assemble the DiGA submission package.

Founders who skip steps to save time tend to find that the saving is fictional and the rework is real.

The DVG and why it exists

The Digitale-Versorgung-Gesetz was the German federal government's attempt to accelerate digital health adoption in a statutory insurance system that had historically struggled to reimburse software. Before DVG, a digital health app might technically be prescribable but practically unreimbursable because there was no code, no category, and no assessment pathway .

DVG changed three things that matter to founders:

First, it created a legal category for DiGA inside the social code (SGB V), assigning BfArM as the competent authority for assessment and listing .

Second, it defined the types of digital health applications eligible: low-risk digital health applications supporting the detection, monitoring, treatment, or alleviation of illnesses, or supporting the detection, treatment, alleviation, or compensation of injuries or disabilities . Class I and Class IIa medical device software are typically in scope. Higher-risk software typically is not.

Third, it established the principle that DiGAs are reimbursable as part of the GKV benefit catalogue, with pricing mechanisms negotiated separately from the listing decision.

DVG was followed by further digital health legislation that has continued to shape the landscape, including regulations touching interoperability standards and data protection duties for DiGA manufacturers .

What Tibor has heard from manufacturers who walked the path

Tibor is explicit that he has not personally taken a product through DiGA. What follows is second-hand pattern recognition from conversations with manufacturers who are in the directory.

The reimbursement rate declines over time. The initial rate negotiated for a provisionally listed DiGA tends to be acceptable. After the initial period, and as evidence accumulates and negotiations reset, rates trend downward. Some manufacturers have reported that the economics eventually become unviable and they have reconsidered continuing .

Clinical evidence is the gating constraint. DiGA is not a benefit-of-the-doubt process. BfArM wants demonstration of positive healthcare effects, which in the DiGA context means quantitative or qualitative evidence of benefit to the German healthcare system: money saved, time saved, more efficient care, or improved patient outcomes attributable to the app. A clinical evaluation that was sufficient for a CE mark may not touch this bar.

Germany is not a single market. The GKV is a patchwork of more than ninety statutory health insurers . Listing in the DiGA directory makes a product reimbursable in principle. It does not mean every insurer will promote it, every physician will prescribe it, or every patient will learn it exists. Commercial traction inside the directory is a separate battle.

The Subtract to Ship playbook for DiGA curiosity

Felix's framing: before writing a single line of DiGA application, answer four questions.

Question one. Is your product actually a medical device under MDR Article 2? If the answer is "we are not sure", you are not ready for DiGA. You are ready for a qualification discussion under MDCG 2019-11 Rev.1. A wellness product is not a DiGA candidate.

Question two. Have you talked to at least three founders whose products are already listed in the DiGA directory? Tibor's single strongest piece of advice on this topic is to get real advice from people who have walked the path. Theoretical advisors who have never submitted to BfArM are exactly the expensive, wrong advisors Felix has watched founders burn money on in first-thirty-days coaching.

Question three. Does your clinical evaluation under MDR Article 61 include the kind of outcomes data BfArM wants? If not, what would it cost to generate it, and is that cost still rational against the reimbursement revenue you realistically expect?

Question four. Have you modelled the reimbursement trajectory, not just the first-year rate? The first-year rate is the easiest number to find. The out-year rate is the one that determines whether the business model works.

If all four answers are clean, DiGA may be a smart strategic move. If any are unclear, the correct next step is not a BfArM submission. The correct next step is a conversation with a DiGA-experienced founder and, separately, a regulatory advisor who knows where MDR ends and DiGA-specific requirements begin.

Reality Check

  1. Can you state your product's intended purpose in one sentence that would survive an Article 2(12) audit?
  2. Do you have a classification rationale under Annex VIII Rule 11 that cites MDCG 2019-11 Rev.1?
  3. Is your CE mark in place, or do you have a credible plan to get there before touching BfArM?
  4. Have you actually read the current BfArM DiGA guidance in its latest version, not a summary from 2020?
  5. Have you spoken to at least three listed DiGA manufacturers about their real experience?
  6. Does your clinical evaluation generate the kind of benefit evidence BfArM wants, not just the MDR minimum?
  7. Do you understand the difference between provisional listing and permanent listing, and which you are targeting?
  8. Have you modelled the reimbursement rate trajectory over at least five years, not just year one?

Frequently Asked Questions

Is DiGA a replacement for a CE mark? No. A CE mark under MDR is a prerequisite for DiGA listing. DiGA is an additional reimbursement layer managed by BfArM. Founders who try to substitute one for the other end up with neither.

Can only German startups apply for DiGA listing? No. Any manufacturer whose product has a valid CE mark and meets the DiGA requirements can apply, regardless of where the manufacturer is legally established . Non-German manufacturers typically need a German authorised representative or local presence for practical reasons.

How long does DiGA listing take from submission to directory entry? Process timelines are discussed in the companion post on the DiGA fast-track process. Specific BfArM decision windows should be verified against current BfArM guidance before planning a launch around them.

Does DiGA listing guarantee commercial success in Germany? No. Listing makes reimbursement legally possible. Traction depends on physician awareness, patient demand, marketing to the German medical community, and navigating the multi-insurer landscape. Several DiGA-approved manufacturers Tibor has spoken with describe the post-listing commercial phase as harder than the application phase.

Is DiGA right for every digital health startup? No. It is right for low-risk digital health applications with clinical evidence of benefit to the German healthcare system, whose business model tolerates declining reimbursement trajectories. For many startups a private-pay or B2B model through hospitals and clinics is a better fit. Felix routinely coaches founders to run the ROI comparison before committing.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 2(12), Article 52, Article 61, Annex VIII Rule 11, Annex XIV Part A.
  2. MDCG 2019-11 Rev.1 (Rev.1 June 2025). Qualification and classification of software in Regulation (EU) 2017/745.
  3. Tibor Zechmeister, follow-up interview Round 2, Section 4 (DiGA), 11 April 2026. Tibor has not personally guided a product through DiGA and defers to founders with first-hand directory experience on BfArM-specific process details.