Wissen - Life Sciences News - Topics - Downloads - Newsletter
Kontakt
Rob Stijlen
Rob Stijlen
Home | Newsletter | UPDATE 3 | 2018 | Software im Gesundheitswesen
24. Oktober 2018

Software im Gesundheitswesen Komplexes Medizinprodukt oder simples Hilfsmittel?

Mit Digitalisierung und Vernetzung im Gesundheitswesen verschwimmen Branchengrenzen: Technologie- und Versicherungsunternehmen bringen Software und Apps auf den Markt, die Patienten bei der Medikamenteneinnahme unterstützen, Hersteller von Medizinprodukten entwickeln Insulinpumpen, die softwaregesteuert Dosierungen anpassen, und Pharmaunternehmen nutzen Daten von mobilen Applikationen in klinischen Studien.

 

Medizinprodukte wie Arzneimittel unterstehen aber jeher einer besonderen Qualitätssicherung, denn es geht um nicht weniger als die Gesundheit der Konsumenten und Anwender. Die zentrale Frage lautet daher: Ab wann wird eine Software zu einem Medizinprodukt und welche gesetzlichen Rahmenbedingungen sind dann einzuhalten? Die Antwort darauf ist vielschichtig und anspruchsvoll.

 

Software als Medizinprodukt gemäss EU-MDR

Mit der neuen Europäischen Medizinprodukte-Verordnung 2017/745 (Medical Device Regulation, MDR), die seit Mai 2017 in Kraft ist, müssen Hersteller genauer hinschauen, ob bei ihren Produkten die neuen Anforderungen hinsichtlich mobiler Applikationen und anderer Software erfüllt werden. Sowohl die Definition als auch die Klassifizierung von Software als Medizinprodukt hat sich nicht nur verändert, sondern im Vergleich zu den Vorgängern, Richtlinien 90/385/EWG und 93/42/EWG, auch verschärft.

Definition „Medizinprodukt“

Die neue Verordnung beschreibt in Artikel 2, was unter einem Medizinprodukt zu verstehen ist, für wen und zu welchem Zweck es hergestellt wird (siehe Grafik).

Software im Gesundheitswesen als Medizinprodukt - Definition

Abbildung: Definition „Medizinprodukt“ (gekürzt, nach MDR); (mit Klick vergrössern)

 

Auch wenn eine Software im Gesundheitswesen keinen der obigen Zwecke alleine erfüllt, kann sie unter die Regulierung eines Medizinprodukts fallen, wenn sie als Zubehör gilt. Die MDR deklariert in Artikel 2 Absatz 2 dazu Gegenstände, für die der Hersteller festlegt, dass sie zusammen mit einem oder mehreren bestimmten Medizinprodukten verwendet werden, um die Funktionalität des eigentlichen Medizinprodukts und dessen Verwendung gemäss Zweckbestimmung zu ermöglichen oder gezielt zu unterstützen.

Die Einstufung der Software entweder als Medizinprodukt oder als Zubehör ist unabhängig vom Ort der Software und von der Art der Verbindung zwischen Software und einem Produkt.

 

Software im Gesundheitswesen als Medizinprodukt? Zweck entscheidet.

(mit Klick vergrössern)

 

Der Zweck entscheidet

Artikel 2 der MDR macht deutlich: Ob eine Software als Medizinprodukt zu behandeln ist oder nicht, hängt primär von der Zweckbestimmung ab. Dabei gilt es genau zu unterscheiden.

Nicht als Medizinprodukt zu behandeln ist Software, die für Zwecke im Bereich Lebensstil und Wohlbefinden eingesetzt wird, auch wenn der Einsatz in Einrichtungen des Gesundheitswesens stattfindet. Vom Hersteller darf dabei keine eindeutige Festlegung für einen oder mehrere medizinische Zwecke gemäss Definition vorliegen, damit gilt der Zweck als allgemein.

Die Grenzen bei der Zweckbestimmung können aber durchaus fliessend sein, wie das oben stehende Beispiel des „Fitness Trackers“ zeigt.


 

Klassifizierung von Software als Medizinprodukt (nach EU-MDR)

Liegen ein oder mehrere medizinische Zwecke vor, ist die Software unmissverständlich ein Medizinprodukt. Die Klassifizierung der Software wird über Regel 11 in der MDR festgelegt, und diese sorgt europaweit für Sprengstoff – denn ein Grossteil der Produkte ist höher zu klassifizieren als zuvor.

Im genauen Wortlaut besagt die Regel 11:

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

Durch die Regel 11 sind, anders als bei den Vorgängern, kaum mehr Produkte der Klasse 1 zuzuordnen, denn welche medizinische Software liefert keine Informationen, die in Therapie oder Diagnostik in die Entscheidungsfindung mit einfliessen? Aus Klasse I wird damit Minimum IIa. Ab Klasse II müssen Hersteller weitaus mehr Aufwand betreiben, um Produkte in Verkehr zu bringen. Unter anderem sind das Qualitätsmanagementsystem nach ISO 13485:2016 zu zertifizieren und die Konformitätsbewertung der benannten Stellen einzuholen. Herstellern ist zu empfehlen, ihr Portfolio anhand der neuen Klassen zu bewerten und Kosten-Nutzen-Abwägungen zu treffen.

 

Software im Gesundheitswesen als Medizinprodukt? Medizinprodukteklassen im Vergleich.Abbildung: Klassen im Vergleich MDD und MDR (mit Klick vergrössern)

 

FDA und Software als Medizinprodukt

Auch die US-amerikanische FDA (Food and Drug Administration), die für die Regulierung der Medizinprodukte im US-Markt zuständig ist, sieht die Zweckbestimmung als entscheidendes Kriterium bei der Bewertung von Software als Medizinprodukt

Als Orientierung und Hilfestellung für Hersteller hat die FDA einige konkrete Beispiele für Software, insbesondere mobile Applikationen, veröffentlicht. Dabei unterscheidet sie zwischen den folgenden Kategorien (siehe auch Tabelle unten):

  • Software, die definitiv kein Medizinprodukt ist
  • Software, bei der die FDA beabsichtigt, nach Ermessen die Gesetzgebung anzuwenden, und
  • Software, die als Medizinprodukt gilt

 

Software im Gesundheitswesen als Medizinprodukt - Softwareklassen Beispiel FDA

Abbildung: Kategorisierungsbeispiele FDA (mit Klick vergrössern)

 

Der Vergleich mit der EU-MDR  zeigt feine Unterschiede: Die FDA kategorisiert in die zweite Gruppe (Ermessensentscheide) auch alle Fitness- und Lifestyle-Apps, die gemäss EU-MDR nicht als Medizinprodukte anzusehen sind. Allerdings fehlt von der EU bislang jegliche weiterführende Orientierungsdokumentation, ebenso fehlen mit der jungen MDR noch praktische Erfahrungswerte.

 


 

Empfehlungen für Hersteller

Für Hersteller gilt, zum frühestmöglichen Zeitpunkt die Zweckbestimmung eines neuen Software-Produkts im Kontext der regulatorischen Auswirkungen festzulegen. Insbesondere Unternehmen, die nicht primär aus dem Medizinproduktbereich kommen, wie beispielsweise pharmazeutische Unternehmen, App-Entwickler oder auch Hersteller von Bildverarbeitungssoftware, riskieren ohne frühe Zweckprüfung einen späten Abbruch ihrer Projekte oder müssen Softwareprodukte vom Markt nehmen, da die regulatorischen Vorgaben auf Produkt- wie Organisationsebene nicht erfüllt sind. Fehlt intern Know-how oder besteht Unsicherheit bezüglich der Zweckbestimmung einer Software, ist die Einbindung von Experten mit der entsprechenden Erfahrung hilfreich, um im spezifischen Fall den besten Weg zu finden. Auch die frühe Einbindung von Behörden kann sinnvoll sein, wenn sich ein Produkt in der Grauzone zum Medizinprodukt befindet.

Nicht zu vergessen ist, dass auch für Software, die nicht unter die Medizinprodukte-Verordnung fällt, beim Einsatz im regulatorischen Umfeld einige Punkte zu beachten sind:

  • Die Formulierung der Zweckbestimmung (in der Regel in der Gebrauchsanleitung) darf keinen Hinweis auf einen diagnostischen oder therapeutischen Zweck beinhalten. Beispielsweise kann bei einer Dokumentationssoftware der Zweck der Speicherung medizinischer Daten aufgeführt sein, es muss aber klar formuliert sein, dass die Daten nicht verändert, analysiert oder neu aufbereitet werden. Ein Hinweis „nicht zur Befundung geeignet“ ist nicht ausreichend und macht aus einem Produkt mit medizinischer Funktionalität kein Nicht-Medizinprodukt.
  • Das Produkt selbst und der Entwicklungsprozess müssen gemäss Industriestandards (Good Documentation Practices) dokumentiert sein.

Für Software, die dediziert für die medizinische Zielgruppe und für den medizinischen Zweck entwickelt wird (Software as Medical Device), sollten bereits während der Entwicklung die Vorbereitungen für die Marktzulassung anlaufen.

Weitere Anforderungen sind u. a.:

  • ein sauber aufgesetztes Qualitätsmanagementsystem nach ISO 13485:2016

 

  • die Validierung der Software und Quali­fizierung der zugehörigen Hardware. Gerade bei Softwarevalidierung empfehlen wir einen agilen Ansatz. Dieser erlaubt hohe Flexibilität für Neuentwicklungen, Updates und Erweiterungen und stellt sicher, dass die Applikation über den gesamten Lifecycle hinweg compliant ist (siehe UPDATE 3 | 2017: Agile Validierung mobiler Applikationen)
  • Nachweise zur Validität und Zuverlässigkeit der Datengenerierung
  • Nachweise, dass ein sinnvoller Krankheitsparameter gemessen wird
  • Ausserdem muss das Produkt Geräte- und System-Interoperabilität sicherstellen und sensitiv genug sein, um Änderungen im Krankheitsverlauf zu messen. Weiter müssen die Benutzbarkeit und die Akzeptanz der Patienten oder Anwendergruppe nachgewiesen werden.

 

Chancen wahrnehmen

Unbestritten, die Entwicklung und Vermarktung von Software als Medizinprodukt geht einher mit nicht unwesentlichen Anforderungen an Prozesse, Dokumentation und Überwachung der Produkte im Markt. Gleichermassen schaffen die hohen Auflagen an Qualität und Sicherheit aber auch Markteintrittsbarrieren und damit Schutz für Unternehmen, die diese Hürden bereits genommen haben oder in Begriff sind zu nehmen.

Es ist davon auszugehen, dass sich der Medizinprodukt-Markt weiter konsolidiert und sich Produzenten, die zuvor die Gesundheitsbranche „mit bedient“ haben, zurückziehen. Das gibt etablierten wie neuen Playern die Chance, das Feld neu zu bespielen und sich Wettbewerbsvorteile zu sichern: durch ihre Spezialisierung auf die Branche und die transparente Erfüllung der regulatorischen Anforderungen, die den Kunden den Einsatz der Produkte leicht machen. Wichtig sind dabei die bewusste Entscheidung über die Entwicklung und Vermarktung einer Software als medizinisches Produkt und die kontinuierliche Bereitstellung von Ressourcen, um das Produkt über den gesamten Lebenszyklus hinweg optimal und gesetzeskonform zu unterstützen.

Lars Schmiedeberg, Sonja Fix

 


 

Das könnte Sie auch interessieren: