In einer Zeit, in der Technologie nahezu alle Aspekte unseres Lebens durchdringt, durchlebt auch der Gesundheitssektor einen bedeutenden Wandel. Die Digitalisierung des Gesundheitswesens ermöglicht es, neue Prozesse zu etablieren und eröffnet neue Behandlungsmethoden. Daher kommt auch zunehmend mehr Software zum Einsatz, die als eigenständiges Medizinprodukt eingeordnet wird. Dieser Blog-Artikel beleuchtet, warum es für Softwarehersteller so wichtig ist, zu wissen, ob Ihr Softwareprodukt ein Medizinprodukt ist oder nicht und worauf Sie bei der Entwicklung achten müssen.
Die Integration von Software in die Medizin hat nicht nur den Arbeitsablauf von Gesundheitsdienstleistern revolutioniert, sondern auch die Art und Weise, wie Patient:innen betreut werden. Von Diagnose- und Überwachungstools bis hin zu innovativen Behandlungsansätzen hat Software im und als Medizinprodukt das Potenzial, die Effizienz zu steigern und gleichzeitig die Qualität der Patient:innenversorgung zu verbessern.
In diesem Artikel werden wir die regulatorischen Anforderungen, Qualitätsstandards und die Rolle von medizinischer Software in der modernen Gesundheitsversorgung näher beleuchten. Wir werden auf die Herausforderungen eingehen, vor denen Unternehmen stehen, und die enormen Chancen, die sich durch die Entwicklung und Implementierung dieser Technologien eröffnen.
Ist eine medizinische Software immer automatisch ein Medizinprodukt?
Hinweis: In diesem Artikel beziehen wir uns hauptsächlich auf die geltende Regulierung in Europa.
In vielen Fällen ist die Qualifizierung als Medizinprodukt sehr einfach. Niemand wird auf die Idee kommen, eine Smartphone-App die mittels Kamera und schlauer Algorithmen Hautkrebs diagnostizieren kann nicht als Medizinprodukt anzusehen. Schwieriger ist der Weg andersrum. Wenn z.B. mittels der Sensoren im Smartphone oder der Smartwatch Vitalparameter wie Puls und Sauerstoffsättigung aufgezeichnet werden, ist der Weg zum Medizinprodukt nicht mehr weit. Das Problem dabei: wenn mein Produkt sich plötzlich als Medizinprodukt entpuppt, muss ich als Hersteller das Produkt für den jeweiligen Markt zulassen um es überhaupt verkaufen zu dürfen.
Grundsätzlich gilt: allein der Hersteller entscheidet
Der Hersteller selbst trifft die Entscheidung, ob es sich bei dem Produkt um ein Medizinprodukt handelt oder nicht. Ein Thermometer kann entweder dazu genutzt werden, die Raumtemperatur anzuzeigen oder um Fieber zu messen. Letzeres wäre ein Medizinprodukt, ersteres nicht.
Formal ausgedrückt: wenn die Zweckbestimmung des Herstellers der Definition eines Medizinproduktes entspricht, dann handelt es sich auch um ein Medizinprodukt.
Es entscheidet also die Zweckbestimmung und nicht unbedingt die Funktion der Software (ChatGPT ist auch kein Medizinprodukt, obwohl es auf Nachfrage wirklich tolle Diagnosen erstellt). Die Zweckbestimmung ist im übrigen nicht unbedingt ein Dokument mit dem Titel “Zweckbestimmung“, sondern umfasst die Angaben des Herstellers zur Verwendung des Produkts, die Gebrauchsanweisung und das Werbe- oder Verkaufsmaterial.
Was ein Medizinprodukt ist, das regelt in Europa die Verordnung (EU) 2017/745 über Medizinprodukte, auch Medizinprodukteverordnung oder kurz MDR genannt. Einfach ausgedrückt sind Medizinprodukte Dinge (auch Software) die den Zweck haben, Krankheiten oder Verletzungen zu diagnostizieren, zu überwachen oder zu therapieren.
Die exakte Definition findet sich in Art. 2 Abs. 1 der MDR. Weil die Qualifizierung selbst anhand dieser Definition immer noch nicht ganz einfach ist, gibt es Guidance Dokumente der Medical Device Coordiation Group (MDCG) die speziell den Fokus auf Software legen. In “MDCG 2019-11“ findet sich folgende Textstelle: „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 medical devices regulation […].“
Und als Ergänzung liefert die MDCG noch eine Infografik dazu.
Was bedeutet eigentlich „Software als Medizinprodukt“ und warum ist die Definition von medizinischen Softwareprodukten für Unternehmen so wichtig?
Bei der MDCG 2019-11 Abs 3.2 findet man dazu folgende Aussage: “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.“
Basierend auf dieser Definition gibt es im medizinischen Kontext vier Typen von Software:
- Software, die kein Medizinprodukt ist:
Beispiel: ein einfaches Kopfschmerztagebuch, welches lediglich Stift und Papier ersetzt und nur der eigenen Protokollierung dient. - Software als Teil eines Medizinprodukts, z.B. embedded Software eines Medizinprodukts; Software in a Medical Device (SiMD)
- Software als eigenständiges Medizinprodukt; Software as a Medical Device (SaMD)
- Software als Zubehör zu einem Medizinprodukt.
Anhand dieser Einordnung muss der Hersteller unterschiedliche Regulierungen beachten.
Kriterien für die Klassifizierung: Wie erfolgt die Einteilung von Software als Medizinprodukt?
Ein Produkt wird unter Berücksichtigung der Zweckbestimmung und der damit verbundenen Risiken in die Klassen I (niedriges Risiko), IIa, IIb und III (hohes Risiko) eingestuft. Die Klasse bestimmt den Umfang des Konformitätsbewertungsverfahrens, an dessen Ende das Medizinprodukt die CE-Kennzeichnung erhält und auf dem europäischen Markt verkauft und verwendet werden darf. Es erscheint nur logisch, dass ein Herzschrittmacher (Klasse III) mit mehr Sorgfalt geprüft wird als z.B. Verbandmaterial (Klasse I).
Die Klassifizierung erfolgt nach mehreren Regeln die im Anhang VIII der MDR zu finden sind. Für Software müssen unter Umständen mehrere Regeln angewendet werden:
Der einfachste Fall ist stand-alone Software (SaMD), die nach Regel 11 klassifiziert wird.
Handelt es sich um Software in einem Medizinprodukt (SiMD) müssen zwei Fälle unterschieden werden: 1. Software, die lediglich das Medizinprodukt steuert: in diesem Fall gilt die Klasse des Medizinprodukts. 2. Software die neben der Steuerung noch weitere Funktionalitäten enthält (z. B. Bildauswertung) muss nach Regel 11 klassifiziert werden. Ist die Klasse der Software höher als die Klasse des Medizinproduktes, muss die Klasse des Produktes auf die höhere Klasse hochgestuft werden.
Normen und Standards
Wenn klar ist, dass es sich bei der Software um ein Medizinprodukt handelt und anhand der Klasse klar ist, welche Regularien gelten, hat der Hersteller die Frage zu klären, wie diese Anforderungen umgesetzt werden können. In der MDR steht nur was getan werden muss, aber nicht wie. Z. B. fordert die MDR, bzgl. Usability: “Anzeigeeinrichtungen werden so ausgelegt […], dass sie […] ergonomischen Grundsätzen entsprechen.“ Wie dies zu erreichen ist, darüber schweigt sich die MDR aus. An dieser Stelle helfen Normen und Standards. Diese stellen den aktuellen und anerkannten Stand der Technik dar und beschreiben u.a. welche Aktivitäten durchgeführt und wie diese dokumentiert werden sollen.
Harmonisierte Normen
Im besten Fall handelt es sich bei den verwendeten Normen um sogenannte “harmonisierte Normen“. Bei harmonisierten Normen handelt es sich um Normen, die für eine geltende Regulierung, wie der MDR, passend sind oder durch einen ergänzenden Anhang passend gemacht wurden. Für den Hersteller gilt dann: hat er sich bei der Produktentwicklung an diese Norm gehalten, dann hat er auch die regulatorischen Anforderungen der MDR erfüllt.
Den aktuellen Stand der Harmonisierung gegen die MDR kann man auf den Webseiten der Europäischen Kommission einsehen. Gibt es eine harmonisierte Norm, sollte diese angewendet werden. Gibt es keine harmonisierte Norm, sollte die aktuelle Version der Norm angewendet werden (Übergangsfristen beachten!).
Relevante Normen und Standards für Medizinprodukte Software
Bei der Entwicklung von SiMD und SaMD spielen v.a. die folgenden Normen und Standards eine Rolle:
ISO 13485
Die ISO 13485 definiert die Anforderungen an ein Qualitätsmanagementsystem. Sie ist aus der ISO 9001 hervorgegangen und adressiert die besonderen Anforderungen für die Entwicklung und Herstellung von Medizinprodukten. Sie ist in der aktuellen europäischen Version DIN EN ISO 13485:2012-12 zur MDR harmonisiert. Ähnlich wie bei der ISO 9001 kann ein etabliertes Qualitätsmanagementsystem von einer Zertifizierungsstelle nach DIN EN ISO 13485 zertifiziert werden.
ISO 14971
Die ISO 14971 beschreibt die Anwendung des Risikomanagements auf Medizinprodukte. In ihrer aktuellen europäischen Version DIN EN ISO 14971:2022-04 ist sie zur MDR harmonisiert. Sie definiert einen Risikomanagementprozess der von der ersten Idee bis zum End-Of-Life des Produkts angewendet werden kann. Risikomanagement hört nie auf sondern ist ein stetiger Prozess.
IEC 62304
Die IEC 62304 beschreibt das Lebenszyklusmodell für Software und schließt neben der eigentlichen Entwicklung auch die Wartungsphase explizit mit ein. Die IEC 62304 wurde 2006 veröffentlicht, 2008 korrigiert und nur durch ein Amendment von 2015 ergänzt/überarbeitet. Eigentlich ist schon lange eine neue Revision geben, allerdings wurde der Entwurf der Version 2 Ende 2021 / Anfang 2022 als “gelöscht“ markiert. Das Normungsgremium will in 2024 die Arbeit an der 62304 wieder aufnehmen. Mit einer neuen Revision ist damit wohl frühestens 2025 zu rechnen.
IEC 62366
Die IEC 62366 beschreibt wie Usability Engineering bei Medizinprodukten angewendet werden soll. Die aktuelle Version von 2015 wurde 2016 korrigiert und 2020 durch ein Amendment ergänzt. Die Norm fokussiert sich auf die Minimierung von Risiken, die durch die Verwendung des Produktes entstehen können.
IEC 82304-1
Die IEC 82304-1 beschreibt allgemeine Anforderungen für die Produktsicherheit von Gesundheitssoftware. Sie füllt die Lücke, die bei der Anwendung der IEC 62304 in Verbindung mit Stand-Alone Software, also SaMD, bleibt. Die IEC 62304 adressiert zwar noch die Verifizierung des Softwaresystems, aber nicht mehr die Validierung. Die IEC 82304-1 gilt nicht nur für Medizinprodukte, sondern für jegliche Gesundheitssoftware, was z. B. auch Fitness-Apps mit einschließt.
AAMI TIR45
Der Technical Information Report (TIR) 45 der Association for the Advancement of Medical Information (AAMI) stellt einen Leitfaden zur Anwendung agiler Praktiken bei der Entwicklung von Medizinprodukte-Software dar. Der erstmals 2012 veröffentlichte TIR45 wurde zuletzt 2023 aktualisiert: AAMI TIR45:2023. Auch wenn die IEC 62304 stark dem V-Modell ähnelt, beschreibt der TIR45, dass eine agile Softwareentwicklung konform zu den regulatorischen Anforderungen für Medizinprodukte möglich ist.
Europäische und internationale Informationsquellen zur Regulierung von Medizintechnik
MDCG
Die Medical Device Coordination Group (deutsch Koordinierungsgruppe Medizinprodukte) – kurz MDCG – ist ein von der MDR gefordertes Expertengremium und setzt sich aus Vertretern der EU-Mitgliedstaaten zusammen. Seit der Veröffentlichung der MDR war das Gremium sehr fleißig und hat eine Vielzahl von Guidance-Dokumenten publiziert.
Zum Thema Qualifizierung und Klassifizierung finden sich z.B. folgende Dokumente:
- MDCG 2019-11: Qualification and classification of software – Regulation (EU) 2017/745 and Regulation (EU) 2017/746
- Manual on borderline and classification under Regulations (EU) 2017/745 and 2017/746
FDA
In den USA ist die Food and Drug Administration (FDA) für die Zulassung von Medizinprodukten zuständig. Die FDA hat über 600 Guidance Dokumente veröffentlicht, die alle frei zugänglich sind. Selbst wenn der amerikanische Markt uninteressant sein sollte, die Guidance Dokumente sind einen Blick wert.
IMDRF
Das Internation Medical Device Regulations Forum (IMDRF) ist aus der Global Harmonization Task Force (GHTF) hervorgegangen. Zu den Mitgliedern zählen: Australien, Brasilien, Kanada, China, die EU, Japan, Russland, Singapur, Großbritannien, Korea und die USA. Das Ziel des IMDRF ist die Konvergenz der regionalen Regulierungen voranzutreiben, damit Medizinprodukte leichter auf einem weltweiten Markt zugelassen und eingesetzt werden können. Auch das IMDRF veröffentlich regelmäßig Dokumente für Hersteller von Medizinprodukten, wie z.B. Software as a Medical Device (SaMD): Key Definitions.
Software Medizinprodukte (SaMD), die konform zur MDR auf dem europäischen Markt verfügbar sind
Medical Device Klasse I
Vivira: DiGA der Vivira Health Lab GmbH zur Behandlung von Rückenschmerzen.
Medical Device Klasse IIa
ECG Monitor: Software zur Aufzeichnung von 1-Kanal-Elektrokardiogrammen der Firma Withings mit Erkennung von Hinweisen auf Vorhofflimmern.
Medical Device Klasse IIb
mdbrain: KI-gestützte MRT Befundungssoftware für die Neuroradiologie der mediaire GmbH.
Medical Device Klasse III
aktuell (Feb. 2024) ist keine Software Klasse III in der Eudamed Datenbank gelistet.
Medizinische Software, die kein Medizinprodukt sind
Im Anhang I von MDCG 2019-11 finden sich einige Beispiele von medizinischer Software, die kein Medizinprodukt darstellen:
- Krankenhausinformationssysteme
- Entscheidungsunterstützungssysteme
- Elektronische Patientenakte
- Picture Archive Communication System (PACS)
- Telemedizinsysteme
- uvm.
Sonderfall ChatGPT
Ein Anwalt hat in einem offenen Brief an das BfArM gefordert, dass ChatGPT als Medizinprodukt angesehen und entsprechend reguliert gehört. Und ja, natürlich kann man ChatGPT mit Symptomen (Fieber, Halsschmerzen, laufende Nase) füttern und ChatGPT wird sich dazu hinreißen lassen zu äußern, dass die Symptome auf eine Erkältung oder eine Grippe hinweisen. Sogar den Hinweis, man könnte z. B. fiebersenkende Medikamente nehmen, bekommt man als Antwort. Und ja, das könnte man für eine Therapieempfehlung halten. Gleichzeitig steht in den Nutzungsbedingungen von ChatGPT: “You must not use any Output relating to a person for any purpose that could have a legal or material impact on that person, such as making […] medical […] decisions about them.“. Da nicht die Funktion der Software relevant ist für die Qualifizierung als Medizinprodukt, sondern die Zweckbestimmung gemäß dem Hersteller, kann ich die Argumentation der Anwaltskanzlei nicht nachvollziehen.
