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

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

Zur Themenwelt Medizinprodukte

Beitrag vom 11.02.2021

Software als Medizinprodukt – wie Hersteller einen Vertriebsstopp vermeiden

Wenn Ende Mai dieses Jahres die europäische Medizinprodukteverordnung endgültig in Kraft tritt, 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. 

Das erste Mal: Wenn Software zum Medizinprodukt wird

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.

Änderungen in der Klassifizierung und was sie bedeuten

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.



Zentrale Anforderungen für Hersteller von Medizinprodukte-Software

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.

Wichtig: Es gibt keinen Bestandsschutz für zugelassene Software

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.

Hat Ihnen der Artikel gefallen?

Entdecken Sie jetzt unsere Themenwelten! Hier finden Sie spannende Fachbeiträge, Experteninterviews und vieles mehr. 

Das könnte Sie auch interessieren:

Alle unsere Themenwelten im Überblick finden Sie in Wissen kompakt.

Unsere Empfehlungen für Sie

Seminar

Software als Medizinprodukt

Entwicklung medizinischer Software gemäß EN 62304 und IEC 82304: Informieren Sie sich über aktuelle Anforderungen und Neuerungen der europäischen Medizinprodukteverordnung (MDR).
Zum Seminar
Medizinprodukteverordnung
Seminar/Webinar

Medical Device Regulation (MDR)

Änderungen und Konsequenzen durch die EU-Medizinprodukteverordnung: Lernen Sie die wichtigsten Änderungen im Bereich des Medizinprodukterechts kennen! Jetzt buchen!
Zu den Veranstaltungen
Seminar

Medizinprodukteverordnung

Grundlagen des Medizinprodukterechts: Sie erhalten einen Überblick über die europäischen und nationalen gesetzlichen Anforderungen zur Herstellung und zum Vertrieb von Medizinprodukten.
Zum Seminar

Sprechen Sie mich gerne an

Roland Katholing

Roland Katholing

TÜV NORD Akademie GmbH & Co. KG
Produktmanager Medizinprodukte und Elektrotechnik
Am TÜV 1, 30519 Hannover

+49 511 998-61980
Fax : +49 511 998-62075

rkatholing@tuev-nord.de

Diese Seite weiterempfehlen