FDA Enforcement Discretion (2026) für Medical Software & Apps

„Sobald Ihre Gesundheits-App irgendetwas Medizinisches tut, will die FDA einen Berg an Dokumentation und eine Marktfreigabe (Clearance) sehen, bevor der erste Patient die App überhaupt öffnet.“

Das hören die meisten Gründer, wenn sie anfangen, medizinische Software für den US-Markt zu entwickeln. Und für viele Produkte stimmt das auch. Gilt Ihr Produkt als Medizinprodukt (Medical Device), erwartet die US-Behörde für Lebensmittel, Arzneimittel und Medizinprodukte, die Food and Drug Administration (FDA), dass Sie eine lange Liste regulatorischer Anforderungen erfüllen: Qualitätsmanagementsystem (QMS), Design-Dokumentation, Risikomanagement, Pflichten nach dem Inverkehrbringen (Postmarket) usw.

Das bedeutet Monate an Arbeit, viel Dokumentation und eine Menge Geld, bevor Ihr erster Nutzer die App überhaupt zu sehen bekommt.

Aber das gilt nicht für jede medizinische Software oder App. Ist Ihr Produkt risikoarm genug, setzt die FDA diese strengen Anforderungen bewusst nicht durch.

Das nennt sich Enforcement Discretion.

Entwickeln Sie eine Coaching-App, eine Tracking-App oder eine Erinnerungs-App für Patienten, stehen die Chancen gut, dass Ihr Produkt unter Enforcement Discretion fällt. Dann steht zwischen Ihnen und Ihrem Launch keine Einreichung bei der FDA, keine Prüfung durch die FDA und keine FDA-Inspektion. Das spart Ihnen viel Zeit und Geld.

Aber woher wissen Sie, ob Ihr Produkt darunterfällt? Und was bedeutet Enforcement Discretion für Themen wie Qualitätsmanagement und Dokumentation? Die Antworten finden Sie in diesem Artikel.

Inhaltsverzeichnis

• 1. Was ist Enforcement Discretion und was bringt sie Ihnen?
• 2. Ist Ihre Software überhaupt ein Medizinprodukt?
• 3. Der große Vorteil von Enforcement Discretion
• 4. Brauchen Sie unter Enforcement Discretion trotzdem ein QMS und Dokumentation?
• 5. Gibt es (unangekündigte) Audits für Software unter Enforcement Discretion?
• 6. Fällt Ihr Produkt unter Enforcement Discretion?
• 7. Wie bekommen Sie Gewissheit?
• 8. Hilfreiche Quellen für die Entscheidung über Enforcement Discretion
• 9. Fazit

1. Was ist Enforcement Discretion und was bringt sie Ihnen?

Beginnen wir mit den Grundlagen. Das US-Recht definiert in Section 201(h)(1) des Federal Food, Drug, and Cosmetic Act (FD&C Act), was ein Medizinprodukt ist. Vereinfacht gesagt ist ein Produkt ein Medizinprodukt, wenn es dazu bestimmt ist, eine Krankheit oder einen anderen medizinischen Zustand zu diagnostizieren, zu behandeln, zu heilen, zu lindern oder zu verhindern. Auch Software kann ein Medizinprodukt sein.

Diese Definition ist sehr weit gefasst. Selbst eine einfache App, die Menschen mit Diabetes zu einer gesünderen Ernährung coacht, kann streng genommen zur Linderung oder Behandlung einer Krankheit bestimmt sein. Auf dem Papier kann sie damit ein Medizinprodukt sein.

Der FDA ist klar, dass es keinen Sinn ergibt, jede dieser Apps wie einen Herzschrittmacher zu regulieren. Deshalb hat die FDA für bestimmte Arten von Software, die als Medizinprodukt gelten, entschieden: Das Risiko ist so gering, dass sie die gesetzlichen Anforderungen an Medizinprodukte nicht durchsetzt. In ihren eigenen Worten: Die FDA „does not, at this time, intend to enforce requirements under the FD&C Act“, beabsichtigt also derzeit nicht, die Anforderungen des FD&C Act durchzusetzen.

Das ist Enforcement Discretion, wörtlich „Ermessen bei der Durchsetzung“. Gemeint ist: Die FDA nutzt ihren Ermessensspielraum und setzt geltende Regeln bewusst nicht durch. Ist Ihre Software ein Medizinprodukt, bleibt sie das auf dem Papier auch.

Wichtig: Für Enforcement Discretion gibt es keinen Antrag, keine Registrierung und keinen Freigabebescheid. Sie „beantragen“ sie nicht. Sie sehen sich Ihr Produkt an, vergleichen es mit der Guidance der FDA und entscheiden selbst, ob es unter Enforcement Discretion fällt. Die FDA bestätigt diese Entscheidung nur, wenn Sie aktiv nachfragen (mehr dazu in Kapitel 7).

2. Ist Ihre Software überhaupt ein Medizinprodukt?

Bevor Sie prüfen, ob Ihr Produkt unter Enforcement Discretion fällt, sollten Sie prüfen, ob Ihre Software überhaupt ein Medizinprodukt ist. Ist sie keines, müssen Sie sich mit der Regulierung von Medizinprodukten gar nicht befassen.

Viel Software im Gesundheitsbereich ist kein Medizinprodukt. Der 21st Century Cures Act von 2016 hat mehrere Arten von Software ausdrücklich aus der Definition des Medizinprodukts herausgenommen (Section 520(o) des FD&C Act), zum Beispiel:

• Administrative Software: Terminplanung, Abrechnung, Praxisverwaltung
• General-Wellness-Software: Apps, die einen gesunden Lebensstil fördern, ohne sich auf eine Krankheit zu beziehen, zum Beispiel ein Fitness- oder Schlaftracker
• Funktionen elektronischer Patientenakten (Electronic Health Records): Software, die Patientenakten speichert und anzeigt
• Datenübertragung und -anzeige: Software, die Daten nur überträgt, speichert oder anzeigt, ohne sie auszuwerten
• Bestimmte Clinical-Decision-Support-Software (CDS): Software, die Ärzten Empfehlungen so gibt, dass sie die Grundlage der Empfehlung selbstständig überprüfen können

Ob Ihre Software ein Medizinprodukt ist, entscheidet nicht die Technologie. Es entscheidet der Intended Use, also die Zweckbestimmung: wofür Ihre Software laut Ihren eigenen Aussagen gedacht ist. Dazu gehören Ihre Website, die Beschreibung im App Store, Marketingmaterial und sogar das, was Sie Kunden oder Investoren erzählen. Dieselbe App mit derselben Funktionalität kann ein Medizinprodukt sein oder nicht, je nachdem, wie Sie sie beschreiben.

Abbildung 1: Drei mögliche Ergebnisse für Ihre Software. Enforcement Discretion wird erst relevant, wenn Ihre Software ein Medizinprodukt ist.

3. Der große Vorteil von Enforcement Discretion

Was bringt Ihnen Enforcement Discretion konkret? Eine ganze Menge. Fällt Ihre Software unter Enforcement Discretion, setzt die FDA die gesetzlichen Anforderungen an Medizinprodukte nicht durch, zumindest derzeit nicht. In der Praxis bedeutet das:

• Premarket Review: keine 510(k)- oder De-Novo-Einreichung und kein monatelanges Warten auf die Entscheidung der FDA
• Registration and Listing: keine Registrierung Ihres Unternehmens und Ihres Produkts bei der FDA und keine jährliche Registrierungsgebühr
• Inspektionen: keine FDA-Inspektion Ihres Unternehmens und Ihrer Prozesse
• Postmarket-Pflichten: keine formalen Meldepflichten gegenüber der FDA nach dem Launch

Und was ist mit dem QMS und der Design-Dokumentation? Die FDA empfiehlt, dass Sie beides trotzdem haben, prüft es aber nicht. Mehr dazu im nächsten Kapitel.

Abbildung 2: Was sich unter Enforcement Discretion im Vergleich zu einem regulierten Medizinprodukt ändert.

Die Premarket Submission, also die Einreichung vor dem Markteintritt, ist ein großer Block an Aufwand und Wartezeit im gesamten Prozess. Selbst wenn Sie sich für ein schlankes QMS und eine saubere Dokumentation entscheiden, kann Ihnen Enforcement Discretion also viele Monate auf dem Weg zum Markt sparen.

4. Brauchen Sie unter Enforcement Discretion trotzdem ein QMS und Dokumentation?

Das ist wohl die häufigste Frage zu Enforcement Discretion. Die Lage ist einfach:

• Das Gesetz verlangt es: Streng genommen gelten die Qualitätsmanagement-Anforderungen der FDA (21 CFR Part 820) grundsätzlich für Ihre Software, wenn sie ein Medizinprodukt ist, es sei denn, die Classification Regulation für diesen Produkttyp nimmt sie davon aus. Enforcement Discretion selbst hebt diese Anforderung nicht auf. Sie bedeutet nur, dass die FDA nicht beabsichtigt, sie durchzusetzen. Seit Februar 2026 trägt 21 CFR Part 820 den Namen Quality Management System Regulation (QMSR) und basiert direkt auf ISO 13485, der internationalen Norm für Qualitätsmanagement bei Medizinprodukten.
• Die FDA empfiehlt es: In den FAQ ihrer Guidance schreibt die FDA, sie sei der Auffassung, dass „all manufacturers of medical device software should have in place an adequate quality management system“. Alle Hersteller von Medizinprodukte-Software sollten also ein angemessenes Qualitätsmanagementsystem haben. Dazu gehören Risikomanagement, gute Design-Praktiken sowie eine saubere Verifizierung und Validierung.
• Die FDA prüft es nicht: Für Software unter Enforcement Discretion setzt die FDA diese Anforderungen nicht durch. Die FDA prüft weder Ihr QMS noch Ihre Dokumentation.

Pragmatisch betrachtet heißt das: Ob Sie ein QMS und eine technische Dokumentation aufbauen, ist Ihre unternehmerische Entscheidung. Sie sollten die Prozesse und die Dokumentation aufbauen, aber die FDA wird (Stand heute) nicht danach fragen.

In der Realität starten deshalb manche Teams mit einem Produkt unter Enforcement Discretion vom ersten Tag an mit einem schlanken QMS. Andere konzentrieren sich zuerst auf das Produkt und ergänzen die Struktur später. Wieder andere verzichten ganz auf die Dokumentation (das ist keine Empfehlung, sondern das, was in der Praxis passiert).

Bevor Sie sich entscheiden, sollten Sie genau wissen, wofür Sie sich entscheiden. Drei Dinge sollten Sie dabei im Hinterkopf behalten:

1. Es ist eine Duldung, keine Ausnahme: Enforcement Discretion ist keine gesetzlich verankerte Ausnahme (Exemption). Das Gesetz sichert der FDA nur das Recht, Enforcement Discretion auszuüben (Section 520(o)(4) des FD&C Act). Enforcement Discretion ist eine Policy in einem Guidance-Dokument der FDA, und Guidance-Dokumente sind nicht verbindlich, nicht einmal für die FDA selbst. Guidance-Dokumente ändern sich außerdem von Zeit zu Zeit und mit ihnen der genaue Umfang der Enforcement Discretion. Allein die Guidance zu Clinical-Decision-Support-Software wurde im Januar 2026 überarbeitet und wenige Wochen später noch einmal korrigiert. Ein Produkt, das heute unter Enforcement Discretion fällt, tut das nach der nächsten Überarbeitung nicht automatisch auch noch.

2. Das eigentliche Risiko ist eine falsche Einschätzung: Enforcement Discretion funktioniert nur, wenn Ihr Produkt wirklich darunterfällt. Kommt die FDA zu dem Schluss, dass Ihre App über den abgedeckten Bereich hinausgeht, zum Beispiel weil Ihr Marketing mehr als Coaching verspricht, dann war Ihr Produkt vom ersten Tag an ein reguliertes Medizinprodukt. Ohne QMS, ohne Dokumentation und ohne Prüfung durch die FDA. Genau dieses Szenario führt zu Warning Letters und erzwungenen Produktänderungen.

3. Andere Märkte und Partner erwarten unter Umständen mehr: Enforcement Discretion ist ein US-Konzept. Andere Märkte haben ihre eigenen Regeln, und Partner wie Kliniken, Krankenversicherungen oder Pharmaunternehmen verlangen unter Umständen trotzdem Qualitätsnachweise.

Gut zu wissen für die EU: Die EU-Medizinprodukteverordnung (MDR) kennt keine Enforcement Discretion. Dieselbe Coaching-App, um die sich die FDA nicht kümmert, kann in der EU ein Medizinprodukt sein, das eine CE-Kennzeichnung braucht. Nach der Klassifizierungsregel der MDR für Software (Regel 11) landen solche Apps oft in einer Risikoklasse, die eine Prüfung durch eine unabhängige Benannte Stelle erfordert. Planen Sie später einen Launch in Europa, lesen Sie unsere Artikel Ist Ihre Software ein Medizinprodukt? und Klassifizierung von Software-Medizinprodukten nach der MDR.

Unsere Empfehlung: Dokumentieren Sie auf jeden Fall, warum Ihr Produkt unter Enforcement Discretion fällt (siehe Kapitel 7). Stellt jemand Ihren Status jemals infrage, sei es die FDA, ein Investor oder ein Partner, haben Sie eine klare Antwort parat. Noch besser ist eine Bestätigung durch die FDA selbst, zum Beispiel über einen 513(g) Request.

5. Gibt es (unangekündigte) Audits für Software unter Enforcement Discretion?

Das ist sehr unwahrscheinlich, wenn Ihre Einschätzung zur Enforcement Discretion stimmt. Ihr Produkt ist nicht einmal bei der FDA registriert. Routine-Inspektionen plant die FDA auf Basis ihrer Registrierungsdatenbank. Sie weiß also in der Regel gar nicht, dass Ihr Produkt existiert. Sie kann zwar jeden Medizinproduktehersteller anlassbezogen inspizieren, aber das ist sehr unwahrscheinlich.

Das heißt nicht, dass die FDA nie auf Sie aufmerksam werden kann. Die FDA bleibt für Medizinprodukte zuständig, auch für solche unter Enforcement Discretion. Fällt Ihr Produkt auf, zum Beispiel durch Beschwerden von Nutzern, Berichte über Schäden oder gewagte Werbeversprechen, kann die FDA sich das genauer ansehen.

6. Fällt Ihr Produkt unter Enforcement Discretion?

Die wichtigste Quelle dafür ist die Guidance „Policy for Device Software Functions and Mobile Medical Applications“ der FDA vom 28. September 2022. Nach Section V.B dieser Guidance beabsichtigt die FDA grundsätzlich, Enforcement Discretion für Softwarefunktionen auszuüben, die:

1. „Help patients (i.e., users) self-manage their disease or conditions without providing specific treatment or treatment suggestions; or“ (Patienten dabei helfen, ihre Erkrankung oder ihren Gesundheitszustand selbst zu managen, ohne konkrete Behandlungen oder Behandlungsvorschläge zu geben, oder)
2. „Automate simple tasks for health care professionals.“ (einfache Aufgaben für medizinisches Fachpersonal automatisieren)

Diese zwei Sätze sind der Kern der Enforcement Discretion. Tut Ihre Software eines dieser beiden Dinge und darüber hinaus nichts Riskanteres, stehen Ihre Chancen gut.

Geringes Risiko ist der gemeinsame Nenner

Alle Beispiele für Enforcement Discretion haben eines gemeinsam: ein geringes Risiko für Patienten. Eine hilfreiche Orientierung, um das Risiko Ihrer Software einzuschätzen, ist das Risiko-Framework des International Medical Device Regulators Forum (IMDRF), eines internationalen Zusammenschlusses von Medizinprodukte-Behörden, zu dem auch die FDA gehört. Es ordnet Software in vier Kategorien ein, je nachdem, wie ernst der Zustand des Patienten ist und wie stark die Software medizinische Entscheidungen beeinflusst:

Abbildung 3: Risikokategorien für medizinische Software nach dem International Medical Device Regulators Forum (IMDRF). Quelle: IMDRF, Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations (N12, 2014). Die Hervorhebung von Kategorie I folgt der Übersicht der NIH, nicht dem IMDRF oder der FDA.

Kategorie IV steht für das höchste Risiko, Kategorie I für das niedrigste. Als Faustregel gilt: Software in Kategorie I ist eher ein Kandidat für Enforcement Discretion, zum Beispiel eine App, die nur über eine nicht schwerwiegende Erkrankung informiert. Die US-Gesundheitsforschungsbehörde National Institutes of Health (NIH) gibt in ihrer Übersicht zur Enforcement Discretion für Startups denselben Rat.

Wichtig: Diese Tabelle ist eine Orientierung, keine Regel der FDA. Ob Ihre Software unter Enforcement Discretion fällt, entscheiden die Guidance-Dokumente der FDA und ihre Beispiele, nicht die IMDRF-Kategorie.

Beispiele

Die Guidance nennt drei typische Kategorien als Beispiele. In einfachen Worten:

• Coaching- und Erinnerungs-Apps für Patienten: Apps, die Menschen mit Erkrankungen wie Diabetes, Bluthochdruck, Herzerkrankungen oder Adipositas mit einfachen Hinweisen dabei unterstützen, sich gesünder zu ernähren, sich mehr zu bewegen, weniger Salz zu essen oder ihre Medikamente nach festem Zeitplan einzunehmen. Die FDA meint damit nur Apps, die Patienten ohne ärztliche Aufsicht sicher allein nutzen können und die bei ernsten Erkrankungen nicht den Arztbesuch ersetzen.
• Foto-Apps für die Kommunikation mit dem Arzt: Apps, die mit der Handykamera Bilder aufnehmen und an medizinisches Fachpersonal senden, zum Beispiel von einer Hautveränderung oder einer Wunde, um zu ergänzen, was der Patient sonst in Worten beschreiben würde
• Einfache medizinische Rechner: Software für die einfachen Berechnungen, die Ärzte im Studium lernen und täglich anwenden, zum Beispiel Body-Mass-Index (BMI), mittlerer arterieller Druck, der APGAR-Score für Neugeborene, die Glasgow Coma Scale oder ein Rechner für den Geburtstermin

Abbildung 4: Die zwei Kriterien aus Section V.B der FDA-Guidance und die drei typischen Beispielkategorien.

Weitere konkrete Beispiele

Appendix B derselben Guidance listet 18 weitere konkrete Beispiele auf. Dazu gehören unter anderem:

• Apps, die Patienten mit diagnostizierten psychischen Erkrankungen wie Depression oder Angststörungen helfen, ihre Bewältigungsstrategien aufrechtzuerhalten, zum Beispiel mit einem „Skill of the Day“
• Apps, die die Medikamenteneinnahme erfassen und Nutzer an die Einnahme erinnern
• Apps, die Vitalwerte wie Herzfrequenz oder Blutdruck erfassen und ihren Verlauf anzeigen
• Apps, die Menschen mit Prädiabetes helfen, sich besser zu ernähren oder mehr zu bewegen
• Apps, mit denen Nutzer eine Pflegekraft anrufen oder einen Notruf absetzen können
• Symptom-Checker, die mögliche Erkrankungen auflisten und Nutzern sagen, wann sie einen Arzt aufsuchen sollten
• usw.

Wo Enforcement Discretion endet

Die Grenze ist meist dann überschritten, wenn Ihre Software nicht mehr unterstützt, sondern entscheidet. Typische Beispiele, die nicht unter Enforcement Discretion fallen:

• Konkrete Behandlungsvorschläge: zum Beispiel eine App, die berechnet, wie viel Insulin ein Diabetiker spritzen soll. Eine Diabetes-App, die Blutzuckerwerte erfasst und zu mehr Bewegung motiviert, kann unter Enforcement Discretion fallen. Sobald sie Ihnen sagt, wie viel Insulin Sie nehmen sollen, ist sie ein reguliertes Medizinprodukt.
• Diagnose: Software, die einem Nutzer sagt, dass er eine bestimmte Krankheit hat, zum Beispiel auf Basis von Sensordaten oder Fotos
• Auswertung medizinischer Bilder oder Signale: Software, die Röntgenbilder, EKG-Signale oder ähnliche Daten auswertet

Beispiele für Software, die die FDA aktiv reguliert, finden Sie in Appendix C derselben Guidance. Ihr Produkt mit Appendix B und Appendix C zu vergleichen, ist meist der schnellste Weg, um zu sehen, wo Sie stehen.

Abbildung 5: Software, die unterstützt, kann unter Enforcement Discretion fallen. Software, die entscheidet, ist meist ein reguliertes Medizinprodukt.

Zwei weitere Stellen, an denen Enforcement Discretion vorkommt

Die Guidance von 2022 ist die wichtigste Quelle, aber nicht die einzige. Im Januar 2026 hat die FDA zwei weitere Guidance-Dokumente aktualisiert, die für viele Softwareprodukte relevant sind:

• General Wellness Products (6. Januar 2026): Ist Ihr Produkt eine Lifestyle-App oder ein Wearable, das einen gesunden Lebensstil fördert, prüfen Sie diese Guidance. Software, die nur einen gesunden Lebensstil fördert, ohne jeden Bezug zu einer Krankheit, ist gar kein Medizinprodukt. Verbindet Ihr risikoarmes Produkt einen gesunden Lebensstil mit einer chronischen Krankheit, etwa mit der Aussage, es „may help living well with type 2 diabetes“ (kann helfen, gut mit Typ-2-Diabetes zu leben), beabsichtigt die FDA nicht zu prüfen, ob es ein Medizinprodukt ist oder die Anforderungen an Medizinprodukte erfüllt.
• Clinical Decision Support Software (29. Januar 2026): Gibt Ihre Software Ärzten Empfehlungen, prüfen Sie diese Guidance. Sie sieht jetzt auch Enforcement Discretion für Software vor, die nur eine einzige Empfehlung gibt, wenn das die einzige klinisch angemessene Option ist und die Software die übrigen Kriterien erfüllt.

7. Wie bekommen Sie Gewissheit?

Da Ihnen niemand Enforcement Discretion automatisch bestätigt, haben Sie zwei Möglichkeiten, Gewissheit zu bekommen.

Option 1: Die FDA fragen

Die FDA bietet mehrere Wege an, Fragen zu stellen:

• E-Mail: Für die Frage, ob Ihre Software ein Medizinprodukt ist, erreichen Sie das Digital Health Center of Excellence der FDA unter digitalhealth@fda.hhs.gov. Für allgemeine Fragen zu regulatorischen Anforderungen können Sie sich an das Office of Industry and Consumer Education (OICE, früher DICE) der FDA unter AskOICE@fda.hhs.gov wenden. Ist danach immer noch unklar, ob Ihr Produkt ein Medizinprodukt ist, ist das Device-Determination-Postfach der FDA unter DeviceDetermination@fda.hhs.gov der nächste Schritt.
• 513(g) Request for Information: Das ist der formale Weg. Sie schicken der FDA eine Beschreibung Ihrer Software und ihres Verwendungszwecks sowie Ihr Labeling oder Marketingmaterial und zahlen eine Gebühr. Die FDA antwortet in der Regel innerhalb von 60 Tagen mit einem vertraulichen Schreiben, in dem sie mitteilt, wie sie Ihr Produkt einordnet. Die Antwort ist keine formale Zulassung, aber sie ist die schriftliche Einschätzung der FDA und der beste Schutz, den Sie bekommen können.
• Pre-Submission (Pre-Sub): Rechnen Sie bereits damit, eine 510(k) oder einen De-Novo-Antrag zu brauchen, können Sie über eine Pre-Sub vorab Feedback der FDA zu Ihrer geplanten Einreichung einholen. Fragen dazu, ob Ihr Produkt ein Medizinprodukt ist oder welche Anforderungen gelten, gehören nicht in eine Pre-Sub. Dafür nutzen Sie einen 513(g) Request.

Abbildung 6: Je formaler der Weg, desto mehr Gewissheit bekommen Sie über Ihren Status.

Unsere Empfehlung: Ob Sie die FDA fragen oder nicht, schreiben Sie Ihre Begründung auf. Ein Dokument mit ein bis zwei Seiten reicht: was Ihre Software tut, Ihr genauer Intended Use, welchem Beispiel aus der Guidance sie entspricht und warum sie die Grenze nicht überschreitet. Gleichen Sie danach Ihre Marketingtexte und jedes neue Feature mit diesem Dokument ab. Prüfen Sie Ihren Status regelmäßig, zum Beispiel einmal im Jahr, denn die Guidance-Dokumente der FDA ändern sich. Dokumentieren Sie jede Prüfung. So haben Sie eine saubere Dokumentation, falls die FDA jemals nachfragt.

Abbildung 7: Eine jährliche Prüfung hält Ihre Dokumentation aktuell.

Option 2: Unterstützung bei der Entwicklung von Medical Software nach FDA

Bei QuickBird Medical entwickeln wir medizinische Software und Medical Apps für den US- und den EU-Markt. Wir unterstützen Sie von der ersten Einschätzung bis zum Launch:

• Regulatorische Einschätzung: Wir helfen Ihnen herauszufinden, ob Ihre Software überhaupt ein Medizinprodukt ist, in welche Risikoklasse sie fällt und ob Enforcement Discretion greift.
• Entwicklung: Wir entwickeln Ihre App oder Software.
• Regulatorische Anforderungen: Wir decken alles ab, was Ihr Produkt braucht, vom Qualitätsmanagement bis zur Dokumentation für eine FDA-Einreichung oder eine CE-Kennzeichnung.

Sie sind nicht sicher, wo Ihr Produkt steht? Erfahren Sie mehr über unsere FDA-konforme Softwareentwicklung oder nehmen Sie direkt Kontakt mit uns auf.

8. Hilfreiche Quellen für die Entscheidung über Enforcement Discretion

Alle folgenden Quellen sind offizielle Quellen der FDA (auf Englisch):

• Policy for Device Software Functions and Mobile Medical Applications (September 2022, PDF): die zentrale Guidance. Lesen Sie Section V.B für die Grundsätze, Appendix B für die Beispiele unter Enforcement Discretion und Appendix C für Software, die die FDA reguliert.
• General Wellness: Policy for Low Risk Devices (Januar 2026): für Lifestyle-Apps und Wearables
• Clinical Decision Support Software (Januar 2026): für Software, die Ärzte bei ihren Entscheidungen unterstützt
• Digital Health Policy Navigator: interaktiver Selbstcheck, ob Ihre Software ein Medizinprodukt ist und ob Enforcement Discretion wahrscheinlich ist
• How to Determine if Your Product is a Medical Device: die Grundlagen der FDA zur Definition des Medizinprodukts, inklusive Ansprechpartnern
• Product Classification Database: die Datenbank der FDA mit allen Produkttypen. Sie können nach dem Submission Type „Enforcement Discretion“ filtern und sehen dann die Produkttypen, für die die FDA Enforcement Discretion ausübt. Viele Einträge sind keine Software, aber ein Blick lohnt sich, wenn Ihr Produkt einem bestehenden Produkttyp ähnelt.

Weiterführende Quellen anderer Herausgeber:

• IMDRF-Risiko-Framework für Software: die internationalen Risikokategorien für medizinische Software
• NIH-Übersicht zur Enforcement Discretion der FDA (September 2024): eine kurze Zusammenfassung für Startups, kein offizielles Dokument der FDA

9. Fazit

Enforcement Discretion ist eines der nützlichsten und zugleich unbekanntesten Konzepte der US-Medizinprodukteregulierung. Hilft Ihre Software Patienten, mit ihrer Erkrankung umzugehen, ohne ihnen eine Behandlung vorzugeben, oder automatisiert sie einfache Aufgaben für Ärzte, wird die FDA Sie höchstwahrscheinlich in Ruhe lassen. Keine 510(k), keine FDA-Registrierung, keine FDA-Inspektion. Ob Sie trotzdem ein QMS und eine technische Dokumentation aufbauen, ist Ihre Entscheidung: Die FDA empfiehlt es, prüft es aber nicht.

Aber es ist eine Duldung, keine Ausnahme. Auf dem Papier ist Ihre Software weiterhin ein Medizinprodukt. Ob sie unter Enforcement Discretion fällt, ist Ihre eigene Einschätzung. Die FDA bestätigt sie nur, wenn Sie nachfragen, hat aber das letzte Wort, falls sie sich Ihr Produkt einmal genauer ansieht. Das größte Risiko ist kein Audit. Es ist eine falsche Einschätzung an dieser Stelle, zum Beispiel weil Ihr Marketing mehr verspricht, als Ihr Produkt leisten darf.

Unser Rat deshalb: Prüfen Sie Ihren Intended Use sorgfältig anhand der Beispiele der FDA, schreiben Sie Ihre Begründung auf, halten Sie Ihr Marketing damit im Einklang und fragen Sie die FDA, wenn Sie unsicher sind.

Sie planen die Entwicklung einer Medical Software?

Wenn Sie Software für den US-Markt entwickeln wollen, geben Sie uns Bescheid. Wir sind auf die Entwicklung von Medizinprodukten für den US-Markt nach FDA-Vorgaben und für den EU-Markt nach MDR spezialisiert.