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?

Ob eine Software überhaupt ein Medizinprodukt ist, folgt aus ihrer Zweckbestimmung nach Art. 2 Nr. 1 MDR. Regel 11 in Anhang VIII der MDR ist dann die zentrale Klassifizierungsregel und bestimmt, 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 aus dem Gespräch ICD-10-Diagnosen vorschlägt → Grenzfall, bei Medizinprodukt-Status regelmäßig 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, zählt auch das Werbematerial, denn nach Art. 2 Nr. 12 kann Werbe- und Verkaufsmaterial die Zweckbestimmung für sich tragen.

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, die eine Benannte Stelle bewerten muss, also ab Klasse IIa, greifen ab August 2028 beide Regelwerke kumulativ (Digital Omnibus, VO (EU) 2026/1744). 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. 3 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.

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

Nach Regel 11 MDR gehört Software, die Informationen liefert, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden, zur Klasse IIa. Kann eine solche Entscheidung zu einer schwerwiegenden Verschlechterung des Gesundheitszustands oder zu einem chirurgischen Eingriff führen, ist es Klasse IIb, bei möglichem Tod oder irreversibler Verschlechterung Klasse III. Software, die für die Überwachung von physiologischen Prozessen bestimmt ist, gehört zur Klasse IIa, bei vitalen Parametern, deren Änderung zu einer unmittelbaren Gefahr für den Patienten führen könnte, zur Klasse IIb. Sämtliche andere Software ist Klasse I. Ab Klasse IIa ist eine Benannte Stelle beteiligt.

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

In der Regel ein Jahr und mehr, abhängig von der Risikoklasse und der Verfügbarkeit Benannter Stellen. Dazu gehören ein Qualitätsmanagementsystem nach ISO 13485, Risikomanagement nach ISO 14971, die klinische Bewertung und die Konformitätsbewertung.

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

Die MDR gilt für jedes Medizinprodukt. Die Hochrisiko-Anforderungen des AI Act kommen hinzu, wenn eine Benannte Stelle das Produkt bewerten muss, in der Praxis also ab Klasse IIa (Art. 6 Abs. 1 AI Act). Sie gelten auf diesem Weg ab dem 02.08.2028 und werden im Konformitätsbewertungsverfahren nach der MDR mitgeprüft. KI-Medizinsoftware der Klasse I wird über die MDR nicht Hochrisiko-KI.

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

Drei häufige Fehler: zu weit gefasste Zweckbestimmung (überhöhte Risikoklasse), zu enge Zweckbestimmung (stimmt nicht mit realer Nutzung überein) und Widersprüche zwischen Zweckbestimmung und Marketingmaterialien. Auch das Marketingmaterial kann die Zweckbestimmung für sich tragen.