Table of Contents
What is DiGA?
DiGA, Digitale Gesundheitsanwendung, or Digital Health Application, is a category of CE-marked medical software that German statutory health insurers (GKV) can reimburse directly. Introduced by the Digital Healthcare Act (DVG) in December 2019 and regulated by the Federal Institute for Drugs and Medical Devices (BfArM), a listed DiGA can be prescribed to the 73 million people covered by German statutory health insurance. BfArM reviews applications within three months. Getting your codebase ready for that review takes longer.
Most digital health founders spend months preparing clinical evidence for BfArM. The ones who’ve been through the process say the technical requirements are what actually slow them down.
We built the Selfapy app, a CBT-based mental health platform for the German market, through exactly this process. Along the way our team worked through over 120 BSI security requirements, addressed penetration test findings across Android and iOS, and shipped three versioned releases on certification deadlines. What that project taught us about DiGA development is what this article covers.
DiGA technical requirements at a glance
| Requirement | What it means | Mandatory since |
|---|---|---|
| CE mark (class I or IIa medical device) | Your app must be regulated as a medical device under MDR | DVG 2019 |
| BSI TR-03161 certification | Product-specific security certification; penetration testing required | July 1, 2025 |
| ISO 27001 ISMS | Information security management system, independently audited | April 1, 2022 |
| DiGAV data protection criteria | 150+ testable requirements across 12 thematic blocks | DVG 2019 |
| ePA integration | FHIR-conformant data export to the electronic patient record | January 1, 2024 |
BSI TR-03161: product-specific, not a company-wide badge
BfArM certifies each product individually under BSI TR-03161. Submit a new major version of your app and you may be back in the certification process, which means the assumption that you’ve „done compliance” after the first release tends to be wrong.
The testing is hands-on: whitebox analysis conducted by BSI-certified labs, including manual code review against BSI implementation concepts and OWASP Top Ten compliance checks. When we worked on Selfapy, this meant working through over 120 BSI requirements covering data protection, encryption protocols, and information leakage prevention. The issues that surface in a pentest are rarely exotic. They’re things like improper session handling, logging that inadvertently exposes sensitive data, or encryption implementations that fall short of the required standard. Finding those during testing rather than during development costs significantly more time.
BSI TR-03161 has been mandatory for all new DiGA applications since July 1, 2025. Developers who handle this phase well already know what auditors look for, which means they avoid the issues rather than fixing them after the fact. This is part of why healthcare software development requires a different kind of team than standard product work.
Data protection: the DiGAV adds a hard list on top of GDPR
GDPR is the floor. The DiGAV, the ordinance implementing Germany’s Digital Healthcare Act, enumerates exactly five purposes for which a DiGA app may process user data: its intended use, proving care effects, generating the AbEM dataset, technical functionality, and further development (with separate, explicit consent required for this last category). Processing data for any purpose outside these five, even with user GDPR consent, puts your DiGA status at risk.
BfArM evaluates data protection compliance against 150+ testable criteria across 12 thematic blocks. Critically, they distinguish between requirements that are „documented”, written into your policies and requirements that are „established”, operationally lived, with continuous improvement cycles to show for it. Auditors look for evidence of the latter. A compliance document without the operational process behind it doesn’t pass.
ISO 27001 ISMS certification is required alongside BSI TR-03161, mandatory since April 1, 2022. One certificate doesn’t substitute for the other; both go into the BfArM submission.
ePA integration: a maintenance obligation, not a launch milestone
Since January 1, 2024, all DiGA apps must export data to Germany’s electronic patient record system (ePA) via Gematik-defined interfaces. The export format must be human-readable and FHIR-conformant, with semantic mapping defined under § 355 SGB V.
When Gematik updates its interface specifications, which it does, you have six months to ship the changes. Teams that design the ePA integration as a bolt-on find those windows become engineering crises. The ones that handle it well treat the Gematik interface as a first-class concern in their data architecture, with a clear abstraction layer that absorbs specification changes without cascading rewrites into the rest of the codebase.
That architectural decision needs to happen early, because the integration touches authentication, data models, and export logic simultaneously. IT systems integration in a regulated context is a different exercise than connecting two standard APIs — the failure modes and the documentation requirements are both more demanding.
What software as a medical device actually changes about how you build?
When Selfapy’s Head of Engineering [insert name and title] said our developer „quickly adapted to the software-as-medical-device development approach,” that phrase covers a lot of ground.
Medical device software operates under different assumptions than standard product development. Traceability is required: every requirement needs to trace to a test, and every test to a documented result. Change management is formal. When you fix a security issue flagged in a pentest, each fix goes through a documented review and verification cycle before it’s considered closed.
The pace can stay high, but the process needs to support auditability from day one. Version-controlled documentation, defined review workflows, and test automation with tracked results are exactly what BfArM auditors check during the quality management assessment. We built Mentalyc’s entire CI/CD and test automation setup from scratch for exactly this reason.
The teams that struggle with DiGA are almost always the ones trying to apply these requirements to a codebase and process that weren’t built with them in mind. The retrofit is harder than building it in from the start.
3 decisions that determine how the process goes
The first is your data architecture. The DiGAV’s restrictions on data processing purposes need to inform your data model before you build it. Decisions about what you collect, where you store it, and what you’re permitted to do with it are much cheaper to get right upfront.
The second is how you design the ePA layer. Treat it as a maintained interface with its own abstraction. The Gematik specification will change. Build for that.
The third is your development process itself. BSI TR-03161 certification and BfArM audits both look at how you build, not only what you built. A traceable development process, requirement tracking, change management, testing records, is part of what you’re submitting.
If you’re already in development and considering DiGA as a future path: a gap assessment now is cheaper than a certification failure later. The apps that fail the BfArM process usually fail the technical review, not the clinical one and the gaps that surface are almost always ones the team didn’t know were there.
🚀 If you’re building a digital health product for the German market and want to talk through what your architecture needs to support, let’s talk.
