App or Software Development
Olivier Le Moal / stock.adobe.com
01.11.2019 283 0

Software 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 nicht unerhebliche 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.  

In diesem Beitrag geben wir Antworten auf folgende Fragen.

  • Welche rechtlichen Grundlagen gibt es?
  • Wann ist Software ein Medizinprodukt?
  • Wie wird Medizinprodukte-Software klassifiziert?
  • Welche Bedeutung hat die Regel 11 der MDR?


Welche rechtlichen Grundlagen gibt es?

Wollen Hersteller ein (Software-)Medizinprodukt in Europa vermarkten, müssen sie die Medizinprodukteverordnung 2017/745 (MDR) oder die In-Vitro-Diagnostika-Verordnung 2017/746 (IVDR) befolgen. Beide Verordnungen sind am 25. Mai 2017 in Kraft getreten. Gegenwärtig gelten auch noch die „alten“ EU-Richtlinien. Der Übergangszeitraum endet aber am 25. Mai 2020, so dass es allerhöchste Zeit ist, sich mit den neuen Regeln vertraut zu machen.

Wer „Praktiker“ ist und sich mit der MDR bzw. der IVDR befasst, wird schnell enttäuscht sein. Im Gegensatz zu den alten EU-Richtlinien regeln MDR und IVDR zwar erheblich mehr, aber 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.

Diese Ungenauigkeiten haben zur Folge, dass die einschlägigen Fachkreise derzeit um Begriffsbestimmungen, Definitionen und Abgrenzungen ringen. Die Situation für Hersteller von Software wird dadurch nicht einfacher. Wünschenswert wären natürlich möglichst einheitliche und verbindliche Regeln. Dafür setzen wir uns ein. Im Mittelpunkt der gegenwärtigen Diskussion stehen vor allem ein aktueller Leitfaden „MDCG 2019-11“ und die „Regel 11“ der MDR.


Wann ist Software ein Medizinprodukt?

Bis zum Erscheinungsdatum von MDCG 2019-11 wurde Software „mit Bezug zu Gesundheit“ im Allgemeinen in 4 Gruppen unterteilt:

  1. Die Software ist kein Medizinprodukt. Ein Beispiel ist eine Fitness-App („Health-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 App, die auf einem Smartphone läuft.

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)“ für Gruppe 4. 

Kontakt

Dr. Cord Schlötelburg
Downloads + Links

Mit Erscheinen von MDCG 2019-11 wird nun ein neuer Begriff eingeführt, 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.

Dies lässt sich stark vereinfacht aber erheblich besser lesbar wie folgt interpretieren:

Medizinprodukte-Software ist Software, die der Prävention, Diagnose oder Therapie von Erkrankungen dient.

Die MDCG-Definition stellt also alleinig den Einsatzzweck der Software in den Mittelpunkt. Ist dieser deckungsgleich mit den entsprechenden detaillierten Formulierungen in der MDR bzw. IVDR handelt es sich um ein Medizinprodukt. 

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. Steuersoftware kann auch Zubehör eines Medizingerätes sein.

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


Wie wird Medizinprodukte-Software klassifiziert?

Je nachdem, ob ihre Software Medizinprodukte-Software, Steuer-Software oder möglicherweise beides ist, müssen Sie unterschiedliche Klassifizierungsregeln der MDR bzw. IVDR anwenden. Mit Hilfe der Klassifizierungsregeln bestimmen Sie die Risikoklasse der Software. Je höher die Risikoklasse, desto höher der Aufwand des CE-Zertifizierungsprozesses.

In den vermutlich allermeisten Fällen wird gelten:

Handelt es sich bei einer Software um eine „Medical Device Software“ und diese ist geräteunabhängig, muss der Hersteller diese „als solche“ klassifizieren.

In diesem Fall gilt die Regel 11 der MDR. Dazu unten mehr.

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 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 Software hat. Es sei an dieser Stelle auch noch einmal darauf hingewiesen, dass der Hersteller selbst 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.


Welche Bedeutung hat die Regel 11 der MDR?

In den (alten) EU-Richtlinien zu Medizinprodukten finden sich keine ausdrücklichen Klassifizierungsregelungen für Software. Um den besonderen Eigenschaften und Risiken von 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. Die Regel 11 ist daher aus Herstellerperspektive ziemlich heftig:

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

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 sicher keine Aussichten auf eine spätere Erstattung durch die Gesetzliche Krankenversicherung, da ein diagnostischer oder therapeutischer Nutzen ja quasi ausgeschlossen wäre. Der Hersteller sollte also sein Geschäftsmodell entsprechend anpassen.

Wir müssen also davon ausgehen, dass ein Großteil der existierenden Software höher klassifiziert werden muss. Damit einher gehen die bekannten und erheblichen Mehraufwände in Sachen Qualitätsmanagement, Einbeziehung Benannter Stellen usw.

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 IMDRF aus dem Jahr 2014 zu übernehmen ("Software as a Medical Device": Possible Framework for Risk Categorization and Corresponding Considerations“). Diese 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.  


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. Diese ist in ihrer jetzigen Form eine echte Innovationsbremse und muss geändert werden. 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".

Wir gehen davon aus, dass auf EU Ebene an dieser Stelle nachgebessert wird und unterstützen diesen Prozess gerne. Wir empfehlen Ihnen, sich dazu an dieser Stelle informiert zu halten oder in unserer Fach-Community mitzudiskutieren und Ihren Standpunkt und Ihre Erfahrungen einzubringen.

VDE Medical Software 2020

VDE-Illustration zum Thema Health
VDE

13. Mai 2020, Frankfurt am Main

Die Klassifizierung Medizinischer Software und die Erfüllung der vorgegebenen Anforderungen sind schwierig. Profitieren Sie von Expertenwissen und tauschen Sie sich mit anderen Experten aus. Oder holen Sie sich einen erfahrenen Dienstleister ins Haus, der Sie unterstützt. All diese Möglichkeiten haben Sie auf der VDE Medical Software 2020. 

Mehr erfahren