TÜV Süd Wenn Software zum Medizinprodukt wird

Anbieter zum Thema

TÜV Süd Product Service GmbH

KUMAVISION AG

Prosmap · Medical Product Platform

Metecon GmbH

Mit der Digitalisierung halten Computerprogramme Einzug in das Gesundheitswesen. Je nach Zweckbestimmung müssen Entwickler unterschiedliche regulatorische Anforderungen erfüllen. TÜV Süd zeigt, wie Hersteller die Konformität ihrer Produkte mit den EU-Verordnungen nachweisen.

Von medizinischen Apps über Software für die Therapieplanung oder die Firmware von Ultraschallgeräten bis hin zu klinischen Informationssystemen: Rechtlich gesehen ist eine Software ein Medizinprodukt, wenn sie einem medizinischen Zweck dient – wie der Diagnose, Untersuchung oder der Vorhersage von Krankheitsverläufen oder auch die Beeinflussung einer Therapie. Nach der EU-Verordnung über Medizinprodukte (MDR – Medical Device Regulation) handelt es sich bei Software sogar um ein aktives Medizinprodukt, so dass abgesehen von der Regel 11 auch andere Regeln für die Klassifizierung der Software in Frage kommen.

Häufig sind sich Hersteller nicht einmal darüber bewusst, dass sie Medizinprodukte entwickeln, denn auch Gesundheits- oder Wellness-Apps auf dem Smartphone können unter Umständen dazu zählen. Seit Anfang 2020 dürfen Ärzte medizinische Apps sogar auf Rezept verschreiben. Zu Corona-Zeiten gewinnen sie an Relevanz. Im Rahmen der Telemedizin ermöglichen sie eine kontaktlose Diagnostik und Therapie.

Voraussetzung dafür ist, dass die „digitale Gesundheitsanwendung (DiGA)“ als Medizinprodukt qualifiziert ist. Dafür müssen Hersteller Benannte Stellen („Notified Bodies“, NoBo) einbeziehen, ein Qualitätsmanagement-System aufbauen und ihre Produkte beim Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) registrieren. Um Kosten zu senken und Aufwände zu reduzieren, ist zunächst zu klären, ob ein Medizinprodukt vorliegt und zu welcher der drei Klassen es gehört, die in der MDR oder, im Rahmen der Übergangsvorschriften, der MDD definiert werden.

Hilfreicher Leitfaden

Das internationale Expertengremium „Koordinierungsgruppe Medizinprodukte“ (MDCG – Medical Device Coordination Group) veröffentlichte im November 2019 den Leitfaden MDCG 2019-11 zur Qualifizierung und Klassifizierung von Software. Die Anforderungen und Kriterien stammen aus den EU-Verordnungen über Medizinprodukte (MDR 2017/745 – Anhang VIII) und In-Vitro-Diagnostika (IVDR 2017/746 – Anhang VIII). Nach der Definition des Leitfadens umfasst der Begriff „medizinische Software“ sowohl Programme, die in Kombination mit einem Medizinprodukt verwendet werden, als auch eigenständige Software (standalone).

Mit einem Flussdiagramm ermitteln Hersteller schrittweise, ob sich eine Software als Medizinprodukt qualifiziert. Zu den wichtigsten Punkten zählen die Zweckbestimmung, der individuelle Patientennutzen und inwieweit die Definition für medizinische Software zutrifft. Die Corona-Warn-App ist bspw. kein Medizinprodukt, weil sie nicht direkt diagnostischen oder therapeutischen Zwecken am Patienten dient. Eine Smartwatch-App hingegen schon, wenn sie den Puls überwacht und dadurch gemäß der Zweckbestimmung und basierend auf der Datenauswertung eine Therapie oder Diagnose beeinflusst. Auch die Software zur Steuerung einer Insulinpumpe, weil sie die richtige Dosis berechnet.

Produktklasse ermitteln

Medizinprodukte werden je nach Gefährdungspotenzial verschiedenen Produktklassen zugeordnet. Die Klassen I bis III repräsentieren das Risikopotenzial in Abhängigkeit vom Anwendungszweck, dem -ort und der -dauer. Die Merkmale sind in der MDR im Anhang VIII festgelegt. Eine Benannte Stelle prüft anschließend, ob alle gesetzlichen Produktanforderungen erfüllt sind. Das bestätigt der Hersteller mit der CE-Kennzeichnung.

Die Klassifizierungsregel 11 ist für Software-Entwickler besonders wichtig: Kommt Software bei der Diagnose, Überwachung oder Therapie zum Einsatz, gehört sie zur Klasse IIa. Besteht die Gefahr, dass sich der Gesundheitszustand eines Patienten aufgrund der Informationen der Medizinprodukte-Software schwerwiegend verschlechtert, gehört sie zur Klasse IIb; führt die Information zu einer irreversiblen Verschlechterung des Gesundheitszustands oder zum Tod, dann gehört sie in die höchste Klasse III. Sämtliche andere Software gehört zur Klasse I. Weitere Hilfestellung gibt der Leitfaden „Software as a Medical Device“: Possible Framework for Risk Categorization and Corresponding Considerations des IMDRF (International Medical Device Regulators Forum).

Risikobewertung: „Faktor Mensch“ mit einbeziehen

Beim Risikomanagement nach ISO 14971 legen Hersteller zunächst mit einer Risikomatrix Akzeptanzkriterien fest. Anschließend gibt eine Risikoanalyse Auskunft darüber, welche Gefährdungen sich aus der Zweckbestimmung ableiten lassen und welche Schweregrade und Wahrscheinlichkeiten möglich sind. Sind die Risiken nicht vertretbar, werden Maßnahmen zur Risikominimierung festgelegt und umgesetzt. Anschließend müssen Hersteller weiterhin kontinuierlich Risiken analysieren und über deren Akzeptanz neu entscheiden.

Auch mangelnde Benutzerfreundlichkeit stellt ein Risiko dar: Gemäß den Untersuchungen der FDA zu Rückrufen lassen sich ein Drittel aller Zwischenfälle mit Medizinprodukten (inklusive Software) auf Anwendungsfehler zurückführen. Die internationale Norm IEC 62366-1 definiert Anforderungen an die Bedienbarkeit: Durch den „Faktor Mensch“ bedingte Risiken müssen Hersteller vorab identifizieren und möglichst ausschließen. Dazu gehören u. a. physikalische Eigenschaften und ergonomische Merkmale – auch die Software-Ergonomie (leicht verständlich und schnell benutzbar) fällt darunter.

Die Mindestanforderungen an die wichtigsten Prozesse im Lebenszyklus einer Software für den konkreten medizinischen Gebrauch sind in Europa mit der Norm IEC 62304 harmonisiert. Das betrifft die Entwicklung und Wartung, das Konfigurations- und Risikomanagement sowie die Problemlösung. Ursprünglich war die Norm sowohl für Standalone- als auch Embedded-Lösungen vorgesehen. In der Praxis richtet sie sich aber eher an Letztere. Die IEC 82304-1 spezifiziert weitere Anforderungen an Standalone-Software.

IT-Sicherheit: Hacker-Angriffe gefährden Menschenleben

Zunehmend wird auch künstliche Intelligenz (KI) in Medizinprodukten angewendet, wie etwa zur Vorhersage von Krankheitsverläufen oder zur Bildanalyse. Entscheidungen müssen aber nachvollziehbar und verifizierbar sein, damit die Anwendung beim Patienten sicher ist. Nach den grundlegenden Sicherheits- und Leistungsanforderungen der MDR ist Software so auszulegen, dass die Wiederholbarkeit, Zuverlässigkeit und Leistung bei ihrer bestimmungsgemäßen Verwendung gewährleistet ist. Den Nachweis für die Erfüllung dieser Anforderung kann der Hersteller durch eine Verifizierung und Validierung der Software erbringen.

Außerdem muss eine Software nach dem Stand der Technik entwickelt werden und die Grundsätze des Softwarelebenszyklus, des Risikomanagements sowie der Informationssicherheit erfüllen. Denn Hacker-Angriffe auf Kliniknetzwerke oder kompromittierte Medizingeräte gefährden unmittelbar Menschenleben. Infolge der Covid-19-Pandemie hat sich die Bedrohungslage insgesamt weiter erhöht, weil Gesundheitsdienste online bereitgestellt werden. TÜV Süd Product Service prüft nach den einschlägigen Software-Standards und zertifiziert als Benannte Stelle Medizinprodukte-Software.

Lesen Sie auch

Metecon

Die Lücke zwischen Medtech-Herstellern und Software-Anbietern schließen

Sigfox

Medical Device Regulation (MDR) unterstützt vernetzte Medizingeräte

Weitere Artikel zur Führung von Medizintechnik-Unternehmen finden Sie in unserem Themenkanal Management.

* Der Autor Abtin Rad ist Global Director Functional Safety, Software and Digitization beim TÜV Süd Product Service.

(ID:47062520)