4 Minuten lesen
Mit der technologischen Entwicklung ist die Gesundheitsbranche sehr daran interessiert, Software in medizinische Geräte zu integrieren, um die Vorhersage, Diagnose, Vorbeugung, Behandlung und das Management von Gesundheitszuständen zu automatisieren und zu verbessern. Die US-Gesundheitsbehörde FDA hat die Rolle, die Software für die Funktion von Medizinprodukten spielen kann, schon lange erkannt, aber sie hat noch keine konkreten Leitlinien oder Regeln aufgestellt, die den Forschern in der Branche die Weiterentwicklung der digitalen Gesundheit erleichtern könnten.
Am 4. November 2021 veröffentlichte die US-amerikanische Zulassungsbehörde FDA den Entwurf eines Leitfadens zum "Inhalt von Anträgen vor der Markteinführung für Gerätesoftwarefunktionen", der den Sponsoren, die für die Erstellung des Dokuments verantwortlich sind, eine konkrete Vorstellung davon vermittelt, welche Informationen sie enthalten 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 während ihres gesamten Lebenszyklus zu gewährleisten. Der neue Leitfaden ist eine Empfehlung und ein Entwurf über die Funktionen von Medizinproduktsoftware, den die FDA als Ersatz für den 15 Jahre alten Leitfaden "Guidance for the content of pre-market submission for the software contained in Medical device" vom Mai 2005 veröffentlichen will. Die FDA hat das Zeitfenster für Rückmeldungen und Diskussionen bis zum 2. Februar 2022 offen gehalten.
In dieser neuen Fassung erkannte die FDA die Art der Verbindung von Software mit einem Medizinprodukt an und differenzierte sie weiter in SaMD - Software als Medizinprodukt und SiMD - Software in einem Medizinprodukt, als Unterteilungen der Funktionen von Gerätesoftware. Software als Medizinprodukt oder SaMD ist eine Software, die selbst die Aufgabe eines Medizinprodukts gemäß der in Abschnitt 201 (h) des FD&C Act genannten Definition des Medizinprodukts erfüllt, aber nicht Teil eines Bestandteils des Produkts ist. Andererseits ist Software in SiMD, wie der Name schon sagt, ein Teil der Komponente oder Hardware des Medizinprodukts, die zur Aufzeichnung, Steuerung oder Anzeige medizinischer oder nichtmedizinischer Informationen verwendet wird.
Der Entwurf konzentriert sich mehr auf die Erwartungen der FDA in Bezug auf die Erstellung von Dokumenten, die für die Einreichung von Softwarefunktionen von Geräten vor dem Inverkehrbringen erforderlich sind. Die FDA hat eine klare Vorstellung davon, was sie von den Dokumenten erwartet, in denen die Software Requirements Specification (SRS) und die Software oder System Design Specifications (SDS) solide festgelegt sind. Die FDA legt Wert auf einen risikobasierten Ansatz bei der Dokumentation der Softwarefunktionen von Geräten vor der Markteinführung. Je nach dem Grad der Besorgnis oder dem Risiko, das mit der beabsichtigten Verwendung des Geräts verbunden ist, soll auch die Dokumentationsstufe als grundlegende und erweiterte Dokumentation variieren. Die wichtigsten Punkte, die bei jeder Dokumentationsstufe hervorgehoben werden müssen, um den Gefährdungsgrad der Software im Zusammenhang mit dem Medizinprodukt zu ermitteln, sind:
- Die Software-Übersicht gibt einen Überblick über die Eingaben und Ausgaben
- Software-Anforderungsspezifikationen (SRS), die Einzelheiten der Software-Architektur mit einem schematischen Diagramm aller Module, Peripheriegeräte, Programmiersprachen, Betriebssysteme, Compiler-Versionen, die Verwendung von Shell-Software und alle UI/UX-Details enthalten
- Software- oder Systemdesignspezifikationen (SDS), die Informationen über die Software bereits in der Entwurfsphase enthalten, sind für Antragsteller erforderlich, die eine erweiterte Dokumentation einreichen. Während die SRS die beabsichtigte Funktion der Software beschreibt, sind die SDS detaillierte Informationen über die Implementierungsmethodik der in der SRS genannten Anforderungen. Das SDB muss ein umfassendes technisches Design-Detail mit angemessenen Informationen über den Nutzen, die Funktionsweise, die sich auf die SRS zurückführen lässt, und darüber, ob für die Bedienung der Software Hilfe erforderlich ist oder ob es sich um ein geschultes CAD-System handelt, das auf AI/ML-Modellen aufbaut, enthalten.
- Die Einhaltung der von der Industrie anerkannten freiwilligen Konsensstandards für die Einreichung von Zulassungsanträgen würde nach diesem neuen Richtlinienentwurf einfacher werden und besser mit den aktuellen Trends, Praktiken und Innovationen des digitalen Gesundheitsmarktes übereinstimmen. Produkte, für die eine einfache und eine erweiterte Dokumentation erforderlich ist, müssen beide der von der FDA anerkannten Version der ANSI/AAMI IEC 62304 Medical device software- Software lifecycle process entsprechen. Erweiterte Dokumente erfordern eine zusätzliche Beschreibung der vollständigen Konfiguration mit noch mehr Details über die Designentwicklung und den Wartungsplan im Software-Lebenszyklus, um bei der Überprüfung mehr Klarheit zu schaffen.
- Auf der Grundlage der Risikoanalyse gemäß den Anforderungen der Quality System Regulations (21 CFR 820) sollten auch sicherheitsrelevante Informationen wie Betriebsumgebung, Wirksamkeit, Genauigkeit, Reaktionszeit, Verzögerungszeit, Konsistenz, Betriebsgrenzen und -bereich sowie alle Basis- oder Schwellenwerte, mit denen die Software arbeiten muss, angegeben werden. Das Vorhandensein eines Vigilanzsystems zur Verfolgung der im Gerätespeicher oder im Speichersystem aufgezeichneten Daten muss erwähnt werden.
- Als Teil des Software-Lebenszyklus sind Software-Verifizierung und -Validierung unerlässlich, die durch das Testen von Software-Komponenten auf System- oder Integrationsebene erreicht werden. Dies ist für eine verbesserte Dokumentation zwingend erforderlich. Außerdem sollte die Beschreibung der Testprotokolle zusammen mit den erwarteten oder beobachteten Ergebnissen erörtert werden, um den Pass/Fail-Status des Systems zu bestimmen.
- Jegliche Beteiligung von ungelösten Anomalien wie Bugs, Defekte, die die Leistung der Softwarefunktion beeinträchtigen können, sollten identifiziert und auf der Grundlage der Fehlertaxonomie gemäß ANSI/AAMI SW91's Classification of defects in health software klassifiziert werden.
Eine erweiterte Dokumentation muss für Produkte vorgelegt werden, die entweder ein Kombinationsprodukt sind oder als Hochrisikoprodukt der Klasse III eingestuft sind, oder für eine Softwarefunktion, die zur Verwendung in Blutspende- und Bluttransfusionsanwendungen bestimmt ist und die Kompatibilitätsbewertung von Spender und Empfänger durchführt. Produkte, die eine besondere Dokumentation erfordern, sollten die erweiterten Dokumentationsanforderungen erfüllen. Die Basisdokumentation sollte Berichte über Gefahrenanalyse, Gefahrenminderung und Risikobegründung enthalten.
Gemäß den MDUFA IV-Verpflichtungen soll die Agentur die endgültige Leitlinie innerhalb von 12 Monaten nach Ablauf der Kommentierungsfrist für den Entwurf veröffentlichen. Die FDA hat angekündigt, am 16. Dezember 2021 ein Webinar für Hersteller von Medizinprodukten, Forscher aus der Digital-Health-Branche und Fachleute zu veranstalten, um diesen Leitfadenentwurf zu diskutieren.
Wenn Sie mehr über die Einreichung von Softwarefunktionen vor der Markteinführung erfahren möchten, wenden Sie sich an einen regionalen Zulassungsexperten wie Freyr. Bleiben Sie informiert. Bleiben Sie compliant.
