Klasse-I-Software

Eine Orientierungshilfe, basierend auf Erfahrungen des Johner Instituts sowie von Oliver Hilgers und Stefan Bolleininger

Die Diskussionen um Klasse-I-Software reißen nicht ab. Dieser Artikel gibt eine Hilfestellung bei der Klassifizierung von medizinischer Software nach den Regeln der MDR. 

1. Hintergrund

a) Relevanz der Fragestellung

Ob medizinische Software als Klasse-I-Software zählt, ist sowohl für Hersteller als auch für Behörden und Benannte Stellen bedeutend:

Für Klasse-I-Software sind die Behörden „zuständig“, für Software der höheren Risikoklassen die Benannten Stellen. Letztere sind trotz erneut verlängerter Übergangsfristen völlig überlastet. Damit gelingt es den Herstellern von Medizinprodukten kaum noch, innovative medizinische Software auch zeitnah in den Markt zu bringen. Sie fehlt bei der Patientenversorgung.

Wenn Software von den Behörden unnötig hochgestuft wird, „verstopfen“ unkritische Produkte zusätzlich den Engpass bei den Benannten Stellen. Zudem leidet die Wettbewerbsfähigkeit der Hersteller.

Diese Überregulierung beobachten die Autoren in letzter Zeit verstärkt. Wird Software dagegen ungerechtfertigt zu niedrig klassifiziert, wird diese nicht, wie vom Gesetzgeber gewünscht, von den Benannten Stellen „überwacht“. 

b) Ziel und Grenzen dieses Artikels

Dieser Artikel soll so zu mehr Klarheit beitragen, um unnötige und zeitraubende Diskussionen sowie falsche Klassifizierungen zu vermeiden. Er hat nicht das Ziel, bestehende Regeln aufzuweichen. Vielmehr geht es darum, die im Abschnitt 4.a) beschriebenen Fehler, Lücken und Inkonsistenzen in den gesetzlichen Vorgaben im Sinne des Gesetzgebers ausgleichen.

2. Rechtlicher Rahmen für Klasse-I-Software

a) MDR

Die gesetzliche Grundlage für die Klassifizierung von Software bildet ausschließlich der Anhang VIII der MDR, insbesondere dessen Regel 11.

b) MDCG-Leitlinien

Die MDCG hat Leitlinien zur Klassifizierung von Produkten veröffentlicht:

• MDCG 2019-11 zur Klassifizierung von Software
• MDCG 2021-24 zur Klassifizierung von Medizinprodukten

Diese Leitlinien sind aber nicht rechtlich bindend. Sie erlauben den Wirtschaftsakteuren die Flexibilität, sie zu nutzen oder auch nicht zu nutzen:

Having regard to the status of guidance documents, economic operators and notified bodies should be allowed flexibility as to how to demonstrate compliance with legal requirements.

MDCG 2022-14, Abschnitt 11

Allerdings kann eine rechtliche Relevanz dann entstehen, wenn eine Leitlinie in einem Gerichtsurteil herangezogen wird. Das war beispielsweise bei einem Gerichtsurteil des Europäischen Gerichtshofs unter Bezugnahme der MEDDEV 2.1/6 geschehen.

c) IMDRF

Das MDCG-Dokument 2019-11 referenziert wiederum ein Dokument der IMDRF zur Qualifizierung und Klassifizierung von Software. Damit wird deren Klassifizierungsschema indirekt bei Entscheidungen über Klasse-I-Software relevant.

3. Klassifizierung von Klasse-I-Software

a) Übersicht

Die folgende Übersicht fasst die gesetzlichen Vorgaben der Regel 11 des Anhangs VIII der MDR in einem Entscheidungsbaum zusammen. Es gibt demnach durchaus Software, die in Klasse I fällt. 

In den folgenden Abschnitten werden wir jeden Schritt (im Diagramm durch eine in Klammern gesetzte Ziffer gekennzeichnet) erläutern.

Abb. 1: Entscheidungsdiagramm zur Klassifizierung von Software. Im grau hinterlegten Kasten geht es um die Unterscheidung von Software, die keine Informationen für diagnostische und therapeutische Entscheidungen liefert.

b) Fallunterscheidung (1)

Diese Fallunterscheidung steht wortwörtlich in der MDR. Dort heißt es

„Software, die dazu bestimmt ist, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden, gehört zur Klasse IIa [oder höher].“

Üblicherweise ist es die Aufgabe von Ärztinnen und Ärzten, eine Diagnose zu stellen und über Therapien zu entscheiden. So definiert der Duden den Begriff Diagnose:

Eine gute Faustformel lautet damit: Eine Software fällt in die Klasse I, wenn sie nur durch Patienten genutzt werden soll und keine physiologischen Vorgänge überwacht.

Vorsicht

• Der Umkehrschluss gilt nicht: Wenn die Zweckbestimmung Ärztinnen und Ärzte als Nutzer vorsieht, folgt daraus nicht automatisch, dass die Software in eine höhere Klasse fällt.
• Die Faustformel gilt nicht, wenn originär ärztliche Aufgaben an Patienten übertragen werden. Beispielsweise würde eine Software nicht in die Klasse I fallen, die den Patienten anhand ihrer Symptome ein Medikament inklusive dessen Dosierung „verschreibt“.

Mehrere Sachverhalte können dazu führen, dass die oben genannte Bedingung („Entscheidungen für diagnostische und therapeutische Zwecke“) nicht erfüllt ist:

1. Die Informationen sind Grundlage für anderen Entscheidungen.
2. Die Informationen dienen nicht der Entscheidungsfindung.
3. Die Software liefert keine Informationen.

Auf diese Fallunterscheidungen gehen die folgenden Absätze ein.

c) Fallunterscheidung (2)

Die Fallunterscheidung (2) klärt, ob die Software überhaupt der Entscheidungsfindung dient – sprich, ob die gewonnenen Informationen für Entscheidungen herangezogen werden. Weil wir die Fallunterscheidung (1) mit Nein entschieden haben, wissen wir, dass es nicht um diagnostische oder therapeutische Entscheidungen geht.

Mit den Informationen könnten jedoch weitere Entscheidungen getroffen werden, beispielsweise zur Prävention, zur Vorhersage, zur Prognose und zur Empfängnisförderung. 

Die MDR unterscheidet diese Sachverhalte explizit und ergänzt (im Unterschied zum Vorgänger MDD) die Definition des Begriffs Medizinprodukt um die Zwecke „Vorhersage“ und „Prognose“. Damit ist klar, dass die EU-Verordnung die Begriffe Diagnose, Vorhersage und Prognose unterscheidet.

Genauso gilt es, Prävention und Therapie zu unterscheiden. DocCheck definiert den Begriff Therapie:

Die Prävention erfolgt zu einem Zeitpunkt, zu dem die Krankheit noch nicht eingetreten und somit deren Behandlung (noch) nicht möglich ist.

Beispiele

für Software, die nicht unter Software für „diagnostische oder therapeutische Zwecke“ fällt:

• Software, die Scores mit dem Zweck berechnet, die Wahrscheinlichkeit oder den Verlauf von Krankheiten vorherzusagen
• Software, deren Zweck darin besteht, Maßnahmen vorzuschlagen, um die Wahrscheinlichkeit einer künftigen Krankheit zu minimieren. Beispiele für solche Vorschläge sind sportliche Aktivitäten, Ernährung, Kontaktaufnahme mit medizinischem Fachpersonal und Teilnahme an einer Früherkennung – aber nicht die Früherkennung selbst.

Die MDR nutzt den Begriff „Prävention“, definiert ihn aber nicht. Sie verwendet ihn wahrscheinlich nur im Sinn der primären Prävention. Es gibt mehrere Formen der Prävention (s. BMG, Doccheck):

• Primäre Prävention: Abschalten von Gefahren
• Sekundäre Prävention: Früherkennung und Therapie von Erkrankungen
• Tertiäre Prävention: Begrenzung bzw. Ausgleich von Krankheitsfolgen

d) Fallunterscheidung (3)

Bei dieser Fallunterscheidung wissen wir, dass die Software keine Informationen liefert, die einer Entscheidungsfindung dienen. Das ist der Fall, wenn die Software entweder keine Informationen liefert oder Informationen, die einem anderen Zweck dienen als der Entscheidungsfindung.

Beispiele für Software, die nicht der Entscheidungsfindung dient, sind Anwendungen, die die Therapie durchführen. Die Entscheidung, dass und welche Therapie durchgeführt werden soll, ist bereits getroffen.

Beispiele

Software, die Patientinnen und Patienten beim Üben und Trainieren anleitet, unterstützt oder das Training durchführt:

• Software zum Augentraining
• Software zum Beckenbodentraining bei erektiler Dysfunktion
• Software zum Üben von Verhaltensänderungen, z. B. bei Suchtverhalten
• Software zum Anleiten von spezifischen Kraft- und Bewegungsübungen

Auch hier steht der Patient als Anwender im Fokus.

Das MDCG-Dokument 2019-11 nennt Software zur Prädiktion im Kontext der Empfängnisförderung explizit als ein Beispiel für eine Klasse-I-Software. 

Bei Standalone-Software, die gar keine Informationen liefert, stellt sich die Frage, ob sie überhaupt ein Medizinprodukt ist. Bei Software, die keine Informationen liefert und Teil eines Medizinprodukts ist, greifen wahrscheinlich andere Regeln als die Regel 11. Es handelt sich somit nicht um „Medical Device Software“ (MDSW).

e) Fallunterscheidung (4)

Die vierte Fallunterscheidung klärt, ob die Software dazu dient, physiologische Prozesse zu überwachen. Ist das der Fall, fällt die Software in die Klassen IIa oder IIb.

Falls die Software auch keine Informationen liefert, die diagnostischen oder therapeutischen Entscheidungen dient (Fallunterscheidung 1), weist die MDR dieser Software die Klasse I zu.

f) Fallunterscheidung (5)

Mit Blick auf den Erwägungsgrund 60 der MDR sollten Produkte, die in die Klasse I fallen, nur ein geringes „Verletzungsrisiko“ haben. Die Autoren der MDR meinen wahrscheinlich nicht nur Verletzungen, sondern auch andere Schädigungen der Gesundheit.  

Hinsichtlich des Risikos sollte immer eine nachvollziehbare Bewertung des Schadens und (!) der Auftrittswahrscheinlichkeit berücksichtigt werden, denn bei sehr geringen Wahrscheinlichkeiten sind schwere Schäden immer möglich. 

Zudem sollten im Rahmen der Klassifizierung noch keine Design- oder Schutzmaßnahmen innerhalb der Software berücksichtigt werden (reine Blackbox-Bewertung; siehe auch MDCG-2021-24, Note 1 zur Regel 9). Der Entscheidungsbaum des Amendment 1 der IEC 62304 hinsichtlich der initialen Sicherheitsklassifizierung liefert eine erste Orientierungshilfe für solch eine Bewertung.

4. Fazit und Zusammenfassung

a) Bewertung der Regeln

Die Diskussionen um die korrekte Klassifizierung von Software sind eine Folge der regulatorischen Vorgaben. So ist die Regel 11 in mehrfacher Hinsicht nicht ganz glücklich:

• Sie ist unvollständig: Sie scheint davon auszugehen, dass alle kritische Software entweder diagnostischen oder therapeutischen Entscheidungen dient oder der Überwachung physiologischer Prozesse. Das ist, wie oben dargestellt, nicht korrekt.
• Dadurch besteht die Möglichkeit, dass Software mit „potenziell hohem Verletzungsrisiko“, die zu keiner dieser beiden Kategorien zählt, in die Klasse I fällt, sprich, einer zu niedrigen Klassifizierung zugeordnet wird.
• Umgekehrt ist es nicht nachvollziehbar, dass alle Software, die diagnostischen und therapeutischen Entscheidungen dient, in Klasse IIa und höher eingestuft werden muss. Selbst das von der MDCG referenzierte IMDRF-Dokument nennt differenzierte Beispiele für solche Klasse-I-Software. Das heißt: In diesen Fällen wird die Software zu hoch klassifiziert.
• Die Regel 11 ist zudem inkonsistent mit anderen Regeln: Weshalb wirft sie Diagnose und Therapie in einen Topf, wohingegen die Regeln für die anderen Produkte beides explizit differenzieren? Software wird somit benachteiligt.

An anderer Stelle wurde bereits kritisiert, dass die Klassifizierung von Software für diagnostische und therapeutische Zwecke nur anhand der Schweregrade, aber nicht auf Basis der Risiken erfolgt. Diesen Missstand versucht das MDCG-Dokument 2019-11 zu mildern. 

Doch auch das MDCG-Dokument lässt Wünsche offen. Besonders hilfreich wäre es, wenn auch Klasse-I-Software besprochen würde. In der Abbildung im Kapitel 11 wird dagegen vordergründig der Eindruck erweckt, alle Software falle mindestens in Klasse IIa. Die Bezugnahme auf das dort referenzierte IMDRF-Dokument müsste noch konkretisiert und ergänzt werden.

Die Handreichungen zur Klassifizierung sollten, wie vom Gesetzgeber vorgesehen, nur auf der Zweckbestimmung der Software basieren und nicht auf deren Funktionalität (z. B. Speichern und Weiterleiten von Daten).

b) Folgen dieser Regeln

Die regulatorischen Dokumente führen zu vielen Diskussionen:

• Die Entscheidungen von Behörden und Benannten Stellen erscheinen nicht immer konsistent und nachvollziehbar, wie auch ein Blick ins DiGA-Verzeichnis zeigt.
• Durch eine Hochklassifizierung entstehen für manche Hersteller unüberwindbare Hindernisse; sie beeinträchtigt deren Wettbewerbsfähigkeit und Innovationskraft.
• Hochklassifizierte Produkte kommen spät oder gar nicht in den Markt und fehlen bei einer Patientenversorgung auf Stand der Technik.
• Eigentümlichkeiten in MDCG-Dokumenten dienen Richtern zur Grundlage für Entscheidungen und werden damit zementiert. 
• Die EU-Vorgaben sind nicht mehr harmonisiert mit den Regelungen in Ländern wie den USA oder Australien, die explizit die Patientensicherheit verfolgen, aber auch die Patientenversorgung mit innovativen Produkten und die Wettbewerbsfähigkeit der Märkte.

c) Wünsche und Empfehlungen

Ideal wäre es, wenn die Regel 11 grundlegend überarbeitet würde. So können die Lücken und Inkonsistenzen beseitigt und ein risikobasierter Ansatz erreicht werden. Falls dabei noch eine Harmonisierung mit anderen Rechtsbereichen gelänge, wären viele Wünsche erfüllt. 

Falls solche Änderungen nicht möglich sind, wäre es wünschenswert, wenn die MDCG das Dokument 2019-11 in einem transparenten Prozesse mit Peer-Review überarbeitet.

Es wäre im Sinne des Gesetzgebers angezeigt, dass die Behörden und Hersteller dem risikobasierten Gedanken der MDR folgen und nicht wahlweise versuchen, das Gesetz so zu interpretieren, dass es keine Klasse-I-Software mehr gibt. 

Dennoch sollte den Erwägungsgründen der MDR Rechnung getragen werden, dass Software, deren Schäden bei einer hinreichenden Wahrscheinlichkeit über niedrige Schweregrade hinausgehen, nicht in die Klasse I fallen sollte. 

Die Hoffnung der Autoren ist, mit diesem Artikel einen Beitrag dazu leisten zu können.

---

Disclaimer

Dieser Artikel spiegelt den aktuellen Stand der Erkenntnisse wider, der sich durch künftige Leitlinien und Gerichtsurteile ändern kann.

Aktualisierungen

• 2022-12-23: Die durchgezogene Linie nach dem Kasten „wahrscheinlich keine MDSW…“ durch eine gestrichelte ersetzt, weil im Fall, dass es keine MDSW ist, abgebrochen werden muss.