Five pieces of evidence. Five effects. One platform.

The German DTx market is full of certification claims that do not hold up on closer inspection: “GDPR-compliant” is not a certification, “BSI-compliant” without a TR reference is not a statement, “ISO-like QMS” is nothing at all. This page describes which five pieces of evidence we carry at DUX Healthcare, what each of them means for a Digital Health Application (DiGA) – and where one piece of evidence ends and the next begins.

Each of the five addresses a different regulatory requirement from DiGAV, MDR, § 139e SGB V, or the BSI catalog. If one is missing, the BfArM application has a gap. If all are present, the application completeness check under DiGAV § 16 (1)↗ stops being a round of follow-up questions and becomes a formality. That is the economic difference.

What it is. BSI TR-03185 is a Technical Guideline from the Federal Office for Information Security that assesses a manufacturer’s entire software development process – from requirements analysis and architecture decisions through implementation, testing, release, and maintenance to post-market upkeep. What is examined is how software is created, not how it looks at the end.

What you get from it. When the process level is certified, a large part of the security review falls away for every follow-on product, every update, every variant – the process evidence applies organization-wide and across all projects. For your DiGA that means: the software on which your product is built is audited at the organizational level. Updates do not require re-auditing the overall process; the evidence carries platform-wide.

Our status. DUX Healthcare is the first company to have undergone the BSI TR-03185 audit. The audit was successful; the formal certificate will be issued shortly.

Why this matters for DiGA. TR-03185 is not formally required in the DiGA application today, but it is the structural foundation on which TR-03161 per DiGA becomes tenable. Anyone who does not run the software lifecycle on a demonstrable process level rebuilds the TR-03161 evidence per product – and pays three times for three DiGAs. The Cyber Resilience Act (CRA) further tightens this requirement at the EU level over the next 24–36 months – anyone audited against TR-03185 today stands there with an early-mover advantage.

What it is. BSI TR-03161 is the product-specific data security assessment for DiGAs – a technical certificate for a concrete product version, divided into Part 1 (Mobile Clients), Part 2 (Web Applications), and Part 3 (Backend/Cloud). It is assessed against around 366 individual requirements across all three parts and ten assessment aspects – from architecture through cryptography, authentication, data storage, to network communication.

What you get from it. Since 01.07.2025, a TR-03161 certificate has been a prerequisite for formal completeness of the BfArM application (DiGA Guide v3.6 ch. 3.4↗). Without this certificate there is no listing in the DiGA directory – and under § 139e (10) SGB V↗ it is issued product-specifically, not company-wide.

Our status. The DiGAs on our platform are per product assessed to BSI TR-03161 and have passed without conditions – a combination rare in Germany.

Why this matters for DiGA. For your product this means: if it builds on the mHealth Suite, the TR-03161 audit starts on a platform substrate that has already demonstrated a pass without conditions multiple times. The cybersecurity hurdle – for in-house developments today the most frequent blocker in the fast track – is no longer a project risk but a platform property. The product-specific evidence is still required; but it becomes calculable in time and cost.

What it is. ISO 13485 is the international standard for quality management systems in medical device development. It covers design controls, change management, supplier evaluation, production, post-market surveillance, and documentation – everything the MDR presupposes in a systematic QMS.

What you get from it. Without an ISO 13485 QMS, no CE-marked medical device in the EU – that is the short answer. The long one: the MDR requires manufacturers to have a documented QMS, and ISO 13485 is the established way to meet that requirement. For your DiGA this means: Design History File, risk management to ISO 14971, clinical evaluation, post-market clinical follow-up, and the conformity proof (Class I: manufacturer’s Declaration of Conformity; Class IIa: additionally with a Notified Body certificate) are not improvised per project but built on a QMS that has been audited for years.

Our status. DUX is ISO 13485 certified – audited by TÜV Hessen, with ongoing surveillance and re-certification on the normal three-year cycle. The QMS is the foundation on which every other piece of evidence rests.

Why this matters for DiGA. In the European medical software world, ISO 13485 is a prerequisite, not a differentiator. If it is missing, the provider cannot be taken seriously. The added value for your DiGA is that the interface between therapeutic concept and MDR CE documentation is not built up individually but arises from an existing, audited QMS process.

What it is. ISO 27001 is the standard for information security management systems. It assesses how an organization handles information assets: access controls, incident response, vendor management, physical security, business continuity. An ISMS is organizational and procedural, not product-specific.

Our status. DUX operates an ISMS to ISO 27001, which was co-audited as part of the BSI TR-03185 assessment. The separate, standalone ISO 27001 third-party certificate will be completed shortly.

Why this matters for DiGA. For answering vendor audits by Notified Bodies, pharma partners, or SHI/BfArM queries about hosting and data processing, an audited ISMS is the central piece of evidence. With the forthcoming third-party certificate, those answers become a formality.

What it is. The BfArM Data Protection Criteria are a catalog of around 150 individual requirements under § 139e (11) SGB V that the BfArM has published as a concrete interpretation of the GDPR requirements for DiGA. They are worded in RFC 2119 grammar (MUST, MUST NOT, SHOULD, MAY) and distributed across twelve topic blocks – from responsibility and legal bases through technical-organizational measures to deletion and logging. Since 01.08.2024 they are formally binding; they are attached to the DiGA application as a checklist (Annex 1 DiGAV).

What you get from it. For international DTx teams this is the assessment level most often underestimated – because it operationalizes GDPR requirements and makes them testable. “We are GDPR-compliant” is not an answer; “we meet GLSR_2.4 (established), DMN_4 (account grace period), TOM_3 (push notifications) and ACC criteria (logging)” is the answer the BfArM expects.

Our status. DUX runs a conformant QMS framework with evidence for all roughly 150 individual criteria. The evidence is part of our ISO 13485 QMS and is documented in the DiGA application.

Why this matters for DiGA. Because the BfArM criteria consistently distinguish between “documented” and “established”: documentation alone is not enough, the criteria have to be lived in practice. That is the most frequent criteria blocker for teams that treat the catalog as downstream documentation. Anyone building on our platform inherits the established practice.

The five pieces of evidence are not redundant – they operate at different levels and solve different regulatory problems. ISO 13485 forms the base on which everything else rests: no QMS, no medical device. BSI TR-03185 certifies how software is created securely in that QMS – at the process level, organization-wide, reusable. BSI TR-03161 certifies the product itself on cybersecurity – per DiGA, for every version. ISO 27001 wraps the whole as information security management. The BfArM Data Protection Criteria finally translate GDPR and DiGAV into a testable set of individual requirements documented per DiGA in the application.

The effect is cumulative: each level reduces the effort at the one above. A team building on a TR-03185-audited platform with an ISO 13485 QMS and existing TR-03161 evidence per DiGA not only saves time in the individual project – it avoids rebuilding the same structures for every follow-on DiGA. That is the economic difference between platform and custom build.

This page explains what the five pieces of evidence mean for a customer project. The technical depth – requirement IDs, RFC 2119 grammar, assessment aspects per BSI part, OWASP Top 10 mapping – is in the knowledge area:

• BSI TR-03161 Certification – A Practitioner’s Guide
• BfArM Data Protection Criteria in detail
• DiGA – practice knowledge on Digital Health Applications