Premarket Submissions of Device Software Functions – Decode the US FDA’s Draft Guidance

Mit der technologischen Entwicklung ist die Gesundheitsbranche bestrebt, Software in Medizinprodukte zu integrieren, um bei der Vorhersage, Diagnose, Prävention, Behandlung und dem Management von gesundheitlichen Zuständen Automatisierung und Genauigkeit zu erzielen. Die US FDA hat die Rolle, die Software für die Funktion von Medizinprodukten spielen kann, zwar längst erkannt, war jedoch bisher konkrete Leitlinien oder Vorschriften schuldig geblieben, die es der Branche und Forschern hätten erleichtern können, Fortschritte im Bereich der digitalen Gesundheit zu erzielen.

Am 4. November 2021 veröffentlichte die US FDA einen Entwurf für Leitlinien zu „Inhalten von Vorababmeldungen für Softwarefunktionen von Medizinprodukten“ und gab Sponsoren, die für die Erstellung des Dokuments verantwortlich sind, genaue Vorstellungen darüber an die Hand, 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 den gesamten Lebenszyklus hinweg sicherzustellen. Die neuen Leitlinien stellen eine Empfehlung und einen Entwurf zu Softwarefunktionen von Medizinprodukten dar, deren Veröffentlichung 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“ aus dem Mai 2005 zugesagt hat. Die Frist für Feedback und entsprechende Diskussionen lief bis zum 2. Februar 2022.

In dieser neuen Fassung hat die FDA die Art und Weise der Verknüpfung von Software mit einem Medizinprodukt anerkannt und diese ferner als Unterteilungen von Gerätesoftwarefunktionen in SaMD (Software as a Medical Device) und SiMD (Software in a Medical Device) unterschieden. Software as a Medical Device (SaMD) ist Software, die selbst die Aufgabe eines Medizinprodukts gemäß der Begriffsbestimmung für Medizinprodukte in Abschnitt 201(h) des FD&C Act erfüllt, jedoch kein Bestandteil des Geräts ist. Software in a Medical Device (SiMD) hingegen ist, wie der Name schon sagt, Teil der Medizinproduktkomponente oder der Hardware, die zum Aufzeichnen, Steuern oder Anzeigen medizinischer oder nichtmedizinischer Informationen verwendet wird.

Der Entwurf konzentriert sich stärker auf die Erwartungen der FDA hinsichtlich der Dokumentenerstellung, die für Einreichungen vor dem Inverkehrbringen von Gerätesoftwarefunktionen erforderlich ist. Sie haben ein klares Verständnis davon entwickelt, was in den Dokumenten erwartet wird, die die Softwareanforderungspezifikation (SRS) sowie die Software- oder Systemdesignspezifikationen (SDS) fundiert belegen. Die FDA legt bei der Dokumentation für Vorababmeldungen von Gerätesoftwarefunktionen den Schwerpunkt auf einen risikobasierten Ansatz. Je nach diesem Grad der Bedenken oder dem mit der Zweckbestimmung des Produkts verbundenen Risiko soll auch der Umfang der Dokumentation als grundlegende oder erweiterte Dokumentation variieren. Die wichtigsten Punkte, die jede Dokumentationsstufe hervorheben muss, um den Grad der Bedenken der mit dem Medizinprodukt verbundenen Software zu ermitteln, sind:

• Die Softwareübersicht, die einen Überblick über die Eingaben und Ausgaben gibt
• Softwareanforderungsspezifikationen (SRS), die Details zur Softwarearchitektur mit einem schematischen Diagramm aller Module, Peripheriegeräte, Programmiersprachen, des Betriebssystems, der Compilerversion, der Verwendung von Shell-Software und aller UI/UX-Details enthalten
• Software- oder Systemdesignspezifikationen (SDS), die Informationen über die Software direkt aus der Designphase abdecken, sind für Sponsoren erforderlich, die eine erweiterte Dokumentation einreichen. Während die SRS die beabsichtigte Funktion der Software beschreibt, enthält die SDS detaillierte Informationen zur Umsetzungsmethodik der in der SRS genannten Anforderungen. Die SDS muss umfassende technische Designdetails mit ausreichenden Informationen über die Nutzbarkeit und Funktionsweise enthalten, die sich auf die SRS zurückführen lassen, unabhängig davon, ob Unterstützung für die Bedienung der Software erforderlich ist oder ob es sich um ein auf KI/ML-Modellen basierendes, trainiertes CAD-System handelt.
• Gemäß diesem neuen Entwurf einer Richtlinie wird es einfacher und zeitgemäßer, die branchenweit anerkannten, freiwilligen Konsensstandards für Zulassungsanträge einzuhalten, um so besser zu den aktuellen Trends, Praktiken und Innovationen des digitalen Gesundheitsmarktes zu passen. Sowohl Medizinprodukte, die eine einfache Dokumentation erfordern, als auch solche mit erweiterter Dokumentation müssen die von der FDA anerkannte Version der Norm ANSI/AAMI IEC 62304 für Software von Medizinprodukten – Software-Lebenszyklusprozesse erfüllen. Erweiterte Dokumente erfordern eine zusätzliche Beschreibung der gesamten Konfiguration mit noch detaillierteren Angaben zur Entwurfsentwicklung und zum Wartungsplan im Software-Lebenszyklus, um bei der Prüfung für mehr Klarheit zu sorgen.
• Basierend auf der Risikoanalyse gemäß den Anforderungen der Vorschriften für Qualitätssysteme (21 CFR 820) sollten auch sicherheitsrelevante Informationen wie die Betriebsumgebung, Wirksamkeit, Genauigkeit, Reaktionszeit, Verzögerungszeit, Konsistenz, Betriebsgrenzen und -bereiche sowie alle Basis- oder Schwellenwerte, die die Software für den Betrieb benötigt, einbezogen werden. Die Bereitstellung eines Überwachungssystems zur Nachverfolgung der Daten, die mithilfe des Gerätespeichers oder eines Speichersystems aufgezeichnet wurden, muss ebenfalls erwähnt werden.
• Als Teil des Software-Lebenszyklus sind Software-Verifizierung und -Validierung unerlässlich. Dies wird durch das Testen von Softwarekomponenten auf System- oder Integrationsebene erreicht. Dies ist für eine erweiterte Dokumentation obligatorisch. Darüber hinaus sollten die Beschreibung der Testprotokolle zusammen mit den erwarteten oder beobachteten Ergebnissen zur Feststellung des Status „Bestanden/Nicht bestanden“ des Systems besprochen werden.
• Jedes Auftreten ungelöster Anomalien wie Fehler oder Mängel, die die Leistung der Softwarefunktion beeinträchtigen können, sollte identifiziert und auf Grundlage der Defekttaxonomie gemäß der Klassifizierung von Mängeln in Gesundheitssoftware nach ANSI/AAMI SW91 klassifiziert werden.

Eine erweiterte Dokumentation muss für Medizinprodukte eingereicht werden, bei denen es sich entweder um ein Kombinationsprodukt handelt, die als Hochrisikoprodukt der Klasse III eingestuft sind oder um eine Softwarefunktion, die für Blutspende- und Bluttransfusionsanwendungen verwendet werden soll und die Kompatibilitätsprüfung von Spender und Empfänger durchführt. Produkte, die eine spezielle Dokumentation erfordern, sollten den Anforderungen an die erweiterte Dokumentation folgen. Die einfache Dokumentation sollte eine Gefahrenanalyse, Risikominderungsmaßnahmen und Berichte zur Risikorechtfertigung umfassen.

Gemäß den Verpflichtungen aus MDUFA IV soll die Behörde die endgültige Leitlinie innerhalb von 12 Monaten nach Ablauf der Frist für die Kommentierung des Entwurfs veröffentlichen. Die FDA hat angekündigt, am 16. Dezember 2021 ein Webinar für Medizinproduktehersteller, Forscher der digitalen Gesundheitsbranche und Fachleute zu veranstalten, um diesen Leitlinienentwurf zu diskutieren.

Um mehr über die Einreichung von Softwarefunktionen für Medizinprodukte vor der Markteinführung zu erfahren, wenden Sie sich an einen regionalen Experten für Zulassungsfragen wie Freyr. Bleiben Sie informiert. Bleiben Sie konform.