Klasse-I-Software

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 Abschnitt 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, die den Patienten anhand ihrer Symptome ein Medikament inklusive dessen Dosierung „verschreibt“, nicht in die Klasse I fallen.

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 andere 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 zu ihrem 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

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.

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: Regel 11 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 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 dieses MDCG-Dokument lässt Wünsche offen.

• Die Leitlinie sollte den Misstand einer suboptimal formulierten Regel 11 nicht durch eigene Interpretationen beheben, die nicht durch die MDR gedeckt sind.
• Die Leitlinie sollte die Tendenz einer zu hohen Klassifizierung nicht weiter verstärken.
• 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

• 2025-07-21: Einführung aktualisiert und etwas gekürzt. In Abschnitt 3.b) auf die „Interpretation“ der aktualisierten Leitlinie MDCG 2019-11 hingeweisen. Wünsche an diese Leitlinie im Kapitel 4.a) ergänzt.
• 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.

Ähnliche Beiträge