MDR Regel 11: Der Klassifizierungs-Albtraum?

Die MDR enthält speziell für Software eine Klassifizierungsregel: Regel 11. Diese Regel 11 hat Sprengkraft! Sie hat das Potenzial, die Innovationskraft in Europa weiter zu schwächen.

Hersteller sollten die Interpretation der MDCG kennen, um Fehlklassifizierungen von Software zu vermeiden und der Argumentation Benannter Stellen und Behörden folgen zu können. Diese Interpretation lernen Sie in diesem Beitrag kennen.

1. Inhalt der MDR-Regel 11

Regel 11 des Kapitels III im Anhang VIII der MDR besagt Folgendes:

„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 einer Person; in diesem Fall wird sie der Klasse III zugeordnet, oder
• eine schwerwiegende Verschlechterung des Gesundheitszustands einer Person oder einen chirurgischen Eingriff; in diesem Fall wird sie der Klasse IIb zugeordnet.

Software, die für die Kontrolle von physiologischen Prozessen bestimmt ist, gehört zur Klasse IIa, es sei denn, sie ist für die Kontrolle von vitalen physiologischen Parametern bestimmt, wobei die Art der Änderung dieser Parameter zu einer unmittelbaren Gefahr für den Patienten führen könnte; in diesem Fall wird sie der Klasse IIb zugeordnet.

Sämtliche andere Software wird der Klasse I zugeordnet.“

Video 1: Das Video erläutert die Konsequenzen der Regel 11 insbesondere für kleine Hersteller. (Anmerkung: Im Video wird noch von „Regel 10a“ gesprochen. Das entspricht der Nummerierung aus der Entwurfsphase der MDR.)

Die Regel 11 wirft erneut die Frage auf, was „physiologische Prozesse“ sind. Eine Definition des Begriffs liefert die MDR nicht.

2. Welche Standalone-Software fällt gemäß Regel 11 NICHT in Klasse I?

a) Definition Medizinprodukt

Laut MDR sind Medizinprodukte weiterhin Instrumente, Apparate, Software usw., die vom Hersteller zu einem der folgenden Zwecke vorgesehen sind:

• Diagnose, Verhütung, Überwachung, Vorhersage, Behandlung oder Linderung von Krankheiten,
• Diagnose, Überwachung, Behandlung, Linderung oder Kompensation einer Verletzung oder Behinderung,
• Untersuchung, Ersetzung oder Änderung des anatomischen Aufbaus oder eines physiologischen oder pathologischen Prozesses oder Zustands,
• Bereitstellung von Informationen mittels in-vitro-Untersuchungen von Proben vom menschlichen Körper einschließlich Organ-, Blut- und Gewebespenden […]

b) Die Folgen

Gleicht man diese Liste mit dem ab, was die Regel 11 adressiert, wird eines klar:

(Fast) jede Software, die der Diagnose, der Überwachung, der Vorhersage oder der Behandlung dient, stellt auch Informationen bereit, die der Entscheidungsfindung mit einer diagnostischen oder therapeutischen Zielsetzung dienen. Genau solche Software klassifiziert die Regel 11 als IIa oder höher.

Auch der EK-Med sieht die Gefahr einer Höherstufung: Konkret schreibt er:

„Diese Regelung wird – insbesondere für Apps – tendenziell eine Höherklassifizierung zur Folge haben und infolgedessen u. a. vermehrt die Involvierung Benannter Stellen sowie die Durchführung klinischer Prüfungen erfordern.“

EK-Med 1934/16

Die ehemalige Regel 10a ist nun fast wortwörtlich in Regel 11 übernommen worden.

c) Die Ausnahmen

Höchstens folgende Zweckbestimmungen könnten eine Klasse I rechtfertigen:

• Prävention: z. B. eine App für den Kardiosport, die Trainingsempfehlungen gibt
• Monitoring, wenn nicht bei vitaler Bedrohung bzw. zur Diagnose. Eine Software überwacht beispielsweise einen physiologischen Parameter, auf dessen Basis man keine Diagnose stellt und nur Handlungen indiziert, die keine Therapie darstellen. Ein etwas an den Haaren herbeigezogenes Beispiel wäre eine Software für den Flüssigkeitshaushalt mit Trinkempfehlungen.
• Prognosen, die nicht der Entscheidungsfindung dienen
• Linderung: ggf. Biofeedbacksysteme, die nicht als Therapie gelten, da diese „nur“ Symptome lindern

Einen weiteren Versuch eines Auswegs beschreibt dieser Beitrag, der die Trennung von Daten und Informationen diskutiert. Demnach würde ein PACS keine Informationen liefern!?

3. Was sind die Folgen der Regel 11?

Die Software wird in der Regel höher klassifiziert. Hier einige Beispiele:

Produkt	Klasse MDD	Klasse MDR
App zur Auswahl und zur Dosisberechnung von Cytostatika	I	III
Standalone-Software-Anwendung für die AMTS	I	III (je nach Medikament)
Software zum Vorschlagen von Diagnosen basierend auf Laborwerten	I	IIb oder höher (bis III)
PDMS	I oder IIa	IIb oder III
App zur Diagnose von Schlafapnoe	I	IIa (oder höher)
Software für die Therapie- bzw. Bestrahlungsplanung	IIb	IIb oder III, je nach Argumentation

a) Folge 1: Kosten und Aufwände für unkritische Anwendungen explodieren

Sobald Software nicht mehr in Klasse I fällt, müssen die Hersteller

1. Benannte Stellen einbeziehen und
2. i. d. R. ein Qualitätsmanagementsystem aufbauen und zertifizieren lassen.

Damit vervielfachen sich die Aufwände und die Kosten. Das trifft insbesondere kleinere Hersteller wie App-Entwickler, Start-ups und universitäre Ausgründungen massiv.

b) Folge 2: Die Klassifizierung spiegelt nicht immer das Risiko wider

Während in der Vergangenheit sogar eine hochkritische Software zur Berechnung von Zytostatika in Klasse I fiel, haben wir jetzt das Gegenteil: Nun kann es dank Regel 11 passieren, dass sogar unkritische Anwendungen der Klasse III zugeordnet werden müssen.

Das liegt daran, dass die Klassifizierung entweder nur den Schweregrad (z. B. „Der Tod könnte verursacht werden“) oder nur die Dauer berücksichtigt („ist irreversibel“).

• Muss jedes Produkt der Klasse III zugeordnet werden, wenn ein Produktfehler im noch so unwahrscheinlichen Fall zum Tod führen kann?
• Führt jede noch so kleine irreversible Schädigung zur gleichen Klassifizierung?

Die Klassifizierung sollte das Risiko widerspiegeln. Risiken sind Kombinationen aus Schweregraden und Wahrscheinlichkeiten. Genau das berücksichtigt die Regel 11 nicht.

Software zum Berechnen von Medikamentendosen, zur Auswahl von Medikamenten, zum Planen von Therapien wie Bestrahlungen und Operationen fällt wahrscheinlich in die Klasse III!

c) Fazit: Regel 11 wird zur Innovationsbremse

Die Sicherheit von Patienten hat höchste Priorität. Die Gesundheit von Patienten ebenfalls. Die Regel 11 wird die Entwicklung von Software-Produkten in einem Maß erschweren, dass kleine Hersteller die regulatorischen Hürden kaum noch überwinden können.

Produkte, die nicht auf den Markt kommen, gefährden die Sicherheit nicht. Aber Produkte, die nicht auf den Markt kommen (können), fehlen, um Krankheiten und Verletzungen zu diagnostizieren, zu lindern und zu behandeln.

Man kann Menschen nicht nur mit Medizinprodukten töten, sondern auch dadurch, dass Medizinprodukte fehlen. Die Autoren der Regel 11 werden sich daran messen lassen müssen.

4. MDCG zur Regel 11

a) Anwendbarkeit der Regel 11

Die MDCG definiert den Begriff „Medical Device Software“. Sie schreibt zusätzlich:

Medical device software is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a „medical device“ in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device.

Quelle: MDCG 2019-11

Durch den Zusatz „regardless of whether the software is independent or is driving or influencing the use of a device“ könnte der Eindruck entstehen, dass die Regel 11 sowohl für die Standalone-Software als auch für die Steuerungssoftware gelten soll.

Das ist jedoch nicht der Fall: Aus der Tatsache, dass beide Typen von Software als Medizinprodukt klassifiziert werden, darf nicht geschlossen werden, dass für beide die Regel 11 anwendbar ist. Vielmehr sind zwei Fälle bei der Klassifizierung nach MDR (nicht Klassifizierung als Medizinprodukt) zu unterscheiden:

1. Die Software „drives a device or influences the use of a device“: Die Klassifizierung der Software entspricht der des „beeinflussten Medizinprodukts“, unabhängig von der Regel 11.
2. „Independent of any other device“ ist: Die Klassifizierung der Software geschieht durch Anwender der Regel 11.

Die Klassifizierung nach MDR erfolgt daher nicht „regardless of“, sondern „depends of whether the software is independent or is driving or influencing the use of a device.“

b) Konsequenzen für die Klassifizierung

Aus dem MDCG Dokument folgt:

Der Gedanke dahinter ist wahrscheinlich, dass eine Software in einer Hardware, die nichts mit der Steuerung der Hardware und damit dem Gerät zu tun hat, wie eine Standalone-Software zu betrachten ist, die „zufällig“ in einer Hardware läuft, deshalb aber nicht als embedded Software reguliert werden sollte. Ob das dem Geist des Gesetzes entspricht oder diesem gar widerspricht, werden möglicherweise Richter entscheiden müssen.

Eine „Kleine Anfrage“ an die Bundesregierung, ob man die verschärften Anforderungen der MDR insbesondere an digitale Medizinprodukte abschwächen oder verschieben könnte, wurde abschlägig beantwortet (Antwort der Bundesregierung).

Überlegungen der MDCG

Die MDCG betont, dass immer die höchste Regel greift. Das gibt allerdings bereits die Regel 3.5 vor. Interessanter ist das Beispiel, das die MDCG ausführt:

Wenn ein Software einen Infrarot-Scanner (Klasse IIa) ansteuert, die zudem die Bilder dieses Scanners auf ein Melanom hin untersucht, greifen zwei Regeln:

1. Regel 3: Die Software kontrolliert und beeinflusst den Scanner. Demnach fiele sie in Klasse IIa.
2. Regel 11: Weil es um die Krebserkennung geht, geht die MDCG von einer Einteilung in die Klasse III aus.

Weil die höhere Regel greift, wäre diese Software in die Klasse III einzuteilen!

Die MDCG läutet indirekt auch das (befürchtete) Aus für alle Klasse-I-Software ein. Sie schreibt mit Bezug auf den Satz „Software, die dazu bestimmt ist, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden“ das Folgende:

„Therefore it will be necessary to consider this sub-rule for all MDSW.“

Entwurf des MDCG-Dokuments zu „Medical Device Software“ (MDCG)

Damit fiele alle Software in die Klassen IIa, IIb oder III.

Interessanterweise ergänzt die MDCG in der Regel 11 das Wort „serious“:

„death or an irreversible serious deterioration of a person’s state of health, in which case it is in class III;“

Entwurf des MDCG-Dokuments zu „Medical Device Software“ (MDCG)

Diese Ergänzung ist zu begrüßen. Gleichzeitig stellt sich die Frage, weshalb im Gesetz eine Korrektur möglich ist, man aber bei der Klassifizierung selbst nicht nachbessert und auf das IMDRF-Guidance-Dokument (s. o.) verweist.

c) Interpretation der Regel 11 durch MDCG 2019-11

Brüssel hat erkannt, dass die Regel 11 nicht zu den besonders gelungenen Teilen der MDR zählt. Die Tatsache, dass deren Klassifizierung nur den Schweregrad berücksichtigt, aber nicht das Risiko, führt dazu, dass zu viele Software-Anwendungen in die Klasse III eingeteilt werden müssen. Schließlich kann im ungünstigsten Fall immer etwas Schlimmes passieren. Damit ist der Gedanke einer risikobasierten Klassifizierung ad absurdum geführt.

Im MDCG-Dokument ist auf Seite 26 eine Tabelle ergänzt, die sich auf eine Klassifizierung des IMDRF bezieht. Dadurch gelingt es unter Umständen, Software niedriger zu klassifizieren.

			Significance of Information
			Treat Provide therapy to human body Diagnose Detect Screen Prevent Mitigate Lead to an immediate or near-term action	Aid in treatment Provide enhanced support To safe and effective use of medicinal products Aid in Diagnosis Help predict risk of a disease or condition Aid to making a definitive diagnosis Triage / Identify early signs of a disease or condition	Inform of options for treatment Inform of options for diagnosis Inform of options for prevention Aggregate relevant clinical information Will not trigger immediate or near-term action
Disease type / Patient condition	Intervention type		Treat or diagnose	Drive clinical mgt.	Inform clinical mgt.
Life threatening Fragile in consideration to the disease in question	Requires major therapeutic interventions Sometimes time critical Vital to avoid death, serious deterioration of health, mitigating public health situations or conditions	Critical	IMDRF IV MDR III	IMDRF III MDR IIb	IMDRF II MDR IIa
Moderate in progression Often curable Non-fragile in consideration to the disease in question	Does not require major therapeutic interventions Not expected to be time critical Vital to avoid unnecessary interventions	Serious	IMDRF III MDR IIb	IMDRF II MDR IIa	IMDRF I MDR IIa
Slow with predictable progression of disease state Minor chronic illnesses or states May not be curable Can be managed effectively		Non-serious	IMDRF II MDR IIa	IMDRF I MDR IIa	IMDRF I MDR IIa

Dieser neue Ansatz bringt Vorteile, löst aber nicht alle Probleme.

Vorteile

• Diese Klassifizierung erfolgt wieder risikobasiert und nicht (einzig) anhand der Schweregrade möglicher Schäden. Die Einbeziehung der Gesundheitszustände und der möglichen Interventionen hilft hierbei.
• Die Anzahl der Produkte, die sinnwidrig in die Klassen IIb oder III eingestuft werden müssten, wird dadurch deutlich sinken. Das ist ebenso gut wie richtig.
• Die Klassifizierung folgt einer Logik. Die Herleitung ist nachvollziehbar.

(Neue) Herausforderungen

Ungeeignete Fehlerbehebung

Die Regel 11 ist schlicht ungeeignet. Es ist nicht nachvollziehbar, dass man diesen Fehler nicht behebt, sondern über eine „Leitlinie“ die Regel wieder teilweise aushebelt. Fehler in Gesetzen müssen in Gesetzen behoben werden, nicht in Erläuterungen. Uns Herstellern würde man solch einen Murks nicht durchgehen lassen.

Verwirrende Beispiele

Die Beispiele werfen neue Fragen auf: Wann dient eine Software dem Zweck „diagnosis“, wann „aid in diagnosis“, wann „aid to making a definitive diagnosis“ und wann dem Zweck „inform of options for diagnosis“?

Welche Software gibt schon eine direkte Diagnose im Sinne eines ICD-Codes aus? (Fast) alle Software-Anwendungen im Kontext von Diagnosen liefern Informationen, die für eine Diagnose mehr oder weniger entscheidend sind. Weshalb hat man nicht einmal die Definitionen des Begriffs „direkte Diagnose“ in der MDR übernommen? Diese findet sich im Anhang VIII 3.7.

Ein neues Problem wird geschaffen

Die erste Revision der MDCG 2019-11 weitet die Anwendbarkeit der Regel 11 a) auf die Prognose auf. Sie schreibt:

a device intended to prevent the risk of illnesses or pathologies by analysing physiological parameters […] can be considered as a device providing information which is used to take decisions with diagnosis purpose (potential detection of pathologies) and in this case is in class IIa.

Die MDR weiß sehr wohl zu unterscheiden zwischen „diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease“. Es ist daher nur schwer nachvollziehbar, dass die Prognose durch die MDCG zur Diagnose umgedeutet wird.

Ein Hauptproblem bleibt ungelöst

Die IMDRF hat bewusst eine Klasse I für die ganz unkritischen Produkte eingeführt. Diesen unkritischen Produkten weist die MDR aber die Klasse IIa zu. Damit bleibt ein großes Problem bestehen: Es gibt kaum noch Software, die gemäß MDR in die Klasse I fällt. Selbst bei unkritischen Produkten ist die Konformitätsbewertung ohne Benannte Stelle nicht mehr möglich, und ein zertifiziertes Qualitätsmanagementsystem wird notwendig.

Während die FDA dereguliert, schwächen wir Europäer unsere Wettbewerbsfähigkeit, indem wir kleine, innovative Firmen, die unkritische Produkte entwickeln, mit Auflagen ersticken. Offensichtlich hat Brüssel die Hausaufgabe nicht erledigt, die sie den Herstellern auferlegt: im Risikomanagement die Risiken und den Nutzen abzuwägen. Wie viele Menschen retten wir durch die neuen Regeln? Wie viele Menschenleben gefährden wir dadurch, dass die neuen Regeln innovative Produkte verhindern?

d) Völlige Verwirrung durch MDCG 2021-24

Übersicht

Mit der Leitlinie MDCG 2021-24 unternimmt Brüssel einen weiteren Versuch, um Klarheit bei der Klassifizierung zu schaffen. Das gelingt im Fall von Software nicht vollständig:

• Die neue Leitlinie löst die Widersprüche zwischen Regel 11 und MDCG 2019-11 nicht auf. Sie adressiert sie nicht einmal.
• Sie nennt Beispiele, die nicht weiterhelfen.
• Manche Beispiele scheinen sogar im Widerspruch zu MDCG 2019-11 zu stehen.
• Die eigentliche Problematik geht die neue Leitlinie nicht an, nämlich die, dass die Regel 11 schweregradbasiert und nicht risikobasiert ist. Wie sollen die Hersteller damit umgehen, dass im schlimmsten und unwahrscheinlichen Fall die Patienten immer „irreversible deterioration“ haben? Wie sollen Hersteller gegen eine offensichtlich unangemessene Einteilung in Klasse III argumentieren?

Die folgende Tabelle kommentiert die Beispiele der MDCG.

Details

Class	Rule 11	Examples	Kommentar
IIa	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:	MDSW intended to rank therapeutic suggestions for a health care professional based on patient history, imaging test results, and patient characteristics, for example, MDSW that lists and ranks all available chemotherapy options for BRCA-positive individuals.Cognitive therapy MDSW where a specialist determines the necessary cognitive therapy based on the outcome provided by the MDSW.	Die Beispiele sind in Übereinstimmung mit MDCG 2019-11. Weshalb aber eine BRCA-positive Patientin, also eine Person, die mit hoher Wahrscheinlichkeit an einem hochaggressiven Krebs leidet, beim Vorschlag einer falschen Chemotherapie keine „serious deterioration“ erleiden soll und damit zumindest die Software in die Klasse IIb befördert, bleibt unklar.
III	— death or an irreversible deterioration of a person’s state of health, in which case it is in class III; or	MDSW intended to perform diagnosis by means of image analysis for making treatment decisions in patients with acute stroke.	Dieses Beispiel ist als eines der wenigen eindeutig und nachvollziehbar, zumindest wenn falsche „treatment decisions“ aufgrund der Software vulnerable Patienten töten oder schwer schädigen würden.
IIb	— a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as class IIb.	A mobile app intended to analyse a user’s heartbeat, detect abnormalities and inform a physician accordingly. MDSW intended for diagnosing depression based on a score resulting from inputted data on patient symptoms (e.g. anxiety, sleep patterns, stress etc.).	Es ist unklar, ob es sich um ein oder zwei Beispiele handelt. Die Formatierung deutet darauf hin, das fehlende Aufzählungszeichen spricht dagegen. Falls es zwei Beispiele sind, fehlen nachvollziehbare Gründe. Entweder man hält sich an die MDCG 2019-11; dann wäre der erste Fall zu klassifizieren in „Aid in diagnosis“ und „often curable“ und somit die Software in Klasse IIa einzuordnen. Oder man zieht die Regel 11 heran; dann wäre die Software ggf. in Klasse III einzuordnen, weil mit einer beliebig geringen Wahrscheinlichkeit immer ein Tod möglich ist. Dass die Regel 11 eine schweregradbasierte Klassifizierung ist und keine risikobasierte, ist genau die Kritik. Hier hilft MDCG 2021-24 leider nicht weiter. Vergleichbare Überlegungen gelten auch im zweiten Fall. Hier wäre der Suizid der schlimmste Fall.
IIa	Software intended to monitor physiological processes is classified as class IIa,	MDSW intended to monitor physiological processes that are not considered to be vital. Devices intended to be used to obtain readings of vital physiological signals in routine check-ups including monitoring at home.	Das ist kein Beispiel, sondern eine Rephrasierung des Textes. Jetzt wechseln die Autoren zu Geräten(?), sodass die Rolle der Software unklar wird. Software, die nur abspeichert, wird durch die MDCG 2019-11 nicht als Medizinprodukt qualifiziert.
IIb	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.	Medical devices including MDSW intended to be used for continuous surveillance of vital physiological processes in anaesthesia, intensive care or emergency care.	Diese Beispiele sind naheliegend. Die Bewertung stimmt mit MDCG 2019-11 überein.
I	All other software is classified as class I.	MDSW app intended to support conception by calculating the user’s fertility status based on a validated statistical algorithm. The user inputs health data including basal body temperature (BBT) and menstruation days to track and predict ovulation. The fertility status of the current day is reflected by one of three indicator lights: red (fertile), green (infertile) or yellow (learning phase/cycle fluctuation).	Während die Regel 15 „alle Produkte, die zur Empfängnisverhütung […] eingesetzt werden sollen“ der Klasse IIb zuordnet, erlaubt das MDCG-Dokument für die Empfängnisförderung zumindest bei Software die Klasse I.

5. Geplante neue Regel 11

a. Kontext der Überarbeitung

Die EU-Kommission hat im Dezember 2025 die Ergebnisse ihrer Evaluierung der MDR und IVDR veröffentlicht zusammen mit  einem Vorschlag zur Überarbeitung der MDR und IVDR. Dieser Vorschlag wird oft als MDR 2.0 bzw. IVDR 2.0 referenziert.

Die Kommission hat erkannt, dass die Regulierung in der jetzigen Form der Innovation abträglich sein könnte. Daher hat sie im Rahmen des „Topic 1: Simplification and Proportionality“ beschlossen, die Klassifizierungsregeln der MDR im Anhang VIII zu überarbeiten:

Some classification rules are adapted resulting in lower risk classes for certain devices, such as reusable surgical instruments, accessories to active implantable devices and software.

Weitere Erwägungsgründe werden nicht genannt.

b. Geplante Formulierung der Regel 11

Die EU plant, die Regel 11 wie folgt vollkommen neu zu formulieren:

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.’;

c. Ansatz

Offensichtlich orientiert sich die EU-Kommission an dem IMDRF-Dokument zur Klassifizierung von Software as Medical Device (SaMD), obwohl der Scope der Regel 11 gerade nicht nur SaMD ist.

Das IMDRF verfolgt einen risikobasierten Ansatz dadurch, dass nicht nur die Schweregrade von Schäden (wie bei der bisherigen Regel 11), sondern auch deren Wahrscheinlichkeiten zumindest eine Rolle spielen können. Denn diese Wahrscheinlichkeit fließt sowohl über den „State of healthcare“ als auch die „Direktheit“ ein, mit der die Software im Rahmen ihrer Zweckbestimmung verwendet und als „Significance of Information“ bezeichnet wird wird (s. Abb. 1).

d. Interpretation / Erläuterung der neuen Regel 11 (ein Versuch)

Die Regel 11 enthält Fallunterscheidungen, die sich wie folgt visualisieren lassen:

Es fällt auf, dass der Fall, dass die Software keinen Output mit einem „clinical benefit“ generiert, nicht abgedeckt wird.

Der gegenteilige Fall legt (wie das IMDRF) die Klasse abhängig von zwei Dimensionen fest.

1. Zweck
2. Kritikalität der Patienten / Schwergrad möglicher Schäden

Zweck → Kritikalität und Schweregrad ↓	Treat or diagnose (wird aber nicht genannt)	Drive clinical management	Inform clinical management
Critical situation with risk of causing death or an irreversible deterioration	III (1)	III (1), IIb (2)	III (1), IIa (3)
Serious situation with risk of causing serious deterioration	IIb (2)	IIb (2), IIa (3)	IIb (2), IIa (3)
Non-serious situation	IIa (3)	IIa (3)	IIa (3)

Allerdings wählt die EU-Kommission im Vergleich zum IMDRF höhere Klassen. Das IMDRF erlaubt die niedrigste Klasse I.

Zweck → Kritikalität und Schweregrad ↓	Treat or diagnose	Drive clinical management	Inform clinical management
Critical situation with risk of causing death or an irreversible deterioration	IV	III	II
Serious situation with risk of causing serious deterioration	III	II	I
Non-serious situation	II	I	I

e. Bewertung

Lob

• Die EU-Kommission hat verstanden, dass die derzeitige Regel 11 überarbeitungswürdig ist.
• Die vorgeschlagene Klassifizierung ist stärker risikobasiert als die bisherige.
• Die Klasse I hat man nicht abgeschafft, was hoffentlich auch die Behörden ermutigt, wieder zu einer rechtskonformen Interpretation zurückzukehren.
• Das Schlupfloch wurde für Software geschlossen, die direkt behandelt (z.B. für Psychotherapie), aber „keine Informationen [liefert], die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden“. Denn die fiel bisher in Klasse I, unabhängig vom Risiko, die von dieser Software ausgeht.

Kritik

Mangelnde formale Präzision, Korrektheit und Vollständigkeit

• Es ist immer schwierig, wenn Regeln nicht alle Fälle abdecken. Was ist beispielsweise mit Software, ohne klinischen Nutzen? Was passiert beispielsweise, wenn die Software keinen klinischen Benefit hat, aber trotzdem die Patienten umbringen kann? Beispielsweise kann eine Software, die erkennen soll, ob eine Wartung notwendig ist, im Fehlerfall zum Ausfall des Medizinprodukts führen.
• Der Vorschlag vermischt die Vulnerabilität der Patienten (z.B. „critical situation“) mit dem möglichen Schwergrad von Schäden („death or irreversible deterioration“). Streng genommen gibt es mit der Dimension „Zweck“ einen dreidimensionalen Klassifizierungsraum, den die Regeln nicht vollständig abbilden.

Unzureichende Klarheit und Verständlichkeit

• Es wird zu weiteren Diskussionen kommen, ob der Output einer Software, die eine Dialyse-Pumpe ansteuert, einen klinischen Benefit hat. Es ist unklar, wie direkt dieser Output einen klinischen Nutzen haben muss. Auch ein PACS hat keinen Anspruch auf einen klinischen Nutzen.
• Es ist unklar, was mit „intended for a disease“ gemeint ist. Die Behandlung dieser Krankheit? Aber weshalb hat man es dann vorher aufgenommen?
• Es ist unklar, ob mit „intended for a disease“ auch die Diagnose und Vorhersage gemeint sind. Zumindest letzteres wäre im Widerspruch zum IMDRF. Damit wäre die erhoffte Harmonisierung wieder dahin.

Mangelnde innere Konsistenz und mangelnde Harmonisierung mit dem IMDRF

• Diesen Widerspruch gibt es auch für die Klassifizierung in IIa für alle nicht kritischen Situationen (siehe Farben in Tabellen oben). Hier unterscheidet das IMDRF explizit den Zweck und erlaubt Klasse I.
• Dadurch, dass die Kommission nicht mehr nur die Kritikalität der Situation als Klassifizierungskriterium wählt, sondern auch den Schweregrad möglicher Schäden, macht sie den ganzen Versuch einer risikobasierten Klassifizierung zunichte. Man muss nur ausreichend unwahrscheinliche Fälle betrachten, schon ist eine „serious deterioration“ nicht mehr auszuschließen. Das Problem ist das Wort „or“ insbesondere beim ersten Spiegelstrich.
• Die Kriterien wie „Critical“ sind nicht definiert. Hier müsste man auf die IMDRF ausweichen oder auf MDCG-Dokumente warten. Ein Gesetz sollte aber alleinstehend vollständig sein.
• Weshalb werden Krankheiten und Verletzungen unterschiedlich behandelt? Heißt das, dass eine Software für kritisch verletzte Patienten anders klassifiziert wird als eine Software für kritisch kranke Patienten? Oder sind mit „Condition“ Verletzungen gemeint? Es wäre gut gewesen, bei den Begriffen zu bleiben, die die Definition des Begriffs „Medizinprodukt“ verwendet, wie „Injury“, „Disability“.

f. Lösungsansatz

Eine relativ elegante Lösung für die meisten Probleme könnte darin bestehen, an den Anfang jedes der drei Spiegelstriche den Text „treat or diagnose“ einzufügen. Das würde zu einer Klassifizierung führen, die eher das Attribut „risikobasiert“ verdient und bei der sich keine Spiegelstriche überschreiben.

Zweck → Kritikalität und Schweregrad ↓	Treat or diagnose	Drive clinical management	Inform clinical management
Critical situation with risk of causing death or an irreversible deterioration	III (1)	IIb (2)	IIa (3)
Serious situation with risk of causing serious deterioration	IIb (2)	IIa (3)	IIa (3)
Non-serious situation	IIa (3)	I	I

Auch wenn diese Änderung nur als klein erscheint, sind die Auswirkungen doch relevant. „Words matter“.

Danke an Robert Dick-Hambeck für diese Anregung!

g. Fazit

Es ist bedauerlich, dass es einmal mehr nicht gelungen ist, Klassifizierungsregeln für softwarebasierte Produkte festzulegen, welche die wichtigsten Qualitätseigenschaften aufweisen:

• Verständlichkeit
• Vollständigkeit
• Innere Konsistenz
• Internationale Abgestimmtheit
• Risikobasiertheit

Und das, obwohl das IMDRF eine gute Vorlage geliefert hat. Es wirkt wie ein Fußballspieler, der das Kunststück schafft, 2 Meter vor dem leeren Tor den Ball an den Pfosten zu setzen.

Doch dieser Artikel bietet zumindest einen Lösungsansatz an.

6. Zusammenfassung und Fazit

Alle Versuche der EU-Kommission und der MDCG, softwarebasierte Medizinprodukte anhand verständlicher, nachvollziehbarer, vollständiger, risikobasierter und international abgestimmter Regeln zu klassifizieren, sind nicht von Erfolg gekrönt.

Das führt zu Unsicherheit, Diskussionen, (meist) Überregulierung, Ungerechtigkeit, unnötigem Aufwand sowie innovationsfeindlichen Rahmenbedingungen in Europa und schadet dem Wirtschaftsstandort und den Patienten.

---

Änderungshistorie

• 2026-01-19: Kapitel 5.f) mit dem Lösungsansatz ergänzt
• 2026-01-16:
  • Key Take-aways am Artikelanfang eingefügt
  • Kapitel 5 zur geplanten Überarbeitung der Regel 11 eingefügt
  • Zusammenfassung und Fazit neu geschrieben und neu nummeriert
• 2025-06-25: Kapitel 4.c) überarbeitet, um die Revision der MDCG 2019-11 zu berücksichtigen
• 2023-03-04: Link auf Fachartikel zu Klasse-I-Software ergänzt
• 2021-10-11: Kapitel 4.d) mit Diskussion der MDCG 2021-24 ergänzt

Ähnliche Beiträge