MDR: Software als Medizinprodukt – was jetzt gilt und wie Hersteller einen Vertriebsstopp vermeiden

Mit der neuen europäische Medizinprodukteverordnung, stehen Medizinprodukte auf dem Prüfstand. Besonders an Software stellt die MDR hohe Anforderungen. Wer diese nicht erfüllt, riskiert einen sofortigen Vertriebsstopp. Umso wichtiger ist es für betroffene Unternehmen, sich eingehend damit zu befassen, was die MDR für Software als Medizinprodukt bedeutet und welche Schritte jetzt notwendig sind. 

Für Alexander Bertel, Auditor und Prüfer, besteht eine der zentralen Änderungen der MDR für Software darin, dass manche Software zum ersten Mal überhaupt als Medizinprodukt gilt. In Zukunft schließt die Definition Produkte ein, die zur Vorhersage und Prognose von Krankheiten dienen.

Das heißt: Wenn eine App Daten sammelt, die Ärzten die Diagnose von Krankheiten erleichtern soll, ist sie bereits ein Medizinprodukt. Anders sieht es mit einer Fitness-App aus, die sich auf Trainingstipps konzentriert.

Wichtig: Ob es sich nach der MDR bei Software um ein Medizinprodukt handelt, entscheiden nicht die Funktionen. Den Ausschlag gibt die Zweckbestimmung. Hier empfiehlt sich ein Blick auf Artikel 2 MDR der europäischen Mdizinprodukteverordnung.

Aber auch für Software, die bisher schon als Medizinprodukt galt, ändern sich oftmals die Anforderungen. Ausschlaggebend dafür sind die neuen Klassifizierungsregeln, speziell die Regel 11.

Hier 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, 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.“

Damit fällt Medizinprodukte-Software, die bisher zur Klasse I gehörte, in Zukunft mit wenigen Ausnahmen mindestens in Klasse IIa. Oft rutscht sie gleich in Klasse III. Eine Folge davon ist, dass betroffene Unternehmen ein zertifiziertes Qualitätsmanagement brauchen –  mit allem, was dazugehört.

Hersteller von Medizinprodukte-Software stehen in Zusammenhang mit der MDR vor allem vor folgenden Herausforderungen:

• Zertifiziertes Qualitätsmanagement: Medizinprodukte ab Klasse IIa brauchen ein zertifiziertes Qualitätsmanagement. Ausschlaggebend dafür ist nicht die ISO-Norm 9001, sondern die ISO-Norm 13485. Da diese noch nicht in der angekündigten erneuerten Fassung vorliegt, gehen Unternehmen auf Nummer sicher, wenn sie sich bei der Einführung eines Qualitätsmanagementsystems direkt an der MDR zu orientieren. Unternehmen, die in den USA tätig sind, sollten außerdem einen Blick auf die 21 CFR 820 werfen.
• Technische Dokumentation: Für Alexander Bertel ist klar: „Die Anforderungen an die technische Dokumentation werden – in Abhängigkeit von der Klassifizierung – enorm steigen.“ Speziell Verifizierungs- und Validierungsprozesse hätten Hersteller von Software in den letzten Jahren viel zu selten durchgeführt und dokumentiert. Im Zweifelsfall ist es notwendig, die entsprechenden Vorgänge nachzuholen oder zu wiederholen, um die eigene technische Dokumentation zu vervollständigen.
• Benannte Stelle: Alle Hersteller, deren Software nicht in die niedrigste Risikoklasse I fällt, müssen eine Benannte Stelle für das Konformitätsbewertungsverfahren einbinden. Dabei ist höchste Eisenbahn geboten, so Alexander Bertel. Denn in der Regel seien die benannten Stellen schon ausgelastet. Außerdem brauchen Software-Hersteller eine Benannte Stelle, die sich mit der MDR und Software auskennt.
• Software-Normen DIN EN 62304. IEC 62366 und IEC 82304-1:

Um nachzuweisen, dass die Anforderungen der MDR an Software erfüllt werden, eignen sich harmonisierte Normen. Besonders wichtig für Software als Medizinprodukt sind die folgenden:

• IEC 62304: Die IEC 62304 stellt Mindestanforderungen an zentrale Software- Lebenszyklus-Prozesse. Dazu gehören die Entwicklung und die Wartung, aber auch das Risikomanagement.
• IEC 82304: Diese Norm bezieht sich auf Health Apps, also Gesundheitssoftware – die je nach ihrer Art auch ein Medizinprodukt ist. Sie beschreibt umfassende Anforderungen an Design, Entwicklung, Validierung, Installation, Wartung und Entsorgung. Speziell bei der Validierung schließt sie eine Lücke, die die IEC 62304 lässt.
• IEC 62366: Die MDR betont den Stellenwert von Usability. Um dem gerecht zu werden, orientieren sich Unternehmen bei der Entwicklung neuer Software am besten an der IEC 62366-1.

Alexander Bertel betont: „Hersteller von Medizinprodukte-Software können nicht sagen: Ich habe ein zugelassenes Produkt, da muss ich nicht mehr ran.“ Für die MDR wird alles neu geprüft. Dabei sei das Risiko für manche Unternehmen nicht unerheblich.

Schließlich hätten viele Hersteller von Software wenig Erfahrung mit ISO Normen. Dann weise zum Beispiel die Entwicklungsdokumentation entsprechende Lücken auf. In solchen Fällen sei es ratsam, sich professionelle Unterstützung zu holen, um diese Lücken schnell zu schließen und zu verhindern, dass Unternehmen eine erfolgreiche Software vom Markt nehmen müssen.

Mittlerweile ist die europäische Medizinprodukteverordnung (MDR) schon eine Weile in Kraft. Wir haben bei Auditor und Prüfer Alexander Bertel nachgefragt, wie es betroffenen Herstellern von Software damit geht.