Regel 11 des Anhangs VIII der MDR ist die Klassifizierungsregel, die die digitale Gesundheit am stärksten aufgewühlt hat. Unter der Richtlinie 93/42/EWG fiel die Mehrheit der Medizinprodukte-Software in die Klasse I, mit Selbstzertifizierung und ohne Benannte Stelle. Unter der MDR fällt der Großteil der Software zur Entscheidungsunterstützung mindestens in die Klasse IIa. Der Klassenwechsel ist keine dokumentarische Anpassung: Er lässt eine Benannte Stelle in das Leben des Herstellers eintreten.
Was Regel 11 genau besagt
Der Wortlaut folgt einer dreistufigen Logik, die man in der richtigen Reihenfolge lesen muss.
Erste Stufe: die Klasse IIa als Standard. Software, die dazu bestimmt ist, Informationen zu liefern, die zur Entscheidungsfindung für diagnostische oder therapeutische Zwecke herangezogen werden, fällt in die Klasse IIa. Das ist der Ausgangspunkt, nicht die Ausnahme. Jede Software zur klinischen Entscheidungsunterstützung betritt den Anwendungsbereich durch diese Tür.
Zweite Stufe: zwei Ausnahmen nach oben. Wenn die Entscheidungen, die die Software beeinflusst, Auswirkungen haben können, die den Tod oder eine irreversible Verschlechterung des Gesundheitszustands verursachen können, fällt die Software in die Klasse III. Können sie eine schwerwiegende Verschlechterung des Gesundheitszustands oder einen chirurgischen Eingriff verursachen, fällt sie in die Klasse IIb. Der chirurgische Eingriff ist ein eigenständiges Kriterium: Eine Software, deren Fehler dazu führen kann, dass operiert oder falsch operiert wird, ist IIb, auch ohne unmittelbare Lebensbedrohung. Genau diese schwerwiegenden Folgen, die die Klasse anheben, sind auch jene, die – sobald die Software auf dem Markt ist – die Vigilanzpflichten und Meldefristen auslösen.
Dritte Stufe: die Überwachung. Software, die zur Überwachung physiologischer Prozesse bestimmt ist, fällt in die Klasse IIa. Sie geht nur dann in die Klasse IIb über, wenn sie lebenswichtige physiologische Parameter überwacht, deren Veränderungen eine unmittelbare Gefahr für das Leben des Patienten darstellen können. Beide Bedingungen sind kumulativ: lebenswichtiger Parameter und unmittelbare Gefahr bei Veränderung. Eine Software, die die Herzfrequenz auf der Intensivstation überwacht, erfüllt beide Kriterien. Eine Anwendung, die dieselbe Herzfrequenz zur Wellness-Nachverfolgung aufzeichnet, erfüllt keines davon und ist wahrscheinlich nicht einmal ein Medizinprodukt.
Alle übrigen Softwareprodukte fallen in die Klasse I. Tatsächlich ist diese Kategorie eng geworden: Die Revision 2025 des Leitfadens nennt dafür ein Beispiel unter strengen Bedingungen.
Eine Anwendungsregel ergänzt das System: Software, die ein Produkt steuert oder dessen Anwendung beeinflusst, fällt in dieselbe Klasse wie dieses Produkt (Anhang VIII, Regel 3.3). Regel 11 gilt für Software, die als solche klassifiziert wird.
Warum die Neuklassifizierung so umfangreich ausfiel
Unter der Richtlinie war das zentrale Kriterium die Stellung der Software innerhalb eines physischen Produkts. Die MDR verschiebt das Kriterium hin zur klinischen Auswirkung eines Fehlers der Software selbst. Eine Software, die eine Differenzialdiagnose vorschlägt, startet in IIa und steigt je nach den Folgen eines fehlerhaften Vorschlags auf IIb oder III. Eine Software zur Bestrahlungsplanung landet in IIb oder III: Ein Dosimetriefehler kann eine irreversible Verschlechterung verursachen. Eine Software zur automatischen EKG-Auswertung steigt auf IIb, sobald ihre Ausgaben eine Entscheidung mit schwerwiegenden Folgen lenken.
Der Übergang von Klasse I zu IIa oder IIb ändert die Natur des Vorgehens: vollständige technische Dokumentation, substanzielle klinische Bewertung, Software-Lebenszyklus gemäß IEC 62304, PMS- und PMCF-Plan sowie Bewertung durch eine Benannte Stelle. Der Hersteller, der in der Klasse aufsteigt, entdeckt gleichzeitig die ISO 13485 und muss sein ISO-13485-QMS auditieren. Seine nunmehr als Medizinprodukte klassifizierte Software unterliegt darüber hinaus der eindeutigen Produktidentifikation und der EUDAMED-Registrierung, auch beim rein digitalen Vertrieb. Der Hersteller füllt nicht bloß mehr Formulare aus. Er wechselt sein regulatorisches Metier.
MDCG 2019-11 Rev.1: die Revision vom Juni 2025 mischt die Karten neu
Der maßgebliche Leitfaden zur Qualifizierung und Klassifizierung von Software, MDCG 2019-11, wurde am 17. Juni 2025 überarbeitet. Das ist keine Kosmetik. Vier Neuerungen betreffen die Hersteller direkt.
Das Ende der „Standalone Software”. Die Revision gibt den Begriff der eigenständigen Software zugunsten eines funktionsbasierten Ansatzes auf: Ausschlaggebend ist die Zweckbestimmung jeder Funktion, nicht der Träger, der sie beherbergt. Der europäische Begriff lautet MDSW (Medical Device Software). SaMD bleibt das IMDRF-Vokabular, das jenseits des Atlantiks verwendet wird, doch eine europäische Akte, die in MDSW denkt, spricht die Sprache ihres Prüfers.
Der modulare Ansatz. Eine Software kann in Module aufgeteilt werden, von denen einige eine medizinische Zweckbestimmung haben, andere nicht. Jedes medizinische Modul muss eine definierte und dokumentierte Zweckbestimmung besitzen, und der Hersteller muss nachweisen, dass die nicht-medizinischen Module weder die Sicherheit noch die Leistung der medizinischen Module beeinträchtigen. Die Grenze wird schriftlich gezogen, in der technischen Dokumentation.
Das Auftauchen des Begriffs MDAI. Die Revision benennt erstmals medizinische Software mit künstlicher Intelligenz (Medical Device AI), eine Teilmenge der MDSW, die parallel der KI-Verordnung unterliegt. Die Hersteller lernender Algorithmen müssen nun zwei Rechtstexte abgleichen, nicht nur einen.
Die Zweckbestimmung als Grundpfeiler. Die Revision betont eindringlich die Forderung nach einer präzisen, eindeutigen Zweckbestimmung, die mit den Validierungsdaten und den öffentlichen Aussagen des Herstellers übereinstimmt, einschließlich Website und Store-Einträgen. Eine Klassifizierung baut auf dieser schriftlich festgelegten Zweckbestimmung auf. Eine unklare Zweckbestimmung erzeugt eine nicht verteidigbare Klassifizierung.
Der Leitfaden unterscheidet außerdem Software, die medizinische Informationen erzeugt oder verändert, von jener, die sich darauf beschränkt, sie anzuzeigen oder zu speichern. Ein Algorithmus, der Daten verarbeitet, um daraus ein klinisches Ergebnis abzuleiten, gehört zur ersten Kategorie. Ein Portal, das Laborergebnisse ohne Verarbeitung anzeigt, gehört zur zweiten, und die zuerst zu stellende Frage ist die der Qualifizierung, noch vor der der Klasse.
Was das für einen Hersteller im Jahr 2026 bedeutet
Ein Hersteller, der seine Software vor Juni 2025 klassifiziert hat, hat seine Argumentation auf der Fassung 2019 des Leitfadens aufgebaut. Diese Fassung ist ersetzt. Die Annahmen zur Qualifizierung der Module, die Grenzfälle, die Präventionssoftware: lauter Punkte, die die Rev.1 anders oder feiner entscheidet. Eine 2022 getroffene Einstufung in Klasse I verdient eine erneute Lektüre mit dem Text von 2025 auf dem Tisch, insbesondere wenn die Software Funktionen zur Entscheidungsunterstützung enthält, die im Lauf der Versionen hinzugefügt wurden.
Das teure Szenario ist immer dasselbe: eine bei ihrer Markteinführung als I klassifizierte Software, Funktion für Funktion angereichert, deren tatsächliche Zweckbestimmung sich hin zur Entscheidungsunterstützung verschoben hat, ohne dass die Klassifizierung nachgezogen wurde. An dem Tag, an dem eine Benannte Stelle oder eine zuständige Behörde die Frage stellt, entsteht die Antwort unter Zeitdruck, mit einer Versionshistorie gegen sich.
Die eigene Klassifizierung mit der Rev.1 erneut zu prüfen, kostet einen strukturierten halben Tag. Sie im Audit als überholt zu entdecken, kostet eine erzwungene Grundsanierung. Der richtige Zeitpunkt, um die Klassifizierung Ihrer Software überprüfen zu lassen, ist der, den Sie wählen, nicht der, den ein Auditor Ihnen aufzwingt.
Regulatorische Quellen: