Klassifizierung von Software als Medizinprodukt in der EU

Wie in vielen anderen Branchen ist Software zu einem integralen Bestandteil der Medizinprodukteindustrie geworden - bezeichnet als Software als Medizinprodukt (SaMD) oder medizinische Software (MDSW). Während sich die vergangenen Jahre und Jahrzehnte hauptsächlich auf Firmware und Schnittstellenlösungen konzentrierten, ist medizinische Software (MDSW) heute allgegenwärtig. Technologisch gesehen sind mobile Anwendungen, AR/VR-Lösungen und durch maschinelles Lernen unterstützte Medizinprodukte nur einige Beispiele dieses wachsenden Bereichs. Fast jedes moderne Medizinprodukt integriert auf irgendeine Weise Software, abgesehen von rein mechanischen Werkzeugen wie Skalpellen und Verbänden.

Der technologische Fortschritt stellt Hersteller von Medizinprodukten in der EU (oder solche, die in den EU-Markt eintreten möchten) vor besondere Herausforderungen. In fast jedem Land ist Software als Medizinprodukt (SaMD) reguliert, jedoch sehen sich europäische Hersteller seit der Einführung der Medizinprodukteverordnung 2017/745 (MDR) vor besonders hohe Anforderungen gestellt.

Man muss auch sagen, dass viele Gerüchte und Mythen rund um MDSW und die MDR entstanden sind. Dieser Artikel will dazu beitragen, die Fakten von den Mythen zu trennen. Obwohl es komplizierter geworden ist, MDSW zu zertifizieren, haben bereits mehrere Hersteller ihre Zertifikate erhalten und somit bewiesen, dass es zwar schwierig sein mag, aber möglich ist.

Welche Hauptherausforderungen gibt es bei MDSW und der MDR im Zusammenhang mit Software als Medizinprodukt (SaMD)?

Bei der Arbeit mit einer neuen oder bestehenden MDSW stehen Hersteller hauptsächlich vor zwei Arten von Herausforderungen.

Die erste Herausforderung besteht darin, zu entscheiden, ob eine bestimmte Software überhaupt in den Anwendungsbereich der MDR fällt oder nicht. Für bestimmte Fälle, wie Diagnose-Software oder mobile Anwendungen, die therapeutische Entscheidungen treffen, ist die Antwort klar. Aber wie steht es mit medizinischen Datenbanken zur Suche oder medizinischen Berechnungen? Die Medical Device Coordination Group (MDCG) hat eine Infografik und auch einen Leitfaden zu diesem Thema bereitgestellt.

Obwohl diese einige Klarstellungen bieten (wie z.B., dass einfacher Datentransfer und -suche eine Software nicht automatisch zu MDSW machen), ist es immer noch notwendig, jeden Einzelfall zu überprüfen.

In der EU erfolgt die Einordnung von Software als MDSW nicht durch ihr allgemeines Risiko, sondern durch spezifische Kriterien wie Symptome, Krankheiten und Schlüsselwörter, die im MDR Artikel 2 Abschnitt 1 festgelegt sind. Dies steht im Gegensatz zum US-Ansatz, bei dem bestimmte Softwarelösungen mit geringem Risiko als Wellnessgeräte und nicht als Software als Medizinprodukt (SaMD) klassifiziert werden.

Die zweite Herausforderung ist die Klassifizierung selbst. Unter der früheren Medizinprodukterichtlinie (MDD) wurden die meisten MDSW als Klasse I-Geräte eingestuft. Dies hatte mehrere Vorteile: Kein Bedarf an einer Benannten Stelle, deutlich schnellere Markteinführungszeiten, keine Notwendigkeit für ein Qualitätsmanagementsystem nach ISO 13485 usw.

Die Umsetzung der MDR bedeutet, dass viele zuvor als Klasse I eingestufte Produkte in die Kategorien IIa oder höher eingeordnet werden müssen, was eine umfassendere klinische Bewertung und Qualitätsmanagementsysteme selbst für Klasse I-Hersteller erforderlich macht. Aber diese Veränderung ist machbar. Trotz einiger Bedenken und Missverständnisse – wie der übertriebenen Behauptung, dass Hersteller von mobilen Apps jedes Smartphone und Betriebssystem einzeln zertifizieren müssen oder dass die Erreichung des Status Klasse I MDSW nun unmöglich sei – passt sich die Branche an und findet Wege zur erfolgreichen Zertifizierung nach den neuen Vorschriften.

Stimmen die Gerüchte über die Klassifizierung von Software als Medizinprodukt (SaMD)?

Wie bei jedem Mythos und Gerücht gibt es wahre und erfundene Anteile. Es ist definitiv wahr, dass die meisten MDSW in einer höheren Klasse als zuvor nach MDD neu klassifiziert werden müssen. Viele Hersteller der Klasse I müssen jetzt Zertifizierungsverfahren bei Benannten Stellen beantragen. Dies ist auch teilweise der Grund, warum es derzeit Engpässe bei Benannten Stellen gibt. Der Hauptgrund dafür ist Regel 11 von Anhang VIII der MDR.

Daher trifft es tatsöchlich zu, dass die meisten harmlosen und moderat riskanten MDSW ein Konformitätsbewertungsverfahren mit einer Benannten Stelle durchlaufen müssen, da es nicht möglich sein wird, in Klasse I zu verbleiben.

Andererseits kann zwar die Zertifizierung von Klasse IIa oder höher länger dauern und mehr Ressourcen erfordern, aber sie ist bei weitem nicht unmöglich. Benannte Stellen haben sich vor der MDR bereits mit MDSW befasst, sodass viele von ihnen mit den meisten Lösungen umgehen können (KI könnte eine besondere Herausforderung darstellen). Gleichzeitig haben sich die grundlegenden Anforderungen für MDSW nicht geändert. Standards wie ISO 14971 (Risikomanagement), IEC 62304 (Software als Medizinprodukt (SaMD) -Prozesse) und IEC 62366-1 (Benutzerfreundlichkeit) gelten weiterhin. Im Fall der IEC 62304 ist die aktuell akzeptierte Version immer noch die von 2005 (mit Änderungen), daher könnte es eine Herausforderung sein, die teilweise veralteten Anforderungen mit modernen Tools wie JIRA zu kombinieren.

Was besagt Regel 11 der MDR genau?

Wahrscheinlich die gefürchtetste Klassifizierungsregel im MDR-Rahmen ist definitiv Regel 11. Diese neue Regel ist explizit der Software gewidmet, so etwas gab es nicht in der vorherigen MDD.

Zunächst muss man sagen, dass diese Regel auf alle Arten von Software mit medizinischem Anspruch anwendbar ist. Es spielt keine Rolle, ob es sich um eine Webanwendung, eine mobile App, eine Firmware oder eine Hardware + Software-Kombination handelt. Wenn die Software Teil eines Medizinprodukts oder selbst ein Medizinprodukt ist, gilt diese Regel.

Regel 11 adressiert im wesentlichen zwei Themen, und man muss die Regel mehrmals lesen, bevor man enschreiden kann, welche Klasse anwendbar sein könnte.

Der erste Teil behandelt auf "Software, die dazu bestimmt ist, Informationen bereitzustellen, die zur Entscheidungsfindung für diagnostische oder therapeutische Zwecke verwendet werden". Bei der Lektüre dieses Teils könnte die Frage auftauchen: "Werden nicht die meisten MDSW zur Unterstützung von Diagnose oder Behandlung verwendet?". Die Antwort ist ja, und daher ist dieser Teil hauptsächlich für eine höhere Klassifizierung verantwortlich. Es spielt keine Rolle, ob das MDSW eine Diagnose alleine erstellt oder ob es unterstützende Daten für Ärzte bereitstellt, die dann eine Diagnose erstellen. Wenn die Zweckbestimmung solche Ansprüche enthält, wird das MDSW mindestens Klasse IIa sein. Wenn der Patient potentiell mit kritischen oder lebensbedrohlichen Schäden bedroht ist, verlangt Regel 11 sogar Klasse IIb oder Klasse III.

Der zweite Teil behandelt auf "Software, die dazu bestimmt ist, physiologische Prozesse zu überwachen" und stuft solche MDSW als Klasse IIa ein. In bestimmten Fällen, wie der Überwachung lebenswichtiger physiologischer Parameter, bei denen Veränderungen sofortige Gefährdung des Patienten verursachen könnten, wird sogar Klasse IIb angewendet.

Die größte Problem ist, dass weder “physiologische Prozesse” noch “lebenswichtige physiologische Parameter” innerhalb der MDR angemessen definiert sind. Dies führt zu einer großen Debatte, und es gibt oft zwei Fraktionen: Fraktion eins erklärt, dass alles, was der menschliche Körper tut, ein physiologischer Prozess ist, und dies geht weit über Herzfrequenz, Blutdruck usw. hinaus. Die andere Fraktion behauptet, dass eine Unterscheidung vorgenommen werden muss. Zum Beispiel, was ist mit dem menschlichen Tremor, der durch Parkinson verursacht wird? Während ein physiologischer Tremor als physiologischer Prozess angesehen werden könnte, was ist mit pathologischem Tremor? Ist es immer noch ein physiologischer Prozess oder die Wirkung physiologischer Prozesse?

Ist Software der Klasse I (Software als Medizinprodukt (SaMD)) überhaupt möglich?

Nach der Interpretation von Regel 11 stellt sich die Frage, ob Software der Klasse I (SaMD) im Rahmen der MDR überhaupt möglich ist. Die kurze Antwort lautet: Ja. Ein erstes Anzeichen dafür findet sich in der Leitlinie der MDCG zur Klassifizierung von Medizinprodukten, in der die Autoren einen Fruchtbarkeitsmonitor als Beispiel für eine Klasse-I-Software verwenden. Darüber hinaus enthält Artikel 2 Abschnitt 1 zusätzliche Schlüsselwörter wie Prognose, Prävention und Vorhersage, die zu einer niedrigeren Klassifizierung führen könnten.

Die Hauptfrage hier ist, ob eine MDSW mit harmlosen Ansprüchen und Klasse I überhaupt relevante Vorteile für Patienten bieten kann. Auch hier lautet die Antwort ja. Allein durch das Beispiel Deutschlands und des DiGA-Ansatzes enthält deren Liste der akzeptierten Technologien mehrere Beispiele für Klasse I MDSW nach MDR.

Es wird jedoch nicht empfohlen, Ansprüche künstlich zu reduzieren, nur um die zusätzlichen Herausforderungen höherer Klassen zu vermeiden. Eine MDSW muss immer nachweisen, dass der klinische Nutzen gegeben ist und mögliche Risiken überwiegt. Wenn es keinen echten Nutzen gibt, macht ein Markteintritt wenig Sinn.

Was sind die größten Herausforderungen in den Produktklassen IIa und höher?

Wenn sich herausstellt, dass Klasse IIa oder höher für das Produkt angemessen ist, sehen sich Hersteller den folgenden Herausforderungen gegenüber:

• Die Notwendigkeit zur Zusammenarbeit mit einer Benannten Stelle

• Wartezeiten von mehreren Monaten und manchmal über einem Jahr, um die Zertifizierung zu erhalten

• Die Notwendigkeit, eine Benannte Stelle zu finden, die bereit ist, sich mit moderner Software zu befassen

• Wahrscheinlich die Zertifizierung des Qualitätsmanagementsystems (QMS)

• Jährliche Überwachungsaudits

• Andere Aspekte wie klinische Bewertung und Einführung eines QMS bleiben unbeachtet, da sie für alle Hersteller gelten, unabhängig von der Produktklasse.

6 Top-Tipps und Hacks für einen optimalen Umgang mit Software als Medizinprodukt (SaMD)

Zwar kann man die MDR und ihre Anforderungen nicht umgehen, aber es gibt Abkürzungen und Optimierungen, um die Time-to-Market zu reduzieren. Hier sind einige Empfehlungen dafür:

1. Prüfen Sie, ob Ihre Software in den Anwendungsbereich der MDR fällt. Eine detaillierte Dokumentation der Zweckbestimmung ist die Grundlage für jede Abgrenzung. Was ist, wenn Sie zu dem Schluss kommen, dass Sie eine Klasse IIb MDSW haben, während die MDR für dieses Produkt überhaupt nicht gilt?

2. Versuchen Sie, das MDSW nach Möglichkeit in medizinische und nichtmedizinische Module aufzuteilen. Die MDR gilt nur für die Teile der Software, die zur medizinischen Zweckbestimmung gehören. Dies ist nicht immer möglich, aber in einer größeren Softwarelösung kann eine Aufteilung Kosten und Zeitaufwand erheblich reduzieren.

3. Im Zweifelsfall lassen Sie die Klassifizierung von Beratern, Anwälten und zuständigen Behörden überprüfen. Insbesondere zuständige Behörden können eine rechtlich bindende Erklärung zur Klasse des MDSW abgeben, was mehr Klarheit bieten kann. Die Entscheidung ist jedoch endgültig, und wenn das Ergebnis nicht der erwarteten Klasse entspricht, wird es nicht möglich sein, andere Klassen zu argumentieren.

4. Wählen Sie die Benannte Stelle für Ihre Produktzertifizierung sorgfältig aus. Die Auditoren und Produktprüfer müssen gute Erfahrungen und Kenntnisse im Umgang mit MDSW haben, damit keine unnötigen Diskussionen entstehen. Sie haben die Wahl, daher ist es wichtig, sich an mehrere Benannte Stellen zu wenden.

5. Seien Sie vorsichtig mit agiler Entwicklung und Änderung von Anforderungen. Ein einzelnes neues Erfordernis könnte Ihr MDSW in eine noch höhere Klasse umklassifizieren. Daher ist es notwendig, jeden neuen Wunsch oder jede Anforderung sorgfältig während der Entwicklung zu analysieren.

6. Überprüfen Sie die Anleitung zu Grenzfällen bezüglich der MDR. Die Menge der MDSW-Beispiele ist noch begrenzt, aber sie können Orientierung bieten. Überprüfen Sie auch den EU-Markt nach ähnlichen Geräten und analysieren Sie deren Klassifizierungen, um einen Benchmark zu haben.

Zusammenfassung und Schlussfolgerungen

Es ist klar, dass die neuen Anforderungen, die durch die MDR implementiert wurden, vielen MDSW-Herstellern Kopfschmerzen bereiten. Die höheren Risikoklassen, die erhöhte Anzahl regulatorischer Anforderungen und auch die rechtliche Unsicherheit aufgrund des Mangels an ausreichend Präzedenzfällen sorgen für Unklarheiten.

Dennoch ist es immer noch möglich, MDSW auf den EU-Markt zu bringen, und dass dies der zweitgrößte MedTech-Markt der Welt ist, fördert die Motivation, sich den zusätzlichen Anforderungen zu stellen.

Die wichtigste Anforderung (wie bei jedem anderen regulatorischen Aspekt) besteht darin, den größten Teil der verfügbaren Zeit in die anfängliche Analyse und Interpretation zu investieren. Ein früher Fehler zu Beginn verursacht 10X oder sogar 100X Kosten in der Entwicklungsphase. Eine zielgerichtete Planung spart Zeit und Ressourcen.

Matrix Requirements GmbH ist ein weltweit führendes Softwareunternehmen, das innovativen Medizinprodukteunternehmen hilft, sich auf die Entwicklung sicherer Produkte zu konzentrieren. Das MatrixQMS (QMS) Qualitätsmanagementsystem reduziert die regulatorische Belastung, indem es die Kluft zwischen agilen und Compliance-Teams überbrückt, um Qualität über den gesamten Produktlebenszyklus sicherzustellen. Wir sind auch sehr stolz darauf, nach EN ISO 13485 und ISO/IEC 27001 zertifiziert zu sein.

Unsere über 200 Kunden, MedTech-Führer wie Medtronic, GE Healthcare, Stryker, Roche Diagnostics und B.Braun sowie Startups und Scale-ups wie Proscia, Element Biosciences, Clue, MindMaze und Diabeloop, sparen Zeit bei der Dokumentation von Produktentwicklungs- und Qualitätsprozessen mit unserer intuitiven Plattform. Matrix Requirements wurde 2015 von Medizinprodukteentwicklern gegründet und hat ein Team von 40 Mitarbeitern, die in Deutschland, den USA, Frankreich, Großbritannien, Belgien und Spanien verteilt sind.

Über den Autor:

Tibor Zechmeister ist Unternehmer im Bereich Medizinprodukte mit über einem Jahrzehnt Erfahrung. Er hat sich auf regulatorische Compliance und Qualitätsmanagementsysteme spezialisiert. Als externer Auditor und Gründer im HealthTech-Bereich kann er Startups und etablierte Unternehmen geschickt durch die Komplexität europäischer Vorschriften wie der MDR 2017/745 führen und so ihren erfolgreichen Markteintritt und verbesserte Patientenergebnisse gewährleisten.