DiGA requirements in 2026 sit on top of the CE mark under MDR and cover data protection under GDPR and German national rules, interoperability via FHIR and KBV-defined standards, information security aligned with ISO 27001 or equivalent, plus usability, accessibility, and robustness. The MDR gets you to the door. The DiGA requirements decide whether you are allowed through it.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • A CE mark under Regulation (EU) 2017/745 is a prerequisite, not the endpoint. DiGA-specific requirements apply on top of MDR conformity.
  • Data protection requires GDPR compliance plus German national rules, including hosting restrictions and data processing transparency obligations .
  • Interoperability is specified through FHIR profiles and KBV (Kassenärztliche Bundesvereinigung) standards for structured exchange with the German healthcare system .
  • Information security expectations align with ISO 27001 or demonstrably equivalent controls, plus medical-device-specific security requirements under MDR Annex I §17.4 and EN IEC 81001-5-1:2022 .
  • Tibor has not guided a product through DiGA himself. DiGA-specific requirement text should be verified against the current BfArM guidance before a founder commits to design decisions.
  • Founders who plan DiGA requirements from day one save months later. Founders who bolt DiGA onto a finished CE-marked product rebuild a lot of work.

Why the requirements layer is the real gate

In the first two posts in this series, Tibor has explained what DiGA is and how the fast-track works. The third question founders ask is almost always operational: what exactly do we have to build, document, and prove to satisfy BfArM on top of the MDR?

The short answer, drawn from public DiGA guidance and from conversations with manufacturers already in the directory, is that BfArM's requirements cluster into five layers. Tibor is confident on the MDR-anchored parts of each layer because he has audited and built to them for over a decade. He is cautious on the DiGA-specific extensions because he has not personally guided a product through BfArM. Every DiGA-specific claim below is flagged where founders should verify against current BfArM guidance before acting.

Felix's sequencing principle applies here too. The worst moment to discover a DiGA requirement is three days before submission. The best moment is during intended-purpose definition.

Layer one: CE mark as the foundation

Everything in this post assumes the manufacturer has or will have a valid CE mark under the MDR. For most DiGA candidates the classification route is Annex VIII Rule 11, resulting in Class I (Article 52 self-certification) or Class IIa (notified body involvement).

The MDR baseline includes:

  • A quality management system to EN ISO 13485:2016+A11:2021.
  • A risk management file to EN ISO 14971:2019+A11:2021.
  • A software lifecycle to EN 62304:2006+A1:2015.
  • Usability engineering to EN 62366-1:2015+A1:2020.
  • Clinical evaluation under MDR Article 61 and Annex XIV Part A.
  • Technical documentation to MDR Annex II and Annex III.

If any of these is weak or missing, the DiGA question is premature. Tibor's view from fifty-plus MDR certifications is consistent: the worst DiGA submissions he has heard about started as the weakest MDR certifications. There is no DiGA shortcut around doing the MDR work properly.

Layer two: data protection

The data protection layer has two sources. The first is GDPR (Regulation (EU) 2016/679), which applies to any processing of personal data of EU residents regardless of DiGA status. The second is German national rules, which BfArM layers on top for DiGA specifically.

Tibor's interview transcript, Section 3 on cybersecurity and data protection, captured the pattern: manufacturers design software that processes personally identifiable information and forget GDPR applies, miss it in their privacy policies, and miss it as data worth protecting in their cybersecurity risk file. The fix is awareness, not legal complexity. For DiGA, awareness becomes mandatory because BfArM will ask.

What manufacturers Tibor has spoken with describe as the DiGA-specific data protection requirements :

  • Data processing only for purposes strictly necessary for the health application's intended purpose.
  • Hosting restricted by territory, typically within the EU/EEA, with potential additional restrictions for certain data categories.
  • Transparent data processing notices meeting both GDPR Article 13 and DiGA-specific disclosure expectations.
  • Contractual safeguards with any processors, consistent with GDPR Article 28.
  • Clear data subject rights fulfilment processes.
  • Breach notification procedures aligned with GDPR Article 33 and any DiGA-specific reporting.

From Section 3 of Tibor's interview: data protection in digital health is less a legal puzzle than an attention problem. Founders who treat the GDPR layer as a checklist exercise late in the project find the checklist turns into a redesign.

Layer three: interoperability

Interoperability is where DiGA departs most clearly from MDR. The MDR has general requirements for interoperability in Annex I , but they are high-level. BfArM's DiGA expectations are concrete and reference specific German healthcare interoperability standards.

The interoperability layer typically includes :

  • Support for HL7 FHIR profiles relevant to the application's clinical domain.
  • Conformance with KBV (Kassenärztliche Bundesvereinigung) standards for data exchange with the German statutory outpatient care system where clinically relevant.
  • Support for standardised identifiers and terminologies, such as SNOMED CT, LOINC, or German national terminologies where applicable.
  • Integration readiness with the German electronic patient record (elektronische Patientenakte, ePA) where clinically relevant to the use case .
  • Open, documented APIs where data exchange is part of the clinical function.

Tibor's framing for founders: interoperability is one of the few areas where DiGA requirements can drive architectural decisions that are expensive to retrofit. A data model designed without FHIR in mind can require significant refactoring to become FHIR-conformant later. Felix's coaching experience confirms the pattern. He has watched founders spend more on retrofitting interoperability after a prototype than the original development cost.

Layer four: information security

The information security layer sits at the intersection of MDR Annex I §17.2 and §17.4, EN IEC 81001-5-1:2022, and DiGA-specific BfArM expectations. ISO 27001 or demonstrably equivalent controls are typically referenced .

From Section 3 of Tibor's interview: cybersecurity in medical devices is continuous, not one-time. A device secure at launch can become insecure later when a SOUP component or library publishes a CVE. The same principle applies to DiGA. BfArM is not looking for a snapshot. It is looking for a lifecycle.

What manufacturers Tibor has spoken with describe as the DiGA information security expectations:

  • A documented information security management system, typically mapped to ISO 27001 or to German BSI IT-Grundschutz.
  • Penetration testing by a competent, independent party, with documented results and remediation status.
  • Secure software development lifecycle aligned with EN IEC 81001-5-1:2022.
  • A software bill of materials (SBOM) traceable to configuration item lists under EN 62304.
  • Vulnerability management with defined monitoring, triage, and patching procedures.
  • Incident response procedures for security events affecting patient data or safety.

Tibor's Section 3 observation on SBOMs deserves repeating for DiGA purposes: a good SBOM follows naturally from the IEC 62304 configuration item list. Libraries, SOUP components, versions, all tracked. The SBOM is not a separate document. It is what the configuration item list should have been all along. Manufacturers who treat SBOM as a new artefact for DiGA are usually discovering that their 62304 work was thin.

Layer five: usability, accessibility, and robustness

The final layer picks up where EN 62366-1:2015+A1:2020 leaves off and adds DiGA-specific expectations on accessibility and robustness.

  • Usability: summative evaluation meeting EN 62366-1, with users representative of the intended population, in a realistic use environment. Tibor's Section 2 interview captured the failure mode: companies save money by testing with engineers, sales staff, friendly customers, or key opinion leaders. Real users at home, potentially elderly, often cannot use the device at all. DiGA assessors know this pattern too.
  • Accessibility: conformance with relevant accessibility standards for users with disabilities, reflecting the obligation under EU accessibility legislation and any German national extensions .
  • Robustness: documented error handling, availability targets, and recovery procedures for service disruptions that could affect patient use.
  • App usability: for connected hardware-plus-app products, the app is part of the usability engineering scope. Tibor's Section 2 point: "it's just an app" is not a defence.

The Subtract to Ship playbook for DiGA requirements

Felix's framing for founders approaching DiGA in 2026:

Step one. Decide DiGA as a target during intended-purpose definition, not after CE mark. Every layer above is cheaper to build in than to retrofit.

Step two. Map the five layers above against your current development plan. For each layer, write down what exists, what is missing, and what you do not yet know. Items in the third column are the verification priorities to clarify with DiGA-experienced advisors before you start building.

Step three. Build the SBOM from your EN 62304 configuration item list from day one. This pays off for CE mark, for DiGA, and for future security audits regardless of market.

Step four. Plan summative usability with real representative users, not employees. DiGA assessors, like MDR notified bodies, have seen every version of "we tested with our own team and it worked fine".

Step five. Hire or contract GDPR and German healthcare data protection expertise early. Tibor's Section 3 advice applies directly: data protection is awareness-limited, not complexity-limited. A competent advisor pays for themselves by preventing the redesign.

Step six. Talk to three manufacturers already in the DiGA directory about their real experience with the requirements layers. Tibor's single strongest piece of advice from Section 4 remains: get first-hand advice from people who walked the path.

Reality Check

  1. Does your product have a valid CE mark under MDR, or a credible plan to get one before BfArM submission?
  2. Is your data protection design aligned with GDPR and the German national rules your DiGA advisors have flagged?
  3. Have you chosen hosting and data residency in line with DiGA expectations?
  4. Have you designed your data model with FHIR and KBV interoperability in mind from the start?
  5. Do you have an SBOM generated from your EN 62304 configuration item list?
  6. Is your information security management mapped to ISO 27001 or equivalent controls, with a current pentest?
  7. Is your summative usability evaluation planned with real representative users, not employees?
  8. Does your accessibility plan meet the standard your DiGA advisors have identified as applicable?
  9. Have you spoken to at least three DiGA-listed manufacturers about their real experience with the requirements layers?

Frequently Asked Questions

Does DiGA require ISO 27001 certification? ISO 27001 is commonly referenced, but whether formal certification is mandatory or equivalent evidence is accepted should be verified against the current BfArM DiGA guidance .

Is FHIR mandatory for all DiGAs? FHIR support is mandatory where the application exchanges data with the German healthcare system in a clinically relevant way. The specific profiles, conformance level, and exemptions should be verified against the current BfArM interoperability catalogue.

Can we host DiGA data outside the EU? Hosting location is one of the strictest DiGA data protection requirements and founders should assume the default is EU/EEA hosting. Any deviation should be reviewed with a German healthcare data protection advisor before design commitment.

How is DiGA usability different from MDR usability? The standard is the same (EN 62366-1:2015+A1:2020). The expectation around real representative users, summative evaluation quality, and user documentation tends to be stricter in practice. Treat DiGA usability as a stricter subset, not a different discipline.

What happens if requirements change after listing? DiGA manufacturers remain responsible for maintaining conformity with current requirements. Significant changes trigger updates and re-assessment . Treat the DiGA listing as a live commitment, not a one-time milestone.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17.2 and §17.4, Annex II, Annex III, Annex VIII Rule 11, Article 61, Annex XIV Part A.
  2. Regulation (EU) 2016/679 (GDPR). Articles 13, 28, 33.
  3. EN IEC 81001-5-1:2022. Health software and health IT systems safety, effectiveness and security. Security. Activities in the product life cycle.
  4. EN 62304:2006+A1:2015. Medical device software. Software life cycle processes.
  5. EN 62366-1:2015+A1:2020. Medical devices. Application of usability engineering to medical devices.
  6. Tibor Zechmeister, follow-up interview Round 2, Sections 2, 3, and 4, 11 April 2026. Tibor has not personally guided a product through DiGA and defers to founders with first-hand BfArM experience for DiGA-specific requirement detail.