DiGA and the EU AI Act: What German Digital Health Apps Need to Know

A DiGA (Digitale Gesundheitsanwendung, an "app on prescription") is, under § 33a and § 139e SGB V, a CE-marked medical device of a low risk class (MDR Class I, IIa, or since the DigiG also IIb). Because a DiGA is a medical device, the EU AI Act treats an AI-based DiGA exactly like any other medical AI:

• If your DiGA is MDR Class IIa or higher (a notified body is involved), an AI component makes it high-risk AI under Article 6(1).
• If your DiGA is basic self-certified Class I, it is not high-risk via that route, though patient-facing transparency (Article 50) can still apply.
• The AI Act conformity check folds into your MDR route under Article 43(3); it is not a separate audit.
• The BfArM DiGA fast-track (which unlocks reimbursement) is a separate, additional process on top of all of this.

Most DiGA with a diagnostic or therapy-driving function are Class IIa under MDR Rule 11, so most AI-based DiGA are high-risk AI. Get your MDR class right and the AI Act answer follows.

Every legal claim below is cited. See Sources.

What a DiGA actually is

A DiGA is defined in German social law (§ 33a SGB V) as a low-risk CE-marked medical device whose main function is based on digital technology and which supports the detection, monitoring, treatment or alleviation of diseases, injuries or disabilities. The BfArM runs the DiGA directory and a fast-track procedure: within three months of a complete application it assesses the manufacturer's claims on data protection, security, interoperability and usability, plus the evidence of a positive healthcare effect. Listing makes the DiGA reimbursable by statutory health insurance.

There are two listing routes. Permanent listing requires robust evidence of a positive healthcare effect up front. Provisional listing lets a manufacturer that has not yet gathered that evidence be listed for a trial period of up to 12 months (extendable by another 12), during which it must generate the evidence or lose the listing. Either way, the DiGA is a medical device with a German reimbursement layer on top, so everything in our medical-AI high-risk guide applies to it directly.

Why the AI Act applies to a DiGA

The AI Act's high-risk trigger for medical AI runs through Article 6(1): an AI system that is, or is a safety component of, a medical device requiring a notified body is high-risk. A DiGA is a medical device, so the only question is your MDR risk class, which decides whether a notified body is involved.

• Class IIa, IIb (notified body involved) with an AI component → high-risk AI. Under MDR Annex VIII Rule 11, software that provides information used for diagnosis or therapy is Class IIa, rising to IIb where the potential harm is greater. Most therapeutic or diagnostic DiGA land here.
• Basic Class I (self-certified) → not high-risk via Article 6(1). Some simple DiGA are Class I. They escape the high-risk route, but Article 50 transparency (telling users they are interacting with AI) can still apply, especially for chat-style tools.

If you are not sure which side you fall on, that is the whole subject of the high-risk pillar, the AI Act × MDR/IVDR crosswalk, and the interactive medical AI risk check.

Three tracks, not one

An AI-based DiGA is running three parallel processes. Keeping them distinct is what keeps the work manageable:

1. MDR conformity (with the AI Act folded in). Your CE marking comes from the MDR. If you are high-risk AI, the AI Act requirements are assessed inside that MDR conformity assessment under Article 43(3), not as a second audit. See how the obligations map in the crosswalk.
2. BfArM DiGA fast-track. The reimbursement track: data protection, security, interoperability, usability, and proof of a positive healthcare effect. It overlaps with, but does not replace, the AI Act.
3. GDPR. Health data is special-category data; you still need a lawful basis and an Article 9 condition. See GDPR × AI Act × MDR for health data.

Where the DiGA data-protection and security stack meets the AI Act

DiGA face some of the strictest data-protection and information-security requirements in European digital health, and manufacturers often assume that clearing them also clears the AI Act. It does not. The DiGA security stack (data-protection criteria under the DiGAV, information-security testing to BSI TR-03161, an ISO 27001 information-security management system, and penetration testing, with security and data-protection certification mandatory since 2024) is real and demanding, but it answers security and privacy questions. The AI Act's data governance (Article 10) answers a different question: is the training, validation and test data behind your model representative, high-quality and examined for bias. A locked-down, ISO-27001-certified DiGA can still have an ungoverned training set. The two overlap in spirit but are not interchangeable, plan the AI Act data-governance workstream separately.

The moving part (track it, do not plan around it)

Timing and scope for AI in medical devices are being revised. The Digital Omnibus proposed by the European Commission in November 2025 would move the application date for AI in Annex I products (medical devices included) to 2 August 2028, and would give the Commission power to limit AI Act requirements where the MDR already imposes equivalent obligations. Some proposals go further on scope. All of this is provisional: build to the durable classification logic (Article 6(1) and 43(3)), and treat specific dates and scope as subject to change. Our deadlines tracker follows the detail.

Worked examples

Common mistakes

• "BfArM approval means we are AI-Act-ready." The fast-track covers reimbursement and security, not the AI Act's high-risk requirements.
• "Our ISO 27001 certificate covers AI Act data governance." Security is not the same as training-data quality and bias examination (Article 10).
• "A DiGA is a special category outside the medical-device rules." It is a medical device; the whole MDR-class-driven analysis applies.
• "We are Class I, so the AI Act is irrelevant." Class I is not high-risk via 6(1), but Article 50 transparency and the GDPR still apply.
• "We will bolt the AI Act on after CE and DiGA listing." The AI Act check is part of the MDR conformity assessment (Article 43(3)); design it in.

Practical checklist for a DiGA team

• Confirm your MDR class (Rule 11). It decides both your conformity route and your AI Act status.
• If Class IIa+ and AI-based, plan the AI Act requirements inside your MDR technical documentation (Article 43(3)).
• Keep the BfArM DiGA requirements (including the BSI/ISO 27001 security stack) as their own track; reuse evidence where it overlaps, but do not assume equivalence with AI Act data governance.
• Sort your GDPR footing for health data early.
• Watch the Omnibus; do not hard-code deadlines.

Is every DiGA a high-risk AI system?

No. A DiGA is high-risk AI only if it is MDR Class IIa or higher (so a notified body is involved) and it contains an AI system. Basic self-certified Class I DiGA are not high-risk via Article 6(1), although Article 50 transparency duties may still apply. Since most therapeutic or diagnostic DiGA are Class IIa under Rule 11, most AI-based DiGA are high-risk.

Does the BfArM fast-track cover my AI Act obligations?

No. The BfArM DiGA assessment (data protection, security, interoperability, usability, positive healthcare effect) is the reimbursement track. It overlaps with the AI Act but does not replace it. Your AI Act high-risk requirements are met through your MDR conformity assessment under Article 43(3).

Does our BSI TR-03161 or ISO 27001 security work satisfy the AI Act?

Not on its own. Those address information security and data protection. The AI Act's Article 10 data governance is about the quality, representativeness and bias of your training, validation and test data, a different obligation. Do both.

My DiGA is Class I. Am I off the hook for the AI Act?

Largely, for the high-risk regime: basic Class I is not high-risk via Article 6(1). But if your app interacts with patients (for example a chatbot), Article 50 transparency obligations can still apply, and the GDPR always does.

Will the Digital Omnibus change this for DiGA?

Possibly. The proposed changes would defer deadlines and reduce duplication between the AI Act and the MDR for medical devices, and some go further on scope. They are not final. Build to the classification logic, which is stable, and track the dates separately.

Sources (official)

• German social law, § 33a SGB V (entitlement to DiGA) and § 139e SGB V (DiGA directory and fast-track); administered by the BfArM, which also sets the data-protection and information-security requirements (including BSI TR-03161). Cited for: DiGA definition, low risk class, provisional vs permanent listing, and the fast-track procedure.
• MDR, Regulation (EU) 2017/745: official text on EUR-Lex. Cited: Annex VIII Rule 11 (software classification), Article 52 (notified body by class).
• EU AI Act, Regulation (EU) 2024/1689: per-article on the European Commission AI Act Service Desk. Cited: Article 6 (high-risk trigger), Article 10 (data governance), Article 43(3) (integrated conformity), Article 50 (transparency); official text on EUR-Lex.
• Digital Omnibus, European Commission proposal of 19 November 2025; Council press release, 7 May 2026. Provisional.

Legalithm provides compliance information and tooling, not legal advice. Classification and reimbursement outcomes depend on your specific product; confirm with your notified body, the BfArM guidance, and qualified counsel. Article references are to Regulation (EU) 2024/1689 (the AI Act) and the MDR (EU) 2017/745.