Einleitung
Im „Proposal for a Regulation amending the MDR“ der Europäischen Kommission vom 16. Dezember 2025 (COM(2025) 1023 final) (https://health.ec.europa.eu/publications/proposal-regulation-simplify-rules-medical-and-vitro-diagnostic-devices_en) finden sich auch die geplanten Änderungen von Regel 11 im Anhang VIII der Medical Device Regulation (Regulation EU 2017/745 (MDR)) (http://data.europa.eu/eli/reg/2017/745/2026-01-01). Dieser Beitrag untersucht die möglichen Auswirkungen dieses Änderungsvorschlags, denn Regel 11 gehört seit Jahren zu den mit am intensivsten diskutierten Regelungen zur Klassifizierung von Software als Medizinprodukt.
Wichtig: mit dem im Dezember 2025 veröffentlichten Vorschlag der Europäischen Kommission zur Änderung der MDR (COM(2025) 1023) handelt es sich ausdrücklich noch um einen Vorschlag, der sich im weiteren Gesetzgebungsverfahren ändern kann und derzeit keine rechtliche Bindungswirkung entfaltet. Dennoch lässt sich bereits eine klare regulatorische Stoßrichtung erkennen. Zur nach wie vor gültigen Anwendung der Regel 11 siehe https://www.vde.com/topics-de/health/beratung/regel-11.
Anmerkung: Sie finden weiter unten die diskutierten Passagen der MDR und des Änderungsvorschlags in englischer Sprache.
Medizinische Zweckbestimmung bleibt Voraussetzung
Auch der Änderungsvorschlag setzt voraus, dass die zu klassifizierende Software ein Medizinprodukt im Sinne der Definition „Medizinprodukt“ gemäß MDR ist. Das ist dann der Fall, wenn die Software einen medizinischen Zweck verfolgt, etwa zur Diagnose, Überwachung, Vorhersage, Prognose oder Behandlung einer Krankheit oder eines Zustands.
Siehe auch MDR, Art. 2, Abs. 1.
Daraus ergibt sich, dass bei der zu klassifizierenden Software ein klinischer Nutzen vorhanden ist.
In der Vergangenheit wurde jedoch der klinische Nutzen häufig überinterpretiert, was insbesondere daran liegt, dass die Regel 11 direkt mit Klasse IIb startet und dann, je nach Kritikalität, die Klassifizierung nach oben (kritischer) oder nach unten (weniger kritisch) zulässt. Es wurde oft diskutiert, dass eine Software damit „automatisch“ in Klasse IIb zu klassifizieren ist, da eine „Klasse-I-Software“ keinen klinischen Nutzen habe.
Trifft das zu?
Kritisch betrachtet bedeutet „klinischer Nutzen“ zunächst nur, dass die Software einen (positiven) medizinischen Zweck erfüllt. Er sagt nichts darüber aus, wie kritisch der Einsatz der Software ist oder welche Folgen ein fehlerhafter Output haben könnte.
Der Änderungsvorschlag der Kommission greift diese Problematik nun auf, indem die Klassifizierung stärker an der Verwendung und den tatsächlichen Risiken ausgerichtet wird. Dies gelingt dadurch, dass die Klassifizierung nun bei Klasse I startet. Damit soll erreicht und verdeutlicht werden, dass klinischer Nutzen allein nicht automatisch eine höhere Risikoklasse (wie z.B. IIb) mit sich bringt.
Fokus der Klassifizierung: Anwendungskontext
Klinischer Nutzen (ist nicht gleichbedeutend mit) Anwendungskontext (ist nicht gleichbedeutend mit) Risiko(klasse).
Regel 11 muss im Kontext der Anwendung des Medizinprodukts, also der zu klassifizierenden Software, angewendet werden. Entscheidend ist also nicht allein, was die Software tut (klinischer Nutzen), sondern auch der Kontext, in dem die Software verwendet wird (Anwendungskontext). Was kann passieren, wenn die Software falsche oder unvollständige Informationen liefert? In welchem zeitlichen Rahmen ist das zu betrachten?
Der Änderungsvorschlag unterstützt diese Logik und hebt sie wesentlich klarer hervor, als dies in der bisherigen Formulierung der Fall ist.
Die „nicht schwerwiegende Situation“
Sobald Software als Medizinprodukt in einer klinischen Situation eingesetzt wird, wird sie Teil eines medizinischen Entscheidungsprozesses. Allein schon durch die Tatsache, dass sie Informationen anzeigt. Sieht der Anwender diese Information, dann wird er beeinflusst.
Eine Frage stellt sich jedoch: rechtfertigt jedwede Informationsdarstellung die Klassifizierung in (mindestens) Klasse IIa? Gemäß dem aktuellen Text der Regel 11 ( „[…] Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden, gehört zur Klasse IIa, […]“) entsteht dieser Eindruck, wobei eine noch höhere Klasse möglich ist. Klasse I scheint komplett auszuscheiden.
Der Änderungsvorschlag greift die Problematik auf und startet mit „Klasse I“. Die Einstufung in Klasse IIa (höhere Klassen sind je nach Kritikalität der Anwendung möglich) soll stattfinden, sofern folgendes zutrifft (frei übersetzt): „[…] die Ausgabe ist für eine Krankheit oder einen Zustand in einer nicht schwerwiegenden Situation vorgesehen oder dient dazu, das klinische Management in einer schwerwiegenden Situation zu steuern oder das klinische Management in einer kritischen oder schwerwiegenden Situation zu informieren […]“.
Leider bleibt die „schwerwiegende Situation“ bzw. die „nicht schwerwiegende Situation“ undefiniert.
Interpretation
Entscheidend ist zu verstehen, dass eine medizinische Software sich auf eine Krankheit beziehen und entsprechende Informationen zur Verfügung stellen kann, jedoch ohne in einer konkreten klinischen Situation (sowohl in einer schwerwiegenden als auch in einer nicht schwerwiegenden Situation) eingesetzt zu werden.
Die „klinische Situation“ bezieht sich darauf, dass die Software beispielsweise konkrete Vorgaben oder Diagnosen für einen speziellen Patienten liefert und den Anwender in seinem Handeln und seinen Entscheidungen maßgeblich beeinflusst. Kann der Anwender die Aussage treffen „Ich habe selbst und eigenständig entschieden – die Software hat mir lediglich Informationen geliefert, um meine Entscheidung vorzubereiten“? In diesem Fall liegt ein bloßer medizinischer Bezug vor und kein tatsächlicher Behandlungskontext mit Entscheidungsdruck.
Der Änderungsvorschlag unterstützt durch die Umformulierung diese Differenzierung und ermöglicht, medizinische Software in Klasse I zu klassifizieren.
Ergebnis: medizinische Software kann demnach einen klinischen Nutzen haben, aber keine Gefährdung für Patienten darstellen, selbst wenn sie sich auf Krankheiten oder Gesundheitszustände bezieht.
Entscheidend ist jedoch die saubere und klare Formulierung einer Zweckbestimmung. Siehe auch https://www.vde.com/topics-de/health/beratung/zulassung-von-medizinprodukten.
Höherklassifizierung
Eine Höherklassifizierung ist nach wie vor angezeigt, wenn medizinische Software aktiv in klinische Entscheidungsprozesse eingreift. Beispielsweise könnte durch die von der Software gelieferten Informationen zu Fehlentscheidungen und damit zu einer ernsthaften Verschlechterung des Gesundheitszustands des Patienten bis hin zu lebensbedrohlichen Situationen führen. In solchen Fällen ist nach wie vor Klasse IIa, Klasse IIb oder sogar Klasse III angezeigt.
Noch kein geltendes Recht
Die Neufassung von Regel 11 ist derzeit nur ein Vorschlag der Europäischen Kommission. Änderungen im weiteren Gesetzgebungsverfahren sind möglich und nicht auszuschließen. Dennoch zeigt der Entwurf klar, dass die bisherigen Auslegungsprobleme erkannt wurden und dass die Klassifizierung medizinischer Software wieder stärker am tatsächlichen Risiko ausgerichtet werden soll.
Textpassagen der MDR und des Änderungsvorschlags
Bitte achten Sie darauf, dass sich die Links bzw. deren Inhalte ändern können. Letzter Zugriff: 20260112.
Regulation (EU) 2017/745 (MDR)
http://data.europa.eu/eli/reg/2017/745/2025-01-10
6.3. Rule 11
Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause:
- death or an irreversible deterioration of a person's state of health, in which case it is in class III; or
- a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb.
Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb.
All other software is classified as class I.
COM(2025) 1023 final – Annex
(g) Section 6.3 is replaced by the following:
‘6.3 Rule 11
Software which is intended to generate an output that confers a clinical benefit and is used for diagnosis, treatment, prevention, monitoring, prediction, prognosis, compensation or alleviation of a disease or condition is classified as class I, unless the output is intended for a disease or condition:
- in a critical situation with a risk of causing death or an irreversible deterioration of a person's state of health, in which case it is classified as class III;
- in a serious situation with a risk of causing a serious deterioration of a person's state of health or a surgical intervention, or to drive clinical management in a critical situation in which cases it is classified as class IIb;
- in a non-serious situation, or to drive clinical management in a serious situation or to inform clinical management in a critical or serious situation in which cases it is classified as class IIa.’;
