DiGA Approval 2026 – the Practical Guide for Manufacturers

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

A DiGA application to the BfArM is not a form you fill out on an afternoon. It is a dossier – 26 data blocks under DiGAV § 2 Abs. 1↗, with CE documentation, clinical evaluation, certificates for information security and data security, data protection concept, evidence study or evaluation concept, liability insurance proof, price statement, and interoperability evidence. Teams touching the regulatory framework for the first time regularly underestimate two things: first, how much of this must be produced before the BfArM is even involved, and second, how quickly the BfArM actually works once the dossier is complete. This guide walks through the application stage by stage, shows which components teams regularly recognise too late, what realistic timelines look like, which cost blocks are not on the BfArM website – and what actually happens after the decision. The regulatory backbone sits in the pillar hub DiGA – Practical Knowledge; this article is the practical addendum.

Fast-track or permanent listing – the decision rule

The first strategic move in a DiGA application is not filling out a field, but choosing the application type. Under DiGAV § 2 Abs. 3 the manufacturer determines in the application whether they apply for permanent listing or provisional listing for the trial period. A switch during the running procedure is ruled out; if a trial fails, a new application is possible at the earliest twelve months after the rejection decision – and a repeated provisional listing is not permitted for the same DiGA (§ 139e Abs. 4 Sätze 9–10 SGB V↗).

The decision hinges on three questions:

1. Is the positive care effect already quantitatively substantiated? If yes – permanent listing. Forcing a finished evidence package into the trial period throws away twelve months and unnecessarily ties up resources in parallel evidence obligations.
2. Which MDR class does the DiGA have? Class IIb can, since the DigiG, no longer be listed for the trial period – for IIb, medical benefit must already be demonstrated at application (§ 139e Abs. 2 Satz 3 SGB V↗; DiGA-Leitfaden v3.6 Kap. 2.3.1). Teams building IIb are on the permanent listing track from day one.
3. Is the data base sufficient for a robust evaluation concept with a realistic study endpoint definition? Provisional listing requires a systematic data analysis of previous use plus an evaluation concept from a manufacturer-independent scientific institution. Teams without this base are not applying for fast-track as a simplification – they are postponing the study risk.

Our rule of thumb with clients: the trial period is not an entry discount, it is a financing and time buffer for teams that generate evidence during the market phase. Teams with the study in hand go permanent. Teams without the study but with solid quantitative preliminary data can use the trial period sensibly. Teams with neither are not yet application-ready.

The six stages of the BfArM procedure

The procedure is often described as “three months”. That holds for stages three through five. Stages one, two, and six are underexposed in public descriptions – and that is precisely where applications get stuck.

Stage 1 – Receipt and acknowledgement

The application is submitted electronically via the BfArM DiGA application portal. Under DiGAV § 16 Abs. 1↗ the BfArM acknowledges receipt of complete application documents within 21 days. The word “complete” is not rhetorical here: if incompleteness is established, stage two starts, not stage three.

Stage 2 – Completeness check and request for further information

The BfArM, naming the missing documents, asks the manufacturer to complete the application within a deadline of up to three months (DiGAV § 16 Abs. 2). If, after the deadline expires, the application documents are not complete, the BfArM rejects the application by decision. That is an administrative rejection, not a substantive one – but it counts as a rejection and forces a new application.

This stage is the most common silent time sink. Teams that plan with “three months at the BfArM” on the drawing board find themselves four months later in the request-for-further-information loop because the BSI TR-03161 test report date does not match the MDR documentation, the intended purpose in CE documentation and application diverge, or the liability insurance sum in the application does not match the policy.

Stage 3 – Substantive assessment

Once a complete application is in hand, the assessment decision under DiGAV § 13↗ runs. The BfArM checks safety and functional capability, quality according to the requirements on data security, data protection, and interoperability, as well as positive care effects – via medical benefit and/or patient-relevant procedural and structural effects. The assessment is a weighing, not an algorithm: it takes into account the particularities of the indication, the risk of the DiGA, and existing care alternatives.

Stage 4 – Substantive request for further information

If the BfArM identifies substantive gaps in the assessment, it can issue a further request for further information under paragraph 2 with a deadline of up to three months. This request works differently from the formal one in stage two: it is substantively grounded, often focused on individual evidence points or methodological aspects, and it can be minimised – not eliminated – through preventive quality of the submission document.

Stage 5 – Decision

The decision arrives within three months of completeness (§ 139e Abs. 3 Satz 1 SGB V↗; in justified individual cases a one-off extension of up to another three months). It can read: listing (permanent or for the trial period), listing with restrictions (for example to a more narrowly defined patient group than applied for), rejection. In the case of provisional listing, the BfArM determines in the decision the type and scope of the parameters to be demonstrated for permanent listing (DiGAV § 17 Abs. 1↗) – this is the regulated frame within which the trial study is to be conducted.

Stage 6 – Listing in the DiGA directory

Only with publication in the directory under § 139e Abs. 1 SGB V↗ is the DiGA prescribable. The listing contains the data from the application that become public: intended purpose, indication, patient groups, exclusion criteria, age groups, languages, price (DiGA-Leitfaden v3.6 Kap. 2.2). From this point the twelve-month free-price phase runs.

What is frequently missing in the application

The completeness arithmetic of the 26 data blocks is easy; the operational completeness of each block is the actual work. We see six positions where applications disproportionately often become subject to requests for further information.

Intended purpose with congruent classification

The intended purpose must be formulated verbatim or demonstrably congruently across CE documentation (Declaration of Conformity, instructions for use, clinical evaluation), application, and evidence study. Drift between documents is the standard reason for requests for further information at the “completeness check” stage. Teams that sharpen the intended purpose again against the marketing narrative after the clinical evaluation have automatically built themselves a remediation round.

Study registration and pre-specification

Studies demonstrating positive care effects must be registered in a WHO-ICTRP-compliant study register (in Germany typically in the Deutsches Register Klinischer Studien, DRKS). What matters is not only the registration itself, but the pre-specification of the final protocol and the statistical analysis plan before the first enrolment. A primary endpoint changed after the fact damages the credibility of the evidence package more than most teams expect.

Data Protection Impact Assessment and Annex-1 checklist

The BfArM Data Protection Criteria form the basis for the DiGAV Annex 1 checklist attached to the application. A free-text data protection concept is no longer sufficient – what is required is the testable criteria checklist with reference pointers to internal documentation, plus a DPIA under GDPR Article 35.

Three criteria where we regularly see a need for rectification in practice:

• CTRL_1 – Internal organisation. The controller must appoint a Data Protection Officer (DPO), demonstrate their professional suitability, give them access to all processing operations, and ensure that no role creates a conflict of interest. Non-EU controllers need, under GDPR Article 27, a representative appointed in writing and established in Germany (BfArM Prüfkriterien CTRL_1.4↗).
• DMN_4 – User account and grace period. User accounts must be usable pseudonymously; identity information (health insurance number, real name, address, directly identifying email) MUST NOT be a prerequisite for use. The grace period after the end of the prescription MUST NOT exceed one third of the prescription duration, but a maximum of three months; during the grace period the data are locked, no longer actively usable (BfArM Prüfkriterien DMN_4).
• TOM_3 – Interaction and integration. Push notifications MUST NOT contain health data, MUST be initially deactivated, and MUST only be activatable via informed, explicit consent. Camera, microphone, and location services follow the same logic – initially off, explicit activation, purpose limitation (BfArM Prüfkriterien TOM_3).

The BfArM criteria distinguish consistently between “documented” and “established” (BfArM Prüfkriterien GLSR_2.4): establishment encompasses conception, documentation, introduction, application, and continuous improvement – in lived practice. A checklist built the day before submission fails at the latest during post-market checks. We cover the criteria in depth in the BfArM Data Protection Criteria article.

BSI TR-03161 test report per DiGA

The test report under DiGAV § 7↗ and DiGA-Leitfaden v3.6 Kap. 3.4 is issued product-specifically. It must match the submitted software state – not a version two sprints older. In practice this means: release freeze for the application state and a clear change management process documenting which commits ran between testing and submission.

TR-03161 lays out, in chapter 2.4, assumptions, threats, and organisational security policies against which the test report is to be measured (BSI TR-03161-1 Kap. 2.4↗): OSP.Authorization (authorisation concept independent of authentication), OSP.CriticalUpdates (vulnerability monitoring plus grace period for outdated versions), OSP.DataSovereignty (user-controlled deletion on local storage and backend), OSP.Disclosure (low-threshold channel for vulnerability reporting, including an anonymous option), OSP.Purpose (strict purpose limitation – location data only where essential for intended use), OSP.SecurityLog (forwarding of security-relevant logs to the backend if a connection exists). The list looks abstract but becomes concrete under review: a DiGA without a vulnerability disclosure channel fails OSP.Disclosure regardless of how good the rest of the code is. For TR-03161 in detail we refer to BSI TR-03161 certification.

MDR Declaration of Conformity and CE evidence

A DiGA is a CE-marked medical device under MDR. Depending on the class, the conformity assessment proceeds via manufacturer declaration (Class I, non-sterile, without measuring function) or with involvement of a Notified Body (Class IIa and above). The application requires the Declaration of Conformity – and, where relevant, the certificates of the Notified Body. “MDR-certified” is not a clean term; the correct phrasing is “CE-compliant under MDR” with a class designation and, for IIa+, naming the Notified Body.

Instructions for use and user roles

The IFU (Instructions for Use) must consistently mirror the user roles (No. 16 of the data blocks), the exclusion criteria (No. 17), and the contract physician activities (No. 18). An IFU that names the physician as co-user but does not describe a physician workflow triggers follow-up questions. The same applies if the exclusion criteria in the IFU are softer than in the application.

The Notified Body question – class-dependent, not universal

The MDR conformity assessment is not in every DiGA project a process with a Notified Body. It depends on the risk class, and more precisely than many process diagrams suggest.

• Class I (non-sterile, without measuring function, non-reusable instruments): The manufacturer declares conformity themselves under MDR Art. 52 Abs. 7↗, registers the product, and affixes the CE mark – without a Notified Body in the product-specific procedure. The vast majority of pure software DiGAs in risk class I follow this path.
• Class IIa and above: Involvement of a Notified Body under MDR Art. 52 Abs. 6 i.V.m. Anhang IX Kap. I und III↗ (or alternatively Annex XI under Art. 52(6) subpara. 2, depending on module). That means: QMS audit by the Notified Body, technical documentation review of a representative device per category, certificate issuance – with the consequence that the DiGA timeline hangs on the Notified Body’s slot availability. These slots are currently tight; new engagements have lead times that rarely accelerate the DiGA project.
• Class IIb since DigiG: Additional sharpness, because IIb is no longer open to the trial period (§ 139e Abs. 2 Satz 3 SGB V↗: evidence of medical benefit at application). The conformity assessment follows MDR Art. 52 Abs. 4 i.V.m. Anhang IX Kap. I und III↗ with assessment of technical documentation per generic product group – which requires that both the MDR certificate of the Notified Body and the comparative study are ready at the time of application. Details in the Class IIb article.

For application strategy this means: the class is a timeline driver, not a compliance by-product. A team that corrects late to “we’re actually IIa” loses six months because the Notified Body has not even been engaged. At the same time, each upward reclassification under MDR drives higher running costs – surveillance audits, annual reports, re-certification cycles. The class question therefore belongs in the product conception phase, not in the regulatory phase.

Communication with the BfArM – consultation, request for further information, appeal

The BfArM is an application authority, but also a consultation partner. The second role is not clear enough to most teams.

Consultation before listing

Under DiGA-Leitfaden v3.6 Kap. 5.4.1 the manufacturer can request a fee-based consultation before application – on evidence design, classification of an application as a DiGA, data security, study concepts. The consultation does not replace legal advice and is not decision-relevant, but it substantially reduces the probability that the application lands in a request-for-further-information loop. For complex indications, borderline cases between DiGA and DiPA, or unclear evidence paths, the consultation is almost always a more sensible investment than a blind application.

Consultation after listing

For DiGAs already listed there is a consultation on lifecycle changes (DiGA-Leitfaden v3.6 Kap. 5.4.2) – in practice: where it is unclear whether a planned change is a substantial modification under § 18 DiGAV subject to notification, the BfArM pre-clarification is faster and cheaper than a post-release dispute over classification.

How to respond to requests for further information

Requests for further information come in two forms: formal (completeness) and substantive (assessment). The formal ones can be resolved in a few days with clean documentation – if the documentation exists. The substantive ones are more demanding: they often call for supplementary methodological justifications, partial analyses, or additional analyses of existing study data. Two rules have proven themselves in our observation:

1. Deliver what is asked – not more. The BfArM team assesses specifically; additional, unrequested attempts to rebuild the overall argumentation enlarge the review surface and prolong the procedure.
2. Manage deadlines actively. The three months under § 16(2) DiGAV are an upper limit, not a target. Teams delivering in two weeks get the decision faster – the backlog sits with the manufacturer, not with the BfArM.

Appeal and second attempt

A rejection decision is an administrative act – objection and action before the administrative court are open. In practice the legal route rarely pays off: it is long, expensive, and does not address the underlying gaps (usually evidence or completeness). The second attempt with a materially improved application is almost always the faster way – with the exception that, after a failed trial period, a new application is possible at the earliest twelve months after the rejection decision, and a repeated provisional listing is ruled out for the same DiGA.

Realistic timelines – 9 to 18 months are not spent at the BfArM

The regulation is fast, the preparation is slow. We explain the 9–18 months DiGA time-to-market like this:

Lead-in (3–9 months): therapy concept, intended purpose, regulatory classification (DiGA vs. DiPA vs. other reimbursement paths), evidence strategy, go/no-go decision on the trial period. For internationally working teams reading DiGAV for the first time, this section regularly doubles – not because of the language, but because of the mental shift from FDA SaMD thinking to German DiGA thinking.

Product and regulatory (3–12 months): MDR conformity assessment, IEC 62304 process, ISO 13485 QMS, risk management under ISO 14971, clinical evaluation, usability under IEC 62366-1. For Class IIa or IIb the Notified Body is added – their slot situation determines the cadence.

Security track (2–4 months parallel, 12 months serial): BSI TR-03161 testing per DiGA, ISMS certificate (ISO 27001), penetration tests by preferably BSI-certified testing bodies, BfArM Data Protection Criteria implementation. This section determines whether a DiGA reaches application readiness in twelve weeks or twelve months – it is the sharpest lever for platform architecture.

Evidence study (3–12 months active data collection + analysis): For permanent listing the study must be completed and analysed before application. For provisional listing it runs during the trial period of up to twelve months, extendable once to up to 24 months.

BfArM procedure (3–6 months): three months target under § 16(1) DiGAV, plus time for requests for further information.

What stands out: the BfArM share is the shortest single block. The critical path almost never runs through the BfArM, but through the Notified Body, the testing body, or the study. Teams that organise their work strictly serially – first MDR, then data security, then data protection, then study – land at 18 months and more. Teams working on a platform with pre-validated modules deliver the product-side section in 12 weeks and run study and regulatory tracks in parallel.

Costs – what the BfArM does not put on its website

The actual costs of a DiGA approval are the most poorly publicly documented figure in the entire procedure. The BfArM levies administrative costs at flat-rate fee rates, additional individually attributable public services as expenses; collection follows §§ 13 to 21 of the Federal Fees Act accordingly (§ 139e Abs. 7 SGB V↗; DiGA-Leitfaden v3.6 Kap. 5.5). The specific amounts come from the Special Fee Ordinance of the BMG and sit, by practical observation, in the low to middle five-figure range depending on application type – for a first application the calculable item.

The relevant cost blocks sit upstream and are qualitatively sorted from our advisory observation – not negotiated contract figures, not project accounting, but market bands:

• Therapy concept and intended purpose: low to middle five-figure range, strongly dependent on whether a clinical guideline is available as a frame. For complex indications or child/adolescent contexts: middle five-figure range upwards.
• MDR conformity assessment, clinical evaluation, IEC 62304, ISO 13485 QMS, risk management: middle five-figure to low six-figure range per DiGA if the QMS is set up anew. With an existing QMS the effort drops markedly, because the QMS itself is not rebuilt per product.
• BSI TR-03161 testing per DiGA including pentest: testing by a preferably BSI-certified testing body plus pentests plus evidence documentation sits in a corridor from middle five-figure to low six-figure range, depending on system complexity (backend scope, number of interfaces, platform scope). First certification is more expensive than re-certification for smaller changes.
• Data protection architecture, BfArM criteria implementation, DPIA: middle five-figure range if the architecture already follows privacy-by-design. Otherwise markedly more, because almost every one of the roughly 150 individual requirements of the BfArM criteria leaves traces in infrastructure or process.
• Evidence study under § 10 DiGAV: by far the largest single item. Six-figure at minimum; with elaborate prospective study designs or high case numbers it goes into the seven-figure range. The study is largely independent of the chosen development architecture and hits in full in practically every DiGA project.
• Internal person-days: the most frequently underestimated item. Product management, regulatory, QMS roles, clinical affairs, data protection officers, and leadership bind between 300 and 800 internal person-days over the course of a first application. These costs do not show up on any invoice – they show up on the calendar.

Together a classic custom build lands at a realistic total effort between €500,000 and €2M per first application – not because the software is that expensive, but because compliance work arises anew per project. The BfArM application fee itself is never the decisive item; it is the easiest one to pay.

After the decision – what being listed means

Listing in the directory is not the conclusion of the regulatory work block, but its beginning on a new level. Five obligation lines begin with the listing date.

Free-price phase and reimbursement negotiation. For twelve months the manufacturer bills the freely set manufacturer price; after this year the reimbursement price negotiated with the GKV-Spitzenverband takes effect – retroactively, if the negotiation takes longer (DiGA-Leitfaden v3.6 Kap. 5.2.1). From 01.01.2026 the reimbursement agreement binds at least 20% of the reimbursement price to performance-dependent parameters (DiGA-Leitfaden v3.6 Kap. 6.1). We treat the mechanism in detail in the article AbEM – application-accompanying performance measurement.

Data protection and data security oversight. The BfArM criteria are not a one-off demonstration: changes to processing purposes, processors, storage locations, logging depth, or account management fall under the catalogue of monitoring duties and can become notifiable as substantial modifications.

Reporting duties under § 33a Abs. 6 SGB V↗. The GKV-Spitzenverband’s annual report on DiGA care is a collective reporting duty fed from manufacturer-side data; at the same time manufacturer-side reporting duties on use and effectiveness run via AbEM (§ 139e Abs. 13 SGB V↗, first delivery 15.04.2027, thereafter half-yearly).

Substantial modifications under § 18 DiGAV. Changes are substantial if they have a significant impact on safety, functional capability, quality, data protection, data security, or evidence – or if they alter directory entries (DiGAV § 18↗). The BfArM provides an electronic check form. Teams rolling out a feature release that changes the patient group and not notifying it risk removal from the directory. Detail questions are covered in Substantial Modifications to DiGAs.

Mandatory further developments. The mandatory calendar points from Ch. 5.2.4 of the guide (ePA integration since 01.01.2024, BSI TR-03161 per DiGA since 01.01.2025 / application-relevant 01.07.2025, AbEM Stage I from 01.07.2026, Stage II from 01.07.2027, Stage III from 01.07.2028) apply retroactively to already-listed DiGAs as well. Each year this calendar binds part of the product capacity that would otherwise flow into outcome improvements.

Frequently asked questions

Further reading

For teams wanting to look deeper at individual stages of the application procedure, the knowledge area DiGA offers thematic deep-dives: the BfArM Data Protection Criteria in detail, the application-accompanying performance measurement (AbEM), the particularities of Class IIb since DigiG, and the most common rejection reasons. For the question of whether a DiGA is the right reimbursement path at all, see the Reimbursement Paths pillar.