Worum geht es in dem FDA Guidance?
Im November 2021 wurde eine Draft-Version des FDA-Guidances „Content of Premarket Submissions for Device Software Functions“ veröffentlicht. Nun ist diese Version seit 14.Juni 2023 offiziell. Dieser Guidance ersetzt die „Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices“ vom Mai 2005.
Die erste Neuerung, die sofort ins Auge fällt, ist der Wechsel von „Software, die im Medizinprodukt enthalten ist“ auf die „Gerätesoftwarefunktion“ = „Device Software Function“. Durch die Bezugnahme auf die Begriffe „Device“ und „Function“ wird der Horizont erweitert für sämtliche Software, die mit ihrer Funktion zur Erfüllung der Zweckbestimmung beiträgt – nicht nur wie bisher auf Software als Teil eines Medizinprodukts (Embedded Software).
Im neuen Guidance wird die Mindestmenge an Informationen empfohlen, die bei einer Einreichung (sog. Submission) für ein Medizinprodukt, welches eine oder mehrere Softwarefunktionen umfasst, vorgelegt werden muss.
Im Guidance Dokument umfasst der Begriff „Antrag vor dem Inverkehrbringen“ unter anderem:
- eine Premarket Notification 510(k) Submission,
- einen Antrag auf De-Novo-Klassifizierung,
- eine Premarket Approval (PMA),
- eine Investigational Device Exemption (IDE),
- eine Humanitarian Device Exemption (HDE) oder
- einer Biologics License Application (BLA).
Dieser Guidance gilt dagegen nicht für Software für die automatisierte Herstellung und Qualitätssysteme oder Software, die kein Medizinprodukt darstellt.
Was ist die größte Neuerung an dem FDA Guidance?
Mit ihrem Guidance hat sich die FDA etwas der IEC 62304 „Medizingeräte-Software – Software-Lebenszyklus-Prozesse“ angenähert. Jedoch besteht nach wie vor der signifikante Unterschied, dass die Software-Sicherheitsklassifizierung der IEC 62304 (Class A, B, C) mögliche Risiko-beherrschungsmaßnahmen berücksichtigt, der FDA Guidance dagegen die Bestimmung seines „Documentation level“ – bisher „Level of concern“ – auf die reine Anwendung/Zweckbestimmung vor der Implementierung von Risikobeherrschungsmaßnahmen richtet.
Beim bisherigen „Level of concern“ wurde zwischen den drei Stufen „Minor“, „Moderate“ und „Major“ unterschieden – je nach Risiko für die Patienten oder für Personen in der Umgebung des Medizinprodukts. Je höher die Klassifizierung, desto größer der Dokumentationsumfang.
Nun wird mit dem neuen Guidance die Klassifizierung komplett neu strukturiert: Es gibt jetzt keinen „Level of concern“ mehr, sondern einen „Documentation level“ mit zwei Klassen:
- Basic Documentation sollte als Mindestansatz bei jeder Einreichung vor dem Inverkehrbringen vorgelegt werden.
- Enhanced Documentation sollte zusätzlich bei jeder Einreichung vor dem Inverkehrbringen vorgelegt werden, bei dem eine/mehrere Gerätesoftwarefunktionen eine Rolle spielen, deren Ausfall oder Fehler eine Gefahrensituation darstellen könnte, die wahrscheinlich zum Tod oder zu schweren Verletzungen eines Patienten, eines Anwenders des Produkts oder anderer Personen in der Anwendungsumgebung führt/führen kann. Dazu gehört auch die Wahrscheinlichkeit, dass die Produktfunktionalität absichtlich oder unabsichtlich durch unzureichende Cybersicherheit des Produkts beeinträchtigt wird.
Unabhängig vom Risiko wird die „Enhanced Documentation“ für eine Reihe von spezifizierten Medizinprodukten empfohlen, insbesondere im Zusammenhang mit Blut-Handling und für Kombinationsprodukte mit Arzneimitteln.
Beispiele für die Bestimmung des Documentation Level
- Ein nicht-invasives Blutdruckmessgerät mit aufblasbarer Manschette
- Beschreibung: Das Gerät ist ein batteriebetriebenes, wiederverwendbares Gerät für den Gebrauch zu Hause und in professionellen Gesundheitseinrichtungen und misst durch softwaregesteuertes Aufpumpen und Ablassen der Manschette den systolischen und diastolischen Blutdruck einer Person.
- Begründung: Das Versagen oder ein potenzieller Fehler der Gerätesoftwarefunktion führt zu keinem Tod oder schwerer Verletzung des Patienten, den Anwender des Geräts oder andere Personen in der Anwendungsumgebung
- Ergebnis: Basic Documentation Level
- Elektrisches Exoskelett für die unteren Extremitäten.
- Beschreibung: Ein verschreibungspflichtiges motorisiertes Exoskelett für die unteren Extremitäten, das aus einer externen, motorisierten Orthese besteht, die zu medizinischen Zwecken über die gelähmten oder geschwächten Gliedmaßen einer Person gelegt wird.
- Begründung: Das Versagen oder ein potenzieller Fehler der Gerätesoftwarefunktion könnte zum Tod oder schwerer Verletzung des Patienten führen
- Ergebnis: Enhanced Documentation Level
- Software-Gerät zur Netzhautdiagnose
- Beschreibung: Das verschreibungspflichtige Gerät enthält einen KI-/ML-fähigen Algorithmus, der dazu bestimmt ist, Bilder für ein diagnostisches Screening auszuwerten, um Netzhauterkrankungen oder -zustände zu erkennen.
- Begründung: Das Versagen oder ein potenzieller Fehler der Gerätesoftwarefunktion könnte zum Tod oder schwerer Verletzung des Patienten führen, falls Erkrankungen nicht (rechtzeitig) erkannt werden.
- Ergebnis: Enhanced Documentation Level
Empfohlener Dokumentationsumfang
Die folgende Tabelle gibt einen Überblick über die empfohlene Dokumentation für jedes Software-Dokumentationselement und die entsprechende Dokumentationsstufe.
|
Software-Dokumentation |
Basic Documentation Level |
Enhanced Documentation Level |
|
Bewertung der Dokumentationsstufe |
Erklärung und Begründung zur Wahl der Dokumentationsstufe sollte die Zweckbestimmung des Produkts berücksichtigen und gegebenenfalls Verweise aus der Einreichungsdokumentation zur Untermauerung der Wahl enthalten. |
|
|
Software-Beschreibung |
Softwarebeschreibung, einschließlich eines Überblicks über die wichtigsten Software-Features und -Funktionen, Analysen, Eingaben, Ausgaben und Hardware-Plattformen. Evtl. Software-Änderungen seit letzter FDA-Einreichung. Unbedingt berücksichtigen: Bedienung der Software (Intended use, vorgesehener Anwender, Patientenpopulation, Analysemethoden, ML-/KI-Methoden), SW-Besonderheiten (HW-/SW-Plattform, OTS-SW, SW-Version und evtl. Unterschiede zwischen einzelnen Versionen), SW-Eingaben und -Ausgaben (Eingabedaten und ihr Format, wer liefert die Eingaben, Ausgaben und ihr Format, wer empfängt die Ausgaben, Beeinflussung oder Ersatz manueller Handlungen, Auslegung auf Interoperabilität) |
|
|
Risk Management File |
Risikomanagementplan aus dem hervorgeht, wie das Gesamtrestrisiko gegen den Nutzen der beabsichtigten Verwendung des Produkts abzuwägen ist. Risikobewertung sollte für die komplette Software/das Softwaresystem vorgelegt werden und Risikoanalyse, Risikobewertung, Risikokontrolle und Nutzen-Risiko-Analyse umfassen. Risikomanagementbericht sollte eine Aufzeichnung der Umsetzung des Risikomanagementplans, einen Bewertungsnachweis der Risikomanagementakte und der Akzeptanz des Restrisikos sowie einen Nachweis für die Eignung der gewählten Methoden für die Sammlung und Bewertung relevanter Informationen aus der Produktion und dem Post Market Surveillance enthalten. |
|
|
Software Requirements Specification (SRS) |
Die Software Requirements Specification beschreibt die Anforderungen an die Software/das Softwaresystem und soll dabei: – in einem gut lesbarem, geordneten und auf der Ebene des Softwaresystems bzw. der Teilsysteme dargestellten Format, – mit ausreichenden Informationen, um die Rückverfolgbarkeit der Informationen in Bezug auf die anderen Elemente der Softwaredokumentation (z. B. System-Anforderungen, System- und Software-Architektur, Software-Design-Spezifikation, Software-Tests) zu verstehen, – bei Änderungen eines bereits zugelassenen oder freigegebenen Produkts, mit der Identifizierung aller relevanten Unterschieden, – mit Identifizierung aller Anforderungen, die für die Sicherheit und Wirksamkeit des Produkts am kritischsten sind und – mit Referenz auf die notwendigen Dokumente vorgelegt sein. |
|
|
System und Software Architektur Design |
Die System- und Software-Architektur stellt detaillierte Diagramme der Module, Schichten und Schnittstellen zur Verfügung, aus denen das Gerät besteht, ihre Beziehungen, die Dateneingänge/-ausgänge und den Datenfluss sowie die Art und Weise, wie Benutzer oder externe Produkte mit dem System und der Software interagieren (evtl. mit Texten beschreiben, um die Prüfung zu erleichtern). Auch die Beziehungen zwischen den einzelnen Diagrammen sollten klar dargestellt werden. Wichtig sind visuelle Aspekte (z.B. Verwendung von Farbe oder anderen visuellen Mitteln), sprachliche Aspekte (z.B. Verwendung von Anmerkungen, konsistente Terminologie/Begriffe), eindeutige Referenzen. |
|
|
Software Design Specification (SDS) |
Nicht notwendig. Die FDA kann bei Bedarf zusätzliche Informationen über die Auslegung anfordern, um die Sicherheit und Wirksamkeit des Produkts zu bewerten |
Die Software Design Specification beschreibt die technischen Designdetails der Softwarefunktionen, die vollständige und korrekte Umsetzung aller Anforderungen der SRS durch das Software Design und die Rückverfolgbarkeit des Software Designs auf die SRS in Bezug auf Verwendungszweck, Funktionalität, Sicherheit und Effektivität. Es wird erwartet, dass die SDS als Guidance für die Implementierung und das Testen diente und nicht nachträglich erstellt wurde. |
|
Software-Entwicklung, Konfigurations-management und Wartungs-maßnahmen |
Zusammenfassung des Lebenszyklus-Entwicklungsplans, Konfigurationsmanagement und Wartungsaktivitäten. ODER Konformitätserklärung gemäß der von der FDA anerkannten Version der IEC 62304, einschließlich der Unterkapitel 5.1.1-5.1.3, 5.1.6-5.1.9, Kapitel 6 (Software-Wartungsprozess) und Kapitel 8 (Software-Konfigurationsmanagement-prozess), sowie gegebenenfalls andere. |
Basic Documentation Level, PLUS vollständige Dokumentation der Umsetzung der Konfigurationsmanagement- und Wartungspläne; ODER Konformitätserklärung zu der von der FDA anerkannten Version der IEC 62304, einschließlich Unterkapitel 5.1 (Softwareentwicklungsplanung), Kapitel 6 (Softwarewartungsprozess) und Kapitel 8 (Softwarekonfigurationsmanagementprozess), sowie ggf. weitere. |
|
Software-Tests als Teil der Verifizierung und Validierung |
Eine Zusammenfassung der Testaktivitäten auf Unit-, Integrations- und System-Ebene (inkl. Änderungen, als Reaktion auf fehlgeschlagene Tests und Regressionsanalyse und -tests); UND Testprotokoll auf Systemtestebene mit den erwarteten Ergebnissen, den tatsächlichen Ergebnissen, den Akzeptanzkriterien sowie dem Testbericht auf Systemebene. Der Testbericht auf Systemebene sollte zeigen, dass alle Tests durchgeführt wurden, die Testergebnisse akzeptabel waren und alle ungelösten Anomalien auf der Grundlage einer Risikobewertung für den Release-Kandidaten akzeptiert wurden. |
Basic Documentation Level, PLUS Testprotokolle auf Unit- und Integrationsebene mit den erwarteten Ergebnissen, den tatsächlichen Ergebnissen, den Akzeptanzkriterien sowie den Testberichten auf Unit- und Integrationsebene. Die Testberichte über die Unit- und Integrationstests sollten zeigen, dass alle Tests durchgeführt wurden, die Testergebnisse akzeptabel waren und alle ungelösten Anomalien auf der Grundlage einer Risikobewertung für den Release-Kandidaten akzeptiert wurden. |
|
Software Version History |
Eine Historie der Softwareversionen, die im Rahmen der Verifizierungs- und Validierungsaktivitäten auf der Unit-, der Integrations- und der System-Ebene getestet und dokumentiert wurden, beginnend mit der Version, die dem regulären Design Control Process unterlag. Dies erfolgt in der Regel in Tabellenform mit Datum und Versionsnummer der getesteten Version (einschließlich, falls zutreffend Bench-, Tier- und klinische Tests) sowie eine kurze Beschreibung aller Änderungen der Version gegenüber der zuvor getesteten Version. Als letzter Eintrag soll die endgültige freigegebene Version aufgelistet sein mit Angabe der Unterschiede zu der zuvor getesteten Version zusammen mit einer Bewertung der potenziellen Auswirkungen der Änderungen auf die Sicherheit und Wirksamkeit des Produkts. |
|
|
Unresolved Software Anomalies |
Liste der verbleibenden ungelösten Software-Anomalien üblicherweise als Tabelle mit – Beschreibung der Anomalie, – Angabe der Art und Weise, wie die Anomalie entdeckt wurde, und, soweit möglich, Angabe der Grundursache(n) der Anomalie; – Bewertung der Auswirkungen der Anomalie auf die Sicherheit und Wirksamkeit des Produkts sowie die Usability; – Ergebnis der Bewertung; und – Risikobasierte Begründung auf Basis der etablierten Risikopolitik, warum die Anomalie nicht korrigiert oder behoben wurde Die Anwendung eines Fehlerklassifizierungssystems oder einer Taxonomie auf jede Anomalie wird empfohlen. |
|
Was sonst noch zu beachten ist
Die Guidance muss für alle Einreichungen seit dem 14. August 2023 befolgt werden.
Alle einzureichenden Dokumente sollen leserlich und verständlich sein, dies bedeutet zum Beispiel
- keine abgeschnittenen Diagramme,
- keine unzureichende Schriftgröße,
- nicht lesbar ohne starke Vergrößerung
Andernfalls kann dies dazu führen, dass die FDA zusätzliche Informationen anfordert und die Zulassung sich verzögert.
Auch wenn die FDA mit dem neuen Guidance Dokument keine Traceability-Matrix o.ä. als Teil der Einreichung vor der Markteinführung fordert, wird erwartet, dass der Hersteller diese Analyse in seiner Auslegungsdokumentation für das Produkt dokumentiert. Die FDA bewertet beispielsweise anhand der vorgelegten Risikobewertung, wie sich identifizierte Risikokontrollmaßnahmen auf die Produktanforderungen, die Softwaretests und die Kennzeichnung zurückverfolgen lassen. Besonderer Fokus wird auf Rückverfolgbarkeit zwischen den in der Software-Anforderungsspezifikation aufgeführten Anforderungen und den Informationen zu diesen Anforderungen und anderen Software-Dokumenten, wie der Software-Design-Spezifikation, dem System- und Software-Architektur-Design und der Software-Testdokumentation, gelegt.
Bei der Erstellung der Software Version History müssen nicht alle getesteten Versionen aufgelistet werden, sondern nur die, die bei den wichtigsten Entwicklungsschritten eingesetzt wurden. Beispielsweise die Software-Version bei der Klinischen Studie, bei den Usability-Tests, bei den Tests im Labor, Standardtests im Haus, usw. Zu den aufgelisteten Versionen müssen alle Informationen vorliegen, damit der Prüfer die Software-Unterschiede leicht nachvollziehen kann.
Bitte beachten Sie: Eine Konformitätserklärung für die vollständige Einhaltung der Norm ANSI/AAMI/IEC 62304 allein ist für die Zulassung nicht ausreichend, da es Unterschiede bei der Kategorisierung der Gerätesoftwarefunktion und empfohlenen Unterlagen zwischen dem FDA Guidance und der IEC 62304 gibt.
In diesem Artikel wurden nur die wichtigsten Inhalte des Guidance genannt. Im Guidance werden noch weitere Kriterien und Aspekte der einzelnen einzureichenden Dokumente erläutert.
Sie benötigen Unterstützung bei der Erstellung Ihrer Softwaredokumentation? Nach IEC 62034, der FDA Guidance oder unter Beachtung beider Regularien? Sprechen Sie uns an, wir erstellen gerne mit Ihnen und für Sie die notwendige Dokumentation.
Bitte beachten Sie, dass alle Angaben und Auflistungen nicht den Anspruch der Vollständigkeit haben, ohne Gewähr sind und der reinen Information dienen.
