Die MDCG 2023-4 bietet einen wichtigen regulatorischen Rahmen für Medizinproduktesoftware (MDSW), die Hardware oder Hardwarekomponenten (die oft keine Medizinprodukte sind) benötigt, um bestimmungsgemäß verwendet zu werden. Wie sieht es aber mit MDSW aus, die auf allgemeine, nicht produktbezogene Software (Betriebssysteme, Browser etc.) angewiesen ist? Dieser Blog-Beitrag beleuchtet MDCG 2023-4 aus einer neuen Perspektive und erweitert dessen Kernprinzipien auf die Kombination von MDSW mit allgemeiner, nicht produktspezifischer Software.
Im Jahr 2021 führte ein Software-Update des Betriebssystems Android zu einer Fehlfunktion einer Insulinpumpe eines Herstellers, die ein ernsthaftes Risiko für die Patienten darstellte. Das Update änderte die Art und Weise, wie die Software für Medizinprodukte (MDSW oder Software as a Medical Device, SaMD) der mobilen Anwendung mit der Pumpe kommunizierte. Dadurch konnte das Insulin nicht rechtzeitig an die Patienten abgegeben werden. Das Problem wurde von Patienten entdeckt, die einen raschen Anstieg ihres Blutzuckerspiegels bemerkten, und schnell an den Hersteller weitergeleitet. Glücklicherweise war der Hersteller in der Lage, schnell einen Patch zur Behebung des Problems herauszugeben, bevor größerer Schaden entstand, aber der Vorfall hat die potenziellen Risiken aufgezeigt, die mit nicht produktbezogener Software von Drittanbietern für MDSW verbunden sind.
Anfang Oktober veröffentlichte die EU das Leitdokument MDCG 2023-4 zu MDSW, die in Kombination mit Hardware oder Hardwarekomponenten, einschließlich Smartphones und Smartwatches, verwendet werden. Das Dokument skizziert drei regulatorische Optionen für die Kombination von MDSW und Hardware, nämlich:
- Die Hardware wird als Zubehör zu einem Medizinprodukt in Verkehr gebracht.
- Die Hardware wird als Medizinprodukt in Verkehr gebracht, entweder als Teil eines Systems (MDR Art. 22), in Kombination mit einem anderen Medizinprodukt (MDR Art. 2(1)) oder als integraler Bestandteil eines Medizinprodukts.
- Die Hardware ist integraler Bestandteil eines Verbraucherprodukts und weder ein Medizinprodukt noch ein Zubehörteil und hat keine medizinische Zweckbestimmung.
Bei den Optionen 1 und 2 wird die Hardware als Zubehör zu einem Medizinprodukt oder als Medizinprodukt klassifiziert und muss daher die vollständige Konformität mit der MDR nachweisen. Bei Option 3 bleibt die Hardware ein allgemeines Konsumprodukt, aber der Hersteller des MDSW ist für die Sicherheit, Leistung und Reproduzierbarkeit der Hardware zur Unterstützung der vorgesehenen medizinischen Zweckbestimmung des MDSW verantwortlich, und die Kombination als System unterliegt der Konformitätsbewertung gemäß der MDR.
Obwohl der Schwerpunkt dieses Leitfadens auf MDSW-Hardware-Kombinationen liegt, kann davon ausgegangen werden, dass die gleichen Prinzipien auch auf Situationen angewendet werden können, in denen die Kombination mit anderer Software erfolgt, d. h. mit allgemeiner, nicht produktspezifischer Software. Beispiele hierfür sind Betriebssysteme oder Webbrowser. In der Praxis könnte es jedoch für einen MDSW-Hersteller nicht praktikabel sein, eine vollständige MDR-Konformität für allgemeine, nicht produktspezifische Software anzustreben. Daher scheint Option 3 die praktikabelste Lösung für Kombinationen von MDSW und nicht produktspezifischer Software in der realen Welt zu sein.
Relevante Konzepte aus der Leitlinie und deren Erweiterung auf allgemeine Software ohne Produktbezug (basierend auf Abschnitt 5, Option 3)
- Der Hersteller der MDSW ist für die Sicherheit, Leistung und Reproduzierbarkeit der gesamten nicht produktbezogenen Hardware zur Unterstützung der vorgesehenen medizinischen Zweckbestimmung der MDSW verantwortlich. Gleiches gilt für die nicht produktbezogene Software. Dies bedeutet, dass für jede nicht produktbezogene Software, auf der die MDSW basiert, ein angemessenes Risikomanagement, Leistungstests, Cybersicherheit und Nachmarktüberwachung im Kontext des MDSW-Systems sichergestellt werden müssen. Hersteller von MDSW können sich nicht von der regulatorischen Verantwortung für generische Software befreien, nur weil diese nicht produktbezogen ist.
- Risiken, die sich aus nicht produktbezogener Hardware und deren Interaktion mit der MDSW ergeben, sollten durch die Risikomanagementprozesse der MDSW abgedeckt werden. Dasselbe gilt für nicht produktbezogene Software. Softwareanomalien, Probleme mit der Benutzerfreundlichkeit, Cyber-Sicherheitslücken und Versionsänderungen der nicht produktbezogenen Software können alle Risiken für die MDSW darstellen. Der Hersteller muss ein proaktives Risikomanagement für das Gesamtsystem betreiben.
- Der Hersteller des MDSW muss klinische Nachweise für alle vorgesehenen Konfigurationen (z. B. alle Plattformen, auf denen das MDSW läuft) vorlegen. Dies gilt auch für Softwarekonfigurationen oder -plattformen.
- Die Überwachung nach dem Inverkehrbringen umfasst die Überwachung der Sicherheit und Leistung der nicht produktbezogenen Hardware. Gleiches gilt für die nicht produktbezogene Software in Verbindung mit der MDSW. Unerwünschte Ereignisse sind im Kontext des Gesamtsystems zu analysieren.
- Änderungen an der nicht produktbezogenen Hardware können die Sicherheit und Wirksamkeit der MDSW beeinträchtigen. Das Gleiche gilt für nicht produktbezogene Software. Nicht produktbezogene Software kann häufig aktualisiert werden, und jede Aktualisierung kann zu Sicherheits- und/oder Leistungsproblemen für die MDSW führen. Der Hersteller der MDSW benötigt Mechanismen, um über Änderungen auf dem Laufenden zu bleiben und deren Auswirkungen durch Regressionstests zeitnah zu bewerten.
Implikationen für Hersteller
- Verständnis des regulatorischen Status aller Software (sowohl Medizinprodukte- als auch Nicht-Medizinprodukte-Software) im MDSW-System, die die Sicherheit, Leistung, Reproduzierbarkeit, Interoperabilität und/oder Kompatibilität des MDSW beeinflussen kann. Erfassung aller Abhängigkeiten und klare Auflistung in der technischen Dokumentation.
- Sicherstellung der Rückverfolgbarkeit von Software, die kein Medizinprodukt ist und auf der die MDSW basiert. Zumindest die Versionsinformationen sind aufzuzeichnen.
- Einführung eines umfassenden Risikomanagements vor und nach dem Inverkehrbringen sowohl für MDSW als auch für Nicht-MDSW-Software. Ein systematischer Ansatz, der Risiken über Komponenten hinweg abdeckt. Nicht produktbezogene Software, die Teil des MDSW ist, muss unter Konfigurationskontrolle bleiben. Die Kontrollstrategie sollte auf dem Risiko basieren, das von der produktbezogenen Software im MDSW ausgeht, und bestimmen, ob der Hersteller die vollständige Kontrolle über die produktbezogene Software haben sollte.
- Für nicht produktbezogene Software, die zu Risiken führen kann, die gemäß dem Risikomanagementplan für das Produkt nicht akzeptabel sind, sollte der Hersteller die vollständige Kontrolle über die nicht produktbezogene Software in Betracht ziehen. Beispielsweise kann die MDSW mit einer dedizierten Hardwareplattform geliefert werden, die keine Änderungen an der nicht produktbezogenen Software ohne Zustimmung des Herstellers der MDSW zulässt.
- Bei nicht produktbezogener Software, die ein akzeptables Risiko darstellen kann, kann der Hersteller zulassen, dass die MDSW frei auf allgemeinen Hardware-Plattformen läuft, auf denen Benutzer die nicht produktbezogene Software ändern können. In diesem Fall sollte der Hersteller der MDSW jedoch ein Änderungsmanagement- und Benachrichtigungsverfahren mit den Anbietern der nicht produktbezogenen Software einrichten. Viele dieser Anbieter stellen Entwicklern Vorab-/Betaversionen zur Verfügung, bevor sie ein Update veröffentlichen. Der Hersteller sollte bevorstehende Updates genau beobachten und eine Regressionsanalyse/Tests mit der Betaversion durchführen, bevor das Update öffentlich veröffentlicht wird.
Natürlich gibt es auch andere Lösungen für die Konfigurationskontrolle von allgemeiner Software. Beispielsweise könnte in der MDSW eine Versionskontrolle für die allgemeine Software implementiert werden, die geeignete Maßnahmen ergreift, wenn eine nicht verifizierte Version auftritt. Die endgültige Wahl der Kontrollstrategie hängt von den Risiken und den Konstruktionsmerkmalen der MDSW und der betreffenden allgemeinen Software ab. Die Wahl kann auch durch die Einhaltung anderer geltender Vorschriften oder durch geschäftliche Gründe beeinflusst werden.
- Sammlung und Auswertung klinischer Daten zu geplanten Kombinationen von MDSW und Nicht-MDSW-Software.
- Aktive und systematische Überwachung und Auswertung von Informationen über Nicht-MDSW-Software im Rahmen der Überwachung nach dem Inverkehrbringen, insbesondere im Hinblick auf ihre kombinierte Verwendung mit MDSW.
Die Prinzipien der MDCG-Richtlinie, die sich auf Hardware konzentrieren, bieten auch einen guten regulatorischen Rahmen für MDSW in Kombination mit allgemeiner Software. Normen wie IEC 82304-1, IEC 82304-2 und IEC 81001-5-1 bieten praktische Anleitungen für die Umsetzung. Da Software im Gesundheitswesen immer mehr an Bedeutung gewinnt, wird eine ganzheitliche Betrachtung des gesamten digitalen Ökosystems, das den beabsichtigten Zweck eines MDSW unterstützt, immer wichtiger. Wie man in Spanien sagt: Zum Tango gehören zwei. Kennen Sie Ihren Partner, der kein Medizintechniker ist, gut, wenn es darum geht, mit Software für Medizinprodukte zu tanzen?
Haben Sie Fragen oder benötigen Sie Unterstützung bei der Prüfung allgemeiner Software in Kombination mit Ihrer MDSW? Dann kontaktieren Sie uns! Unsere Software- und Regulierungsexperten freuen sich darauf, gemeinsam mit Ihnen Ihren Anwendungsfall zu analysieren und eine praktische Strategie zu entwickeln, um die Sicherheit, Leistung und Konformität der allgemeinen Software im Ökosystem Ihrer MDSW zu gewährleisten.