Wie wird medizinische Software nach der MDR klassifiziert?

Zuerst qualifizieren, dann klassifizieren

Vor der Risikoklasse steht die Frage, ob die Anwendung überhaupt Medical Device Software (MDSW) ist. Maßgeblich ist die vom Hersteller festgelegte medizinische Zweckbestimmung nach Artikel 2 Nummer 1 und 12 der Verordnung (EU) 2017/745 (MDR). Software, die beispielsweise nur Termine, Abrechnung oder unveränderte Dokumente verwaltet, wird nicht allein durch den Einsatz im Krankenhaus zum Medizinprodukt. Verarbeitet oder interpretiert sie dagegen Daten für Diagnose, Prognose, Überwachung oder Therapie, kann sie unter die MDR fallen. MDCG 2019-11 Rev. 1 betont, dass Plattform, Cloud-Betrieb oder Einbettung in Hardware diese Grundentscheidung nicht verändern.

Regel 11 als Ausgangspunkt

Für eigenständige Medizinsoftware ist häufig Regel 11 in Anhang VIII einschlägig:

• Informationen für diagnostische oder therapeutische Entscheidungen führen grundsätzlich zu Klasse IIa.
• Könnte eine darauf beruhende Fehlentscheidung eine schwerwiegende Verschlechterung oder einen chirurgischen Eingriff verursachen, ist Klasse IIb vorgesehen.
• Könnte sie Tod oder irreversible Verschlechterung verursachen, kommt Klasse III in Betracht.
• Software zur Überwachung physiologischer Prozesse ist grundsätzlich Klasse IIa; bei vitalen Parametern und möglicher unmittelbarer Gefahr Klasse IIb.
• Andere Software, die keiner spezielleren Regel unterliegt, fällt nach Regel 11 in Klasse I.

Weitere Regeln dürfen nicht ausgeblendet werden. Regel 15 erfasst etwa Software zur Empfängnisverhütung, Regel 22 geschlossene Regelkreise, bei denen die diagnostische Funktion das Patientenmanagement wesentlich bestimmt. Software, die ein Hardwareprodukt steuert oder beeinflusst, wird nach Anhang VIII Nummer 3.3 grundsätzlich derselben Klasse zugeordnet wie dieses Produkt.

Die Begründung muss prüfbar sein

Die Klassifizierung sollte als dokumentierter Entscheidungsweg aufgebaut werden: genaue Zweckbestimmung, Nutzer und Patientengruppe, Eingangsdaten, ausgegebene Information, klinischer Kontext, vorhersehbare Fehlfunktion und mögliche Schadensschwere. Funktionen oder Module können getrennt zu bewerten sein, wenn nur ein Teil eine medizinische Zweckbestimmung erfüllt. Die höchste anwendbare Regel entscheidet; eine pauschale Aussage wie „Gesundheits-App = Klasse I“ reicht nicht.

Die Einordnung beeinflusst Konformitätsbewertung, Beteiligung einer Benannten Stelle und Umfang der Nachweise. Sie ist deshalb vor Architektur- und Marktzugangsentscheidungen festzulegen und bei Änderungen erneut zu prüfen. Dieser Überblick ist ein Arbeitsrahmen; die verbindliche Einstufung hängt vom konkreten Produkt und seiner dokumentierten Zweckbestimmung ab.