4 Minuten lesen
Mit der Weiterentwicklung der Technologie ist die Gesundheitsbranche zunehmend daran interessiert, Software in medizinische Geräte zu integrieren, um Automatisierung und Genauigkeit in die Vorhersage, Diagnose, Prävention, Behandlung und das Management von Gesundheitszuständen zu integrieren. Die US FDA seit langem die Rolle erkannt, die Software für die Funktionsweise medizinischer Geräte spielen kann, aber noch keine konkreten Leitlinien oder Vorschriften erarbeitet, die den Forschern der Branche Fortschritte im Bereich der digitalen Gesundheit erleichtern könnten.
Am 4. November 2021FDA die US FDA einen Leitfadenentwurf zum Thema„Inhalt von Premarket-Einreichungen für Gerätesoftwarefunktionen“, der den für die Erstellung des Dokuments verantwortlichen Sponsoren eine klare Vorstellung davon vermittelt, welche Informationen darin enthalten sein müssen. Diese von den Sponsoren bereitgestellten Informationen sind für die FDA wichtig, FDA die Gerätesoftware, die eine oder mehrere Funktionen ausführt, FDA bewerten und die Sicherheit und Wirksamkeit während ihres gesamten Lebenszyklus zu gewährleisten. Die neue Leitlinie ist eine Empfehlung und ein Entwurf zu den Funktionen von Medizinprodukt-Software, den die FDA als Ersatz für die 15 Jahre alte Leitlinie „Guidance for the content of pre-market submission for the software contained in Medical device” (Leitlinie zum Inhalt von Vorab-Einreichungen für die in Medizinprodukten enthaltene Software) aus dem Mai 2005 veröffentlichen FDA . Die Frist für Rückmeldungen und Diskussionen zu diesem Thema läuft bis zum 2. Februar 2022.
In dieser neuen Version FDA die FDA die Art der Verbindung von Software mit einem Medizinprodukt FDA und diese weiter in SaMD Software as a medical device SaMD Software as a medical device SiMD (Software in a Medical Device) als Unterkategorien der Funktionen von Gerätesoftware unterteilt. Software as a medical device SaMD eine Software, die selbst die Aufgabe eines Medizinprodukts gemäß der Definition des Medizinprodukts in Abschnitt 201 (h) des FD&C Act erfüllt, aber nicht Teil eines Bestandteils des Produkts ist. Software in SiMD hingegen ist, wie der Name schon sagt, Teil der Komponente oder Hardware eines Medizinprodukts, die zur Aufzeichnung, Steuerung oder Anzeige medizinischer oder nichtmedizinischer Informationen verwendet wird.
Der Entwurf konzentriert sich stärker auf die Erwartungen der FDA der Dokumentvorbereitung, die für die Einreichung von Anträgen auf Marktzulassung für Gerätesoftwarefunktionen erforderlich ist. Die FDA hat ein klares Verständnis dafür entwickelt, was sie in den Dokumenten erwartet, die die Softwareanforderungsspezifikation (SRS) und die Software- oder Systemdesignspezifikationen (SDS) robust festlegen. Die FDA einen risikobasierten Ansatz bei der Dokumentation für die Einreichung von Anträgen auf Marktzulassung für Gerätesoftwarefunktionen. Basierend auf diesem Grad der Besorgnis oder dem mit der beabsichtigten Verwendung des Geräts verbundenen Risiko soll auch der Umfang der Dokumentation variieren, und zwar zwischen einer grundlegenden und einer erweiterten Dokumentation. Die wichtigsten Punkte, die jede Dokumentationsstufe hervorheben muss, um den Grad der Besorgnis hinsichtlich der mit dem Medizinprodukt verbundenen Software 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
- Sponsoren, die erweiterte Unterlagen einreichen, benötigen Software- oder Systemdesignspezifikationen (SDS), die Informationen zur Software bereits ab der Entwurfsphase enthalten. Während SRS die beabsichtigte Funktion der Software beschreibt, enthält SDS detaillierte Informationen zur Implementierungsmethodik der in SRS genannten Anforderungen. SDS muss umfassende technische Designdetails mit ausreichenden Informationen zur Nützlichkeit, zur Funktionsweise, die sich auf SRS bezieht, dazu, ob für die Bedienung der Software Unterstützung erforderlich ist oder ob es sich um ein geschultes CAD-System handelt, das aufML basiert, enthalten.
- Die Einhaltung der branchenweit anerkannten freiwilligen Konsensstandards für Zulassungsanträge würde gemäß diesem neuen Leitlinienentwurf einfacher und besser auf die aktuellen Trends, Praktiken und Innovationen des digitalen Gesundheitsmarktes abgestimmt sein. Geräte, für die sowohl eine grundlegende als auch eine erweiterte Dokumentation erforderlich ist, müssen der FDA Version der Norm ANSI/AAMI IEC 62304 „Medical device software – Software lifecycle process” (Medizinische Gerätesoftware – Software-Lebenszyklusprozess) entsprechen. Erweiterte Dokumente erfordern eine zusätzliche Beschreibung der vollständigen Konfiguration mit noch detaillierteren Angaben zur Designentwicklung und zum Wartungsplan im Software-Lebenszyklus, um mehr Klarheit bei der Überprüfung zu gewährleisten.
- Basierend auf der Risikoanalyse gemäß den Anforderungen der Qualitätssystemvorschriften (21 CFR 820) sollten auch sicherheitsrelevante Informationen wie die Betriebsumgebung, Wirksamkeit, Genauigkeit, Reaktionszeit, Verzögerungszeit, Konsistenz, Betriebsgrenzen und -bereich sowie alle Basis- oder Schwellenwerte, die die Software für den Betrieb benötigt, enthalten sein. Die Bereitstellung eines Überwachungssystems zur Verfolgung der mit dem Gerätespeicher oder 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 Behörde die endgültige Leitlinie innerhalb von 12 Monaten nach Ablauf der Frist für Stellungnahmen zum Entwurf veröffentlichen. Die FDA angekündigt, am 16. Dezember 2021 ein Webinar für Hersteller von Medizinprodukten, Forscher aus der digitalen Gesundheitsbranche und Fachleute zu veranstalten, um diesen Leitlinienentwurf zu diskutieren.
Um mehr über die Einreichung von Gerätesoftwarefunktionen vor der Markteinführung zu erfahren, reach an einen regionalen Regulierungsexperten wie Freyr. Bleiben Sie informiert. Bleiben Sie konform.
