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

Infos ausblenden

Zu den Blog-Artikeln

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.

Inhaltsübersicht
Zulassungsverfahren
Allgemeines zur FDA
Klassifizierung von Medizinprodukten und IVDs
Anforderung der FDA an die Software-Entwicklung
FDA und IEC 62304
FDA und Mobile Medical Apps
510(k): Premarket Notification
21 CFR part 820: Quality System Regulations der FDA
21 CFR part 11: Electronic Records and Signatures

Aktuelles

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

Zulassungsverfahren

Abhängig von der Art und Klasse des Medizinprodukts bietet die FDA verschiedene Zulassungsverfahren an wie:

  • Premarket Notification PMN auch bekannt als 510(k) für Produkte, für die es bereits ein zugelassenes Vergleichsprodukt gibt. Hier gibt es noch Sonderformen:
  • Premarket Approval PMA für neue und kritische Produkte
  • De Novo Verfahren für neue und weniger kritische Produkte
  • Investigational Device Exempt IDE für Produkte, die im Rahmen klinischer Prüfungen eingesetzt werden
  • Humanitarian Device Exemption für experimentelle Produkte i.d.R. für terminal erkrankte Patienten
  • Breakthrough Medical Devices: Beschleunigte Zulassung von Produkten für Patienten mit kritischen oder gar lebensbedrohlichen Erkrankungen und Verletzungen.
  • Safer Technologies Program: Beschleunigte Zulassung von Produkten für Patienten mit weniger kritischen Erkrankungen und Verletzungen.

Das Johner Institut unterstützt mit seinen US-Kolleginnen und Kollegen die Hersteller von Medizinprodukten bei allen Zulassungsverfahren und bei der Kommunikation mit der US-Behörde z.B. bei Pre Submission Meetings.

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.

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.

Klassifizierung und Registrierungswege von Medizinprodukten und IVDs in den USA

In den USA werden Medizinprodukte risikobasiert klassifiziert und in die Klasse I (niedriges Risiko) bis III (hohes Risiko) eingeordnet. Diese Einteilung gilt sowohl für Medizinprodukte, als auch für IVDs. Auch das Klassifizierungsverfahren ist identisch. Klassifizierungsregeln wie man sie aus Europa kennt gibt es bei der FDA nicht. Die FDA legt die Klassifizierung für generische Produkttypen fest.

Die Klassifizierung ist ein Teil zur Ermittlung des Registrierungswegs. Der Registrierungsweg wird jedoch nicht ausschließlich anhand der Klassifizierung festlegt, sondern basierend auf der Zweckbestimmung und den damit zusammenhängenden Anforderungen (Controls), um die Sicherheit und Effektivität des Produktes zu gewährleisten.

„Controls“: Anforderungen an Medizinprodukte

Alle Medizinprodukte in den USA unterliegen den sogenannten „General Controls“. Diese beschreiben die Basisanforderungen der FDA und umfassen:

  • Adulteration;
  • Misbranding;
  • Device registration and listing;
  • Premarket notification;
  • Banned devices;
  • Notification, including repair, replacement, or refund;
  • Records and reports;
  • Restricted devices; and
  • Good manufacturing practices.

Klasse I Produkte unterliegen ausschließlich den „General Controls“. Diese sind ausreichend um die Sicherheit und Effektivität des Produktes sicherzustellen. Für Klasse II und III Produkte hat die FDA neben den General Controls weitere Anforderungen definiert, um die Sicherheit und Effektivität zu gewährleisten.

Als Daumenregel kann man festhalten:

  • Klasse I und II Produkte werden über das 510(k) Verfahren zugelassen – außer es sind Ausnahmen für den betreffenden Produkt Code definiert. So sind beispielsweise knapp ¾ der Klasse I Produkte von den Anforderungen einer Premarket Notification (510(k)) ausgenommen. Einige Produkte sind auch von bestimmten Anforderungen der Good Manufacturing Practices ausgenommen (Quality System Regulations – 21 CFR Part 820).
  • Klasse III Produkte werden über das PMA-Verfahren registriert – außer es sind Ausnahmen für den betreffenden Product Code definiert.

Die folgende Tabelle enthält die häufigsten Zulassungswege basierend auf dem Produktrisiko:

Tabelle 2: Registrierungswege in Abhängigkeit der Anforderungen

ClassControlsExemptionsRegistrierungsweg
Class IGeneral ControlsWith ExemptionsListing
Without Exemptions510(k)
Class IIGeneral Controls and Special ControlsWith ExemptionsListing
Without Exemptions510(k)
Class IIIGeneral Controls and Premarket Approval (PMA)/PMA
(510(k) für wenige Ausnahmen)

Wie ermitteln Sie nun die Klassifizierung und das Registrierungsverfahren?

Das Registrierungsverfahren legt die FDA fest. Wie oben beschrieben passiert dies basierend auf der Zweckbestimmung und den notwendigen „Controls“. Für diesen Zweck unterhält die FDA eine Datenbank mit übergeordneten Produktgruppen (Panels).

Abbildung 1: Classification Panels; Quelle: FDA

Anmerkung:

In Vitro Diagnostika finden sich in den Panels „Chemistry“ (21 CFR 862), Hematology (21 CFR 864) und Immunology (21 CFR 866).

Innerhalb der Panels definiert die FDA Produkttypen anhand von einer allgemeinen Produktbeschreibung, für die jeweils eine Regulation Number festgelegt ist. Innerhalb der Regulation Numbers ordnet die FDA Produkt Codes für bestimmte Produkttypen zu.

Abbildung 2: Zusammenhang zwischen Product Panels, Regulation Number und Product Codes

Mittlerweile finden sich mehr als 1700 Definitionen für verschiedene Produkttypen in der Gesetzgebung.

Für jeden Product Code definiert die FDA

  • Die Klasse
  • Das Registrierungsverfahren
  • Eine Regulation Number
  • Einen Product Code
  • Anforderungen an das QMS
  • Soweit zutreffend:
    • Geltenden Special Controls
    • Weitere Beschreibungen zum Produkt (z.B. technische Informationen oder Anwendungsbereich)

Möchten Sie also die Klassifizierung und den Registrierungsweg ermitteln, benötigen Sie den richtigen Product Code. Wie Sie hierbei vorgehen können zeigt die nachfolgende Graphik:

Abbildung 3: Vorgehen zum Festlegen von Product Codes

Was tun wenn…

Nicht immer ist die Zuordnung zu einem Product Code eindeutig. Was können Sie tun, wenn

1. Es keinen passenden Product Code gibt?

In diesem Fall wird Ihr Produkt automatisch als Klasse III Produkt klassifiziert und müsste über das PMA-Verfahren zugelassen werden. Handelt es sich jedoch um ein Produkt, das die FDA wahrscheinlich der Klasse I oder II zuordnen würde, weil General Controls oder General und Special Controls ausreichend sind, um die Sicherheit und Wirksamkeit des Produktes sicherzustellen, kann ein De Novo Prozess durchlaufen werden.

Dies ist ein Verfahren für neuartige Produkte der Klasse I und II für die es kein Vergleichsprodukt auf dem Markt gibt.

2. Mehr als ein Product Code zutreffend ist?

Finden Sie mehrere Product Codes, die für Ihr Produkt zutreffend sein können, sollten Sie prüfen unter welchem Product Code vergleichbare Produkte registriert sind. Hierzu können Sie zum Beispiel die Registration and Listing Database nutzen und nach Konkurrenzprodukten suchen.

Sie haben die Möglichkeit einen

3. Sie unsicher sind, ob Sie den korrekten Product Code ermittelt haben?

Hier ist der erste Schritt zu prüfen welche Zweckbestimmung andere Produkte unter dem von Ihnen ermittelten Product Code haben. Sind Sie nach wie vor unsicher, können Sie die FDA um eine formale Bewertung Ihres Produktes und die Einteilung in einen Product Code bitten. Das hierzu notwendige Verfahren wird 513(g) Request genannt. Die FDA hat ein Guidance Document herausgegeben, in dem der Prozess beschrieben ist: “FDA and Industry Procedures for Section 513(g) Requests for Information under the Federal Food, Drug, and Cosmetic Act Guidance (2012).”

Ermittlung des Product Codes – ein Fallbeispiel

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.

Weiterführende Informationen

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) Guidance Documents zur Cybersecurity

Die FDA hat gleich vier Guidance Documents zum Thema Cybersecurity veröffentlicht:

  1. Die FDA beschreibt in Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, wie und welche Hersteller die Risiken durch mangelnde IT-Sicherheit bzw. durch Cyber-Angriffe im Risikomanagement betrachten müssen.
  2. Auch für das Postmarket Management of Cybersecurity in Medical Devices hat die FDA ein Guidance Document zur Cybersecurity veröffentlicht.
  3. Cybersecurity for Networked Medical Devices Containing OTS software
  4. Cybersecurity for Medical Devices and Hospital Networks: FDA Safety Communication
Weiterführende Informationen

Lesen Sie hier mehr zum Thema FDA & Cybersecurity.

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.

Weiterführende Informationen

Lesen Sie hier mehr zum Thema Mobile Medical Apps.

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.

g) Interoperable Devices

Die FDA erklärt im „Guidance Document“ zu den „Interoperable Medical Devices“ welche Aspekte die Hersteller bei der Entwicklung von Medizinprodukten beachten und welche Dokumente sie bei den „Submissions“ einreichen müssen.

h) Decision Support Systems

Im Guidance Document zu den Decision Support Systems erklärt die FDA, wann ein solches System als Medizinprodukt zu klassifizieren ist.

i) Zubehör

Im Guidance Document „ Medical Device Accessories – Describing Accessories and Classification Pathways“ beschreibt die FDA, wann und wie ein Produkt als Zubehör zu klassifizieren ist und geht dabei explizit auch auf „Software as a Medical Device“ ein.

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.

Das Johner Institut empfiehlt, IEC 62304 konform zu arbeiten. Die Norm stellt die absolute Untergrenze dessen dar, was das Berufsethos jeden Entwicklers verlangen sollte.

Als zweites sei empfohlen für Produkte, die von der U.S.-Behörde zugelassen werden sollen und in einer niedrigen Sicherheitsklasse sind, die fehlenden Dokumente zu erstellen. Das sind im Wesentlichen die Architektur und die Unit-/Integrations-/Systemtests.

4. FDA & mobile Apps

Die FDA hat ein Guidance Dokument zu mobilen Anwendungen (Apps), das zum Jahresende veröffentlicht.

Die Überlegungen, die die FDA anstellt und über die ein Artikel berichtet, klingen 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.
Weiterführende Informationen

Lesen Sie hier mehr zum Thema Mobile Medical Apps.

Hersteller von medizinischer Software müssen nicht nur die Anforderungen der FDA erfüllen. Ein Tool der Federal Trade Commission verschafft einen Überblick über weitere Regularien, die Hersteller zu beachten haben.

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.


Montag, 19. Oktober 2015 | Prof. Dr. Christian Johner

Design Verification von Medizinprodukten und standalone Software

Die Forderung nach „Design Verification“ erhebt keinesfalls nur die FDA. Dieser Beitrag beschreibt, was unter „Design Verification“ zu verstehen ist und welche regulatorischen Forderungen Sie als Medizinproduktehersteller erfüllen sollten.

Beitrag lesen


Montag, 12. Oktober 2015 | Prof. Dr. Christian Johner

Design Validation: Was Sie nachweisen müssen

Den Begriff „Design Validation“ assoziieren die meisten Medizinproduktehersteller mit der FDA. Doch nicht nur die FDA, sondern auch die europäischen Regularien, insbesondere die ISO 13485, fordern eine Validierung von Design und Entwicklung.

Eine weiterer häufiger Fehler bei Software-Entwicklern besteht darin, die „Design Validation“ mit der Validierung des (Software-)Designs zu verwechseln.
Beitrag lesen


Freitag, 18. September 2015 | Prof. Dr. Christian Johner

Corrective Action, Correction und Preventive Action

Die FDA (im 21 CFR part 820 – QSR) und die ISO 13485 fordern „Corrective Actions“ und „Prevention Actions“, zusammen kurz als CAPA bezeichnet. Dieser Artikel nennt Beispiele für „Corrective Actions“ und „Preventive Actions“, nennt die regulatorischen Anforderungen und hilft, die Begriffspaare „Corrective Action“ und „Correction“ sowie „Corrective Action“ und „Preventive Action“ zu unterscheiden.

Update: Artikel präzisiert, Beispiele

Beitrag lesen


Mittwoch, 9. September 2015 | Prof. Dr. Christian Johner

FDA MAUDE Datenbank: Input fürs Risikomanagement

Die FDA MAUDE Datenbank stellt Informationen zur „Manufacturer and User Facility Device Experience“ bereit. Sie entspricht damit etwa der Datenbank, mit der das BfArM Meldungen von Hersteller zur Risiken publiziert. Ein neues Werkzeug hilft bei der Auswertung.

Beitrag lesen


Freitag, 28. August 2015 | Prof. Dr. Christian Johner

FDA aktualisiert „Refuse to Accept Policy“ für 510(k)

Unter der „Refuse to Accept Policy“ der FDA versteht man einen Kriterienkatalog, anhand dessen die FDA 510(k) Anträge bewertet und ggf. zurückweist. Diese „Refuse to Accept Policy“ hat die FDA im August 2015 aktualisiert.
Beitrag lesen


Mittwoch, 29. Juli 2015 | Prof. Dr. Christian Johner

Level of Concern: Was die FDA damit erreichen möchte

Die FDA unterscheidet drei sogenante „Levels of Concern“, die sehr an die Sicherheitsklassen der IEC 62304 erinnern. Allerdings gibt es Unterschiede, die immer wieder zu Problemen bei Inspektionen oder 510(k)-Zulassungen führen.

Beitrag lesen


Mittwoch, 18. März 2015 | Prof. Dr. Christian Johner

Design History File: Device Master Record, Device History Record

Die FDA fordert in 21 CFR part 820 (das sind die „Quality System Regulations“) ein Design History DHF. Dieses DHF sollte nicht mit dem Device History Record und dem Device Master Record verwechselt werden. Dieser Beitrag erläutert, was das Design History File enthalten muss und wie es sich von den beiden anderen „Akten“ unterscheidet.

Beitrag lesen

Dienstag, 24. Februar 2015 | Prof. Dr. Christian Johner

23andMe DNA Test und die FDA

23andMe: endlich FDA-Clearance? (Mai 2017)

Stück für Stück kämpft sich 23andMe zurück. Zwar hat die Firma nun eine FDA Clearance, aber nur für einen einzigen Test, wie engadget berichtet. Dies zeigt, wie schwierig sich 23andMe damit tut, die regulatorischen Anforderungen v.a. der FDA zu erfüllen. Wahrscheinlich betreffen die Herausforderungen v.a. den Nachweis der klinischen Wirksamkeit zumal 23andMe nicht nur das Medizinprodukt FDA-konform in Verkehr bringen muss, sondern teilweise die zugrundeliegende Forschung betreibt.

Inzwischen hat 23andme zwar die Genehmigung der FDA wieder erhalten, der Umfang der Tests ist aber stark eingeschränkt. E-Health-Com schreibt, dass nicht einmal die BRCA-Mutationen, die zu erblichem Brustkrebs führt, im Portfolio von 23andme ist. Angelina Jolie hatte sich auf Basis dieses Genbefunds für eine Operation entschieden…

Beitrag lesen