Einreichungen vor der Markteinführung von Softwarefunktionen für Produkte – Entschlüsseln Sie den Entwurf der Leitlinien der US FDA

Mit der Entwicklung der Technologie ist die Gesundheitsbranche bestrebt, Software in Medizinprodukte zu integrieren, um Automatisierung und Genauigkeit bei der Vorhersage, Diagnose, Prävention, Behandlung und dem Management von Gesundheitszuständen zu integrieren. Die US FDA hatte die Rolle, die Software spielen kann, um die Funktionsweise von Medizinprodukten zu verbessern, lange erkannt, hatte aber noch keine konkreten Leitlinien oder Regeln vorgelegt, die den Forschern der Branche Fortschritte im Bereich der digitalen Gesundheit ermöglicht hätten.

Am 4. November 2021 veröffentlichte die US FDA einen Leitlinienentwurf zum Thema „Inhalt von Prämarkt-Einreichungen für Gerätesoftwarefunktionen“, der Sponsoren, die für die Erstellung des Dokuments verantwortlich sind, eine klare Vorstellung davon vermittelt, welche Informationen enthalten sein müssen. Diese von den Sponsoren bereitgestellten Informationen sind für die FDA wichtig, um die Gerätesoftware, die eine oder mehrere Funktionen ausführt, zu bewerten und die Sicherheit und Wirksamkeit über ihren gesamten Lebenszyklus hinweg zu gewährleisten. Die neue Leitlinie ist eine Empfehlung und ein Entwurf zu Medizinprodukt-Softwarefunktionen, die die FDA als Ersatz für das 15 Jahre alte Leitliniendokument „Guidance for the content of pre-market submission for the software contained in Medical device“ vom Mai 2005 zu veröffentlichen zugesagt hat. Das Zeitfenster für Rückmeldungen und Diskussionen dazu ist bis zum 2. Februar 2022 geöffnet.

In dieser neuen Version hat die FDA die Art der Verbindung von Software mit einem Medizinprodukt anerkannt und sie weiter in SaMD – Software als Medizinprodukt und SiMD – Software in einem Medizinprodukt – als Unterkategorien von Softwarefunktionen für Geräte unterteilt. Software als Medizinprodukt oder SaMD ist eine Software, die selbst eine Aufgabe eines Medizinprodukts gemäß der Definition des Medizinprodukts in Abschnitt 201 (h) des FD&C Act ausführt, aber kein Bestandteil des Geräts ist. Andererseits ist Software in SiMD, wie der Name schon sagt, Teil der Medizinproduktkomponente oder Hardware, die zur Aufzeichnung, Steuerung oder Anzeige medizinischer oder nicht-medizinischer Informationen verwendet wird.

Der Entwurf konzentriert sich stärker auf die Erwartungen der FDA hinsichtlich der Dokumentenerstellung, die für die präklinische Einreichung von Softwarefunktionen für Geräte erforderlich ist. Sie haben ein klares Verständnis dafür entwickelt, was sie in den Dokumenten erwarten, die die Software Requirements Specification (SRS) und die Software- oder System Design Specifications (SDS) robust etablieren. Die FDA betont einen risikobasierten Ansatz bei der Dokumentation für die präklinische Einreichung von Softwarefunktionen für Geräte. Basierend auf diesem Grad der Besorgnis oder dem mit der beabsichtigten Verwendung des Geräts verbundenen Risiko soll auch der Umfang der Dokumentation als grundlegende und erweiterte Dokumentation variieren. Die wichtigsten Punkte, die jede Dokumentationsstufe hervorheben muss, um den Grad der Besorgnis der mit dem Medizinprodukt verbundenen Software zu identifizieren, sind:

• Die Softwareübersicht, die einen Überblick über die Eingaben und Ausgaben gibt
• Die Software-Anforderungsspezifikationen (SRS) umfassen Details zur Softwarearchitektur, ergänzt durch ein schematisches Diagramm aller Module, Peripheriegeräte, Programmiersprachen, des Betriebssystems, der Compiler-Version, der Nutzung etwaiger Shell-Software sowie aller UI/UX-Details
• Software- oder System Design Specifications (SDS), die Informationen zur Software bereits ab der Entwurfsphase abdecken, sind für Sponsoren erforderlich, die eine erweiterte Dokumentation einreichen. Während SRS die beabsichtigte Funktion der Software beschreibt, liefert SDS detaillierte Informationen zur Implementierungsmethodik der in SRS genannten Anforderungen. SDS muss umfassende technische Designdetails mit ausreichenden Informationen zum Nutzen und zur Funktionsweise enthalten, die auf die SRS zurückzuführen sind, sowie Angaben dazu, ob Unterstützung für den Betrieb der Software erforderlich ist oder ob es sich um ein trainiertes CAD-System handelt, das auf KI/ML-Modellen basiert.
• Die Einhaltung der branchenweit anerkannten freiwilligen Konsensstandards für regulatorische Einreichungen würde gemäß dieser neuen Entwurfsleitlinie einfacher und besser auf die aktuellen Trends, Praktiken und Innovationen des digitalen Gesundheitsmarktes abgestimmt sein. Geräte, die eine grundlegende und erweiterte Dokumentation erfordern, müssen beide der von der FDA anerkannten Version von ANSI/AAMI IEC 62304 Medizinproduktssoftware – Software-Lebenszyklusprozess – entsprechen. Erweiterte Dokumente erfordern eine zusätzliche Beschreibung der vollständigen Konfiguration mit noch detaillierteren Angaben zum Designentwicklungs- und Wartungsplan im Software-Lebenszyklus, um eine bessere Klarheit bei der Überprüfung zu gewährleisten.
• Basierend auf der Risikoanalyse gemäß den Anforderungen der Qualitätsmanagementsystem-Verordnungen (21 CFR 820) sollten auch sicherheitsrelevante Informationen wie Betriebsumgebung, Wirksamkeit, Genauigkeit, Reaktionszeit, Verzögerungszeit, Konsistenz, Betriebsgrenzen und -bereich sowie jeder Basis- oder Schwellenwert, den die Software für ihren Betrieb benötigt, enthalten sein. Die Bereitstellung eines Vigilanzsystems zur Verfolgung der mit Gerätespeicher oder Speichersystem aufgezeichneten Daten muss erwähnt werden.
• Im Rahmen des Software-Lebenszyklus sind die Verifizierung und Validierung der Software unerlässlich. Dies wird durch das Testen von Softwarekomponenten auf System- oder Integrationsebene erreicht. Eine erweiterte Dokumentation erfordert dies zwingend. Zudem sollte die Beschreibung der Testprotokolle, einschließlich der erwarteten oder beobachteten Ergebnisse zur Feststellung des Bestanden/Nicht-Bestanden-Status des Systems, ebenfalls behandelt werden
• Jegliche ungelösten Anomalien wie Bugs oder Defekte, die die Leistung der Softwarefunktion beeinträchtigen können, sollten identifiziert und gemäß der Defekt-Taxonomie nach ANSI/AAMI SW91 (Klassifizierung von Defekten in Gesundheitssoftware) klassifiziert werden

Eine erweiterte Dokumentation ist für Geräte einzureichen, die entweder ein Kombinationsprodukt sind, als Hochrisikogerät der Klasse III eingestuft werden oder eine Softwarefunktion darstellen, die für Blutspende- und Bluttransfusionsanwendungen vorgesehen ist und die Kompatibilität von Spender und Empfänger bewertet. Geräte, die eine spezielle Dokumentation erfordern, müssen die Anforderungen an die erweiterte Dokumentation erfüllen. Die Basisdokumentation sollte Berichte zur Gefahrenanalyse, Gefahrenminderung und Risikobegründung umfassen

Gemäß den MDUFA IV-Verpflichtungen soll die Behörde die endgültige Leitlinie innerhalb von 12 Monaten nach Ende der Entwurfs-Kommentierungsfrist veröffentlichen. Die FDA hat angekündigt, am 16. Dezember 2021 ein Webinar für Hersteller von Medizinprodukten, Forscher der digitalen Gesundheitsbranche und Fachleute zu veranstalten, um diese Entwurfsleitlinie zu diskutieren.

Um mehr über die präklinische Einreichung von Softwarefunktionen für Geräte zu erfahren, wenden Sie sich an einen regionalen Regulierungsexperten wie Freyr. Bleiben Sie informiert. Bleiben Sie konform.