Software Change: Was die FDA von Ihnen erwartet

Donnerstag 1. September 2016

Wie Sie einen Software Change regulatorisch konform durchführen, erläutert die FDA in einem neuen Draft Guidance.

Sie beschreibt darin, wann Sie eine erneute 510(k) Einreichung (Premarket Notification) benötigen und wann Sie die Änderungen „nur“ dokumentieren müssen.

Was ein Software Change ist

Software Changes im „Scope“ des Guidance Documents

Unter einem „Software Change“, der in den Anwendungsbereich des Guidance Documents fällt, versteht die FDA jede Änderung an einer Software, die als standalone Software oder als Teil eines Produkts (embedded Software) bereits legal nach einem 510(k) Verfahren zugelassen wurde.

D.h. für Änderungen der Software während der Entwicklung ist das Guidance Document ebenso wenig anwendbar wie für Software, die ein anderes Zulassungsverfahren (z.B. PMA) durchlaufen hat.

Beispiele für Software Changes

Beispiele für Software Changes sind:

  • Geänderter Algorithmus, um Nutzen für Patienten weiter zu erhöhen
  • Verbesserung der GUI (Benutzerschnittstelle) z.B. um Risiken zu minimieren
  • Austausch einer Komponente eines Drittherstellers auf die neuste Version
  • Implementierung einer neuen risikominimierenden Maßnahme
  • Umsetzung eines neuen Kundenwunsches z.B. in Form zusätzlicher Funktionalität
  • Fehlerbehebung (Bug Fix)
  • Refactoring, um Wartbarkeit zu verbessern
  • Umstieg auf nächste Version der Programmiersprache

IEC 62304 und Software Changes

Die IEC 62304 legt ebenfalls fest, was Hersteller bei Software Changes beachten sollten. Diese Vorgaben, zu denen Sie weiter unten mehr erfahren, betreffen aber nicht die Fragestellung, ob eine Neueinreichung (z.B. bei einer benannten Stelle) notwendig ist.

Wann Sie bei der FDA neu einreichen müssen

Die Regeln

Die FDA verlangt bei Änderungen immer eine Neueinreichung, es sein denn eine der folgenden Bedingungen ist erfüllt (die Nummern beziehen sich auf die Grafik unten):

  • (1) Die Änderung dient ausschließlich der Verbesserung der IT-Sicherheit
  • (2) Die Änderung ist eine reines Bug-Fixing.
  • Es spricht auch sonst nichts dagegen.

Den dritten Punkt können Sie dann als erfüllt sehen, wenn alle(!) der folgenden Bedingungen zutreffen

  • (3) Es gibt keine neuen Fehlerursachen, d.h. Elemente in einer Ursachenkette, die zu einem nennenswerten Schaden führen können.
  • (4) Es entstehen dadurch keine neuen Gefährdungen oder Gefährdungssituationen, die zu einem nennenswerten Schaden führen können.
  • (5) Die Änderung betrifft keine bereits bestehende risikominimierende Maßnahme oder bedingt eine solche Maßnahme.
  • (6) Die (klinische) Leistungsfähigkeit und die Erfüllung der Zweckbestimmung können durch die Änderung nicht beeinträchtigt werden.
  • (7) Sonstige Änderungen sind beherrscht.

Erneut gibt es einen „Gummiparagraphen“ (Punkt 7.), auf den wir gleich zu sprechen kommen.

Software Change aus Sicht der FDA

Software Change: Zum Vergrößern klicken

Die Darstellung macht klar, dass die FDA die Notwendigkeit eines erneuten Einreichens v.a. davom abhängig macht, ob zusätzliche oder höhere Risiken durch den Software Change entstehen können. Gleichzeitig möchte die FDA Verbesserungen der IT-Sicherheit nicht durch bürokratische Hürden erschweren.

Beispiele

Die Nummerierung in der Liste oben entspricht der der FDA. Zu jedem dieser Punkte nennt die FDA Beispiele, die wir hier aufgreifen, ergänzen oder in verständlicherer Sprache wiedergeben.

  1. Verbesserung der IT-Sicherheit
    • Prüfen von Benutzereingaben einer Anwendung auf Cross-side Scripting
    • Austausch des Verschlüsselungsalgorithmus durch eine sicherere Version
  2. Bug-Fixing (Herstellen der spezifizierten Funktionalität)
    • Austausch des fehlerhaften Kleiner-Zeichens (<) durch das korrekte Kleiner-Gleich-Zeichen (≤).
    • Ergänzung der vergessenen Maskierung von Sonderzeichen beim Einlesen von HL7 Nachrichten
  3. Neue Fehlerquellen
    • Hinzufügen eines neuen Behandlungsparameters bei einem EEG-Gerät
    • Software für ein zusätzliches Betriebssystem anbieten
  4. Neue Gefährdungen oder Gefährdungssituationen
    • Ein implantiertes aktives Medizinprodukt, das Software enthält, soll über kabellose Verbindung „von außen“ konfiguriert werden können. Diese neue Übertragung kann eine Energiezufuhr und damit eine neue bzw. geänderte Gefährdung(ssituation) bedeuten.
  5. Neue oder geänderte Risikokontrollmaßnahmen
    • Die Alarmgrenzen eines Chirurgie-Roboters werden aufgeweitet, um in der Praxis auftretende Fehlalarme zu minimieren.
    • Bei der Überprüfung einer Probennummer verlangt die Software vom Bediener nicht mehr eine explizite Freigabe der Messung, sondern gibt nur eine Warnung aus und protokolliert das Problem.
  6. Möglicher Einfluss auf Leistungsfähigkeit oder Erreichen der Zweckbestimmung
    • Um den Durchsatz eines IVDs zu erhöhen, ändert der Hersteller die Software dahingehen, dass sie die Messung verkürzt.
    • Der Hersteller möchte durch einen neuen Software-Algorithmus die Detektion von Arhythmien aus EKG-Daten verbessern.
  7. Weitere Faktoren: Es gibt Faktoren, bei denen keines der o.g. Kriterien greift, bei denen aber dennoch eine Neueinreichung abgewogen werden muss. Die FDA ermutigt die Hersteller in diesem Graubereich (wie sie es selbst nennt), Kontakt mit ihr aufzunehmen. Als Beispiele nennt sie:
    • Änderungen an Programmiersprache
    • Portierung auf neue Hardware, Betriebssysteme, Middleware usw.
    • Reengineering und Refactoring

Software Change: Was Sie noch beachten sollten

Unabhängig von der Frage, ob ein Software Change eine Neueinreichung erforderlich macht, sollten Sie folgendes bedenken:

  • Änderungen an der Software – auch während der Entwicklung – müssen einem Prozess folgen.
  • Dazu zählt, dass Änderungen freigegeben sein müssen,
  • dass die Software nach den Änderungen ganz oder teilweise neu geprüft (Regressionstests) wird und
  • dass Sie Änderungsanfragen daraufhin untersuchen, ob weitergehende Maßnahmen wie eine Behördenmeldung oder ein Rückruf notwendig sind. Lesen Sie hierzu auch den Artikel zu den Change Requests.
  • Ihre benannte Stelle kann unabhängig von der Vorstellung der FDA von Ihnen verlangen, Softwareänderungen (Software Changes) zu kommunizieren.

Kategorien: FDA Zulassung - die U.S. Food and Drug Administration, Software & IEC 62304
Tags:

Kommentar schreiben