FDA-Software-Dokumentation für medizinische Geräte

Freiberuflich Verfasser von Rechtsvorschriften Shreya Chenni bietet einen Leitfaden zur FDA-Softwaredokumentation für Medizinprodukte, einschließlich einer Aufschlüsselung der Anforderungen nach Klassifizierung. 

Die Medizinprodukt industry is seeing rapid technological advancement and a high rate of innovation.  Nowadays, many devices are AI-enabled, which allows early detection of disease, identification of different patterns of a biological activity, and improved diagnostic accuracy. Some examples of AI-enabled applications or devices include Arterys Application, Philips WSI and QuantX by Quantitative Insights. The software has to be verified and validated, to ensure its safety and effectiveness. 

Für jedes Gerät, das Software enthält, die durch die 510(k)-Routemüssen bestimmte softwarebezogene Dokumente eingereicht werden. In diesem Artikel besprechen wir die erforderlichen Dokumente für 510(k)-Anträge und wissen, wie sie auf der Grundlage Ihrer Software-Klassifizierung zu erstellen sind.  

Wie klassifizieren Sie Ihre Software für medizinische Geräte? 

Bestimmen Sie die zutreffende Besorgnisstufe (LoC). Es gibt drei Stufen: 

• Schwerwiegend: ein Versagen oder ein verborgener Fehler könnte unmittelbar zum Tod oder zu schweren Verletzungen des Patienten oder des Bedieners führen 

OR 

 ein Versagen oder ein latenter Fehler indirekt zum Tod oder zu schweren Verletzungen des Patienten oder des Bedieners durch falsche oder verzögerte Informationen oder durch die Handlung eines Pflegepersonals führen könnte.

• Mäßig: ein Versagen oder ein verborgener Konstruktionsfehler könnte unmittelbar zu leichten Verletzungen des Patienten oder des Bedieners führen

 OR 

ein Versagen oder ein latenter Fehler könnte indirekt zu leichten Verletzungen des Patienten oder des Bedieners durch falsche oder verzögerte Informationen oder durch die Handlung eines Pflegepersonals führen. 

• Geringfügig: wenn Fehler oder latente Konstruktionsmängel wahrscheinlich nicht zu Verletzungen des Patienten oder des Bedieners führen. 

Verwenden Sie die Tabelle 1 und Tabelle 2 der FDA-Leitfaden für den Inhalt von Zulassungsanträgen für Software in Medizinprodukten um die Fragen zu beantworten und Ihren Software-Grad der Besorgnis zu bestimmen. 

FDA-Softwaredokumente für medizinische Geräte

Welche Unterlagen müssen eingereicht werden?

Für Software, die als mittelschwer und schwerwiegend einzustufen ist, müssen 11 verschiedene Dokumente eingereicht werden. Für Software, die als weniger besorgniserregend eingestuft wird, sind hingegen sieben verschiedene Dokumente erforderlich. Umfang und Detaillierungsgrad dieser Dokumente variieren je nach Risikoklasse.

In der folgenden Tabelle sind die für die einzelnen Ebenen erforderlichen Dokumente aufgeführt: 

Kleinere	Mäßig	Major
Grad der Besorgnis	Grad der Besorgnis	Grad der Besorgnis
Beschreibung der Software	Beschreibung der Software	Beschreibung der Software
Gefährdungsanalyse für Geräte	Gefährdungsanalyse für Geräte	Gefährdungsanalyse für Geräte
Spezifikation der Softwareanforderungen (SRS)	Spezifikation der Softwareanforderungen (SRS)	Spezifikation der Softwareanforderungen (SRS)
Analyse der Rückverfolgbarkeit	Analyse der Rückverfolgbarkeit	Analyse der Rückverfolgbarkeit
Dokumentation der Verifizierung und Validierung	Dokumentation der Verifizierung und Validierung	Dokumentation der Verifizierung und Validierung
Revisionsstand Geschichte	Revisionsstand Geschichte	Revisionsstand Geschichte
————	Architektur-Design-Diagramm	Architektur-Design-Diagramm
————	Dokument zur Spezifikation des Softwareentwurfs	Dokument zur Spezifikation des Softwareentwurfs
————	Software Development Environment Description	Software-Entwicklungsumgebung Beschreibung
————	Ungelöste Anomalien (Bugs oder Defekte)	Ungelöste Anomalien (Bugs oder Defekte)

 

Beschreibung der Dokumente 

1. Grad der Besorgnis 

Notieren Sie die Antworten auf die Fragen in Tabelle 1 und Tabelle 2 der FDA-Leitfaden für den Inhalt von Zulassungsanträgen für Software in Medizinprodukten  in diesem Dokument. Fügen Sie eine Begründung für den ermittelten Grad der Besorgnis bei. 

2. Software Beschreibung

Dieses Dokument stellt die Gerätesoftware vor und sollte daher einen umfassenden Überblick über die Merkmale, Funktionalitäten und den Verwendungszweck geben. Es sollte die Programmiersprache, die Hardwareplattform, das Betriebssystem und die Verwendung von Standardsoftware enthalten. Gegebenenfalls sollten Abbildungen und Diagramme beigefügt werden. 

Falls das Gerät Standard-Software verwendet, lesen Sie den FDA-Leitfaden "Leitfaden für die Verwendung von Standardsoftware in Medizinprodukten." 

3. Gefahrenanalyse für das Gerät 

 Eine Gefahrenanalyse des Geräts ist ein Muss. Dabei sollten alle vorhersehbaren Gefahren im Zusammenhang mit der bestimmungsgemäßen Verwendung des Geräts (Software und Hardware) erfasst werden. Die Risikoanalyse sollte in Übereinstimmung mit ISO 14971. Die Gefahrenanalyse sollte die Gefahr, das Risiko, den Schweregrad der Gefahr, die Ursache der Gefahr, die Risikokontrollmaßnahme und die Überprüfung der Kontrollmaßnahme ermitteln. 

4. Spezifikation der Softwareanforderungen

Die Software Requirements Specification (SRS) dokumentiert alle Anforderungen an die Software. Im Grunde beschreiben die Anforderungen, was die Software leisten soll. Die Anforderungen können in verschiedene Kategorien eingeteilt werden, wie z. B. funktional, Leistung, Benutzeroberfläche und Vorschriften. 

Bei kleineren LoC kann die SRS eine Zusammenfassung der funktionalen Anforderungen sein, bei mittleren und großen LoC müssen die Anforderungen jedoch detailliert und in der Regel aufgelistet sein. Stellen Sie sicher, dass jeder aufgelisteten Anforderung eine Anforderungs-ID zugewiesen ist, z. B. SRS-01, SRS-02 usw. 

Hier sind einige Beispiele für das SRS: 

Hardware-Anforderungen: Fügen Sie die Anforderungen über -  

• Mikroprozessoren 
• Speichergeräte
• Sensoren 
• Energiequellen 
• Sicherheitsmerkmale
• Kommunikation

Anforderungen an die Programmierung: Einschließlich der Anforderungen an die Programmgröße, Einschränkungen usw. 

Schnittstellenanforderungen: Dazu gehören Anforderungen, die die Kommunikation zwischen der Software und Hardware-Geräten wie Druckern und Monitoren beschreiben. Andere Anforderungen, wie das Betriebssystem, mit dem die Software kompatibel ist, und so weiter. 

Software Performance and Functional Requirements Software performance and functional requirements include algorithms or control characteristics for therapy, diagnosis, monitoring, alarms, analysis, and interpretation with full text references or supporting clinical data, if necessary. 

Die Leistungs- und Funktionsanforderungen an die Software können auch Folgendes umfassen:

• Geräteeinschränkungen aufgrund von Software 
• Interne Software-Tests und -Kontrollen
• Fehler- und Unterbrechungsbehandlung 
• Fehlererkennung, -toleranz und Wiederherstellungsmerkmale 12 Enthält unverbindliche Empfehlungen 
• Sicherheitsanforderungen
• Zeit- und Speicheranforderungen 
• Identifizierung von Standardsoftware, falls erforderlich. 

5. Architektur-Design-Diagramm

 In diesem Dokument werden die Beziehungen, der Datenfluss und die Interaktion zwischen den Hauptkomponenten oder Funktionsblöcken der Software klar dargestellt. Dies wird in der Regel in Form von Flussdiagrammen, Blockdiagrammen und gegebenenfalls anderen Formen dargestellt. Bei mittelschwerer und schwerer Software kann das Entwurfsdiagramm Zustandsdiagramme enthalten. 

6. Software-Entwurfsspezifikationen (SDS)

Die Umsetzung der Anforderungen wird in diesem Dokument detailliert beschrieben. Jedes SDB ist zu nummerieren, z. B. SDS-01, ähnlich wie die SRS. Zu jeder in der SRS enthaltenen Anforderung sollte es eine entsprechende Entwurfsspezifikation geben. Es ist jedoch auch möglich, dass eine einzige Entwurfsspezifikation einer Gruppe von Anforderungen entspricht. 

7. Rückverfolgbarkeitsanalyse

Dieses Dokument verknüpft die Anforderungen, die Entwurfsspezifikation, die Gefährdungen und die V&V-Tests. Die Rückverfolgbarkeitsmatrix kann wie unten dargestellt entworfen werden, Details können nach Bedarf hinzugefügt werden: 

Benutzerbedarf (optional)	SRS	SDS	Gefahren	V&V-Testfälle
UND-001	SRS-001 SRS-002	SDS-001	Haz-001	TC-001
UND-002	SRS-002	SDS-001 SDS-002	Gefahr-002	TC-002 TC-004

 

8. Beschreibung der Software-Entwicklungsumgebung (SDED)

Für mittelschwere und schwere Software muss ein SDED vorgelegt werden, in dem der Lebenszyklusplan für die Softwareentwicklung, die Wartung und die Softwareaktivitäten beschrieben werden. Der Detaillierungsgrad unterscheidet sich für Moderate und Major. Siehe EN 62304 Tabelle 1: Tabelle A.1 - Zusammenfassung der Anforderungen nach Software-Sicherheitsklasse. Diese Tabelle kann verwendet werden, um die einzubeziehenden Elemente und die zu dokumentierenden Aktivitäten für die jeweilige Klasse zu bestimmen. Die drei Klassen A, B und C entsprechen dem Grad der Besorgnis der FDA.  

9. Dokumentation der Verifizierung und Validierung

Geringfügige LoC: Dokumentieren Sie die Tests auf Geräteebene und die Integrationstests (falls zutreffend). Stellen Sie sicher, dass die Testfälle ein Akzeptanzkriterium und eine Zusammenfassung der Testergebnisse enthalten. 

Moderater LoC: Dokumentieren Sie eine zusammenfassende Liste der Validierungs- und Verifizierungsaktivitäten und ihrer Ergebnisse. Einschließlich Akzeptanzkriterien. Sicherstellen, dass die Rückverfolgbarkeitsanalyse auf die Testfall-IDs verweist. 

Wichtiger LoC: Zusätzlich zu den oben genannten Informationen (Moderate LoC) sollte eine Beschreibung aller fehlgeschlagenen Tests und der daraufhin vorgenommenen Änderungen dokumentiert werden. 

10. Revisionsstand Historie

Dokumentieren Sie die wichtigsten Änderungen an der Software und stellen Sie sicher, dass der letzte Eintrag die neueste Version der Software ist. Geben Sie die Versionsnummer und das Datum an und beschreiben Sie die Änderungen im Vergleich zur vorherigen Version. 

11. Ungelöste Anomalien 

Dokumentieren Sie die ungelösten Fehler, die in der zu veröffentlichenden Software vorhanden sind. Erfassen Sie für jeden Fehler die folgenden Angaben: 

• Das Problem
• Auswirkungen auf die Geräteleistung 
• Geplante Fristen für die Behebung dieser Fehler (falls zutreffend) 

The above eleven documents cover the entire documentation necessary for the device software. Additionally, FDA requires Cybersecurity Documentation such as cybersecurity plan, risk management and V&V tests and their results. For more information on this FDA guidelines on Cybersecurity requirements refer to: Inhalt von Anträgen vor der Markteinführung für das Management der Cybersicherheit in Medizinprodukten. 

Referenzen: 

• Leitfaden für den Inhalt von Anträgen vor der Markteinführung von in Medizinprodukten enthaltener Software

Benötigen Sie Hilfe bei der FDA-Softwaredokumentation für Medizinprodukte? Setzen Sie sich mit freiberuflichen Autoren in Verbindung und Experten für FDA-Einreichungen auf Kolabtree.