Die MDR enthält speziell für Software eine Klassifizierungsregel: Die 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 um 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

Die Rule 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. So wurde die Regel während der Entwurfsphase der MDR nummeriert)

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 der 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 dient. Genau solche Software klassifiziert die Regel 11 als IIa oder höher.

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

„Diese Regelung wird – insbesondere für Apps – tendenziell eine Höherklassifizierung zur Folge haben und infolge dessen 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 in Regel 11 fast wortwörtlich ü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. Z.B. eine Software überwacht 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:

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

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 Kosten für die Hersteller. 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-Produkte 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 stand-alone 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 Medizinproduktes 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“ 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älllig“ in einer Hardware läuft, deshalb aber nicht als embedded Software reguliert werden sollte. Ob das dem Geist des Gesetzes entspricht oder gar diesem 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 auch 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 zum 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-Dokument 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; or

Entwurf des MDCG-Dokument 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) Abschwächung der Regel 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 Schweregrade berücksichtigt, aber nicht das Risiko, führt dazu, dass zu viele Software-Anwendungen in der Klasse III eingeteilt werden müssten. Schließlich kann im ungünstigsten Fall immer etwas Schlimmes passieren. Damit ist der Gedanke einer risikobasierten Klassifizierung ad absurdum geführt.

Das MDCG Dokumment hat auf Seite 26 eine Tabelle ergänzt, die sich auf eine Klassifizierung des IMDRFs bezieht. Dadurch gelingt es unter Umständen, Software niedriger zu klassifizieren.

Dieser neue Ansatz bringt Vorteile, löst aber sich 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öglicher Interventionen hilft hierbei.
• Die Anzahl der Produkte, die sinnwidrig in den Klasse 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 ein „Erläuterungsdokument“ (MEDDEV?) die Regel wieder teilweise aushebelt. Fehler in Gesetzen müssen in Gesetzen behoben werden, nicht in Erläuterungen. Uns Herstellern würde man so 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 „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 die Diagnose mehr oder weniger entscheidend ist. Weshalb hat man nicht einmal die Definitionen des Begriffs „direkte Diagnose“ in der MDR übernommen? Diese findet sich im Anhang VIII 3.7.
• 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: Wieviele Menschen retten wir durch die neuen Regeln? Wie viele Menschenleben gefährden wir dadurch, dass die neuen Regeln innovative Produkte verhindern?

5. Fazit

Es bleibt also dabei: Der Gesetzgeber scheint Software hochklassifizieren und damit den umgekehrten wie die FDA gehen zu wollen, die die Digitalprodukte bewusst dereguliert.

Sind Sie unsicher, wie Sie Ihre Software klassifizieren müssen? Unser Micro-Consulting hilft mit kostenlosen Tipps.

Micro-Consulting anfragen

Kategorien: Regulatory Affairs

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.