Software-Anbieter sind gefordert: Erfüllen sie das neue Medizinprodukterecht nicht, droht in acht Monaten ein Vertriebsstopp. Worauf jetzt zu achten ist.
Die EU Medizinprodukteverordnung 2017/745 (MDR) wirft ihre Schatten voraus. Auf den Tag genau in acht Monaten – am 26. Mai 2020 – greift das neue Regelwerk. Medizinprodukte müssen auf den Prüfstand. Bei vielen ändert sich die Risiko-Klassifizierung. Sie werden hochgestuft mit teils erheblichen Folgen.
Besonders kritisch ist dies bei medizinischer Software: War sie bislang oft der risikoärmsten Klasse I zugeteilt, wird sie künftig meist in eine höhere Risikostufe rutschen und mehr regulatorische Anforderungen auslösen. Doch damit nicht genug: Weil insoweit keine Übergangsfristen greifen, droht bei „Non-Compliance“ im Mai 2020 ein sofortiger Vertriebsstopp. Soweit noch nicht geschehen, sollten Anbieter von medizinischer Software Strategien für die Übergangszeit bereithalten.
Zum Hintergrund: Die MDR
Der europäischen Medizinprodukteindustrie stehen erhebliche Änderungen bevor: Im Mai 2020 entfaltet die EU Medizinprodukteverordnung Geltung. Sie wurde und wird kontrovers diskutiert – insbesondere im Hinblick auf ihre praktischen Auswirkungen.
Die Reform wird zu einer Reihe von Änderungen auf verschiedenen Ebenen führen. Praktisch wichtige Kernpunkte sind:
- Strengere Anforderungen an die Sicherheit von Medizinprodukten,
- eine größere Transparenz, die lückenlose Rückverfolgbarkeit der Produkte über die gesamte Lieferkette und
- verschärfte Kontrollen durch benannte Stellen einschließlich unangekündigter Audits.
Für die Hersteller von medizinischer Software wird die MDR ganz besondere Auswirkungen haben. Das liegt zunächst daran, dass die Qualifikation von Software als Medizinprodukt fortgeschrieben und präzisiert wird. Gemäß Art. 2 Ziff. 1 MDR gilt als „Medizinprodukt“ unter anderem eine Software, die dem Hersteller zufolge eine medizinische Zweckbestimmung hat. Das ist, verkürzt gesagt, unter anderem dann der Fall, wenn die Software allein oder in Kombination der Diagnose, Verhütung, Überwachung, Behandlung oder Linderung von Krankheiten bei Menschen dienen soll. Diese Voraussetzungen, die heute schon in sehr ähnlicher Form gelten, legen Behörden, benannte Stellen und Gerichte tendenziell weit aus
Einordnung medizinischer Software unter der MDR
Neu ist, dass medizinische Software künftig im Regelfall als Medizinprodukt der Klasse IIa zu qualifizieren sein wird – und nicht mehr, wie vielfach heute, als Produkt der Klasse I. Das ergibt sich aus den Regeln für die Klassifizierung für Medizinprodukte.
Maßgebend ist insoweit Anhang VIII, Regel 11 der MDR. Danach gehört Software, die dazu bestimmt ist, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden, im Grundsatz zur Klasse IIa. Wenn sie zu Entscheidungen führen kann, die eine schwerwiegende Verschlechterung des Gesundheitszustands einer Person oder einen chirurgischen Eingriff zur Folge haben können, wird die Software Klasse IIb zugeordnet. Sollte sie den Tod oder eine irreversible Verschlechterung des Gesundheitszustands einer Person zur Folge haben können, wird die Software sogar in Klasse III eingeordnet.
Nur Software, die diese Voraussetzungen nicht erfüllt, fällt unter Klasse I.
Die Herausforderung: Software als Medizinprodukt höherer Risikoklasse
Ob ein Medizinprodukt in die Klasse I oder die Klasse IIa oder höher eingeordnet wird, ist praktisch von erheblicher Bedeutung. Denn: Um ein Medizinprodukt auf den Markt bringen zu dürfen, muss es mit einem CE Kennzeichen versehen sein. Dieses darf der Hersteller nur dann aufbringen, wenn er für das betreffende Produkt ein so genanntes Konformitätsbewertungsverfahren erfolgreich durchlaufen hat. Dabei werden unter anderem technische Voraussetzungen, klinische Daten, Produktsicherheit sowie das Qualitätsmanagement des Herstellers bewertet.
Bei Produkten der Klasse I darf diese Bewertung und Dokumentation der Hersteller selbst vornehmen. Er muss die entsprechenden Daten der Behörde auf Verlangen vorzeigen können. Bei Produkten der Klasse IIa und höher ist zwingend eine so genannte „benannte Stelle“ einzubeziehen. Diese nimmt die Prüfung vor und stellt bei positiver Entscheidung ein entsprechendes Zertifikat aus.
Das bedeutet: Ist eine medizinische Software heute als Medizinprodukt der Klasse I klassifiziert, hat der Hersteller die Zertifizierung zumeist selbst vorgenommen. Das ist kostengünstiger und einfacher. Ein Zertifikat einer benannten Stelle hat er nicht. Das ist nach geltendem Recht auch nicht erforderlich.
Anders wird das unter der MDR. Von deren Geltungsbeginn an gilt dieselbe Software aufgrund der neuen Klassifizierungsregeln als Medizinprodukt der Klasse IIa. Solche Produkte dürfen aber nur dann in den Verkehr gebracht werden, wenn ein Zertifikat einer benannten Stelle ihre Konformität mit den Voraussetzungen der MDR bescheinigt. Das hat der Hersteller nicht – weder für die MDR noch für die derzeitig geltende Medizinprodukte-Richtlinie (MDD) oder das deutsche Medizinproduktegesetz (MPG).
Das Problem: Keine Übergangsfrist – ein Vertriebsstopp droht
Was bedeutet das nun praktisch? Es muss doch eine Übergangsfrist geben, sollte man meinen. Dem ist aber leider nicht so. Die MDR hält zwar Übergangsfristen bereit. Diese greifen aber nicht für Konstellationen wie die hiesige – denn es fehlt an einem Zertifikat einer benannten Stelle.
Art. 120 MDR sieht verschiedene Übergangsregelungen vor. Grob gesagt dürfen Medizinprodukte, die unter der Geltung der MDD rechtmäßig in den Verkehr gelangt sind, auch unter der Geltung der MDR noch weiter vertrieben werden, solange sie über ein gültiges Zertifikat verfügen. So sieht Art. 120 Abs. 3 MDR etwa vor, dass ein Produkt, für das eine Bescheinigung einer benannten Stelle gemäß der MDD erteilt wurde, in Verkehr gebracht werden darf, sofern es ab dem Tag des Geltungsbeginns der MDR weiterhin der MDD entspricht und sofern keine wesentlichen Änderungen der Auslegung und der Zweckbestimmung vorliegen.
Diese Übergangsvorschrift greift für MDD-konforme Klasse I Produkte nicht. Denn sie setzt das Vorliegen einer gültigen MDD-Bescheinigung einer Benannten Stelle voraus – und daran fehlt es hier ja gerade. Andere einschlägige Übergangsvorschriften gibt es nicht.
Die Lösung: Strategien für die Vermarktungsfähigkeit
Vor diesem Hintergrund gilt: Eine medizinische Software, die als Klasse I-Produkt MDD-konform vertrieben wird, darf – wenn sie unter der MDR als Klasse IIa oder höher einzustufen ist – ab dem 26. Mai 2020 nicht mehr in den Verkehr gebracht werden. Es sei denn, der Hersteller hat rechtzeitig eine Zertifizierung des Produkts gemäß Klasse IIa MDR (oder höher) erreicht. Nach Art. 120 Abs. 5 MDR besteht die Möglichkeit, bereits vor dem 26. Mai 2020 ein Produkt, das der MDR entspricht, in Verkehr zu bringen. Letzteres ist alles andere als einfach – denn die Anzahl der benannten Stellen, die heute schon nach dem neuen MDR Standard zertifizieren dürfen, ist sehr überschaubar. Die Kapazitäten sind entsprechend gering, die Wartezeiten lang.
Damit sind alternative Strategien zum Erhalt der Vermarktungsfähigkeit gefragt.
Zumindest theoretisch denkbar ist, dass bei entsprechender sachlicher Rechtfertigung noch versucht werden kann, unter der MDD eine Zertifizierung für zumindest solche Module der medizinischen Software zu erhalten, die als Klasse IIa qualifiziert werden können. Dann würde die benannte Stelle gemäß den geltenden Regelungen zertifizieren, und der Hersteller könnte sich gemäß Art. 120 Abs. 3 MDR auf dieses Zertifikat berufen.
Eine praktisch relevantere Möglichkeit dürften die Regeln über dem Abverkauf von bereits in den Verkehr gebrachter Ware bieten. Gemäß Art. 120 Abs. 4 MDR dürfen Produkte, die vor dem 26. Mai 2020 rechtmäßig in den Verkehr gebracht wurden bis zum 27. Mai 2025 weiter auf dem Markt bereitgestellt oder in Betrieb genommen werden. Voraussetzung für einen solchen Abverkauf ist also, dass das Produkt bereits vor dem 26. Mai 2020 in den Verkehr gebracht, also auf dem Unionsmarkt bereitgestellt worden ist. Dafür sind verschiedene Gestaltungsformen denkbar. Wichtig ist jedoch, dass das zuvor in den Verkehr gebrachte Produkt dann abverkauft wird, und zwar nur dieses – nicht etwaige Abwandlungen oder Weiterentwicklungen. Das kann bei Software-Updates oder Modulergänzungen zu Abgrenzungsthemen führen. Hier ist in jedem Fall eine vorausschauende Planung erforderlich.
Medizinische Software hat es in sich: Nicht nur wegen der komplexen Abgrenzungsfrage, ob sie ein Medizinprodukt ist oder nicht, sondern derzeit auch und vor allem, weil unklar ist, wie die Vermarktung über Mai 2020 hinaus sichergestellt werden kann. Unternehmen, die in diesem Bereich aktiv sind, sollten verifizieren, ob sie entsprechend aufgestellt sind und auch das Fehlen einer Übergangsfrist in ihren Planungen berücksichtigt haben.
