4 Min. Lesezeit
Mit dem technologischen Fortschritt legt die Gesundheitsbranche zunehmend Wert darauf, Software in medizinische Geräte zu integrieren, um Automatisierung und Präzision bei der Vorhersage, Diagnose, Prävention, Behandlung und dem Management von Gesundheitszuständen zu gewährleisten. Die US-amerikanische Lebensmittel- und Arzneimittelbehörde ( US , FDA)FDA hatte die Rolle, die Software für die Funktionsweise medizinischer Geräte spielen kann, schon seit Langem erkannt, hatte jedoch noch keine konkreten Leitlinien oder Vorschriften erlassen, die den Forschern der Branche Fortschritte im Bereich der digitalen Gesundheit erleichtert hätten.
Am 4. November 2021 veröffentlichte die US-amerikanische Medizinproduktebehörde ( US ,FDA ) einen Leitlinienentwurf zum Thema„Inhalt von Anträgen vor der Markteinführung für Softwarefunktionen von Medizinprodukten“, der den für die Erstellung des Dokuments verantwortlichen Antragstellern eine klare Vorstellung davon vermittelt, welche Informationen darin enthalten sein müssen. Diese von den Antragstellern bereitgestellten Informationen sind für die US-amerikanische Medizinproduktebehörde ( FDA ) wichtig, um die Medizinprodukt-Software, die eine oder mehrere Funktionen ausführt, zu bewerten und die Sicherheit und Wirksamkeit während ihres gesamten Lebenszyklus sicherzustellen. Der neue Leitfaden ist eine Empfehlung und ein Entwurf zu Softwarefunktionen von Medizinprodukten, 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“ (Leitfaden zum Inhalt von Zulassungsanträgen für in Medizinprodukten enthaltene Software) veröffentlichen will, der im Mai 2005 herausgegeben wurde. Es wurde eine Frist für Rückmeldungen eingeräumt; Diskussionen zu diesem Thema sind bis zum 2. Februar 2022 möglich.
In dieser neuen Fassung hat die „ FDA “ die Art der Verknüpfung von Software mit einem Medizinprodukt anerkannt und diese weiter in „ SaMD “ – Software als Medizinprodukt – und „SiMD“ – Software in einem Medizinprodukt – als Unterkategorien der Funktionen von Medizinprodukt-Software differenziert. „Software as a Medical Device“ ( SaMD ) ist eine Software, die gemäß der Definition eines Medizinprodukts in Abschnitt 201 (h) des FD&C Act selbst die Aufgabe eines Medizinprodukts erfüllt, jedoch kein Bestandteil des Produkts ist. Demgegenüber ist Software in SiMD, wie der Name schon sagt, Teil der Komponente oder Hardware des Medizinprodukts, die zur Aufzeichnung, Steuerung oder Anzeige medizinischer oder nichtmedizinischer Informationen dient.
Der Entwurf konzentriert sich stärker auf die Erwartungen der „ FDA “ hinsichtlich der Dokumentationserstellung, die für die Einreichung von Anträgen zur Marktzulassung von Medizinprodukt-Softwarefunktionen erforderlich ist. Die Behörde hat klare Vorgaben dazu erarbeitet, was in den Dokumenten enthalten sein muss, um die Software-Anforderungsspezifikation (SRS) sowie die Software- oder System-Designspezifikationen (SDS) fundiert zu begründen. Der Leitfaden „ FDA “ betont einen risikobasierten Ansatz bei der Dokumentation für die Zulassungsanträge von Softwarefunktionen für Medizinprodukte. Je nach dem Grad der Bedenken oder dem mit dem Verwendungszweck des Medizinprodukts verbundenen Risiko soll auch der Umfang der Dokumentation variieren und in eine „grundlegende“ und eine „erweiterte“ Dokumentation unterteilt werden. Die wichtigsten Punkte, die bei jeder Dokumentationsstufe hervorgehoben werden müssen, um den Grad der Bedenken hinsichtlich der mit dem Medizinprodukt verbundenen Software zu ermitteln, sind:
- Die Softwareübersicht vermittelt einen Überblick über die Ein- und Ausgänge
- Software-Anforderungsspezifikationen (SRS), die Einzelheiten zur Softwarearchitektur enthalten, einschließlich eines schematischen Diagramms aller Module, Peripheriegeräte, Programmiersprachen, des Betriebssystems, der Compiler-Version, der Verwendung von Shell-Software sowie aller UI/UX-Details
- Für Auftraggeber, die eine erweiterte Dokumentation einreichen, sind Software- oder Systemdesignspezifikationen (SDS) erforderlich, die Informationen zur Software bereits ab der Entwurfsphase enthalten. Während das SRS die beabsichtigte Funktion der Software beschreibt, enthält das SDS detaillierte Informationen zur Implementierungsmethodik der im SRS genannten Anforderungen. Das SDS muss umfassende technische Entwurfsdetails mit ausreichenden Informationen zum Nutzen und zur Funktionsweise enthalten, die auf das SRS zurückgeführt werden können, sowie Angaben dazu, ob für den Betrieb der Software Unterstützung erforderlich ist oder ob es sich um ein geschultes CAD-System handelt, das auf KI-/ML -Modellen basiert.
- Die Einhaltung der branchenweit anerkannten freiwilligen Konsensstandards für Zulassungsanträge würde laut diesem neuen Leitlinienentwurf vereinfacht und besser an die aktuellen Trends, Praktiken und Innovationen im Bereich der digitalen Gesundheit angepasst. Sowohl Produkte, für die eine grundlegende als auch eine erweiterte Dokumentation erforderlich ist, müssen der von der „ FDA “ anerkannten Version der Norm ANSI/AAMI IEC 62304 „Medizinprodukte-Software – Software-Lebenszyklusprozess“ entsprechen. Erweiterte Unterlagen erfordern eine zusätzliche Beschreibung der vollständigen Konfiguration mit noch detaillierteren Angaben zum Entwurfs-, Entwicklungs- und Wartungsplan im Software-Lebenszyklus, um bei der Prüfung mehr Klarheit zu schaffen.
- Auf der Grundlage der Risikoanalyse gemäß den Anforderungen der Vorschriften zum Qualitätssicherungssystem (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 ihren Betrieb benötigt, aufgenommen werden. Die Bereitstellung eines Vigilanzsystems zur Nachverfolgung der Daten, die im Gerätespeicher oder im Speichersystem aufgezeichnet werden, muss erwähnt werden.
- Im Rahmen des Software-Lebenszyklus sind Softwareverifikation und -validierung von entscheidender Bedeutung; dies wird durch das Testen von Softwarekomponenten auf System- oder Integrationsebene erreicht. Dies ist für eine verbesserte Dokumentation unerlässlich. Darüber hinaus sollte auch die Beschreibung der Testprotokolle zusammen mit den erwarteten oder beobachteten Ergebnissen zur Feststellung des Bestanden/Nicht bestanden-Status des Systems erörtert werden.
- Jedes Auftreten von ungelösten Anomalien wie Fehlern oder Mängeln, die die Leistungsfähigkeit der Softwarefunktion beeinträchtigen können, sollte identifiziert und anhand der Fehlertaxonomie gemäß der „Klassifizierung von Fehlern in Gesundheitssoftware“ nach ANSI/AAMI SW91 klassifiziert werden.
Für Produkte, bei denen es sich entweder um Kombinationsprodukte handelt oder die als Hochrisikoprodukte der Klasse III eingestuft sind, sowie für Softwarefunktionen, die für den Einsatz bei Blutspenden und Bluttransfusionen vorgesehen sind und die Kompatibilitätsprüfung zwischen Spender und Empfänger durchführen, müssen erweiterte Unterlagen eingereicht werden. Produkte, für die besondere Unterlagen erforderlich sind, müssen den Anforderungen an die erweiterte Dokumentation entsprechen. Die grundlegenden Unterlagen sollten kurze Berichte zur Gefahrenanalyse, zur Gefahrenminderung und zur Risikobegründung enthalten.
Gemäß den Verpflichtungen im Rahmen von MDUFA IV soll die Behörde die endgültigen Leitlinien innerhalb von 12 Monaten nach Ablauf der Frist für Stellungnahmen zum Entwurf veröffentlichen. Das „ 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 Leitlinienentwurf zu erörtern.
Wenn Sie mehr über die Einreichung von Softwarefunktionen für Medizinprodukte vor der Markteinführung erfahren möchten, wenden Sie sichreach an einen regionalen Experten für Zulassungsfragen wie Freyr. Bleiben Sie auf dem Laufenden. Halten Sie die Vorschriften ein.
