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 durch die Software erfüllt wird.

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

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 Medizinprodukte-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 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 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 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 die Frage, welche Medical Device Software noch realistisch 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. Ein weiteres Problem bei Regel 11 ist, dass keine Risikobetrachtung enthalten ist. Es wird nicht betrachtet, mit welcher Wahrscheinlichkeit sich etwa Tod oder Verschlechterung des Gesundheitszustandes einstellen kann? Selbst die „harmloseste“ Software kann theoretisch den Tod zur Folge haben, wenn (extreme) unerwünschte Ereignisse eintreten. Bedauerlicherweise verstärkt 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 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: 

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

Fazit  

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 nur bedingt zur Vereinfachung bei.

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.

2 Kommentare zu “Medizinische Software und Medical Apps: Qualifizierung, Klassifizierung und Zulassung als Medizinprodukt

  1. Sehr geehrte Damen und Herren,

    Sie haben auf ihrer Seite (https://meso.vde.com/software-classification-guidance/#Our_Recommendations, inzwischen leider nicht mehr vorhanden) eine Aussage bezüglich “Software driving or influencing the use of a medical device” getätigt. Sinngemäß hies es dort, dass entsprechender Abschnitt aus dem MDCG-Dokument so zu interpretieren sei, dass selbst aus der Kombination von Steuergerät und Medizinprodukt ein medizinischer Zweck verfolgt werden müsse, damit die Steuer-Software entsprechend als “Software driving or influencing the use of a medical device” gelte. Wie lässt sich nun Ihre Aussage von oben “Steuersoftware unterstützt die medizinische Zweckbestimmung nicht unmittelbar, ist aber dennoch ein Medizinprodukt. ” interpretieren? Muss das Medizinprodukt, wenn die Softwaresteuerung angebunden ist, einen medizinischen Zweck verfolgen, damit die Steuerung als “Software driving or influencing the use of a medical device” gilt, oder könnte man die Zulassung nach MDR für die Softwaresteuerung umgehen, indem man eine medizinische Zweckverfolgung mit der Kombination aus Steuerung und Medizinprodukt untersagt?

    Vielen Dank für eine Antwort.
    MfG Markus Heimel

    1. Sehr geehrter Herr Heimel,
      Figure 1 von MDCG 2019-11 enthält einen Entscheidungsbaum zur Erörterung der Frage, um welche Art Software es sich handelt. Wird Frage 2 mit “ja” beantwortet, empfiehlt MDCG 2019-11 die Software als “Covered by the MDR”, d.h. es handelt sich um ein Medizinprodukt und muss die geltenden Anforderungen erfüllen.
      Viele Grüße
      Cord Schlötelburg

Kommentare sind geschlossen.