Medizinische Software: Klassifizierung und Zulassung als Medizinprodukt

Software, deren Anwendung einem medizinischen Zweck dient, ist rechtlich gesehen ein Medizinprodukt. Die Vermarktung eines Medizinprodukts ist in Europa streng reguliert. Für den Hersteller der Software hat dies einen hohen Aufwand und erhebliche Haftungsrisiken zur Folge. Daher sollte der Hersteller so früh wie möglich klären, ob es sich bei einer Software überhaupt um ein Medizinprodukt im rechtlichen Sinne handelt und – falls ja – zu welcher Risikoklasse es gehört. Dieser Fachbeitrag gibt einen Überblick über den Weg einer Software zu einem Medizinprodukt mit CE-Kennzeichen. 

Rechtliche Grundlagen  

Wollen Hersteller ein (Software-)Medizinprodukt in Europa vermarkten, müssen sie die europäische Medizinprodukteverordnung (EU) 2017/745 (MDR) bzw. In-vitro-Diagnostika-Verordnung (EU) 2017/746 (IVDR) befolgen. Gegenwärtig gilt auch noch die “alte” europäische Richtlinie 93/42/EWG über Medizinprodukte (MDD). Der Übergangszeitraum endet aber am 25. Mai 2021, so dass es höchste Zeit ist, sich mit den neuen Regeln vertraut zu machen.  

Wer „Praktiker“ ist und sich mit der MDR und der IVDR befasst, wird schnell enttäuscht sein. Im Gegensatz zur MDD regeln die Verordnungen zwar erheblich mehr und erhöhen die Anforderungen um ein Vielfaches, aber das tun sie insgesamt wenig konsistent und präzise. 

Es findet sich nicht einmal eine eindeutige Begriffsdefinition. So ist z. B. einmal von „Software als solche“ („Software as such“) und an anderer Stelle von „Software, die für sich genommen ein Produkt ist“ („software which constitutes a device in itself“) die Rede. 

Weitere regulatorisch relevante Dokumente sind (harmonisierte) europäische Normen, ggf. vorhandene gemeinsame Spezifikationen der EU-Kommission, etwaige Implementierungs- und/oder nationale Gesetzgebungen sowie unterschiedliche Leitlinien, allen voran die der Medical Device Coordination Group (MDCG)

Die o. g. Ungenauigkeiten in den europäischen Gesetzestexten sowie die schiere Fülle an Gesetzen, Regeln und (verbindlichen) Empfehlungen haben zur Folge, dass die einschlägigen Fachkreise um Begriffsbestimmungen, Definitionen und Abgrenzungen ringen. Die Situation für Hersteller medizinischer Software wird dadurch nicht einfacher. Wünschenswert wären natürlich möglichst einheitliche und verbindliche Regeln. Dafür setzen wir uns als VDE ein.

In der Online-Fachveranstaltung am 29.10.2020 lernen Sie die Anforderungen aus der europäischen Medizinprodukteverordnung MDR auf Ihre eigene Software zu übertragen. Zudem haben Sie die Grundlagen gelernt, um ein QM-System aufzubauen.

Wann ist Software ein Medizinprodukt? 

Zu Beginn einer Softwareentwicklung sollte die grundlegende Frage stehen, ob es sich überhaupt um eine medizinische Software im regulatorischen Sinne handelt und ob damit eine Zulassung bzw. Zertifizierung als Medizinprodukt erforderlich ist. 

Software „mit Bezug zu Gesundheit“ wird im Allgemeinen in 4 Gruppen unterteilt: 

  1. Die Software ist kein Medizinprodukt. Ein Beispiel ist eine Fitness-App. 
  2. Die Software ist ein Medizinprodukt und Teil eines Medizingeräts. Ein Beispiel ist die Software eines Patientenmonitors. 
  3. Die Software ist ein Medizinprodukt und Zubehör eines Medizingeräts. Ein Beispiel ist eine Servicesoftware zur Aufrechterhaltung der Gerätefunktion. 
  4. Die Software ist ein Medizinprodukt und eigenständig. Ein Beispiel ist eine medizinische Smartphone-App, mit deren Hilfe Hautveränderungen beurteilt werden können. 

Für die unterschiedlichen Gruppen haben sich unterschiedliche Bezeichnungen eingebürgert. Am häufigsten zu lesen sind „Health-App“ oder „Gesundheits-App“ für Gruppe 1, „embedded Software“ für Gruppe 2 und „Software as Medical Device (SaMD), Medical App oder Medizinische App“ für Gruppe 4. 

Ende 2019 wurde zur Frage der Klassifizierung medizinischer Software die Leitlinie “MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR” veröffentlicht. Diese führt einen neuen Begriff ein, und zwar „Medical Device Software“. Die MDCG versteht darunter folgendes:  

“Medical Device Software is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a medical device in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device.”

MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR

Dies lässt sich stark vereinfacht, aber erheblich besser lesbar, interpretieren als Software, die der Prävention, Diagnose oder Therapie von Erkrankungen dient. 

Die MDCG-Definition stellt also alleinig den Einsatzzweck der Software in den Mittelpunkt. Passt dieser zu den entsprechenden detaillierten Formulierungen in der MDR bzw. IVDR handelt es sich um ein Medizinprodukt. Die MDCG 2019-11 schließt bestimmte Arten von Software als Medizinprodukt aus, und zwar solche, die Bevölkerungsdaten sammelt, Informationen aus medizinischen Leitlinien bereitstellt, für epidemiologische Studien bestimmt ist oder als Register fungiert. 

Darüber hinaus definiert die MDCG 2019-11 „Steuer-Software“, allerdings benennt sie diese weitaus komplizierter („Software intended to drive or influence the use of a (hardware) medical device“). Steuersoftware unterstützt die medizinische Zweckbestimmung nicht unmittelbar, ist aber dennoch ein Medizinprodukt. 

Die Leitlinie MDCG 2019-11 richtet sich in erster Linie an Hersteller medizinischer Software und legt Qualifizierungskriterien für medizinische Software fest. Die Autoren weisen ausdrücklich darauf hin, dass die Leitlinie rechtlich nicht bindend ist. Es ist aber in jedem Fall davon auszugehen, dass die Empfehlungen in der Praxis, d. h. vor allem bei den Benannte Stellen, eine wesentliche Rolle spielen werden. Es empfiehlt sich also, die Leitlinie im Detail zu studieren. 

Zweckbestimmung 

Entscheidend ist also die Zweckbestimmung einer medizinischen Software, die der Hersteller formuliert. Eine Zweckbestimmung sollte folgende Aspekte berücksichtigen: 

  • medizinischer Nutzen 
  • medizinische Indikation  
  • Patientenpopulation 
  • Interaktionsort mit dem Menschen 
  • Nutzungsumgebung 
  • Funktionsprinzip 

Der Hersteller muss nun die Zweckbestimmung seiner medizinischen Software mit der regulatorischen Definition in der MDR (und ggf. IVDR) abgleichen. Die MDR definiert Medizinprodukte in erster Linie nach ihren Anwendungsgebieten (Artikel 2). Diese sind: 

  • Diagnose, Verhütung, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung von Krankheiten, 
  • Diagnose, Überwachung, Behandlung, Linderung von oder Kompensierung von Verletzungen oder Behinderungen, 
  • Untersuchung, Ersatz oder Veränderung der Anatomie oder eines physiologischen oder pathologischen Vorgangs oder Zustands und 
  • Gewinnung von Informationen durch die In-vitro-Untersuchung von aus dem menschlichen Körper, auch aus Organ-, Blut- und Gewebespenden stammenden Proben. 

Darüber hinaus sind Produkte zur Empfängnisverhütung oder -förderung sowie zur Reinigung, Desinfektion oder Sterilisation Medizinprodukte im Sinne des Gesetzgebers. 

Medizinische Geräte müssen zudem für den Menschen bestimmt sein. Außerdem ist das Wirkprinzip wichtig. Medizinprodukte wirken im oder am menschlichen Körper, jedoch nicht pharmakologisch, metabolisch oder immunologisch. 

Die IVDR ergänzt in Artikel 2 die Definition eines Medizinproduktes der MDR um spezifische Aspekte, die für In-vitro-Diagnostika (IVD) charakteristisch sind. Eine “IVD-Software” dient demnach der In-vitro-Untersuchung von aus dem menschlichen Körper stammenden Proben, einschließlich Blut- und Gewebespenden und dient dazu, bestimmte Diagnose- bzw. Therapie-relevante Informationen zu liefern. 

Risiko-Klassifizierung

Je nachdem, ob eine Software Medizinprodukte-Software, Steuer-Software oder möglicherweise beides ist, kommen unterschiedliche Klassifizierungsregeln zur Anwendung. Mit Hilfe der Klassifizierungsregeln wird die Risikoklasse einer medizinischen Software bestimmt. Je höher die Risikoklasse, desto höher der Aufwand des CE-Zertifizierungsprozesses. 

In den vermutlich allermeisten Fällen wird gelten, dass ein Hersteller im Falle einer geräteunabhängigen “Medical Device Software“ diese „als solche“ klassifizieren muss. In diesem Fall gilt die Regel 11 der MDR. Dazu mehr im nächsten Abschnitt. Handelt es sich dagegen um eine „Steuer-Software“, so muss der Hersteller diese als Teil des Gerätes klassifizieren. 

Von Bedeutung in diesem Zusammenhang ist die Regel 3.3 in Anhang VIII der MDR. Demnach wird Software, die ein Produkt steuert oder dessen Anwendung beeinflusst, derselben Klasse zugerechnet wie das Produkt. Regel 3.3 besagt zudem, dass Steuer-Software für sich allein klassifiziert werden muss, wenn diese von anderen Produkten unabhängig ist. MDCG 2019-11 interpretiert an dieser Stelle, dass eine Medizinprodukte-Software, die gleichzeitig auch Steuer-Software ist, stets für sich allein gemäß ihrer medizinischen Zweckbestimmung klassifiziert werden muss. Die resultierende Risikoklasse darf laut MDCG 2019-11 aber nicht geringer ausfallen als die des dazugehörigen Gerätes. 

Außerdem betonen die Autoren von MDCG 2019-11 noch die Bedeutung der Regel 3.5 in Anhang VIII der MDR, die vereinfacht besagt, dass immer die strengste Regel gilt, sollte einmal etwas unklar sein. Die Regeln 3.3 und 3.5 finden im Übrigen Ihre Entsprechung bei den In-Vitro-Diagnostika in den Regeln 1.4 und 1.9 im Anhang VIII der IVDR. 

Spätestens jetzt dürfte klar sein, welche herausragende Bedeutung die Formulierung der Zweckbestimmung für den späteren Vermarktungsweg einer medizinischen Software hat. 

Es sei an dieser Stelle auch noch einmal darauf hingewiesen, dass der Hersteller die Zweckbestimmung seines (Software)Produkts definieren und davon ausgehend die Risikoklasse festlegen muss. Auch wenn dies zukünftig in den allermeisten Fällen im Dialog mit einer Benannten Stelle stattfindet, trägt der Hersteller hier die volle Verantwortung. 

Bedeutung der Regel 11 der MDR  

In der bislang gültigen MDD finden sich keine ausdrücklichen Klassifizierungsregelungen für medizinische Software. Um den besonderen Eigenschaften und Risiken medizinischer Software Rechnung zu tragen, wurde die Regel 11 Bestandteil der MDR. Sie definiert ausdrücklich die Klassifizierung von Software. 

Wie bereits oben erwähnt, gilt die Regel 11 für Medical Device Software, also vereinfacht ausgedrückt für jede Software mit einer medizinischen Zweckbestimmung. Im Wortlaut: 

“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.” 

Anhang VIII, Kapitel III, Regel 11, Medizinprodukteverordnung

Es stellt sich aus praktischer Sicht sofort die Frage, welche Medical Device Software überhaupt noch realistisch als Klasse I Medizinprodukt klassifiziert werden kann. Immerhin sollte dies aktuell die häufigste Software-Risikoklasse sein. Welche Medical Device Software – also solche mit medizinischer Zweckbestimmung – dient letztlich nicht der Entscheidungsfindung für diagnostische oder therapeutische Zwecke? 

Oder andersrum betrachtet: Sollte es tatsächlich eines Tages eine Klasse I Medical Device Software gemäß MDR geben, hätte diese vermutlich kaum Aussichten auf eine spätere Erstattung durch die Gesetzliche Krankenversicherung (GKV), da ein diagnostischer oder therapeutischer Nutzen MDR bedingt ausgeschlossen wäre. Ausnahmen ergäben sich möglicherweise bei Digitalen Gesundheitsanwendungen (DiGA) nach §139e SGB V. Eine DiGA kann einen positiven Versorgungseffekt auch als patientenrelevante Struktur- und Verfahrensverbesserung in der Versorgung demonstrieren, die dann Grundlage für eine Erstattung durch die GKV sein kann.  

Ein weiterer, offensichtlicher Schwachpunkt von Regel 11 ist, dass keine Risikobetrachtung erfolgt. Das erscheint unrealistisch. Mit welcher Wahrscheinlichkeit stellen sich etwa Tod oder Verschlechterung des Gesundheitszustandes ein? Selbst die „harmloseste“ Software kann theoretisch den Tod zur Folge haben, wenn (extreme) unerwünschte Ereignisse eintreten. 

Bedauerlicherweise verstärkt die MDCG 2019-11 die restriktive Wirkung von Regel 11 noch weiter, denn eine Medical Device Software, die auch ein Gerät steuert, muss ja im Zweifelsfall immer der höheren Klasse zugeordnet werden. 

Mit Blick auf die fehlende Risikobetrachtung schlägt MDCG 2019-11 vor, eine Empfehlung des International Medical Device Regulators Forum (IMDRF) aus dem Jahr 2014 zu übernehmen. Die Empfehlung Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations definiert eigene Risikokategorien, die sich aus der Verbindung des Patientenstatus („non-serious, serious, critical“) mit der Bedeutung einer softwarevermittelten Information für die Diagnose bzw. Therapie ergeben („low, medium, high“). Die MDR Risikoklassen werden dann mit den IMDRF Risikoklassen „gematcht“. Demnach stellt beispielsweise eine MDR Klasse III Software sehr wichtige Informationen bereit, welche Einfluss auf eine patientenkritische Situation haben. 

Pflichten als Software-Hersteller 

Bevor ein Hersteller seine Software als Medizinprodukt auf den (europäischen) Markt bringt, muss er die allgemeinen Verpflichtungen aus Artikel 10 der MDR bzw. IVDR umsetzen. Diese sind zusammengefasst: 

Wir haben zu vielen der genannten Punkte Fachbeiträge verfasst, deren Verlinkungen Sie oben finden. Außerdem bieten wir regelmäßig Informationsveranstaltungen zu regulatorischen Themen an, deren Nutzung wir Ihnen aufgrund der Komplexität der Anforderungen dringend empfehlen. 

Grundlegende Sicherheits- und Leistungsanforderungen 

Ein Hersteller medizinischer Software muss durch eine Konformitätserklärung bestätigen, dass sein Produkt die grundlegenden Sicherheits- und Leistungsanforderungen gemäß Anhang I der MDR erfüllt. Anhang I der IVDR spricht hier von Allgemeinen Sicherheits- und Leistungsanforderungen. Grundlegende Anforderungen sind beispielsweise: 

  • Kompatibilität 
  • Interoperabilität 
  • Wiederholbarkeit 
  • Zuverlässigkeit 
  • Leistung 
  • Software-Lebenszyklus 
  • Validierbarkeit 
  • Verifizierbarkeit 
  • IT-Sicherheit 
  • Netzwerkeignung 
  • Eignung für den mobilen Einsatz 
  • Ergonomie und Gebrauchstauglichkeit 

Welche Anforderungen konkret erfüllt werden müssen, hängt von der jeweiligen Auslegung einer Software, deren Zweckbestimmung, der Risikoanalyse und den konkreten Vorgaben der Anhänge I von MDR bzw. IVDR ab.  

Normen 

Bei der Realisierung der o. g. Anforderungen helfen insbesondere harmonisierte europäische Normen, deren Anwendung eine Konformitätsvermutung auslösen. Wichtige Normen sind: 

Derzeit gibt es keine (harmonisierte) gesamthafte Norm für die Sicherheit medizinischer Software im Sinne von IT-Security bzw. Cybersecurity. Dies ist misslich, denn der Softwareanteil und der Vernetzungsgrad von Medizinprodukten steigen, so dass Security auch für Medizinproduktehersteller und -betreiber zu einem sehr wichtigen Thema geworden ist. Hinzu kommt, dass die MDR IT-Sicherheit nun ausdrücklich einfordert. 

Auch die bereits oben erwähnten Digitalen Gesundheitsanwendungen (DiGA) setzen sehr hohe Anforderungen an die IT-Sicherheit. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat dazu sogar eine eigene technische Richtlinie veröffentlicht, die verpflichtende Sicherheitsanforderungen an digitale Gesundheitsanwendungen (BSI TR-03161) beschreibt. 

Aufgrund des hohen Bedarfs an technischen Regeln für die IT-Sicherheit medizinischer Software sind zwischenzeitlich eine Reihe von Leitlinien, u. a. auch von der MDCG, erschienen. Im Fachbeitrag “Cybersecurity von Medizinprodukten als Teil der IT-Sicherheit im Gesundheitswesen” haben wir den aktuellen Stand der Dinge zusammengefasst.  

CE-Kennzeichnung 

Grundlage für das Anbringen der CE-Kennzeichnung ist das Konformitätsbewertungsverfahren. Die MDR beschreibt hier in Artikel 52 mehrere Wege. Im einfachsten Fall, d. h. bei einer Klasse I Software, ist es ausreichend, wenn der Hersteller ein “Basis-QMS” hat, das den Anforderungen der MDR genügt. In diesem Fall sind weder eine Zertifizierung des QMS noch eine Kontrolle durch eine Benannte Stelle erforderlich.  

Bei Software höherer Risikoklassen wird im Regelfall das Konformitätsbewertungsverfahren mit vollständigem und nach ISO 13485 zertifizierten QMS durchlaufen. Dies setzt ein vollständiges QMS beim Hersteller voraus. Dazu kommt die Zertifizierung des QMS durch eine Benannte Stelle. Auch die technische Dokumentation der Software muss von einer Benannten Stelle zertifiziert werden. Mit der EU-Konformitätserklärung übernimmt der Hersteller die Produktverantwortung. Sie enthält festgelegte Angaben und muss fortlaufend aktualisiert werden.

Im Anschluss stellt der Hersteller eine EU-Konformitätserklärung aus und bringt das CE-Kennzeichen an. Ist eine Benannte Stelle beteiligt, beinhaltet das CE-Kennzeichen deren 4-stellige Kennnummer. Das CE Kennzeichen erscheint auf der Verpackung, der Gebrauchsanweisung und auf Werbematerial. Außerdem erfolgt noch die Registrierung des Medizinprodukts in der europäischen Medizinproduktedatenbank EUDAMED und die Vergabe der UDI Codes.    

Fazit  

Insgesamt sind die CE-Zertifizierung und damit die europäische Vermarktung von medizinischer Software nicht einfacher geworden. 

Der aktuelle MDCG-Leitfaden 2019-11 beschreitet grundsätzlich einen sinnvollen Weg, indem er die Definition medizinischer Software von der Frage entkoppelt, ob Software miteinander und/oder mit Hardware verbunden ist. Allerdings ist der MDCG-Leitfaden schwer lesbar, enthält Inkonsistenzen und trägt aus praktischer Sicht nicht wirklich zur Vereinfachung bei. 

Es werden auch keine überzeugenden Ansätze formuliert, wie Hersteller mit der Regel 11 umgehen sollen. Immerhin findet sich im Anhang des MDCG-Leitfadens eine Tabelle mit Vorschlägen, wie eine Klassifizierung unter Anwendung von Regel 11 erfolgen kann. Bezeichnenderweise taucht Klasse I Software in dieser Tabelle gar nicht mehr auf. Zudem findet sich ein Disclaimer mit dem Wortlaut „for illustrative purposes only“. 

Es ist davon auszugehen, dass der überwiegende Teil medizinischer Software höher klassifiziert werden muss. Damit steigen die Anforderungen, z. B. an das Qualitätsmanagement, die klinische Bewertung oder die IT-Sicherheit. Zudem müssen in den meisten Fällen Benannte Stellen einbezogen werden. Diese stehen zum derzeitigen Zeitpunkt weder qualitativ noch quantitativ in ausreichendem Maße zur Verfügung.

Bis zum Geltungsbeginn der MDR am 26. Mai 2021 könnte also noch ein “Run” bei der Registrierung von Klasse I Software einsetzen, vor allem mit Blick auf die Beantragung Digitaler Gesundheitsanwendungen (DiGA). Nach Geltungsbeginn könnte sich die MDR zu einer nur schwer überwindbaren Hürde insbesondere für kleine und wenig finanzstarke Hersteller medizinischer Software erweisen.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.