Medizinische Software – regulatorische und technische Basis

Von Christoph Eberhardt · CEO, DUX Healthcare · Stand 19. April 2026

Welcher Foundation-Stack trägt jedes Software-Medizinprodukt nach MDR? Dieser Hub ordnet den SaMD-Stack: MDR (VO (EU) 2017/745) als Rechtsrahmen, IEC 62304 als Software-Lebenszyklus, ISO 13485 als QMS, ISO 14971 als Risiko-Management, IEC 62366-1 als Usability-Engineering und IEC 82304 als Health-Software-Norm — plus den 2026-Ausblick auf den AI Act. DiGA-spezifische Aufsätze (BSI TR-03161, BSI TR-03185, BfArM-Datenschutzprüfkriterien) liegen unter /wissen/diga/, nicht in diesem Hub.

DUX-Praxis-Anker: 7 Jahre Software-as-Medical-Device-Entwicklung, fünf DiGAs unter Vertrag auf der mHealth Suite, BSI TR-03185 als erstes Unternehmen Deutschlands.

Was „Medical Software Foundation" für DiGA-Hersteller wirklich umfasst

Die öffentliche DiGA-Diskussion konzentriert sich auf das BfArM-Verfahren. Die technische Vorbereitung – das, was vor dem BfArM-Antrag stattfindet – ist selten im Fokus, obwohl sie den Großteil der Projektzeit und des Projektbudgets bindet. Der Rahmen, gegen den eine DiGA tatsächlich gebaut wird, lässt sich als sieben übereinandergeschichtete Ebenen beschreiben:

1. Rechtsrahmen. Die MDR (Verordnung (EU) 2017/745) gilt seit 26. Mai 2021 und ist der verbindliche EU-Rahmen für alle Medizinprodukte, die in Verkehr gebracht werden. Ergänzt durch die IVDR (Verordnung (EU) 2017/746) für In-vitro-Diagnostika. Für Software ist die Qualifikation als MDSW (Medical Device Software) nach MDCG 2019-11 Rev.1 der erste Prüfschritt – gefolgt von der Klassifizierung nach Anhang VIII Regel 11.
2. Software-Lebenszyklus. IEC 62304 ist der international harmonisierte Standard für den Software-Lebenszyklus von Medizinprodukte-Software. Die MDR nimmt ihn in Anhang I Abschnitt 17 implizit in Bezug (Grundlegende Sicherheits- und Leistungsanforderungen an Software); Benannte Stellen prüfen ihn de facto als Konformitätsnachweis. Die IEC 62304 kennt Software-Sicherheitsklassen A, B und C – die Sicherheitsklasse bestimmt, welche Prozessartefakte verpflichtend sind.
3. Qualitätsmanagement. ISO 13485 ist das QMS (Qualitätsmanagement-System) für Medizinprodukte-Hersteller. MDR Art. 10 Abs. 9 verlangt ein QMS; ISO 13485 ist der harmonisierte Nachweispfad. Für DiGA-Antragsteller ist ISO 13485 nicht direkt antragspflichtig, aber ohne ISO-13485-QMS keine saubere MDR-Konformitätsbewertung – und ohne MDR-Konformitätsbewertung keine CE-Kennzeichnung – und ohne CE-Kennzeichnung keine DiGA nach § 33a Abs. 1 SGB V↗.
4. Risikomanagement. ISO 14971 ist der harmonisierte Standard für Risikomanagement von Medizinprodukten. Er läuft als eigener Prozess parallel zur IEC 62304 und zieht sich durch den gesamten Lebenszyklus – von der Zweckbestimmung bis zum Post-Market-Surveillance.
5. Usability. IEC 62366-1 ist der harmonisierte Standard für Gebrauchstauglichkeit. Für DiGA kein Ornament: Der überwiegende Teil der Nutzer-Risiken in einer DiGA sind Use-Errors, nicht Software-Fehler.
6. Cybersicherheit – organisatorisch. BSI TR-03185 ist die organisatorische Zertifizierung des SDLC, binär, pro Unternehmen. Internationaler Orientierungsrahmen: MDCG 2019-16 Rev.1↗ (Cybersecurity for Medical Devices, Juli 2020) plus IMDRF N60/N88. Die DiGA-spezifische Produkt-Cybersicherheit (BSI TR-03161) liegt im DiGA-Bereich.
7. Datenschutz. DSGVO bildet den Rahmen; die BfArM-Datenschutzprüfkriterien nach § 139e Abs. 11 SGB V übersetzen ihn DiGA-spezifisch in rund 150 testbare Einzelanforderungen. Verantwortlicher im Sinne der DSGVO ist der Hersteller (Art. 4 Nr. 7 DSGVO), nicht ein Plattform-Dienstleister. Diese Ebene liegt primär im DiGA-Wissens-Bereich – siehe BfArM-Datenschutzprüfkriterien im Detail.

Die sieben Ebenen arbeiten nicht isoliert. Eine Änderung im Datenmodell (Ebene 7) zieht eine Änderung der Risiko-Analyse (Ebene 4), eine Änderung im Software-Architekturdokument (Ebene 2), eine Änderung im Change-Control-Record (Ebene 3), eine Neu-Bewertung der TR-03161-Evidenz (Ebene 6, DiGA-Bereich) und potenziell eine wesentliche Veränderung nach § 18 DiGAV nach sich. Teams, die die Ebenen als Silo-Projekte betreiben, entdecken die Kopplung spät; Teams, die sie als ein System behandeln, bauen sie einmal und pflegen sie.

MDR Regel 11 – die Klassifizierungs-Frage für Software

Wenn ein Produkt als MDSW qualifiziert ist – also als Software mit eigenständigem medizinischem Zweck nach MDCG 2019-11 Rev.1 Abschnitt 2 – ist die erste Folgefrage die Risikoklasse. Für Software ist Anhang VIII Regel 11 MDR der zentrale Prüfstein. Der Wortlaut ist kurz; seine Interpretation bindet den Großteil der Klassifizierungs-Praxis.

Regel 11 legt fest (verkürzt): Software, die Informationen liefert, auf deren Basis Entscheidungen mit diagnostischer oder therapeutischer Absicht getroffen werden, ist Klasse IIa – es sei denn, die Entscheidung kann zum Tod oder zu irreversibler Verschlechterung des Gesundheitszustands (Klasse III) oder zu schwerwiegender Verschlechterung oder chirurgischer Intervention (Klasse IIb) führen. Software zur Überwachung physiologischer Prozesse ist Klasse IIa – es sei denn, sie überwacht vitale physiologische Parameter, deren Variationen unmittelbare Gefahr bedeuten können (Klasse IIb). „Alle sonstige Software" ist Klasse I.

MDCG 2019-11 Rev.1 Abschnitt 4.2.1 zerlegt Regel 11 operational in drei Sub-Rules:

• Sub-Rule 11a – Software für diagnostische oder therapeutische Entscheidungen. Default IIa; IIb oder III bei entsprechendem Schadenspotenzial. Dies ist die Sub-Rule, unter die der überwiegende Teil der DiGA fällt.
• Sub-Rule 11b – Software zur Überwachung physiologischer Prozesse oder Parameter. Default IIa; IIb bei Überwachung vitaler Parameter mit unmittelbarer Gefahrenlage.
• Sub-Rule 11c – „Alle sonstige Software". Klasse I. Diese Restkategorie ist schmaler, als Teams häufig annehmen.

Zwei Interpretationsfallen, die regelmäßig zu Fehl-Klassifizierungen führen:

Die „Informations"-Schwelle ist niedrig. Sub-Rule 11a greift nicht erst bei deterministischen Entscheidungsempfehlungen. „Information zur Entscheidungsfindung" umfasst Scores, Trends, risikostratifizierende Darstellungen und Warnhinweise. Eine Adhärenz-Tracking-App, die dem Patienten oder Arzt „Compliance 72 %" anzeigt und als Entscheidungsbasis für Therapieanpassung dient, fällt unter 11a – nicht unter 11c.

Klasse I ist enger, als der Alltag vermuten lässt. Sub-Rule 11c ist Residual-Kategorie. Produktteams, die ihre DiGA als „reine Tagebuchfunktion" oder „reines Patient-Facing-Logbuch" einstufen und auf Klasse I abzielen, übersehen oft, dass dieselbe Datenerfassung im Versorgungspfad Entscheidungen fundiert – womit 11a greift. Der DiGA-Leitfaden v3.6 Kap. 2.3 hat die IIb-Öffnung mit dem DigiG formalisiert; IIb-DiGA müssen medizinischen Nutzen bereits bei Antragstellung belegen und können die Erprobung nicht nutzen.

Zwei weitere MDCG-Dokumente ergänzen das Bild für Sonderkonstellationen: MDCG 2020-1 zur klinischen Bewertung von MDSW und MDCG 2023-4 für MDSW, die mit nicht-medizinischer Hardware zusammenarbeitet (Consumer-Wearables, Standard-Smartphones). Für AI-basierte DiGA kommt MDCG 2025-6 / AIB 2025-1 hinzu – siehe Abschnitt AI Act × MDR.

Ein eigener Cluster-Artikel zu „MDR Rule 11 für Software – Klassifizierung in der Praxis" mit Entscheidungsbaum, typischen Konstellationen und Grenzfällen ist in Vorbereitung.

IEC 62304 – Software-Lebenszyklus in der Praxis

IEC 62304:2006+A1:2015 (Medical device software – Software life cycle processes) ist die normative Brücke zwischen der MDR und der täglichen Entwicklungsarbeit. Die MDR verlangt in Anhang I Abschnitt 17 (Grundlegende Sicherheits- und Leistungsanforderungen an Software) einen geeigneten Software-Lebenszyklus; die IEC 62304 liefert ihn in Form von Prozessanforderungen zu Entwicklung, Wartung, Risiko-Management und Konfigurationsmanagement.

Der zentrale Hebel der IEC 62304 sind die drei Software-Sicherheitsklassen:

• Klasse A – Keine Verletzung oder Gesundheitsschäden möglich.
• Klasse B – Nicht-schwere Verletzung möglich.
• Klasse C – Tod oder schwere Verletzung möglich.

Die Software-Sicherheitsklasse ist nicht dieselbe wie die MDR-Risikoklasse. Eine MDR-Klasse-IIa-DiGA kann aus einer Klasse-A- oder Klasse-B-Software bestehen; eine MDR-Klasse-IIb-DiGA kann je nach Architektur und Risiko-Analyse Klasse B oder C erreichen. Die Klassifizierung treibt den Pflichtumfang: Architektur-Dokumentation, Unit-Testing-Evidenz, Code-Review-Prozess, Konfigurationsmanagement-Granularität – alle skalieren mit der Klasse.

Praktisch relevante Teilprozesse:

• Software-Entwicklungsplan (Kap. 5.1) – der Plan, der die Abschnitte unten verbindlich zuordnet. Ohne Plan kein konformer Lebenszyklus.
• Software-Anforderungsanalyse (Kap. 5.2) – strukturierte Herleitung der Software-Anforderungen aus der Zweckbestimmung und den Risiko-Controls.
• Software-Architektur (Kap. 5.3) – die SOUP-Deklaration (Software of Unknown Provenance) sitzt hier. Jede Drittanbieter-Bibliothek, jedes Framework, jeder Cloud-Dienst ist SOUP-pflichtig – Version, Zweck, Risiko, Alternativen.
• Unit-Ebene und Integration (Kap. 5.5–5.6) – testgetriebene Evidenz, die die implementierte Architektur gegen die Anforderungen validiert.
• System-Release (Kap. 5.8) – Freigabe-Gate mit Evidenz, dass alle Anforderungen erfüllt, alle bekannten Anomalien bewertet, alle Risiken akzeptiert sind.
• Software-Wartung (Kap. 6) – der oft unterschätzte Teil. Jede Feature-Release einer gelisteten DiGA muss gegen denselben Prozess laufen wie die Erstversion – Impact-Analyse, Klassifizierungs-Review, Release-Dokumentation.
• Konfigurationsmanagement (Kap. 8) – Git plus CI/CD reichen nicht, wenn die Verbindung zu den Risiko-Controls und Anforderungen nicht nachweisbar ist.
• Problem-Resolution (Kap. 9) – strukturierter Umgang mit Anomalien, inklusive Root-Cause, Korrekturmaßnahme und Re-Test.

DUX betreibt die IEC 62304 als gelebten Prozess, nicht als Dokumentations-Übung. Konkret: Jede Software-Komponente auf der mHealth Suite trägt eine einmal hinterlegte Sicherheitsklasse, die bei der Verwendung in einer konkreten DiGA kontextualisiert und – wenn das DiGA-spezifische Risiko-Umfeld es erfordert – hochgestuft wird. Plattform-Effekt: Die Dokumentation pro DiGA wird zum Delta-Set, nicht zur Neuaufstellung. Ein eigener Cluster-Artikel zur IEC-62304-Implementierung in der Praxis ist in Vorbereitung.

ISO 13485 und ISO 14971 – QMS und Risikomanagement als Basis

ISO 13485:2016 (Medizinprodukte – Qualitätsmanagementsysteme – Anforderungen für regulatorische Zwecke) ist das harmonisierte QMS für Medizinprodukte-Hersteller. Für DiGA-Antragsteller ist ein ISO-13485-konformes QMS kein Antragsbestandteil, aber die Basis jeder sauberen MDR-Konformitätsbewertung: Die MDR verlangt in Art. 10 Abs. 9 ein QMS, und Benannte Stellen akzeptieren ISO 13485 als Nachweispfad.

Für Software-Hersteller in DiGA-Umgebungen relevant sind vor allem:

• Design and Development (Kap. 7.3) – strukturierter Produkt-Lebenszyklus von der Zweckbestimmung bis zur Markteinführung. Enthält Design-Inputs, Design-Outputs, Design-Reviews, Design-Verifizierung, Design-Validierung und Design-Transfer. Die IEC 62304 sitzt hier hinein.
• Purchasing (Kap. 7.4) – Lieferanten-Qualifizierung. Für DiGA operativ relevant für Cloud-Provider (AWS, GCP, Azure), Analytics-SDKs, Authentifizierungs-Dienste.
• Corrective and Preventive Action (CAPA, Kap. 8.5) – der Prozess, über den Abweichungen, Beschwerden, Post-Market-Befunde und interne Audits in konkrete Verbesserungen laufen.
• Management Review (Kap. 5.6) – regelmäßige Leitungs-Bewertung des QMS. Das BfArM fragt in Post-Market-Prüfungen gezielt nach Management-Review-Protokollen.

Teams, die „ISO 13485 konform" sein wollen, ohne zu zertifizieren: Das ist formal nur dann tragfähig, wenn die Konformität durch eine Benannte Stelle im Rahmen der MDR-Konformitätsbewertung (Klasse IIa/IIb/III) geprüft wird. Für Klasse-I-DiGA ohne Benannte-Stellen-Einbindung ist ein externes ISO-13485-Zertifikat nicht formal erforderlich, operativ aber praktisch unumgänglich – Auditspuren, Zulieferer-Verträge, Management-Reviews stehen oder fallen mit einem etablierten QMS.

ISO 14971:2019 (Medizinprodukte – Anwendung des Risikomanagements) ist der parallele Standard für das Risikomanagement. Er ist keine Ergänzung zur IEC 62304, sondern läuft eigenständig: Risiko-Management umfasst alle Risiken des Medizinprodukts (Software-Fehler, Use-Errors, Cybersecurity, Datenfluss-Fehler, Fehlinterpretation durch Anwender), die IEC 62304 adressiert nur die Software-internen Risiken. Die beiden Standards sind miteinander verschränkt: Die Risiko-Controls, die ISO 14971 identifiziert, werden in der IEC-62304-Architektur als Software-Anforderungen umgesetzt und dort geprüft.

Operatives Rückgrat von ISO 14971 für DiGA:

• Risikoanalyse – systematische Identifikation von Gefährdungen und Gefährdungssituationen entlang der Zweckbestimmung und der vorhersehbaren Fehlanwendung.
• Risiko-Evaluation – Kombination von Wahrscheinlichkeit und Schwere; Entscheidung über Akzeptanz-Schwellen.
• Risiko-Controls – mitigierende Maßnahmen, geordnet nach Hierarchie (inhärente Sicherheit → Schutzmaßnahmen → Informationen für Sicherheit).
• Residual-Risiko-Beurteilung – Bewertung des nach Controls verbleibenden Risikos, Patientennutzen-Abwägung, Gesamturteil.
• Post-Market-Surveillance-Rückfluss – Praxisbefunde laufen zurück in die Risiko-Akten; das Risiko-Management ist nie „fertig".

Ein eigener Cluster-Artikel „ISO 13485 für Software-Hersteller – QMS ohne Overhead" ist in Vorbereitung.

BSI TR-03185 – organisatorische SDLC-Zertifizierung

BSI TR-03185 ist die organisatorische Zertifizierung des Software-Entwicklungs-Lebenszyklus. Sie ist binär – kein „mit Auflagen"-Ausgang – und evaluiert Prozesse, die über einzelne Projekte hinweg greifen: Projekt-Management, Konfigurations- und Change-Management, Secure-Coding-Anforderungen, Drittanbieter-Software-Management, Test-Methodik, Incident-Management, Betriebs- und Wartungsphase. Der Cyber Resilience Act (VO (EU) 2024/2847)↗ liegt in derselben Richtung und adressiert Cybersicherheit über den gesamten Produkt-Lebenszyklus – TR-03185 ist eine der praxisnahen deutschen Umsetzungen. DUX Healthcare ist das erste Unternehmen, das die TR-03185-Zertifizierung erhalten hat.

TR-03185 und die DiGA-spezifische TR-03161 ergänzen sich: Eine Organisation mit TR-03185-Zertifikat durchläuft jede folgende TR-03161-Prüfung schneller, weil die SDLC-Evidenz pro DiGA nicht neu aufgebaut werden muss. Die Produktprüfung pro DiGA bleibt aber Pflicht und ist unter BSI TR-03161 Zertifizierung im DiGA-Bereich dokumentiert.

Zwei weitere Standards, die in der Architektur-Diskussion immer wieder auftauchen und gegen die sauber abzugrenzen ist:

• ISO 27001 – Informationssicherheits-Management-System. Für DiGA ist ein akkreditiertes ISO-27001-Zertifikat (oder gleichwertig) auf Organisations-Ebene Pflicht (DiGA-Leitfaden v3.6 Kap. 3.4.1). Kein Ersatz für TR-03161; in der TR-03161 Teil 3 wird ISO 27001 (oder IT-Grundschutz, oder äquivalent) explizit als Voraussetzung adressiert.
• BSI C5 – Cloud-Computing-Kriterienkatalog. Cloud-gehostete DiGA-Backends sollen nach Empfehlung des BSI auf Providern laufen, die C5 (oder Äquivalenz) erfüllen. Große Hyperscaler erfüllen das typisch; kleinere oder selbstgebaute Infrastrukturen oft nicht.

BfArM-Datenschutzprüfkriterien – Schnittstellen zum Foundation-Stack

Datenschutz ist für DiGA-Antragsteller nicht primär MDR-Thema – die MDR regelt Sicherheit und Leistung, nicht Datenschutz. Den Rechtsrahmen stellen DSGVO und das nationale Datenschutzrecht; das BfArM operationalisiert sie im DiGA-Kontext über die BfArM-Datenschutzprüfkriterien nach § 139e Abs. 11 SGB V. Der Prüfkriterien-Katalog umfasst rund 150 Einzelanforderungen in zwölf Themenblöcken (Verantwortlichkeit, Informationspflichten, Einwilligung, Rechtmäßigkeit der Verarbeitung, Auftragsverarbeitung, Internationale Datenübermittlungen, Betroffenenrechte, Pseudonymisierung, Authentifizierung, Access Control, Protokollierung, Löschung) und ist seit 01.08.2024 über DiGAV § 4 Abs. 8 verbindlich umzusetzen; der Hersteller legt die Umsetzung mit der Erklärung nach Anlage 1 DiGAV mit dem Antrag offen. Eine formale Zertifizierung durch eine akkreditierte unabhängige Stelle nach ISO/IEC 17065 ist Stand Q1 2026 noch nicht möglich, weil keine Stelle akkreditiert ist – sobald eine solche Stelle akkreditiert ist, wird das BfArM die Vorlage eines formalen Zertifikats mit Vorlauf einfordern.

Der Verantwortliche im Sinne der DSGVO (Art. 4 Nr. 7) ist der Hersteller, nicht ein Plattform-Dienstleister. DUX implementiert auf Plattform-Seite die technischen Anforderungen (TOM_, AV_1.3 TOMs, ACC_, Pseudonymisierung, Access Control); die Prozess-Seite (CTRL_1.2 DSB-Ernennung, CTRL_1.4 EU-Vertreter sofern anwendbar, AV_2 Auftragsverarbeiter-Vertrag, DSFA_1.8 Review-Kadenz) bleibt Hersteller-Verantwortung – DUX unterstützt operativ.

Diese Ebene liegt primär im DiGA-Wissens-Bereich. Wer den Katalog im Detail braucht, liest den ausführlichen Artikel BfArM-Datenschutzprüfkriterien im Detail.

Für die Foundation-Perspektive relevant sind drei Schnittstellen zum technischen Stack:

1. Die RFC-2119-Grammatik der Prüfkriterien entspricht der TR-03161. MUSS-Anforderungen sind nicht verhandelbar; SOLL-Anforderungen nur mit Nachweis fehlenden Risikos auslassbar.
2. Die Kriterien verzahnen mit der IEC-62304-Architektur. Pseudonymisierung, Access Control, Protokollierung und Löschung sind nicht nur Compliance-Punkte, sondern Software-Anforderungen – sie müssen als solche im Architektur-Dokument, im Risiko-Management und im Test-Protokoll auftauchen.
3. Die Prüfkriterien laufen parallel zur TR-03161, nicht sequenziell. Beide werden im Antrag vorgelegt; beide werden unabhängig geprüft; beide können denselben technischen Mechanismus (z. B. einen Audit-Trail) abbilden – aber sie fragen verschiedene Dinge.

Für Teams, die aus einem Consumer-App-Hintergrund kommen: Der wesentliche Mindset-Shift liegt in der Granularität. DSGVO-Konformität als Datenschutz-Erklärung reicht nicht; Anlage-1-DiGAV-Checkliste plus rund 150 einzeln geprüfte Kriterien ist die real geprüfte Schwelle.

AI Act × MDR – der 2026-Ausblick

Der EU AI Act (Verordnung (EU) 2024/1689) ist am 01.08.2024 in Kraft getreten. Die Pflichten greifen gestaffelt: Verbot bestimmter Praktiken ab 02.02.2025, Pflichten für General-Purpose-AI-Models ab 02.08.2025, High-Risk-AI-System-Pflichten ab 02.08.2026 (AI Act Art. 113↗). Für KI-Systeme, die als MDR/IVDR-Produkt klassifiziert sind, gilt eine verlängerte Übergangsfrist – integrierte Konformitätsbewertung greift regulär ab 02.08.2027.

Für DiGA mit KI-Komponenten ist MDCG 2025-6 / AIB 2025-1↗ (Juni 2025) die zentrale Interpretations-Quelle. Der Kerngedanke: Ein MDAI (Medical Device Artificial Intelligence) – also ein AI-System, das als MDR/IVDR-Produkt qualifiziert – wird dann als High-Risk-AI-System nach Art. 6(1) AIA eingestuft, wenn (a) es als Sicherheitskomponente eines Produkts oder selbst als Produkt unter MDR/IVDR fällt und (b) die MDR/IVDR-Konformitätsbewertung unter Beteiligung einer Benannten Stelle erfolgt. In Tabelle 1 der MDCG 2025-6 ist die Zuordnung explizit ausgeführt: MDR-Klasse-I-Produkte ohne Benannte-Stellen-Beteiligung sind kein Art.-6(1)-High-Risk; MDR-Klasse-IIa/IIb/III-Produkte sind es.

Praktische Konsequenz für DiGA mit KI-Komponenten (typisch: Symptom-Scoring, personalisierte Therapieempfehlung, Adherence-Prediction, Bildanalyse):

• Klasse-IIa-DiGA mit Benannter Stelle ist zugleich High-Risk-AI-System nach AI Act. Die AI-Act-High-Risk-Pflichten (Daten-Governance, Transparenz, menschliche Aufsicht, QMS-Ergänzungen, Post-Market-Monitoring-Integration) überlagern die MDR-Anforderungen, ersetzen sie nicht.
• Klasse-I-DiGA ohne Benannte-Stellen-Beteiligung ist nach Art. 6(1) typischerweise kein High-Risk-AI-System, kann aber anderen AI-Act-Anforderungen (z. B. Transparenz-Pflichten nach Art. 50) unterliegen.
• Das QMS nach MDR/ISO 13485 deckt viele AI-Act-Pflichten ab – aber nicht alle. AI-Act-spezifische Anforderungen (Daten-Qualität nach Art. 10, menschliche Aufsicht nach Art. 14, Logging nach Art. 12) verlangen QMS-Erweiterungen, insbesondere im Trainingsdaten-Management und in der Model-Lifecycle-Dokumentation.

Empfehlung an DiGA-Teams mit KI-Komponenten: Den AI Act heute als Architektur-Input behandeln, nicht als Projekt für 2027. Trainingsdaten-Herkunft, -Kuratierung und -Bias-Analyse sind retrospektiv kaum herstellbar. Modell-Governance-Artefakte – Modell-Karte, Impact-Assessment, Drift-Monitoring – werden in jedem ernst gemeinten Model-Ops-Setup ohnehin gebaut; sie dokumentarisch an AI-Act-Art.-10-bis-Art.-15-Anforderungen auszurichten, ist geringer Zusatzaufwand.

Ein eigener Cluster-Artikel „AI Act und Medizinprodukte – was 2026 zu tun ist" ist in Vorbereitung.

Plattform vs. Custom-Build – der Platform-Angle

DUX Healthcare baut keine DiGAs in Custom-Manier. Fünf DiGAs sind aktuell unter Vertrag und werden auf der mHealth Suite entwickelt — plattform-entwickelt, jede pro DiGA gegen BSI TR-03161 geprüft, CE-konform nach MDR. Auf Prozessebene ist der Software-Entwicklungszyklus als erstes Unternehmen Deutschlands nach BSI TR-03185 zertifiziert.

Der Grund, warum Plattform gegenüber Custom-Build im Foundation-Stack strukturell vorteilhaft ist, hat nichts mit Entwicklungs-Geschwindigkeit zu tun. Er hat mit dem Charakter der Stack-Artefakte zu tun:

• IEC 62304-Architektur, SOUP-Deklarationen, Unit-Test-Evidenz, Konfigurationsmanagement – einmal auf Plattform-Ebene gebaut, pro DiGA delta-geprüft.
• ISO 13485-QMS-Prozesse, Design-Control, CAPA, Management-Review – pro Organisation, nicht pro Produkt.
• ISO 14971-Risiko-Kataloge – plattform-spezifische Basis-Risiko-Bibliothek plus DiGA-spezifische Produkt-Risiken.
• TR-03161-Evidenz – geteilte Architekturkomponenten (Authentifizierung, Backend-Kommunikation, Secret-Management) tragen die O.*-Anforderungen einmal; DiGA-spezifische Komponenten werden delta-geprüft.
• TR-03185-SDLC – pro Organisation, einmal zertifiziert, jede folgende TR-03161-Prüfung beschleunigend.
• BfArM-DS-Kriterien – plattform-weite Lösungen für Access Control, Protokollierung, Löschung, Pseudonymisierung; DiGA-spezifische Konfiguration in der Anwendung.

Wer die Plattform-Mechanik selbst anschauen will, findet die Übersicht unter /build/.

Antworten auf häufige Fragen