By Christoph Eberhardt · CEO, DUX Healthcare · 17 April 2026
Most US DTx companies arrive at DiGA with an FDA mental model: a risk-based classification, a cleared device, a cybersecurity section in a premarket submission, and – separately, later, painfully – a reimbursement conversation with CMS, commercial payers, and employer-sponsored plans. That mental model is not wrong for the US. It is partially transferable to Germany, and the parts that do not transfer are the parts that matter most. A DiGA is not a German 510(k). It is a combined regulatory-and-reimbursement instrument, built on top of a European CE mark under the MDR, with clinical-evidence, cybersecurity, and data-protection bars that look superficially similar to the FDA regime and diverge in structure, scope, and legal weight. This article maps the two pathways for a US audience, flagging what transfers, what does not, and where the surprises sit.
What DiGA and FDA SaMD actually are
A DiGA (Digitale Gesundheitsanwendung – Germany’s certified digital health application) is a specific legal construct under German social-insurance law. It is a CE-marked medical device under the EU MDR of low-to-moderate risk class (Class I, IIa, or – since the 2024 DigiG reform – IIb), whose “main function rests essentially on digital technologies” and which supports the “detection, monitoring, treatment or alleviation” of a diagnosed condition. Once listed in the public DiGA-Verzeichnis by the BfArM, the product can be prescribed by any German physician or psychotherapist and is reimbursed by GKV (Gesetzliche Krankenversicherung – Germany’s statutory health insurance system) at a price negotiated with the GKV-Spitzenverband.
Software as a Medical Device (SaMD) is defined by the IMDRF as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device” (IMDRF/SaMD WG/N10). The FDA adopted this IMDRF definition and operationalises it through its existing device-regulation framework: SaMD is not a separate regulatory category in the US – it is medical-device software routed through the 510(k), De Novo, or PMA pathways depending on risk, with the IMDRF risk categorisation (Categories I–IV) informing how rigorous a submission has to be.
The important asymmetry: DiGA is a product category with a reimbursement outcome attached; FDA SaMD is a regulatory lens on a subset of medical-device software.
Classification – MDR Rule 11 vs FDA risk-based classification
EU side: MDR Rule 11
Under MDR Annex VIII Rule 11, software intended to provide information used to take diagnostic or therapeutic decisions is Class IIa, except where decisions may cause death or irreversible deterioration (Class III) or serious deterioration / surgical intervention (Class IIb). Software monitoring physiological processes is Class IIa, except for vital parameters with immediate-danger variations (Class IIb). All other software is Class I.
Rule 11 was a tectonic shift from the old MDD. Under the MDR most therapeutic software is Class IIa or higher – which means a Notified Body product audit, substantially higher conformity-assessment effort, and a QMS under ISO 13485 as table stakes. Class I DiGAs exist, but many DTx products sit at Class IIa; Class IIb has been in scope since 2024 but has no preliminary-listing route (the pivotal study must be complete at filing).
US side: three pathways, one risk framework
The FDA classifies medical devices as Class I (low risk), Class II (moderate risk), or Class III (high risk). For SaMD, the practical pathway split is:
- 510(k) Premarket Notification – most Class II SaMD. Demonstrates substantial equivalence to a legally marketed predicate device. Documentation follows FDA Premarket Software Guidance (June 2023), with a two-tier Basic / Enhanced Documentation Level model.
- De Novo Classification Request – for novel low-to-moderate-risk SaMD without a legally marketed predicate. The FDA determines classification on first clearance.
- PMA (Premarket Approval) – Class III devices. Rare for behavioral-health and DTx categories.
Mapping with caveats
A rough rule-of-thumb mapping, with the caveat that CE marking under MDR is not FDA clearance and vice versa:
| MDR / DiGA side | FDA / US side |
|---|---|
| MDR Class I – manufacturer self-declaration; eligible for DiGA preliminary listing | FDA Class I – often 510(k)-exempt or 510(k) with low-risk comparator |
| MDR Class IIa under Rule 11 – Notified Body product review; eligible for DiGA preliminary or permanent listing | FDA Class II – typically 510(k); De Novo if novel |
| MDR Class IIb – Notified Body; DiGA permanent-listing only, no preliminary route | FDA Class II with higher scrutiny, or De Novo; sometimes PMA for high-risk AI |
| MDR Class III – not DiGA-eligible | FDA Class III – PMA required |
Three practitioner points:
- A 510(k)-cleared product is not automatically CE-markable. The technical file, clinical evaluation, and post-market surveillance plan have to be built against MDR requirements. IEC 62304 and ISO 14971 are shared reference points; substantial parts of the risk file and architecture documentation transfer.
- CE marking is a precondition for DiGA listing, not a substitute for it. The DiGA Guide v3.6 Sec. 2.3.4 is explicit. FDA clearance does not short-circuit the MDR path.
- Class assignment matters for the DiGA listing route. MDR Class I and IIa can enter via preliminary listing; Class IIb must arrive with completed evidence.
Intended use – “indications for use” vs Zweckbestimmung
Both systems anchor everything else in a precise purpose statement. On the US side, “indications for use” is the FDA-recognised purpose statement. On the German side, the Zweckbestimmung (intended purpose) under MDR Article 2(12) does the same anchoring work, plus more: it defines the MDR classification, the scope of the clinical evaluation, the labeling, the instructions for use, the declaration of conformity, and – for a DiGA specifically – the indications cited in the BfArM application.
Three contrasts:
- Scope discipline. The FDA 510(k) summary is a summary; the Zweckbestimmung is an operative legal text that travels through the entire MDR and DiGAV regime.
- Indication-specific evidence. The DiGAV § 10 comparative study must be designed for the indication in the Zweckbestimmung. About one in five DiGAs transitioning from trial to permanent listing is listed with restrictions, per the GKV-Spitzenverband 2025 report.
- Changing the purpose statement is a regulatory event. Under DiGAV § 18, changes that materially affect safety, functional suitability, data protection, or evidence are “substantial changes” requiring BfArM notification.
A US team that has an indications-for-use statement cleared by the FDA has most of the conceptual work done, but the Zweckbestimmung for MDR and DiGAV purposes must be re-drafted with German regulatory grammar.
Clinical evidence – pivotal studies, positive care effects
This is where the two systems diverge most decisively.
FDA pathway: substantial equivalence or reasonable assurance
A 510(k) demonstrates substantial equivalence to a predicate device. Clinical evidence is required when performance testing cannot establish equivalence; for many DTx products, a comparative usability study or modestly-sized clinical study is sufficient. A De Novo clearance requires reasonable assurance of safety and effectiveness – typically a pivotal clinical study, pre-specified endpoints, FDA pre-submission alignment. PMA requires a pivotal randomised study.
The common denominator: clinical evidence for FDA clearance is about safety and effectiveness, not about comparative benefit vs usual care. A 510(k)-cleared DTx product may be on the market with no comparative efficacy data whatsoever.
DiGA pathway: comparative study for positive care effects
DiGAV § 10 requires a comparative study showing that use of the DiGA is better than non-use – better on a medical benefit (mortality, morbidity, quality of life, symptom severity) or on a patient-relevant structural/procedural improvement (adherence, access to care, health literacy, coordination-of-care). The study designs accepted are broader than the US pivotal-RCT default:
- Retrospective comparative studies, including intra-individual designs (§ 10 para. 1).
- Prospective comparative studies (§ 10 para. 2).
- Health-services research and social-research methods, quantitative-comparative (§ 10 para. 3).
“Usual care” as a comparator has to be the actual German status quo. Foreign studies are admissible only if the manufacturer can demonstrate transferability of care guidelines, health-system context, and validated instruments in the relevant language (DiGA Guide v3.6 Sec. 4.3.9). Studies must be registered in a WHO-ICTRP-compliant registry; the full clinical study report must be disclosed in anonymised form.
Cross-walk: can FDA-stage evidence satisfy the DiGA bar?
Usually not. A 510(k) clinical dataset is rarely designed as a comparative study against a German usual-care comparator. A De Novo pivotal study is closer – often randomized, often comparator-controlled – but the comparator, the patient population, and the endpoints typically do not map to a BfArM-acceptable “positive care effect” on the indication claimed in the DiGA Zweckbestimmung.
Concretely: a US team that has a De Novo clearance should plan for a separate DiGA pivotal study, pre-registered in DRKS or another WHO-ICTRP-compliant registry, designed with BfArM-acceptable endpoints for the German indication, usually executed in Germany. Class I and IIa products may run this study during a 12-month (extensible to 24-month) preliminary listing; Class IIb must arrive with the study complete.
The US bar is usually lower at regulatory clearance and higher at reimbursement negotiation. The German bar is higher at regulatory clearance and then continues into outcomes measurement via AbEM (Anwendungsbegleitende Erfolgsmessung) from 1 July 2026 onward. The total lifetime evidence burden is probably similar; the sequencing is very different.
Cybersecurity – FDA premarket guidance vs BSI TR-03161
FDA side
The FDA’s current final guidance Cybersecurity in Medical Devices (February 2026) expects premarket submissions to document a Secure Product Development Framework (SPDF), threat modeling and cybersecurity risk assessment, a Software Bill of Materials (SBOM), vulnerability-management and TPLC security risk management processes, cybersecurity testing including penetration testing, cybersecurity labeling, and post-market cybersecurity management plans. For “cyber devices” as defined in section 524B of the FD&C Act, plans, procedures, and an SBOM are statutory requirements. Cybersecurity is a content block, not a separate certificate.
German side: BSI TR-03161 as a per-product certificate
BSI TR-03161 (Sicherheitsanforderungen an digitale Gesundheitsanwendungen) is a German federal Technical Guideline. For DiGAs, it is mandatory since 1 January 2025 and application-relevant since 1 July 2025.
Three points that catch US teams out:
- Certification is per DiGA, not per company. Under § 139e para. 10 SGB V, the certificate is product-specific. A company with three DiGAs pays for three certifications.
- Penetration testing is mandatory, by an accredited test lab. The BfArM strongly prefers BSI-accredited test centres; manual code review and whitebox testing against the BSI implementation concept and the OWASP Top Ten are expected.
- ISMS certification is independent and required. Mandatory since 1 April 2022 for any DiGA manufacturer: accredited ISO 27001, or ISO 27001 based on BSI IT-Grundschutz. SOC 2 Type II or HITRUST do not substitute.
| FDA / US side | DiGA / German side |
|---|---|
| Secure Product Development Framework, premarket | BSI TR-03185 (process-level) and BSI TR-03161 (product-level); IEC 81001-5-1 common ground |
| Threat modeling, premarket | Required input to BSI TR-03161 risk analysis |
| SBOM, premarket | Expected in BSI TR-03161 documentation and under MDR Annex II |
| Penetration testing, scoped as appropriate | Mandatory; preferably BSI-accredited test lab |
| Post-market vulnerability management | Part of TR-03161 scope; lifecycle obligation |
| No standalone cyber certificate | Per-DiGA BSI TR-03161 certificate is a formal application artifact |
Most of the engineering transfers. The certification workstream is additional – plan 2–4 months and €50,000–€150,000 for a first DiGA TR-03161 certification if security is engineered in from day one. Detail in BSI TR-03161 certification.
Data protection – HIPAA vs GDPR + BfArM Datenschutzkriterien + DiGAV § 4
US starting point: HIPAA
HIPAA establishes the Privacy Rule and Security Rule for Protected Health Information (PHI). Compliance is operational: administrative, physical, and technical safeguards, breach notification, business-associate agreements. Cloud vendors who sign BAAs and demonstrate HIPAA controls (AWS, GCP, Azure all offer HIPAA-eligible services) give US DTx teams a well-travelled compliance pattern.
German stack: three layers, not one
- GDPR (Regulation (EU) 2016/679) – the baseline. Legal bases for processing, DPIA, data subject rights, breach notification at 72 hours, DPO where applicable.
- DiGAV § 4 paras. 2–3 – DiGA-specific restrictions. Processing purposes are limited to four exhaustive cases: intended use; evidence of positive care effects; the AbEM dataset; technical functioning and further development. Advertising is excluded by statute. Third-country processing is only permissible in the EU/EEA or in countries with an Article 45 GDPR adequacy decision.
- BfArM Datenschutzprüfkriterien under § 139e para. 11 SGB V – binding since 1 August 2024 through DiGAV § 4 Abs. 8. The catalogue of roughly 150 testable requirements across 12 thematic blocks uses RFC 2119 keywords (MUST, MUST NOT, SHOULD, MAY). The manufacturer MUST implement and declare implementation in the application-bound declaration under Annex 1 DiGAV. Formal third-party certification by an accredited ISO/IEC 17065 body is not yet operational because no body has been DAkkS-accredited.
The controller under GDPR Art. 4 No. 7 is the manufacturer of the DiGA – not a platform service provider.
Cross-walk: is HIPAA enough?
No. Three concrete gaps:
- Cloud region and lawful basis. A HIPAA-compliant AWS us-east-1 configuration is not DiGA-compliant. DiGA data must be processed in the EU/EEA or an adequacy-decision jurisdiction.
- Purpose limitation. HIPAA allows treatment, payment, and healthcare-operations processing with broad scope. DiGAV § 4 restricts to four named purposes.
- The BfArM criteria layer. HIPAA controls map onto ISO 27001/SOC 2 controls reasonably well, but the BfArM Datenschutzprüfkriterien include testable requirements (audit trail, account management, push notifications, deletion logic, data portability, pseudonymous use) that neither HIPAA nor GDPR articulate at the same granularity.
The practical ramification: EU-region cloud (not a US region with cross-border data flows), EU-based legal manufacturer, EU-hosted backend services, and data processing agreements structured for GDPR Article 28 – not for HIPAA business-associate terms.
Reimbursement – the biggest structural difference
The US and German reimbursement systems are least comparable and most consequential.
US: Two decisions, many negotiations. FDA clearance gets a product on market. Reimbursement runs separately through CMS (Medicare/Medicaid), commercial payers, employer-sponsored plans, and PBMs. There is no single “DTx pathway” to national reimbursement; coverage decisions are payer-by-payer, region-by-region, and often require additional real-world evidence beyond what FDA expected. Time from FDA clearance to broad reimbursement is typically 12–36 months and uneven.
Germany: One decision, immediate national reimbursement. A BfArM listing under § 139e SGB V triggers reimbursement for ~73 million statutorily insured citizens. Year 1 manufacturer-set price; from month 13 negotiated with GKV-Spitzenverband (per § 134 SGB V); from 1 January 2026 with at least 20 % outcomes-linked components.
This is the single biggest structural reason for international teams to consider Germany: the regulatory and reimbursement decisions are fused.
Frequently asked questions
Does FDA clearance shorten the DiGA path?
Can our 510(k) study satisfy the DiGAV § 10 requirement?
Is HIPAA + SOC 2 enough for DiGA data protection?
If we already have FDA cybersecurity content, do we need BSI TR-03161?
US to Germany