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 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-Kennzeichnung.
Welche rechtlichen Vorschriften gelten für Software als Medizinprodukt?
Wollen Hersteller eine Software mit medizinischer Zweckbestimmung in Europa vermarkten, müssen sie ab 26. Mai 2021 (Gültigkeitsbeginn) die europäische Medizinprodukteverordnung (EU) 2017/745 (MDR) bzw. ab 26. Mai 2022 (Gültigkeitsbeginn) die In-vitro-Diagnostika-Verordnung (EU) 2017/746 (IVDR) befolgen. Mit der EU-Verordnung 2023/607 wurden die Übergangsfristen für das Inverkehrbringen und die Inbetriebnahme von Alt-Produkten (legacy devices) unter den alten Richtlinien MDD und AIMDD in Art. 120 (3) MDR geändert. Unter bestimmten Voraussetzungen ist dies bis zum 31.12.2028 und 31.12.2027 möglich. Nähere Erläuterungen sind im DOkument MDCG 2020-3 von der Medical Device Coordination Group zu finden.
Weiterhin sind die Bestimmungen der europäischen Datenschutzgrundverordnung 2016/679 (DSGVO) zu beachten.
Auch zukünftige Rechtsakte wie der europäische Artificial Intelligence Act (AIA) können die bestehenden Anforderungen weiter erhöhen.
Wann gilt Software als Medizinprodukt?
Zu Beginn einer Softwareentwicklung sollte zunächst die 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.
In den beiden Verordnungen findet sich leider keine eindeutige Begriffsdefinition für Software. 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. Immerhin benennen MDR und IVDR in Artikel 2 Software ausdrücklich als (mögliches) Medizinprodukt, wenn ein entsprechender medizinischer Zweck für die Software vorgesehen ist.
Ende 2019 wurde zu Definitionsfragen bei medizinischer Software das Dokument MDCG 2019-11 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).
Die MDCG-Definition stellt alleinig die Zweckbestimmung der Software in den Mittelpunkt. Bestimmte Arten von Software werden ausgeschlossen, und zwar Software, die Bevölkerungsdaten sammelt, Informationen aus medizinischen Leitlinien bereitstellt, für epidemiologische Studien bestimmt ist oder als Register fungiert.
Darüber hinaus definiert MDCG 2019-11 Steuer-Software („Software intended to drive or influence the use of a (hardware) medical device“). Steuersoftware unterstützt die medizinische Zweckbestimmung nicht unmittelbar, gilt aber dennoch ein Medizinprodukt. Steuer-Software kann auch als Zubehör im Sinne von MDR und IVDR gelten.
MDCG 2019-11 enthält ebenso wie das „Manual on borderline and classification for medical devices under Regulation (EU) 2017/745 on medical devices and Regulation (EU) 2017/746 on in vitro diagnostic medical devices” Beispiele für Software als Medizinprodukt.
Zweckbestimmung
Entscheidend ist also die Zweckbestimmung einer medizinischen Software, die der Hersteller formuliert. Eine Zweckbestimmung sollte u.a. folgende Aspekte berücksichtigen:
- medizinischer Nutzen
- medizinische Indikation
- Patientenpopulation
- Funktionsprinzip
- Interaktionsort mit dem Menschen
- Nutzungsumgebung
Der Hersteller gleicht die Zweckbestimmung seiner Software mit der regulatorischen Definition von Medizinprodukten in der MDR (und ggf. IVDR) ab. 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.
Inwiefern eine medizinische Software “am” Körper wirkt, sei dahingestellt. Diese Definition basiert offensichtlich auf einer “Hardware-lastigen” Herangehensweise an Medizinprodukte. Der größte Teil von Softwareanwendungen sollte keinen unmittelbaren räumlichen Bezug zum Körper haben. Bei einem Web-App basierten Therapiemanagementprogramm zum Beispiel, sind Softwarecode und Rechenoperationen überwiegend mit einer Server-Hardware verknüpft, die sich im Sinne eines Cloud basierten Dienstes irgendwo befinden kann.
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.
Risikoklassifizierung
Je nachdem, ob eine Software Medical Device Software und/oder Steuer-Software 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 der Zulassung.
In den meisten Fällen gilt, dass ein Hersteller einer geräteunabhängigen Medical Device Software diese „als solche“ klassifizieren muss. In diesem Fall gilt die Regel 11 Anhang VIII 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 Anhang VIII 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 Medical Device 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 Anhang VIII 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 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 Diskurs mit einer Benannten Stelle stattfindet, trägt der Hersteller hier die volle Verantwortung.
Regel 11 der MDR
In den (alten) Medizinprodukterichtlinien finden sich keine ausdrücklichen Klassifizierungsregelungen für medizinische Software. Um die besonderen Eigenschaften und Risiken medizinischer Software zu berücksichtigen, wurde die Regel 11 Bestandteil der MDR. Sie definiert ausdrücklich die Klassifizierung von geräteunabhängiger, medizinischer Software.
Die Regel 11 gilt für geräteunabhängige Software mit medizinischer 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).
Aus praktischer Sicht stellt sich die Frage, welche Medical Device Software noch als Klasse I Medizinprodukt klassifiziert werden kann. Software-vermittelte Informationen sollten in den meisten Fällen auch der Entscheidungsfindung für diagnostische oder therapeutische Zwecke dienen. Denkbar wäre Software, die der unmittelbaren Therapieanleitung dient, ohne dabei weitere Informationen zu Therapie (oder Diagnose) zu liefern, Software für primärpräventive Zwecke oder Software ohne direkten Bezug zu Diagnose oder Therapie, die aber trotzdem in den Geltungsbereich der MDR fällt (Empfängnisverhütung, Reinigung, Desinfektion, Sterilisation oder Anhang XVI-Produkte).
Ein kritischer Aspekt bei Regel 11 ist, dass nur eine bedingte Risikostratifizierung vorgesehen ist. So wird zum Beispiel nicht betrachtet, mit welcher Wahrscheinlichkeit sich etwa Tod oder Verschlechterung des Gesundheitszustandes einstellen können. Selbst die „harmloseste“ Software kann theoretisch den Tod zur Folge haben, wenn seltene und unerwünschte Ereignisse eintreten. MDCG 2019-11 verstärkt die restriktive Wirkung von Regel 11, denn eine Medical Device Software, die auch ein Gerät steuert, muss 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.
MDCG 2019-11 enthält Beispiele für Risikoklassifizierungen. Außerdem können das Produkte-Modul der europäischen Datenbank EUDAMED sowie das Verzeichnis des BfArM über Digitale Gesundheitsanwendungen (DiGA) zur Suche nach weiteren Beispielen genutzt werden.
Pflichten als Hersteller von Medizinprodukten
Bevor ein Hersteller seine Software als Medizinprodukt auf den (europäischen) Markt bringt, setzt er die allgemeinen Verpflichtungen aus Artikel 10 der MDR bzw. IVDR um. Diese sind zusammengefasst (die Verlinkungen führen zu speziellen Fachbeiträgen):
- Erfüllung der Grundlegenden Sicherheits- und Leistungsanforderungen
- Einrichtung eines Qualitätsmanagementsystems
- Aufbau eines Risikomanagementsystems
- Durchführung einer klinischen Bewertung oder Leistungsbewertung im Falle eines IVD
- Bereitstellung einer Gebrauchsanweisung und Kennzeichnung
- Erstellung einer technischen Dokumentation
- Einrichtung eines Systems zur Überwachung des Medizinprodukts nach dem Inverkehrbringen (Post Market Surveillance, PMS)
- Gewährleistung einer finanziellen Absicherung für den Haftungsfall
- Benennung einer Verantwortlichen Person
- Registrierung (inkl. Unique Device Identification, UDI)
- Konformitätsbewertungsverfahren, EU-Konformitätserklärung und CE-Kennzeichnung.
Die grundlegenden Sicherheits- und Leistungsanforderungen gemäß Anhang I MDR entsprechen den Allgemeinen Sicherheits- und Leistungsanforderungen in Anhang I IVDR. Grundlegende Anforderungen für Software aus Kapitel II Anhang I MDR sind vor allem:
- Kompatibilität
- Interoperabilität
- Wiederholbarkeit
- Zuverlässigkeit
- Leistung
- Anwendung von Software-Lebenszyklus-Prozessen
- Validierbarkeit
- Verifizierbarkeit
- IT-Sicherheit
- Netzwerkeignung
- Eignung für den mobilen Einsatz
Wie diese Anforderungen konkret erfüllt werden müssen, hängt von der jeweiligen Auslegung einer Software, deren Zweckbestimmung und den Ergebnissen der Risikoanalyse ab.
Normen
Durch die (freiwillige) Anwendung harmonisierter Normen in Europa seitens des Herstellers wird im Sinne einer Konformitätsvermutung von der Einhaltung eines Teils der allgemeinen Sicherheits- und Leistungsanforderungen durch den europäischen Gesetzgeber ausgegangen (Art. 8 (1) MDR). Harmonisierte europäische Normen (EN) werden in der Reihe C des offiziellen Amtsblatts der EU bekanntgegeben. Diese gehen oftmals auf internationale Normenversionen (ISO und IEC) zurück. Nachfolgend sind wichtige Normen für medizinische Software in Bezug auf einzelne Themen aufgelistet (die Verlinkungen führen zu speziellen Fachbeiträgen):
- Risikomanagement (ISO 14971, Medizinprodukte – Anwendung des Risikomanagements auf Medizinprodukte)
- Qualitätsmanagement (ISO 13485, Medizinprodukte – Qualitätsmanagementsysteme – Anforderungen für regulatorische Zwecke)
- Software-Lebenszyklus (IEC 62304, Medizingeräte-Software: Software-Lebenszyklus-Prozesse)
- Produktsicherheit (IEC 82304-1, Gesundheitssoftware - Teil 1: Allgemeine Anforderungen für die Produktsicherheit)
- Gebrauchstauglichkeit (IEC 62366-1, Medizinprodukte Teil 1: Anwendung der Gebrauchstauglichkeit auf Medizinprodukte)
- Klinische Prüfung (ISO 14155, Klinische Prüfung von Medizinprodukten an Menschen – Gute klinische Praxis)
- Sicherheit (Safety) (IEC 60601-1, Medizinische elektrische Geräte, Teil 1: Allgemeine Festlegungen für die Sicherheit einschließlich der wesentlichen Leistungsmerkmale). Die Norm befasst sich mit der elektrischen Sicherheit aktiver Medizinprodukte und spricht bei medizinischer Software von “Programmierbaren Elektrischen Medizinischen Systemen”, kurz “PEMS” und widmet diesen einen eigenen Abschnitt. Die IEC 60601-1 setzt PEMS in direkten Bezug zum geforderten Risikomanagement-Prozess und fordert die Dokumentation eines Softwarelebenszyklus.
- Informationssicherheit (Security) (IEC TR 60601-4-5, Medical electrical equipment - Part 4-5: Guidance and interpretation - Safety-related technical security specifications). Auch Digitale Gesundheitsanwendungen (DiGA) müssen sehr hohe Anforderungen an die IT-Sicherheit erfüllen (vgl. BSI TR-03161).
Derzeit gibt es keine Normen für KI-basierte Software, die sich speziell auf den Anwendungsbereich Medizin beziehen.
Fazit
Das aktuelle MDCG-Dokument 2019-11 beschreitet grundsätzlich einen sinnvollen Weg, indem er die Definition medizinischer Software tendenziell von der Frage entkoppelt, ob Software miteinander und/oder mit Hardware verbunden ist. Allerdings ist das MDCG-Dokument schwer lesbar, enthält Inkonsistenzen und trägt aus praktischer Sicht nur bedingt zur Vereinfachung bei.
Generell stellt man bei der MDR fest, dass sie aus einer “Hardware-Historie” heraus entwickelt wurde. Insgesamt ist die Zulassung von medizinischer Software in Europa aufwendiger geworden. Nehmen Sie Kontakt zu uns auf. Wir helfen Ihnen bei der praktischen Umsetzung Ihres Software-Projekts, erstellen mit Ihnen eine detaillierte CE-Roadmap und implementieren alle erforderlichen Prozesse. Außerdem bieten wir regelmäßig Informationsveranstaltungen zu regulatorischen Themen an.
