Software as Medical Device (SaMD): Wann Ihre KI-App zum Medizinprodukt wird

Software as a Medical Device (SaMD) ist ein zentrales Konzept der europäischen Medizinproduktregulierung. Für Softwareunternehmen und Startups, die KI-gestützte Lösungen für das Gesundheitswesen entwickeln, ist die korrekte Einordnung ihrer Software entscheidend: Handelt es sich um ein Medizinprodukt – oder nicht? Dieser Leitfaden führt Sie durch die regulatorischen Anforderungen der MDR, die Schnittstellen zum EU AI Act und gibt Ihnen eine konkrete Checkliste für den Weg zur Marktfähigkeit.

1. Was ist SaMD? Definition und Abgrenzung

Der Begriff Software as a Medical Device (SaMD) beschreibt Software, die eigenständig – also ohne Teil eines Hardware-Medizinprodukts zu sein – einen medizinischen Zweck erfüllt. Die Medical Device Regulation (MDR, Verordnung (EU) 2017/745) definiert in Art. 2 Nr. 1:

"Medizinprodukt" bezeichnet unter anderem Software, die vom Hersteller zur Verwendung beim Menschen für einen oder mehrere der in der Verordnung genannten spezifischen medizinischen Zwecke bestimmt ist.

Entscheidend ist die Zweckbestimmung des Herstellers. Nicht die technische Funktionalität der Software bestimmt, ob sie ein Medizinprodukt ist, sondern der vom Hersteller vorgesehene Verwendungszweck.

Abgrenzung: SaMD vs. SiMD vs. Wellness-Software

• SaMD (Software as a Medical Device): Eigenständige Software mit medizinischem Zweck. Beispiel: KI-basierte Hautkrebs-Screening-App, die eine diagnostische Empfehlung gibt.
• SiMD (Software in a Medical Device): Software, die Teil eines Hardware-Medizinprodukts ist. Beispiel: Steuerungssoftware eines Beatmungsgeräts.
• Gesundheits- und Wellness-Software: Software ohne spezifischen medizinischen Zweck. Beispiel: Fitness-Tracker, der nur Schritte zählt, ohne diagnostischen Anspruch.

Die Grenze zwischen SaMD und Wellness-Software ist fließend und wird durch die Zweckbestimmung des Herstellers gezogen. Eine Schrittzähler-App wird zum Medizinprodukt, wenn der Hersteller sie zur Überwachung der Mobilität nach einer Hüft-OP bewirbt.

2. MDR Regel 11: Wann wird Software zum Medizinprodukt?

Regel 11 in Anhang VIII der MDR ist die zentrale Klassifizierungsregel für Software. Sie bestimmt nicht nur, ob eine Software ein Medizinprodukt ist, sondern auch, in welche Risikoklasse sie fällt. Der Wortlaut:

"Software, die dazu bestimmt ist, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden, gehört zur Klasse IIa, es sei denn, diese Entscheidungen haben Auswirkungen, die Folgendes verursachen können: den Tod oder eine irreversible Verschlechterung des Gesundheitszustands (Klasse III) oder eine schwerwiegende Verschlechterung des Gesundheitszustands oder einen chirurgischen Eingriff (Klasse IIb). Software, die für die Überwachung physiologischer Prozesse bestimmt ist, gehört zur Klasse IIa, es sei denn, sie ist für die Überwachung vitaler physiologischer Parameter bestimmt, bei denen Schwankungen zu einer unmittelbaren Gefahr für den Patienten führen können (Klasse IIb). Alle andere Software gehört zur Klasse I."

Die wichtigste Konsequenz: Software, die diagnostische oder therapeutische Entscheidungen beeinflusst, ist mindestens Klasse IIa und damit konformitätsbewertungspflichtig durch eine Benannte Stelle. Eine Selbstzertifizierung wie bei Klasse-I-Produkten ist nicht möglich.

3. Risikoklassifizierung: Entscheidungsbaum für Ihre Software

Die korrekte Risikoklassifizierung ist der erste und wichtigste Schritt Ihrer regulatorischen Strategie. Folgen Sie diesem strukturierten Entscheidungsbaum:

Stufe 1: Hat die Software einen medizinischen Zweck?

• Nein: Kein Medizinprodukt. Aber prüfen Sie, ob der EU AI Act Anwendung findet.
• Ja: Weiter zu Stufe 2.

Stufe 2: Liefert die Software Informationen für diagnostische oder therapeutische Entscheidungen?

• Nein: Prüfen Sie, ob die Software physiologische Prozesse überwacht. Falls ja: Klasse IIa (oder IIb bei vitalen Parametern). Falls nein: Klasse I.
• Ja: Mindestens Klasse IIa. Weiter zu Stufe 3.

Stufe 3: Welche Auswirkungen können fehlerhafte Entscheidungen haben?

• Tod oder irreversible Gesundheitsschäden möglich: Klasse III
• Schwerwiegende Gesundheitsschäden oder chirurgischer Eingriff möglich: Klasse IIb
• Sonstige Auswirkungen: Klasse IIa

Praxisbeispiele: Eine KI zur Erkennung diabetischer Retinopathie, deren Fehldiagnose zur Erblindung führen kann → Klasse III. Eine KI-Dokumentationshilfe, die ICD-10-Codes vorschlägt → Klasse IIa. Eine KI zur Optimierung von Medikamentendosierungen bei Chemotherapie → Klasse IIb bis III.

4. Zweckbestimmung als Schlüssel

Die Zweckbestimmung (Intended Purpose) ist das zentrale Dokument Ihrer regulatorischen Strategie. Sie definiert, was Ihre Software tun soll – und was nicht. Die MDR verlangt in Art. 2 Nr. 12 eine klare Angabe über die bestimmungsgemäße Verwendung.

Die Zweckbestimmung bestimmt:

• Ob Ihre Software ein Medizinprodukt ist
• Welcher Risikoklasse sie zugeordnet wird
• Welche klinischen Nachweise Sie erbringen müssen
• Welche Konformitätsbewertung durchzuführen ist

Typische Fehler bei der Zweckbestimmung

• Zu weit gefasst: "Die Software unterstützt Ärzte bei der Diagnose." Diese Formulierung führt regelmäßig zu einer höheren Risikoklassifizierung als nötig.
• Zu eng gefasst: Eine künstlich eingeschränkte Zweckbestimmung, die nicht der tatsächlichen Nutzung entspricht, kann bei einer Prüfung durch die Benannte Stelle oder bei Haftungsfällen zum Problem werden.
• Widersprüchlich zur Vermarktung: Wenn Ihre Marketing-Materialien eine andere Verwendung suggerieren als die offizielle Zweckbestimmung, kann die Behörde die tatsächliche Zweckbestimmung anhand der Gesamtkommunikation bestimmen.

Unsere Empfehlung: Formulieren Sie die Zweckbestimmung frühzeitig, präzise und abgestimmt auf Ihre regulatorische Strategie. Lassen Sie sie juristisch prüfen, bevor Sie die klinische Bewertung beginnen.

5. CE-Kennzeichnung: Der Weg zur Konformität

Die CE-Kennzeichnung ist die Voraussetzung für das Inverkehrbringen eines Medizinprodukts im europäischen Wirtschaftsraum. Für SaMD ab Klasse IIa ist die Einbeziehung einer Benannten Stelle (Notified Body) erforderlich.

Die wesentlichen Schritte zur CE-Kennzeichnung

• Qualitätsmanagementsystem (QMS): Implementierung eines QMS nach ISO 13485:2016. Dieses bildet das Fundament aller weiteren regulatorischen Aktivitäten.
• Risikomanagement: Durchführung nach ISO 14971:2019. Für Software zusätzlich IEC 62304 (Software-Lebenszyklusprozesse) und IEC 82304-1 (Gesundheitssoftware).
• Technische Dokumentation: Erstellung gemäß Anhang II und III der MDR, einschließlich Produktbeschreibung, Design- und Herstellungsinformationen, Sicherheits- und Leistungsanforderungen sowie Nutzen-Risiko-Analyse.
• Klinische Bewertung: Nachweis der klinischen Sicherheit und Leistungsfähigkeit gemäß Art. 61 MDR. Bei Software kann dies auch über Literaturstudien, Equivalence-Analysen oder eigene klinische Studien erfolgen.
• Konformitätsbewertung: Prüfung durch die Benannte Stelle und Ausstellung der EU-Konformitätserklärung.
• Post-Market Surveillance: Etablierung eines Systems zur Überwachung nach dem Inverkehrbringen (PMS-Plan, PSUR).

Die Dauer des gesamten Prozesses beträgt erfahrungsgemäß 12 bis 24 Monate, abhängig von der Risikoklasse und der Verfügbarkeit Benannter Stellen. Planen Sie ausreichend Vorlaufzeit ein und berücksichtigen Sie die zusätzlichen Anforderungen durch den EU AI Act bei Updates und Änderungen.

6. Schnittmenge MDR und EU AI Act: Was gilt zusätzlich?

Für KI-basierte Medizinprodukte greifen ab August 2027 beide Regelwerke kumulativ. Die folgende Tabelle zeigt die wichtigsten Überschneidungen und Ergänzungen. Vertiefende Informationen finden Sie in unserem Beitrag zur AI Act und MDR Compliance.

Der Vorteil für Hersteller: Art. 43 Abs. 1 EU AI Act sieht vor, dass die Konformitätsbewertung nach dem AI Act in die bestehende MDR-Konformitätsbewertung integriert wird. Sie benötigen also keine separate AI-Act-Zertifizierung – die Benannte Stelle prüft beide Regelwerke in einem Verfahren.

7. DiGA als Sonderfall

Digitale Gesundheitsanwendungen (DiGA) nach § 33a SGB V sind ein deutscher Sonderweg, der die europäische MDR-Regulierung mit nationalen Anforderungen des BfArM kombiniert. Für KI-basierte DiGA ergeben sich besondere Herausforderungen.

DiGA-spezifische Anforderungen

• CE-Kennzeichnung als Voraussetzung: Jede DiGA muss zunächst als Medizinprodukt der Klasse I oder IIa CE-zertifiziert sein. Für KI-basierte DiGA ist regelmäßig Klasse IIa einschlägig (Regel 11).
• DiGAV-Anforderungen: Die Digitale-Gesundheitsanwendungen-Verordnung (DiGAV) stellt zusätzliche Anforderungen an Datenschutz, Informationssicherheit (nach BSI-Anforderungskatalog), Interoperabilität und Barrierefreiheit.
• Nachweis positiver Versorgungseffekte: Im Fast-Track-Verfahren muss innerhalb von 12 Monaten (nach vorläufiger Aufnahme) ein positiver Versorgungseffekt nachgewiesen werden – entweder medizinischer Nutzen oder patientenrelevante Verfahrens- und Strukturverbesserungen.
• KI-Transparenz: Das BfArM verlangt zunehmend Transparenz über eingesetzte KI-Verfahren. Mit Inkrafttreten der AI-Act-Pflichten wird sich dies weiter verschärfen.

Detaillierte Informationen zu den besonderen Anforderungen an KI in DiGA finden Sie in unserem Beitrag zu den DiGA-KI-Anforderungen.

8. Checkliste für Startups: Von der Idee zum zugelassenen Medizinprodukt

Die folgende Checkliste fasst die wesentlichen Schritte zusammen, die ein Startup auf dem Weg zur Marktreife beachten muss:

Phase 1: Regulatorische Strategie (Monat 1–3)

• Zweckbestimmung formulieren und juristisch prüfen lassen
• Risikoklassifizierung nach Regel 11 MDR durchführen
• Prüfen, ob das KI-System unter den EU AI Act fällt (Hochrisiko-Einstufung)
• Regulatorische Roadmap erstellen, einschließlich Zeitplan und Budget
• Regulatory-Affairs-Verantwortlichen benennen (intern oder extern)

Phase 2: QMS und Entwicklung (Monat 3–9)

• Qualitätsmanagementsystem nach ISO 13485 implementieren
• Softwareentwicklung nach IEC 62304 aufsetzen (Lebenszyklusmodell, Risikoklassen)
• Risikomanagement nach ISO 14971 durchführen
• Usability Engineering nach IEC 62366 einbeziehen
• Für KI-Systeme: Daten-Governance gemäß Art. 10 EU AI Act aufbauen (Trainingsdatenqualität, Bias-Monitoring)
• Cybersicherheitskonzept erstellen

Phase 3: Klinische Evidenz (Monat 6–18)

• Klinische Bewertung planen (Literaturrecherche, Äquivalenzbewertung oder eigene Studie)
• Klinischen Bewertungsplan (Clinical Evaluation Plan, CEP) erstellen
• Bei Bedarf: Klinische Prüfung nach Art. 62 MDR durchführen
• Klinischen Bewertungsbericht (CER) verfassen
• Post-Market Clinical Follow-Up (PMCF) planen

Phase 4: Konformitätsbewertung (Monat 12–24)

• Benannte Stelle auswählen und Vertrag abschließen (Vorlaufzeiten beachten)
• Technische Dokumentation finalisieren
• Audit durch Benannte Stelle vorbereiten und durchführen
• Eventuelle Nachforderungen (CAPAs) bearbeiten
• EU-Konformitätserklärung ausstellen und CE-Kennzeichnung anbringen
• Registrierung in EUDAMED (sobald vollständig verfügbar)

Phase 5: Markteinführung und laufende Pflichten

• Post-Market Surveillance System implementieren
• Vigilanz-System einrichten (Meldung schwerwiegender Vorkommnisse)
• Periodische Sicherheitsberichte erstellen (PSUR)
• Bei KI-Systemen: Monitoring gemäß Art. 72 EU AI Act (kontinuierliche Leistungsüberwachung)
• Änderungsmanagement für Software-Updates etablieren – jedes Update kann eine erneute Konformitätsbewertung auslösen
• Optional: DiGA-Zulassung beim BfArM beantragen

Wichtiger Hinweis für KI-Startups: Wenn Ihre Software lernende Algorithmen verwendet, die sich durch Updates verändern, müssen Sie ein Konzept für das Change Management entwickeln, das sowohl die MDR- als auch die AI-Act-Anforderungen berücksichtigt. Jede wesentliche Änderung des KI-Modells kann als neues oder wesentlich verändertes Produkt gelten und eine erneute Konformitätsbewertung erfordern. Planen Sie dies von Anfang an in Ihre Entwicklungs- und Geschäftsstrategie ein.

Häufig gestellte Fragen (FAQ)

Was ist Software as a Medical Device (SaMD) und wann gilt meine Software als Medizinprodukt?

SaMD ist eigenständige Software, die ohne Teil eines Hardware-Medizinprodukts zu sein einen medizinischen Zweck erfüllt. Ob Software ein Medizinprodukt ist, bestimmt die Zweckbestimmung des Herstellers — nicht die technische Funktionalität. Eine Schrittzähler-App wird zum Medizinprodukt, wenn sie zur Überwachung nach einer OP beworben wird.

Welche Risikoklasse gilt für KI-basierte Medizinsoftware nach der MDR?

Nach Regel 11 MDR ist Software, die diagnostische oder therapeutische Entscheidungen beeinflusst, mindestens Klasse IIa. Bei Risiken für schwerwiegende Gesundheitsschäden gilt Klasse IIb, bei Todesgefahr oder irreversiblen Schäden Klasse III. Ab Klasse IIa ist die Prüfung durch eine Benannte Stelle erforderlich.

Wie lange dauert die CE-Kennzeichnung für medizinische KI-Software?

Erfahrungsgemäß 12 bis 24 Monate, abhängig von der Risikoklasse und der Verfügbarkeit Benannter Stellen. Der Prozess umfasst QMS nach ISO 13485, Risikomanagement nach ISO 14971, klinische Bewertung und die eigentliche Konformitätsbewertung.

Müssen KI-Medizinprodukte sowohl MDR als auch EU AI Act erfüllen?

Ja, ab August 2026 greifen beide Regelwerke kumulativ. Der Vorteil: Die Konformitätsbewertung nach dem AI Act wird in die bestehende MDR-Bewertung integriert, sodass die Benannte Stelle beide Regelwerke in einem Verfahren prüft.

Was sind die häufigsten Fehler bei der Zweckbestimmung von Medizinsoftware?

Die drei häufigsten Fehler: zu weit gefasste Zweckbestimmung (führt zu überhöhter Risikoklasse), zu enge Zweckbestimmung (stimmt nicht mit der realen Nutzung überein) und Widersprüche zwischen offizieller Zweckbestimmung und Marketingmaterialien. Die Behörde kann die tatsächliche Zweckbestimmung anhand der Gesamtkommunikation bestimmen.