Medizinische Software und Medical Apps: Qualifizierung, 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 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. 

Wann gilt Software als Medizinprodukt?  

Wollen Hersteller eine Software mit medizinischem Zweck in Europa vermarkten, müssen sie ab 26. Mai 2021 die europäische Medizinprodukteverordnung (EU) 2017/745 (MDR) bzw. ab 26. Mai 2022 die In-vitro-Diagnostika-Verordnung (EU) 2017/746 (IVDR) befolgen.

Zu Beginn einer Softwareentwicklung sollte also 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 entprechender medizinischer Zweck für die Software vorgesehen ist.

Ende 2019 wurde zu Definitionsfragen bei 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).

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 die 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.

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.

In wie fern eine medizinische Software “am” Körper wirkt, sei einmal dahin gestellt. 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 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 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 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 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 den besonderen Eigenschaften und Risiken medizinischer Software Rechnung zu tragen, 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 (extrem seltene und extreme) 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 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 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:

• 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.

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.

Die grundlegenden Sicherheits- und Leistungsanforderungen gemäß Anhang I der MDR entsprechen den Allgemeinen Sicherheits- und Leistungsanforderungen in Anhang I der IVDR. Grundlegende Anforderungen für Software 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
• Ergonomie und Gebrauchstauglichkeit

Welche Anforderungen konkret wie erfüllt werden müssen, hängt von der jeweiligen Auslegung einer Software, deren Zweckbestimmung und den Ergebnissen der Risikoanalyse ab.

Normen

Um die o. g. Anforderungen nachzuweisen, bietet sich insbesondere die Anwendung einschlägiger Normen an. Wichtige Normen für medizinische Software sind:

• Risikomanagement (DIN EN ISO 14971:2020-07, Medizinprodukte – Anwendung des Risikomanagements auf Medizinprodukte)
• Qualitätsmanagement (DIN EN ISO 13485:2016-08, Medizinprodukte – Qualitätsmanagementsysteme – Anforderungen für regulatorische Zwecke)
• Software-Lebenszyklus (DIN EN 62304 VDE 0750-101:2016-10, Medizingeräte-Software: Software-Lebenszyklus-Prozesse). Im Fachbeitrag “Software Lebenszyklus bei Medizinprodukten: IEC 62304” erörtern wir, was Hersteller bei der Betrachtung des Software Lebenszyklus beachten müssen und wie Normen konkret dabei helfen.
• Gebrauchstauglichkeit (DIN EN 62366-1 VDE 0750-241-1:2021-08, Medizinprodukte Teil 1: Anwendung der Gebrauchstauglichkeit auf Medizinprodukte). Im Fachbeitrag “Usability Engineering für Medizinprodukte: IEC 62366” erläutern wir, warum Hersteller von Medizinprodukten verpflichtet sind, einen an der Gebrauchstauglichkeit orientierten Entwicklungsprozess durchzuführen (Usability Engineering).
• Klinische Prüfung (DIN EN ISO 14155:2012-01, Klinische Prüfung von Medizinprodukten an Menschen – Gute klinische Praxis)
• Sicherheit (Safety) (DIN EN 60601-1 VDE 0750-1:2013-12, 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. Software gilt regulatorisch ebenfalls als aktives Medizinprodukt. Die Norm spricht bei medizinischer Software von “Programmierbaren Elektrischen Medizinischen Systemen”, kurz “PEMS” und widmet diesen einen eigenen Abschnitt. Die 60601-1 setzt PEMS in direkten Bezug zum geforderten Risikomanagement-Prozess und fordert die Dokumentation eines Software-Lebenszyklus. In unserem Fachbeitrag zu “Elektrische Sicherheit bei aktiven Medizinprodukten: Die Norm IEC 60601-1” erfahren Sie weitere Details.

Derzeit gibt es keine “gesamthaften” Normen für IT-Security / Cybersecurity oder für Künstliche Intelligenz (KI). Dies ist misslich, denn beide Bereiche sind für Medizinproduktehersteller und -betreiber zu einem sehr wichtigen Thema geworden. Hinzu kommt, dass die MDR IT-Sicherheit ausdrücklich einfordert. Einen aktuellen Überblick zu den beiden Themen erhalten Sie hier:

• Cybersecurity-Risikomanagement für Medizinprodukte: ARGOS
• Effizienter Marktzugang für Künstliche Intelligenz (KI)-basierte Software: BAIM

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. Den Digitalen Gesundheitsanwendungen als medizinische Apps auf Rezept haben wir einen eigenen Fachbeitrag gewidmet.

Fazit

Der aktuelle MDCG-Leitfaden 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 der MDCG-Leitfaden 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.