FDA Zulassung – die U.S. Food and Drug Administration

Dieser Artikel wendet sich insbesondere an Personen die Medizinprodukte, die Software enthalten oder standalond Software sind, für den US-Markt entwickeln und daher den Forderungen der FDA (Food and Drug Administration) gerecht werden müssen.
FDA Logo

Aktuelles

Wir versorgen Sie in unserem FDA-Update mit den aktuellsten Informationen zu der U.S. Gesundheitsbehörde.

Die FDA

Die FDA, die Food and Drug Administration, ist eine US-amerikanische Behörde, die für die Zulassung und Marktüberwachung von Lebensmitteln, Medikamenten und Medizinprodukten verantwortlich ist. Die Behörde ist mit Polizeigewalt ausgestattet und darf im Rahmen gegebener Grenzen Gesetze erlassen, die im 21 CFR nachzulesen sind. Insofern ist die FDA Legislative, und Exekutive in einer „Person“.

Die U.S.-Behörde lässt – ebenfalls im Gegensatz zu Europa – Medizinprodukte zu, wobei es mehrere Verfahren wie die nach 510(k) oder PMA gibt.

Bekannt und gefürchtet ist die FDA für ihre Vorort-Inspektionen mit den ggf. resultierenden Abweichungsberichten (Form 483) und Warning Letters. Die FDA überwacht den Markt aktiver als europäische Behörden und fahndet nach Produkten, die Medizinprodukte gemäß Definition sind aber nicht entsprechend den Regularien entwickelt, hergestellt und vertrieben werden.

Die Konsequenzen von Abweichungen sind gravierender. Sie reichen vom Veröffentlichen all der Schandtaten (siehe Artikel zur FDA MAUDE Datenbank), bis zur gewaltsamen Werksschließung, vom Importverbot bis zum Einsammeln aller Produkte durch US-Marshalls – auf Kosten des Unternehmens versteht sich.

Der Maßnahmenkatalog der FDA

Es ist zu empfehlen, sich an die Spielregeln der FDA zu halten. Welche das sind, speziell in Bezug auf das QM-System und 21 CFR part 820, lernen Sie auch in den Videotrainings im Auditgarant.

FDA und Software-Entwicklung

1. Levels of Concern versus Sicherheitsklasse der IEC 62304

Die Entwickler medizinischer Software kennen die Norm IEC 62304 gut, welche die Anforderungen an den Software-Lebenszyklus beschreibt. Diese Norm definiert drei Sicherheitsklassen, beispielsweise die Klasse A, „Keine Verletzung oder Schädigung der Gesundheit ist möglich“, oder Klasse C, „Tod oder schwere Verletzung möglich“. Das erinnert doch sehr stark an die drei „Levels of Concern“, welche die FDA einführt. Oder? Doch Vorsicht Falle!

In der Tat gleichen die Definitionen dieser Levels sehr denen der Sicherheitsklassen. Beispielsweise ist der „Major Level“ wie folgt festgelegt:

„Major if a failure or latent flaw could directly result in death or serious injury to the patient or operator […]“.

Nur die Konsequenzen, welche aus der Klassifizierung gezogen werden (dürfen), unterscheiden sich: Während die IEC 62304 für die Komponenten der niedrigen Klasse A kaum Dokumentation verlangt, verzichtet die Behörde nur darauf, dass diese Dokumentation für eine Premarket Submission nach 510(k) eingereicht wird. Von einem Verzicht auf das Erstellen der Dokumente schreibt der „Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices“ nichts.

Nur diesen kleinen aber wesentlichen Unterschied wollen wir Software-Entwickler meistens nicht wahrhaben.

Lesen Sie hier mehr zum  Level of Concern.

Sie wünschen weitere Tipps und Informationen zur FDA und zu den Zulassungsverfahren? Der Auditgarant bietet Ihnen hochwertige Videotrainings. Schneller, kompetenter und unterhaltsamer werden Sie kaum etwas über die FDA erfahren. Also, melden Sie sich gleich an!

2. Guidance-Dokumente der FDA für Software

Für uns Entwickler medizinischer Software sind v.a. die folgenden Guidance-Dokumente der FDA relevant.

a) Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices

Dieses Dokument zu den 510(k) Submissions kennt den „Level of Concern“. Diese Levels sind auf den ersten Blick sehr vergleichbar mit den Sicherheitsklassen der 62304. Aber – und jetzt kommt die Falle – abhängig vom „Level of Concern“ dürfen nur weniger Dokumente eingereicht werden. Erstellt werden müssen sie in jedem Fall. Siehe oben ….
Zu diesen Dokumenten zählen

  • Festlegung des Levels of Concern
  • Zusammenfassende Beschreibung der Software
  • Risikoanalyse
  • Software Requirements Specification (IEC 62304: Software-Anforderungen)
  • Architecture Design Chart (IEC 62304: Software-Architektur)
  • Software Design Specification (IEC 62304: Detailliertes Design)
  • Beschreibung der Entwicklungsumgebung (IEC 62304: Teil des Entwicklungsplans)

Wie Sie diese Dokumente „FDA-konform“ erstellen zeigt Ihnen Schritt für Schritt der Auditgarant. Diese Serie an Videotrainings geht auch auf die Zulassungsverfahren ein.

Gibt es also keine Chance, den (Dokumentations-)Aufwand an das Risiko des Produkts oder des Beitrags, den die Software dazu liefert, anzupassen?

b) General Principles of Software Validation

Um das zu beantworten, sollten wir einen Blick in ein zweites Guidance-Dokument General Principles of Software Validation werfen. Dieses Dokument kennt keine „Levels of Concern“, wohl aber einen risikobasierten Ansatz. Doch was bedeutet das? Dieser Ansatz erlaubt es sehr wohl, abhängig von Risiko beispielsweise mehr oder weniger intensiv zu testen. Nur darf es nicht sein, dass – wie das bei der IEC 62304 der Fall wäre – eine Aktivität ganz ausgelassen bzw. nicht dokumentiert wird.

c) FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices

Dieses Dokument diskutiert Anforderungen an den Einsatz von Off-The-Shelf Software“, die etwa aber nicht ganz den SOUPs entspricht. Die Anforderungen sind aber detaillierter als die der IEC 62304 und können im Extremfall ein Audit beim Hersteller dieser Fremdsoftware einschließen.

d) Content of Premarket Submissions for Management of Cybersecurity in Medical Devices

Die FDA beschreibt in diesem Dokument, wie und welche Hersteller die Risiken durch mangelnde IT-Sicherheit bzw. durch Cyber-Angriffe im Risikomanagement betrachten müssen.

e) Mobile Medical Applications

Dieses Guidance Dokument der FDA klärt welche mobilen Anwendungen als Medizinprodukt zu klassifizieren sind und bei welchen die FDA eine Zulassung erwartet. Interessanterweise ist das nicht bei allen Apps, die der Definition des Begriffs Medizinprodukt entsprechen. Dazu bezieht die FDA in weiteren Dokumenten Stellung. Mehr dazu weiter unten.

f) Usability Guidance

Allgemein für Medizinprodukte, aber für Software auch relevant ist das Guidance Document zum Usability Engineering, von der FDA auch Human Factors Engineering genannt.

3. FDA und IEC 62304

Was nützt Ihnen also die IEC 62304 bei der amerikanischen Gesundheitsbehörde? Hier gibt es widersprüchliche Ansichten und Erfahrungen in Audits:

  • Auf der einen Seite ist die IEC 62304 ein „recognized standard“ der FDA, sie hat daran sogar mitgewirkt. D.h. dass die Einhaltung der IEC 62304 geeignet sein könnte, beim Auditor vermuten zu lassen, dass die Software regelkonform entwickelt wurde – mit den oben genannten Einschränkungen.
  • Auf der anderen Seite kann Ihre Behauptung, dass Sie IEC 62304 konform sei, dazu führen, dass dies auch geprüft wird. Wenn Sie hier patzen haben Sie ein Problem. Umgekehrt ist die IEC 62304 alleine auch nicht ausreichend, um die Übereinstimmung der Softwareentwicklung mit den Forderungen der FDA zu „beweisen“. In anderen Worten: Die Einhaltung der Norm kann nach Einschätzung mancher schaden, aber nur wenig nützen.

Ich empfehle, IEC 62304 konform zu arbeiten. Die Norm stellt ja auch die absolute Untergrenze dessen dar, was das Berufsethos jeden Entwicklers verlangen sollte. Wer glaubt, weniger sei auch ausreichend, sollte nochmals in Erwägung ziehen, das erste Lehrjahr zum Fachinformatiker nachzuholen.

Als zweites empfehle ich für Produkte, die von der U.S.-Behörde zugelassen werden sollen und beispielsweise Sicherheitsklasse A sind, zusätzlich die fehlenden Dokumente zu erstellen – das werden im Wesentlichen die Architektur und die Unit-/Integrations-/Systemtests sein. Alles andere empfinde ich als unprofessionell.

4. FDA & mobile Apps

Die FDA arbeitet zurzeit an einem Guidance Dokument zu mobilen Anwendungen (Apps), das zum Jahresende erscheinen soll.

Die Überlegungen, die die FDA anstellt und über die ein Artikel berichtet, klingen für mich nachvollziehbar:

  • Sie möchte eine gute Balance aus technischem Fortschritt und Patientensicherheit finden.
  • Unkritische Anwendungen wie für die Fitness, Erinnerung an Rezepte oder Patientenakten sollen von den Regularien befreit sein.
  • Kleine Änderungen an der Software müssen die Entwickler nicht erneut von der FDA bewerten lassen.

Das ist alles keine revolutionären Änderungen, aber auf einige Klarstellungen dürfen wir dennoch erwarten.

Lesen Sie mehr unter dem Tag Mobile Medical Apps

Hintergrundinformationen

Kontakt mit der USA-Behörde

Sie können bei einer Anfrage zur Klassifizierung Ihres Medizinprodukts einen Request for Information nutzen.

Gründe für abgelehnte FDA-Anträge

JAMA „The Journal of the American Medical Association“ zeigt in ihrem Artikel, welche Schwierigkeiten bei der Zulassung bei der FDA auftreten können und erklärt, wie kostspielig eine Ablehnung sein kann.
Dafür wurden alle Medikamente-Anträge in den Jahren 2000 bis 2012 ausgewertet, deren Inhaltsstoffe vorher nicht in den USA vermarktet wurden. Es wurden die FDA-Antworten verwendet, um die Nichtzulassungen auszuwerten.

Von 302 Bewerbungen wurden exakt 50% sofort angenommen (151). Inklusive Nachreichungen waren es nahezu dreiviertel (222). Alle Bewerbungen, die eine oder mehrere Nachreichungen vornehmen mussten, hatten mit einer Verzögerung ihrer Zulassung von durchschnittlich 435 Tagen zu kämpfen. Diese Zahl ist enorm und zeigt, dass es sich von Anfang an lohnt, seine FDA-Zulassung auf hohem Niveau einzureichen. Ein Jahr oder länger, in dem ein Produkt nicht vertrieben werden kann, kann ein Unternehmen viel Geld kosten.

Die häufigsten Gründe für Verzögerungen waren falsche Medikamentedosierungen, die zu unpassenden Wirkungen führen könnten und die ungenügende Darstelle der eigenen Studienergebnisse. Es muss sichergestellt sein, dass das höchste Level an Sicherheit in der Wirkung und in der Analyserichtigkeit erreicht wird.

Kritik: Handelt die FDA intransparent, unvorhersehbar und unangemessen?

Erst durch den Newsletter von MedCert bin ich auf eine Studie aufmerksam geworden, die u.a. ein Stanford Professor vor einem halben Jahr veröffentlicht hat.

Wieso soll man es beschönigen. Ein gutes Zeugnis sieht anders aus:

Kritik an der FDA

In einem weiteren Satz heißt es dann:

„Survey respondents confirmed that they are able to make their products available to patients faster and at a significantly lower cost in markets such as Europe.“

Möglicherweise wird bei manchen Konsequenz und Strenge mit Bürokratie und Willkür verwechselt. Möglicherweise wird polizeiliche Gewalt als Garant für sicherere Produkte missverstanden. Schade.


Dienstag 21. Februar 2017 von Prof. Dr. Christian Johner

Nach dem Artikel zum Design Input geht es in diesem Beitrag um den Design Output, einen Begriff, den Sie wahrscheinlich am ehesten aus dem FDA Umfeld kennen.

Den ganzen Beitrag lesen »


Montag 20. Februar 2017 von Prof. Dr. Christian Johner

Unter „Design Input“ versteht man die Entwicklungsvorgaben, an die nicht nur die FDA konkrete Forderungen stellt.

Dieser Artikel beschreibt, welche Inhalte Ihr Design Input enthalten sollte. Sie erfahren, wie das Risikomanagement mit dem Design Input zusammenspielt.

Den ganzen Beitrag lesen »


Donnerstag 26. Januar 2017 von Prof. Dr. Christian Johner

Für die klinische Bewertung von Software gelten die gleichen gesetzlichen Anforderungen wie für die klinische Bewertung aller Medizinprodukte.

Doch die Methoden für die klinische Bewertung von Software unterscheiden sich teilweise. Auch deshalb haben sich die FDA und das IMDRF dazu entschlossen, gemeinsam ein eigenes „Guidance Document“ herauszugeben mit dem Titel „Software as a Medical Device (SaMD): Clinical Evaluation“ (hier zum Download) und als Entwurf veröffentlicht.

Dieser Artikel verschafft Ihnen einen Überblick darüber, wie Sie die klinische Bewertung bei Software konform mit den Anforderungen der europäischen und US-amerikanischen Behörden durchführen können.
Den ganzen Beitrag lesen »


Montag 16. Januar 2017 von Prof. Dr. Christian Johner

Wie Sie eine Benefit-Risk (Nutzen-Risiko) Abwägung durchführen sollen, verrät die FDA in einem „Guidance Document“.

Es trägt den Titel “Factors to Consider When Making Benefit-Risk Determinations in Medical Device Premarket Approval and De Novo Classifications” und wurde am 24. August 2016 veröffentlicht.

Dieses Guidance-Document zur Benefit-Risk-Abwägung ist nicht nur bei FDA-Zulassungen sehr hilfreich. Nutzen Sie es auch bei der abschließenden Nutzen-Risiko-Bewertung gemäß ISO 14971.

Den ganzen Beitrag lesen »


Mittwoch 11. Januar 2017 von Prof. Dr. Christian Johner

Die FDA hat sich umfassende Transparenz auf die Fahnen geschrieben. Entsprechend publiziert die Behörde regelmäßig Informationen in einer Menge, die kaum noch überschaubar ist. Dieser Artikel hält Sie mit dem Wichtigsten auf dem Laufenden.

Den ganzen Beitrag lesen »


Dienstag 20. Dezember 2016 von Prof. Dr. Christian Johner

Die GLP (Good Laboratory Practice) definiert Anforderungen an ein Qualitätssicherungssystem für nicht-klinische gesundheits- und umweltrelevante Sicherheitsprüfungen.

Lesen Sie in diesem Artikel, welche Anforderungen ggf. auch Medizinproduktehersteller erfüllen müssen, welche Regularien dabei zu beachten sind und welche dieser Anforderungen die Software betreffen.

Den ganzen Beitrag lesen »


Donnerstag 1. September 2016 von Prof. Dr. Christian Johner

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.
Den ganzen Beitrag lesen »


Dienstag 26. Juli 2016 von Prof. Dr. Christian Johner

Ein „detailliertes Design“ fordern sowohl die IEC 62304 als auch die FDA, jedoch ohne diesen Begriff präzise zu definieren. Lesen Sie hier, wie Sie die regulatorischen Anforderungen schnell und „auditsicher“ erfüllen können.

Inhaltsübersicht

Den ganzen Beitrag lesen »


Freitag 24. Juni 2016 von Prof. Dr. Christian Johner

Mit dem 21 CFR part 822 legt die FDA die Anforderungen an die Post-Market Surveillance fest. Ein zugehöriges „Guidance Document“ gibt Handlungsleitung, wie Hersteller die Forderungen des 21 CFR part 822 erfüllen sollen.

Den ganzen Beitrag lesen »


Montag 13. Juni 2016 von Prof. Dr. Christian Johner

Im QSIT (Quality System Inspection Technique) weist die FDA Ihre Inspektoren an, wie diese die Konformität von Qualitätsmanagementsystemen mit den regulatorischen Forderungen des 21 CFR part 820 prüfen sollen. Für Medizinproduktehersteller dient der QSIT damit nicht nur zur Vorbereitung auf FDA Inspektionen, sondern auch als Anregung für das Vorgehen bei eigenen internen Audits.

Den ganzen Beitrag lesen »