DiGA – practitioner knowledge for digital health applications

By Christoph Eberhardt · CEO, DUX Healthcare · as of 17 April 2026

This knowledge area is the DUX guide to Digital Health Applications (DiGA) – not an encyclopaedia, but a collection of practical assessments of how the German DiGA process actually works: how the BfArM procedure runs under the DiGAV (as of 27.01.2026) and the DiGA Guide v3.6 (as of 10.12.2025), which data protection and cybersecurity requirements are sharp today, how positive care effects are reliably demonstrated, what the Performance Measurement (AbEM) means for pricing from 2026, and where international teams systematically underestimate what market entry in Germany costs. Written from the perspective of a company that has been building digital medical devices for more than ten years – seven years as a Software-as-Medical-Device specialist, with five DiGAs running on its own platform. Where we have a position, we mark it as such; where the regulation is unfinished, we say so.

What a DiGA is – and what it is not

A Digital Health Application (DiGA) is, under § 33a Abs. 1 SGB V↗, a CE-marked medical device of a low risk class (Class I, IIa or – since DigiG – IIb under MDR Art. 51 i. V. m. Anhang VIII↗), whose main function is substantially based on digital technologies, which supports the detection, monitoring, treatment or alleviation of a disease, and whose positive care effects against non-treatment or standard treatment are demonstrated or are to be demonstrated during a pilot phase.

Three distinctions teams regularly get wrong:

1. A DiGA is not wellness. Preventive primary applications without a diagnosed indication cannot be listed in the DiGA directory under DiGA-Leitfaden v3.6 Kap. 2.1.4. Secondary and tertiary prevention fall under “treatment” – but only if a risk factor can be coded as a diagnosis.
2. A DiGA is not a DiPA. Digital care applications under § 40a SGB XI (long-term care funds) follow a separate regulatory framework (DiPAV). The BfArM process is different, the evidence threshold is different, the pricing mechanics are different. Product teams building for care do not go through the DiGAV.
3. A DiGA is not a pure patient portal. Functions without a medical intended purpose – pure appointment booking, shop integration, community – are optional additional services and must be segregated without endangering the care effects (DiGA-Leitfaden v3.6 Kap. 2.1.3). An “app with health features” is not a DiGA; a DiGA with a community feature is.

Teams that draw these three distinctions cleanly at the start save themselves six months of wrong product build. Teams that skip them end up in the BfArM back-and-forth cycle or on the wrong reimbursement path. We cover the adjacent paths (DiPA, HMV, ZPP, NUB, selective contracts) in a separate knowledge area on reimbursement paths, which goes online in the coming weeks.

Who can apply – and what “manufacturer” really means

Eligible to apply is the manufacturer in the medical device regulatory sense, i.e. the party that places the DiGA on the market under its own name and signs the EU Declaration of Conformity under MDR Art. 19↗ (GLSR_2.3, BfArM Datenschutzprüfkriterien v1.0↗). For non-European companies, this means: no DiGA without an EU-resident Legal Manufacturer. This is the most frequent blocker for US and UK teams choosing Germany as their first reimbursement market; a dedicated guide on international market-entry paths will follow in a later wave.

The BfArM process in practice – fast-track vs. final listing

In public perception, the BfArM procedure is the bottleneck. The numbers say something different: measured as what-the-BfArM-actually-does, the fast-track procedure is one of the fastest market-access procedures in Europe. It only feels slow because the heavy work packages sit in front of it.

Two application types, not three

The DiGAV recognises exactly two application types (DiGA-Leitfaden v3.6 Kap. 2.3):

• Permanent listing – when the comparative study under § 10 DiGAV is already available and the positive care effect is demonstrated. The manufacturer submits the finished package and the BfArM decides within three months of a complete application.
• Provisional listing for a pilot phase – for DiGA in Class I/IIa, where a systematic data evaluation plus an evaluation concept from a manufacturer-independent scientific institution are available. The evidence study is conducted during a pilot phase of up to twelve months, extendable once by up to twelve months (max. 24 months in total).

The pilot phase is not open to Class IIb – since DigiG, medical benefit must be demonstrated on submission for IIb (DiGA-Leitfaden v3.6 Kap. 2.3.1). Whoever builds in IIb is on a permanent-listing track from day one.

A change of application type during the procedure is not possible. If a pilot phase fails – either because the study report does not arrive in time or because the evaluation is negative – the DiGA is delisted, and a new application is possible at the earliest twelve months after the rejection decision. A second provisional listing is ruled out.

The three-month rule that rarely applies as a rule

The BfArM confirms receipt of complete application documents within 21 days (DiGAV § 16 Abs. 1↗). If they are incomplete, the BfArM requests supplementation – and sets a deadline of up to three months. Whoever misses the deadline receives a rejection notice (§ 16 Abs. 2 DiGAV).

This is the mechanism teams underestimate. “Three months to listing” is the statutory target period from a complete application. The realistic practical time is significantly longer, because the completeness of the application – 26 individual data blocks under DiGAV § 2 Abs. 1↗, including CE documentation, GDPR conformity, BSI data security certificate, ISMS certificate, study or evaluation concept, liability insurance proof, pricing data, interoperability proof – is rarely achieved at the time of submission.

The 26 data blocks – why completeness is not trivial

DiGAV § 2 Abs. 1 lists 26 data blocks (Nr. 1 to 26, including Nr. 4a and 21a) that the application must contain. They range from obvious items – manufacturer, product name, intended purpose, instructions for use – to details that teams regularly underestimate: the medical institutions involved in development (No. 7), the sources of medical content including guidelines, textbooks and studies (No. 8), the contractual physician activities the manufacturer considers necessary (No. 18), user roles (No. 16), the exclusion criteria for quality-assured use (No. 17), the locations of data processing (No. 20), the semantic mapping of the data processed by the DiGA to the ePA specifications (No. 21a), the level of liability insurance coverage (No. 23) and the data from aids and implants transmitted under § 374a SGB V↗ (No. 26).

The key strategic point: under paragraph 3, the manufacturer determines in the application whether to apply for a permanent or a provisional listing. A change of application type during the procedure is not possible. Whoever does not choose the application type cleanly – because the evidence strategy is still open, because the class has been misjudged, because the indication boundaries are not yet stable – pays the price for the unresolved issue at the latest on submission. Data blocks 9 through 13 (PICO short form, patient groups, positive care effects, studies, diagnostic accuracy study) are tightened for Class IIb: they must also be suitable to carry the medical benefit – structural and procedural improvements alone are not enough.

The realistic timeline

When we talk to DiGA teams, we break down the actual timeline like this:

• Lead-up (therapeutic concept, intended purpose, evidence strategy, regulatory path): depends on the team, typically 3–9 months for international firms navigating the DiGAV for the first time.
• Product and regulatory work (MDR conformity assessment, IEC 62304, ISO 13485, risk management, clinical evaluation, usability): 3–12 months, depending on class and whether a Notified Body is involved.
• Data protection & data security (BSI TR-03161 per DiGA, ISMS certificate, BfArM Data Protection Criteria, DPIA): 2–4 months – but only if the security track runs in parallel. Sequentially it costs a year.
• Application at the BfArM + formal review + decision: 3–6 months, depending on completeness at submission.

We tell our clients: twelve weeks, not twelve months – for the product-side section, once the medical intended purpose is in place and the regulatory work is mapped on a platform. BfArM and evidence study come before or run in parallel, not inside the twelve weeks. Teams without the platform principle end up at nine to eighteen months – and not because the BfArM works slowly.

Demonstrating positive care effects – the evidence bottleneck

The real bottleneck of DiGA is not regulation. It is evidence.

DiGAV § 10↗ requires, for the proof of positive care effects, a comparative study showing that the application is better than non-use. “Better” is quantitative, appropriately chosen and transferable to Germany. The comparator must match the reality of care – a DiGA versus “no therapy” is only admissible if no therapy is actually the status quo. Studies must in principle be conducted in Germany; foreign studies are admissible on a case-by-case basis if the manufacturer demonstrates transferability to the German care context (DiGA-Leitfaden v3.6 Kap. 4.3.9).

The GKV-Spitzenverband notes in its report for 2025 (reporting period up to 31.12.2025) that of 74 DiGA admitted by the end of 2025, only 14 were already able to provide evidence of benefit on admission – around 19 % (GKV-Spitzenverband DiGA-Bericht 2025↗). That is the payer’s perspective and should be read as such – but the bare number is correct. The industrial counterweight, the SVDGV, phrases the same figure differently: 34 DiGAs have made the transition from pilot phase to permanent listing, which demonstrates that the pilot-phase model works (SVDGV DiGA-Report 2025↗).

Both readings are correct. But they answer different questions. The payer asks: “What are we getting for the money we are paying today?” The industry asks: “Does the fast-track work as a market-entry path?” For a manufacturer submitting in the next 18 months, what matters is: the evidence threshold will not fall. It will be supplemented by AbEM, not replaced – and the evaluation decision under DiGAV § 13 Abs. 1↗ is a judgement, not an algorithm. The BfArM takes into account the particularities of the indication, the risk of the DiGA and existing care alternatives.

What the DiGAV accepts as a “comparative study”

The procedure is methodologically more open than many teams assume. § 10 DiGAV allows:

• Retrospective comparative studies, including those with intra-individual comparison (§ 10 Abs. 1).
• Prospective comparative studies as an alternative (§ 10 Abs. 2).
• Health services research and social research methods – not only clinical RCTs – as long as the approach is appropriate for the care effect to be demonstrated and remains quantitatively comparative (§ 10 Abs. 3).

The comparator rule is strict: non-use can mean non-treatment or treatment without a DiGA. Another DiGA may only serve as comparator if it is permanently listed in the directory – DiGAs in a pilot phase cannot serve as reference (§ 10 Abs. 4). Studies must in principle be conducted in Germany; foreign studies are admissible on a case-by-case basis where the comparability of treatment guidelines, of the health system (access and reimbursement) and of the validated assessment instruments in the language version used is demonstrated (DiGA-Leitfaden v3.6 Kap. 4.3.9).

Studies must be registered in a WHO-ICTRP-compliant study registry; the German Clinical Trials Register (DRKS) at the BfArM is the obvious registrar. Study results must be published at the latest twelve months after study completion – including negative results – and the complete Clinical Study Report must be disclosed in anonymised form (§ 10 Abs. 6 DiGAV; DiGA-Leitfaden v3.6 Kap. 4.4). A peer-reviewed publication is not mandatory, but the international standard reporting logic (CONSORT for RCTs, analogous standards for other designs) applies.

Study design – our position

We see three errors that systematically recur in DiGA evidence packages:

1. Under-powered sample size. Studies that do not cleanly define a clinically relevant minimum difference do not fail in the protocol but in the results report – when the p-value does not hold or the confidence interval spans the clinical relevance threshold.
2. Comparator in theory, not in the reality of care. “Usual care” in an academic study context is not the same status quo as the average primary-care management of an indication. External validity suffers, and the BfArM questions transferability.
3. No pre-specification. The WHO-ICTRP-compliant study registry (in Germany: DRKS) is mandatory, but pre-specification of the final protocol including the statistical analysis plan is decisive for the credibility of post-hoc robust results (DiGA-Leitfaden v3.6 Kap. 4.3.10).

The study is not the first thing a DiGA company builds – but the first thing it must think about once the intended purpose is set. It is the most expensive single item. It is the one that cannot be retrofitted.

Data protection as a first-class citizen – not a checklist

The misconception most teams arrive with is: “We have GDPR and an ISMS, so we’re through.” Since the 2024 and 2025 cut-off dates, that is no longer true.

The four layers that must align in the application

1. GDPR conformity within the DiGAV framework. DiGAV § 4 Abs. 2↗ restricts admissible processing purposes to four exhaustively listed cases: intended-purpose use, proof of positive care effects, the AbEM dataset, technical functionality and further development. Advertising is excluded. Consent for further development must be obtained separately. Third-country processing only in the EU/EEA or under an adequacy decision (§ 4 Abs. 3).
2. BfArM Data Protection Criteria under § 139e Abs. 11 SGB V↗. Since 01.08.2024, DiGA must implement the BfArM-published criteria catalogue – around 150 individual requirements with the RFC-2119 keywords MUSS, DARF NICHT, SOLL, KANN, distributed across twelve thematic blocks from accountability via logging to deletion (BfArM Datenschutzprüfkriterien v1.0 GLSR_1↗). Unlike the GDPR’s general clauses, these criteria are testable and are attached to the application as a checklist (Annex 1 DiGAV).
3. ISMS certificate. Mandatory since 01.04.2022 – ISO 27001 or ISO 27001 on the basis of IT-Grundschutz (BSI Standard 200-2). An accredited certificate, not “conformant” (DiGA-Leitfaden v3.6 Kap. 3.4.1).
4. BSI TR-03161 data security certificate. Mandatory since 01.01.2025, formally application-relevant since 01.07.2025. The certificate is issued per DiGA, not per company – a point we elaborate below. An ISMS certificate explicitly does not suffice (DiGA-Leitfaden v3.6 Kap. 3.4).

What “per DiGA” means in practice

A widespread but incorrect way of speaking is: “We are BSI TR-03161 certified.” Under § 139e Abs. 10 SGB V↗, the certificate is issued product-specifically. What is certified is a concrete DiGA version, not a manufacturer. Platform effects arise not from certificate transfer, but from shared architecture: shared libraries, shared backend services, shared development process. Our DiGAs are tested under BSI TR-03161 per DiGA – not the company.

For the initial certification of a DiGA, penetration tests for all components including the backend are mandatory, primarily by BSI-certified testing bodies, with manual code reviews and whitebox tests based on the BSI implementation concept and the OWASP Top Ten (DiGA-Leitfaden v3.6 Kap. 3.4.2).

Alongside, we hold a second certification across our portfolio: BSI TR-03185 – Secure Software Lifecycle. This is a different test level. TR-03185 certifies the organisation’s development process – the audit looks at how software is built, not at what it looks like in the end. DUX Healthcare was the first company to receive BSI TR-03185 certification. The certification is binary – no “with conditions”, no “without conditions” – and it does not change the role of the TR-03161 per-DiGA review. Details are in our BSI TR-03161 guide in English.

Pricing and AbEM – why the 20 % rule changes everything

The economic model of DiGA has shifted in two steps: with the DigiG, the price-negotiation mechanisms were tightened; with the 2nd DiGAV amendment ordinance and the Performance Measurement (AbEM), a performance-based price component becomes binding from 2026.

The mechanics today

After listing, the manufacturer may charge a freely set manufacturer price for twelve months. After this first year, the reimbursement price negotiated with the GKV-Spitzenverband takes effect – retrospectively, if negotiation takes longer (DiGA-Leitfaden v3.6 Kap. 5.2.1).

The GKV-Spitzenverband reports an average manufacturer price of €544 for 2025 against an average negotiated reimbursement price of €227 – a delta of a factor of 2.4 (GKV-Spitzenverband DiGA-Bericht 2025). The interpretation is not neutral: from the payer’s perspective the delta is a structural problem (free pricing without proof of benefit); from the industry’s perspective it is risk compensation for seed financing during the pilot phase. Both sides are right – and both sides know that the 20 % rule shifts the conflict rather than resolving it.

The 20 % rule and what it actually does

From 01.01.2026, the reimbursement agreement provides for a share of success-dependent price components of at least 20 % of the reimbursement price (DiGA-Leitfaden v3.6 Kap. 6.1). “Success-dependent” means: tied to the parameters collected in AbEM – usage data today, PGI-C and patient satisfaction from 2027, indication-specific PROMs from 2028.

What this means economically:

• The risk of “therapeutically ineffective but marketed” shifts from the payer to the manufacturer.
• Product quality over the lifecycle (retention, drop-out rate, patient-perceived change) becomes price-relevant – not only the approval evidence.
• The temptation to price too high early becomes more expensive: if the AbEM data is weak after a year, the success-dependent share is cut retrospectively.

We do not read this as an “attack on DiGA” – but as a signal that DiGA is moving from a pure reimbursement mechanism to an outcome-linked product model. This is structurally advantageous for platform-built DiGA: retention, engagement and drop-out rate are measurable and optimisable in a module-based architecture, and must be rebuilt by hand every time in a custom build.

Mandatory further developments – the calendar that regularly surprises

The DiGA rulebook is a moving target. From Guide v3.6 (DiGA-Leitfaden v3.6 Kap. 5.2.4), the following mandatory calendar arises for already-listed DiGA – each of these requirements is retrospectively binding for existing DiGAs, not only for new applications:

• From 01.04.2022: ISMS certification under ISO 27001 or ISO 27001 on the basis of IT-Grundschutz (BSI Standard 200-2), accredited certificate.
• From 01.01.2024: Interoperable export interface and ePA connection under § 6a DiGAV, GesundheitsID connection under § 291 Abs. 8 SGB V↗.
• From 01.01.2025: BSI TR-03161 data security certificate per DiGA, formally application-relevant from 01.07.2025.
• From 01.01.2026: Success-based price components ≥ 20 % in the reimbursement agreement.
• From 01.07.2026: AbEM data collection stage I (usage data).
• From 15.04.2027: First AbEM data delivery to the BfArM, then semi-annually.
• From 01.07.2027: AbEM data collection stage II (PGI-C, patient satisfaction).
• From 01.07.2028: AbEM data collection stage III (indication-specific PROMs from the BfArM list).
• In future: Data protection certification under Article 42 GDPR (date open).

Whoever does not have this calendar in their roadmap builds short-term mandatory work between productive release cycles every year. This is operationally expensive and strategically uncomfortable, because every year product capacity has to be kept free for mandatory rework – exactly the capacity that is actually needed for the AbEM-relevant outcome improvements.

The AbEM stages at a glance

The obligation to conduct AbEM applies to all permanently listed DiGAs that have demonstrated at least a medical benefit and are reimbursed as part of standard care; data from self-payers remain excluded (DiGA-Leitfaden v3.6 Kap. 6.1). In the data analysis, a distinction is made between initial and direct follow-up prescriptions – only data that is not identifiable to the manufacturer as a follow-up prescription feeds into the reported results, to reduce sample bias from self-selection.

First transmission to the BfArM: 15.04.2027, then semi-annually (15 April and 15 October). Quarterly evaluation (DiGA-Leitfaden v3.6 Kap. 6.2). Details are in the dedicated guide AbEM – the new Performance Measurement.

ePA, interoperability and § 374a SGB V – the next hurdle

While the data protection block is mature, the interoperability block is the open front. DiGAV § 6a↗ requires DiGAs, with the consent of insured persons, to be able to transfer their data to the electronic patient record (ePA) under § 341 SGB V↗ – via the interface defined by Gematik under § 354 Abs. 2 Nr. 6 SGB V↗, in a human-readable format and conformant with the specification on semantic and syntactic interoperability under § 355 Abs. 2a SGB V↗.

The obligation to connect to the ePA has applied since 01.01.2024 (DiGA-Leitfaden v3.6 Kap. 5.2.4). Updates to the semantic specifications must be implemented within six months of publication (§ 6a Abs. 3 DiGAV). This is the sentence that most often surprises teams: ePA integration is not a one-off job but an ongoing maintenance effort.

On top of that, § 374a SGB V↗ – DiGAs must be able to process data from aids and implants, insofar as they are relevant to the intended purpose. Which product names are transmitted and what data is involved must be stated in the application (DiGAV § 2 Abs. 1 Nr. 26). For cardiology or orthopaedic indications, this is not a side topic but half the architectural setup.

What goes wrong – the most common reasons for rejection

We read the feedback our clients and partners bring back from BfArM procedures. This is not representative statistics – it is observation. The patterns repeat themselves in very similar form, though, and they broadly match the positions that the GKV-Spitzenverband and the BfArM express in public statements.

The four most common stumbling blocks:

1. Incomplete application. The BfArM does not primarily demand “more evidence” – it first demands completeness. If any one of the 26 data blocks under § 2 Abs. 1 DiGAV is missing, § 16 Abs. 2 DiGAV sets a deadline, and whoever misses it receives a rejection notice. This is administrative law, not content.
2. Evidence package does not match the applied-for indication. Studies that sought to prove a broadly formulated indication but actually cover only a narrow patient group lead to restrictions in the listing. According to the GKV report 2025, every fifth DiGA that moves from a pilot phase to permanent listing is listed with restrictions.
3. Data protection checklist formally met, operationally not lived. The BfArM criteria consistently distinguish between “documented” and “established” (GLSR_2.4). Established means: in lived practice, with operation and continuous improvement. Teams that do not actually live the change process after the release kick-off fail at the latest in post-market reviews.
4. “Substantial change” underestimated. Under DiGAV § 18↗, changes are substantial if they materially affect safety, functional capability, quality, data protection, data security or the evidence – or if they alter directory entries. The BfArM provides an electronic review form. Whoever rolls out a feature release that changes the patient group and fails to notify it risks delisting.

Most rejections are not substantive evidence problems but process problems. Evidence failure is noticed late (after study end), but process failure is noticed early enough to prevent it. That is why we work in the knowledge base with process deep-dives – the approval guide and the BfArM Data Protection Criteria in detail – rather than generic evidence essays.

The market in 2026 – numbers and how to read them

We are reluctant to cite market numbers in a knowledge section tied to regulation. But three numbers from the GKV report 2025 are so central that they cannot be skipped – and we cite them with explicit attribution:

• By the end of 2025, 74 DiGAs had been listed in the directory; 58 were still listed at the end of 2025 (48 permanent, 10 in pilot phase), 16 were delisted (GKV-Spitzenverband DiGA-Bericht 2025).
• Around 1.6 million DiGAs were activated by the end of 2025, with an associated SHI spend of around €400 million – of which, in 2025 alone, around 690,000 DiGAs and over €170 million in spend, an increase of 63 % over the previous year (ibid.).
• The average manufacturer price in 2025 was €544, the average negotiated price €227. The GKV report interprets the delta as a steering deficit; the SVDGV report sees it as compensation for seed costs in the pilot phase (SVDGV DiGA-Report 2025).

Both sources are not neutral. The GKV report is submitted to the Bundestag by the GKV-Spitzenverband under § 33a Abs. 6 SGB V↗; it is the payer’s perspective. The SVDGV report is the industry’s perspective. Whoever reads them alongside each other understands the DiGA market; whoever reads them as the sole truth understands one half.

Where DUX comes in – platform, not custom build

DUX Healthcare does not build DiGAs in custom fashion. We build DiGAs on the mHealth Suite: a platform with 80+ pre-validated modules, on which intended purpose, MDR documentation, BSI TR-03161, data protection architecture, ePA interface and AbEM data collection are laid down as jointly borne infrastructure. Five DiGAs run on this platform today – platform-built, each DiGA tested under BSI TR-03161, CE-marked under MDR. At the process level, our software development lifecycle is the first ever to be certified under BSI TR-03185.

Why this is relevant if you are looking for DiGAV knowledge: the platform structurally changes the time and cost envelope of DiGA development – not because we “work faster” but because the requirements the DiGAV places on every DiGA are not rebuilt per project. This enables timelines of twelve weeks, not twelve months for the product-side section (intended purpose in place, BfArM application and evidence study beforehand or in parallel). It is the operational flip side of the regulation that the rest of this knowledge area covers.

If you want to look at the platform mechanics themselves, they live at /build/.

Answers to common questions

Articles in this knowledge area

The DiGA section grows in waves. These three cluster articles are online today; more will follow in the coming weeks. If you need a specific deep-dive, write to hello@dux-healthcare.com – many articles emerge from real practitioner questions.

Approval and application

• DiGA approval 2026 – the practitioner’s guide – how the BfArM application is set up step by step, with a focus on the 26 data blocks under § 2 DiGAV.

Data protection and security

• BfArM Data Protection Criteria in detail – the around 150 criteria, their RFC-2119 grammar, and how they are evidenced in the application.
• BSI TR-03161 Certification – A Practitioner’s Guide – the per-DiGA certificate, the SPD logic, realistic costs and typical weak points.

Evidence and outcome measurement

• AbEM – the new Performance Measurement – stages I/II/III, collection timings, reporting data.