Digitale Produkte Wann ist eine Software ein Medizinprodukt?

Entwickler müssen frühzeitig klären, ob ihre Software im regulatorischen Sinne ein medizinisches Produkt ist. Davon hängen Zulassung und Zertifizierung ab. Ein Blick in die EU-Verordnungen lohnt sich.

Im Gesundheitswesen setzen sich immer mehr vernetzte, digitale Produkte durch: von Smartphone-Apps und Fitness-Trackern bis hin zu komplexen Anwendungen für die medizinische Diagnostik. Doch ein medizinisches Produkt unterliegt strengen Regularien. Auftraggeber, Entwickler und Hersteller müssen bereits zu Beginn der Softwareentwicklung die Frage klären, ob ihre Applikation im regulatorischen Sinne ein medizinisches Produkt ist oder nicht. Davon hängt ab, ob eine Zulassung und eine Zertifizierung als Medizinprodukt erforderlich ist. Vereinfacht gesagt: Software ist unter rechtlichen Gesichtspunkten als Medizinprodukt zu bewerten, wenn sie einen medizinischen Zweck erfüllt. Das umfasst die Prävention, Diagnose oder Therapie einer Erkrankung.

Eine Software, die Röntgenbilder aufnimmt und verarbeitet, gilt als Medizinprodukt. Nicht so eindeutig ist die Lage zum Beispiel bei einem Krankenhausinformationssystem (KIS). Steuert die Software ausschließlich Abläufe und speichert sie Patientendaten zu Dokumentationszwecken, handelt es sich in der Regel nicht um ein Medizinprodukt. Sind jedoch Module integriert, die Ärzte oder Pflegepersonal bei der Untersuchung oder Behandlung aktiv unterstützen, ist das System als Medizinprodukt zu klassifizieren.

Wann eine Smartphone-App ein Medizinprodukt ist

Auch bei Gesundheits- und Wellness-Apps auf mobilen Endgeräten hängt es vom Einsatzzweck ab: Die Corona-Warn-App ist beispielsweise kein Medizinprodukt, da sie nur dokumentiert und nicht der Diagnose oder Therapie dient. Eine Smartphone-App, die den Puls misst und anzeigt, ist für sich allein genommen ebenso kein Medizinprodukt. Das ändert sich, wenn die App gemäß der Zweckbestimmung die Daten für eine Diagnose nutzt oder Empfehlungen für die Behandlung eines Patienten gibt.

Im Zuge der fortschreitenden Digitalisierung im Gesundheitswesen dürfen Ärzte seit Anfang 2020 medizinische Apps verschreiben. Kontaktlose Untersuchungen und Behandlungen tragen dazu bei, Ansteckungen zu vermeiden und die Corona-Pandemie zu verlangsamen. Voraussetzung für eine App auf Rezept ist, dass diese digitale Gesundheitsanwendung (DiGA) als Medizinprodukt qualifiziert wurde. Dafür müssen Hersteller je nach Risikoklasse Benannte Stellen (Notified Bodies) einbeziehen, ein Qualitätsmanagement-System aufbauen und das Produkt beim Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) registrieren. Das BfArM listet auf seiner Website alle bisher zugelassenen digitalen Gesundheitsanwendungen auf. Eine der ersten digitalen Gesundheitsanwendungen ist eine Software, die Tinnitus-Patienten leitlinienbasiert und verhaltenstherapeutisch unterstützt.

Eine praktische Orientierungshilfe zur Qualifizierung und Klassifizierung bietet der Leitfaden MDCG 2019-11 der internationalen Medical Device Coordination Group (MDCG), der im November 2019 veröffentlicht wurde. Der Leitfaden berücksichtigt Programme als Teil oder Zubehör eines Medizinprodukts (Hardware) und eigenständige (Stand-alone-)Software. Hersteller werden Schritt für Schritt zur Antwort auf die Frage geführt, ob ihre Software ein Medizinprodukt ist. Wichtige Aspekte sind dabei die Zweckbestimmung und der individuelle Patientennutzen.

Die rechtlichen Anforderungen identifizieren

Für Medizinprodukte gelten in Europa die europäische Medizinproduktverordnung (EU) 2017/745, international mit MDR abgekürzt, und die In-vitro-Diagnostika-Verordnung (EU) 2017/746 (IVDR). Am 25. Mai 2021 endete der Übergangszeitraum für die MDR – bis dahin galt auch noch die alte europäische Richtlinie 93/42/EWG über Medizinprodukte (MDD). Die MDR und IVDR regeln mehr Details als die MDD und stellen höhere Anforderungen. Für Softwareentwickler ist es ohne fachliche Unterstützung mitunter schwierig, die vielen regulatorisch relevanten Begriffe, Spezifikationen und Leitlinien anzuwenden sowie die nötigen Dokumente anzufertigen.

Je nach Gefährdungspotenzial werden Medizinprodukte in die Produktklassen I bis III eingeordnet. Das potenzielle Risiko ist abhängig von Anwendungszweck, -ort und -dauer. Die Merkmale sind in der MDR im Anhang VIII beschrieben. Generell gilt: Je höher die Produktklasse, desto höher ist auch der Aufwand für die Zertifizierung. Eine Benannte Stelle prüft, ob alle gesetzlichen Produktanforderungen erfüllt sind. Das bestätigt der Hersteller mit der CE-Kennzeichnung.

Geräteunabhängige medizinischer Software

Bei geräteunabhängiger medizinischer Software gilt die für Entwickler besonders wichtige Klassifizierungsregel 11 der MDR. Sie besagt, dass Software, die diagnostische oder therapeutische Entscheidungen unterstützt, generell zur Klasse IIa gehört. Sollten die Informationen jedoch zu Entscheidungen führen, die mit einer gravierenden Verschlechterung des Gesundheitszustands eines Patienten einhergehen können, ist das Medizinprodukt in die Klasse IIb einzuordnen.

Falls als Konsequenz der Entscheidung eine irreversible Schädigung oder der Tod eintreten könnte, gehört die Software zur höchsten Klasse III. Für sämtliche andere Software gilt die Klasse I. Gegenüber der MDD ist damit die in der MDR definierte Klasse I sehr stark ausgedünnt. An die Klasse I werden die geringsten regulatorischen Anforderungen gestellt. Weitere nützliche Informationen zur Risikoeinordnung enthält der Leitfaden „Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations“ des IMDRF (International Medical Device Regulators Forum).

Software muss leicht zu verstehen und nutzbar sein

Die Anwendung des Risikomanagements auf Medizinprodukte regelt die Norm ISO 14971. Hersteller legen zuerst eine Risikomatrix und Akzeptanzkriterien fest. Eine Risikoanalyse zeigt anschließend, welche Gefährdungen sich aus dem Einsatzzweck ableiten lassen und wie hoch die Wahrscheinlichkeit des Eintretens ist. Außerdem gibt sie Auskunft über den möglichen Schweregrad der Gefährdung. Sind die ermittelten Risiken nicht vertretbar, werden Maßnahmen zur Risikominimierung identifiziert und implementiert. Außerdem müssen die Hersteller eine ganzheitliche Risikobetrachtung über den gesamten Lebenszyklus umsetzen.

Anforderungen an die Bedienbarkeit definiert die internationale Norm IEC 62366-1. Oft wird das Risiko unterschätzt, das von einer mangelnden Benutzerfreundlichkeit ausgeht. Laut Untersuchungen der US-Behörde für Lebens- und Arzneimittel (FDA) gehen ein Drittel aller Zwischenfälle mit Medizinprodukten – einschließlich medizinischer Software – auf das Konto von Anwendungsfehlern. Hersteller sollten unbedingt menschliche Einflussfaktoren kennen und Fehlbedienungen durch eine optimierte Software-Ergonomie möglichst ausschließen. Gerade im medizinischen Umfeld muss Software leicht zu verstehen und möglichst schnell und intuitiv nutzbar sein.

Der Lebenszyklus einer Software

Hersteller sollten ebenfalls die international gültige Norm IEC 62304 berücksichtigen. Sie stellt Mindestanforderungen an die wichtigsten Prozesse im Lebenszyklus einer Software. Das reicht von der Entwicklung über die Wartung bis hin zum Risikomanagement und zur Problemlösung. Die Norm wurde sowohl für Stand-alone-Software als auch für Embedded-Anwendungen entwickelt. Allerdings richtet sich die Norm in der Praxis an die Entwickler von Embedded-Anwendungen. Weitere allgemeine Anforderungen an die Produktsicherheit von Stand-alone-Software stellt die IEC 82304-1.

Zunehmend integrieren Hersteller künstliche Intelligenz (KI) in ihre Medizinprodukte. Die KI eröffnet neue diagnostische Optionen bei der Bildanalyse und ermöglicht präzisere Prognosen von Krankheitsverläufen. Die Entscheidungen müssen allerdings jederzeit transparent, nachvollziehbar und verifizierbar sein, um klinisch sinnvoll handeln und die Sicherheit des Patienten gewährleisten zu können. Das gehört zu den grundlegenden Sicherheits- und Leistungsanforderungen der MDR. Der Hersteller verifiziert und validiert seine Software und weist so Sicherheit und Leistungsanforderung nach.

Software für Medizinprodukte ist besonders gefährdet

Stand-alone-Software auf Smartphones und Embedded-Software in vernetzten Medizinprodukten ist gegenüber Angriffen über das Internet besonders gefährdet. Daher muss Software nach dem Stand der Technik entwickelt werden und die Anforderungen des Cyber-Security-Risikomanagements und der Informationssicherheit erfüllen. Hackerangriffe im Gesundheitswesen haben schwerwiegende Folgen: Nicht mehr funktionierende oder manipulierte Medizinprodukte und gestohlene Gesundheitsdaten können nicht nur zu Reputationsverlust führen, sondern Menschenleben gefährden. Die Datenschutz-Grundverordnung (DSGVO) formuliert verschiedene Anforderungen zu Datenintegrität und Vertraulichkeit. Verstößen gegen die DSGVO führen zu erheblichen Strafen. Die Konformitätsnachweise sind Bestandteil der technischen Dokumentation.

Dieser Beitrag stammt von unserem Partnerportal Elektronikpraxis.

* Dr. Abtin Rad ist bei TÜV Süd Global Director Functional Safety, Software and Digitization in München.

(ID:47515040)