SaMD vs. SiMD: Software als Medizinprodukt unter FDA und EU-MDR

TL;DR

Software as a Medical Device (SaMD) ist Software, die einen medizinischen Zweck erfüllt, ohne Teil eines Hardware-Medizinprodukts zu sein. Software in a Medical Device (SiMD) ist Software, die ein Hardware-Produkt steuert oder darin eingebettet ist. Die internationale Definition stammt vom International Medical Device Regulators Forum (IMDRF). Dieses definiert SaMD als „Software, die dazu bestimmt ist, für einen oder mehrere medizinische Zwecke verwendet zu werden, und die diese Zwecke erfüllt, ohne Teil eines Hardware-Medizinprodukts zu sein.“ ¹

Diese Unterscheidung bestimmt, wie Software klassifiziert und eingereicht wird. In der EU wird SaMD eigenständig klassifiziert, zumeist nach MDR-Regel 11. Software, die ein Produkt steuert, übernimmt die Klasse dieses Produkts. In den USA autorisiert FDA Softwarefunktionen von Medizinprodukten über 510(k), De Novo oder PMA. Die Liste KI-gestützter Produkte von FDA verdeutlicht dieses Muster. Von den 1.614 Produkten auf der Liste gelangten 96,2 % über 510(k) auf den Markt. Die Zahl der pro Jahr autorisierten Produkte stieg von 18 im Jahr 2016 auf 335 im Jahr 2025. ²

2026 brachte mehrere Änderungen mit sich. FDA überarbeitete im Januar ihre Leitlinien zu klinischer Entscheidungsunterstützung und allgemeinem Wohlbefinden sowie im Februar ihre Leitlinie zur Cybersicherheit. Die EU verschob die Hochrisikopflichten des AI Act für KI-gestützte Medizinprodukte auf den 2. August 2028. Dieser Leitfaden erläutert die Definitionen, wie Sie feststellen, ob es sich bei Software überhaupt um ein Medizinprodukt handelt, wie FDA und die EU sie klassifizieren, was zu einer Einreichung gehört und wie andere wichtige Märkte sie behandeln.

SaMD, SiMD und MDSW: Was die einzelnen Begriffe bedeuten

SaMD ist ein definierter Begriff. SiMD ist eine beschreibende Bezeichnung ohne verbindliche rechtliche Definition. Die EU verwendet einen dritten Begriff, MDSW, der beides abdeckt.

Das IMDRF grenzt dies eindeutig ab: „Software erfüllt nicht die Definition von SaMD, wenn ihre Zweckbestimmung darin besteht, ein Hardware-Medizinprodukt zu steuern.“ Zudem heißt es dort: „Mobile Apps, die die obige Definition erfüllen, gelten als SaMD.“ Die Leitlinie von FDA aus dem Jahr 2022 zu Softwarefunktionen von Medizinprodukten stellt fest, dass diese „‚Software as a Medical Device (SaMD)‘ und ‚Software in a Medical Device (SiMD)‘ umfassen können.“ ³

In der EU ersetzt MDCG 2019-11 Rev.1 den Begriff „Standalone-Software“ durch MDSW und stellt fest, dass die frühere Bezeichnung „im Kontext der Medizinprodukteverordnungen nicht mehr verwendet wird.“ Die Durchführungsvorschrift 3.3 der MDR legt die Konsequenz für die Klassifizierung fest: „Software, die ein Produkt steuert oder dessen Anwendung beeinflusst, wird derselben Klasse zugerechnet wie das Produkt. Ist die Software von anderen Produkten unabhängig, so wird sie für sich allein klassifiziert.“ ^{4 5}

Australiens TGA beschreibt SiMD äußerst praxisnah. Solche Software wird „üblicherweise vorinstalliert mit dem Hardware-Produkt geliefert“, und „SiMD wird als Teil des Produkts reguliert, in dem sie installiert ist.“ ⁶

Erste Frage: Ist die Software überhaupt ein Medizinprodukt?

Ein Großteil der Gesundheitssoftware ist kein Medizinprodukt. Ausschlaggebend sind die Zweckbestimmung und in den USA fünf gesetzliche Ausschlüsse.

In den USA schließt Section 520(o) des FD&C Act, eingefügt durch den 21st Century Cures Act, fünf Arten von Softwarefunktionen von der Definition eines Medizinprodukts aus:

• administrative Unterstützung;
• Aufrechterhaltung oder Förderung einer gesunden Lebensweise ohne Bezug zu einer Krankheit;
• elektronische Patientenakten, es sei denn, die Funktion interpretiert oder analysiert diese;
• Übertragung, Speicherung, Konvertierung oder Anzeige von Daten, es sei denn, sie interpretiert oder analysiert diese Daten;
• bestimmte klinische Entscheidungsunterstützung (CDS). ⁷

Der CDS-Ausschluss gilt nur dann, wenn die Software keine medizinischen Bilder oder Signale analysiert. Sie muss medizinische Informationen anzeigen oder analysieren, die Empfehlung einer medizinischen Fachkraft unterstützen und es dieser Fachkraft ermöglichen, die Grundlage der Empfehlung unabhängig zu überprüfen.

FDA überarbeitete im Januar 2026 zwei zentrale Leitlinien:

• Klinische Entscheidungsunterstützung. Die Leitlinie wurde am 6. Januar 2026 neu herausgegeben und am 29. Januar 2026 korrigiert. Software, die eine konkrete Diagnose- oder Behandlungsanweisung gibt, erfüllt das dritte Kriterium nicht. Wenn nur eine Option klinisch angemessen ist und die Software die Kriterien ansonsten erfüllt, beabsichtigt FDA, Durchsetzungsermessen (Enforcement Discretion) auszuüben. Software, die Empfehlungen an Patienten oder Pflegepersonen statt an medizinisches Fachpersonal richtet, bleibt ein Medizinprodukt. ⁸
• Allgemeines Wohlbefinden. Die überarbeitete Leitlinie vom 6. Januar 2026 besagt, dass FDA „bestimmte Produkte, die nicht-invasive Sensorik verwenden“, zur Abschätzung physiologischer Parameter wie Blutdruck, Sauerstoffsättigung oder Glukose als Produkte für das allgemeine Wohlbefinden betrachten kann. Dies gilt nur unter bestimmten Bedingungen. Das Produkt muss nicht-invasiv sein, darf kein von FDA autorisiertes Produkt ersetzen und darf keine Ausgaben liefern, die zu einer konkreten klinischen Maßnahme veranlassen. ⁹

In der EU legt MDCG 2019-11 Rev.1 einen Entscheidungspfad fest. Software für „allgemeine Zwecke, selbst wenn sie im Rahmen der Gesundheitsversorgung eingesetzt wird,“ oder für „Zwecke der Lebensführung und des Wohlbefindens“ ist gemäß Erwägungsgrund 19 der MDR kein Medizinprodukt. Software, die medizinische Informationen für einen einzelnen Patienten erstellt oder verändert, ist dies in der Regel schon. Die Überarbeitung vom Juni 2025 betont zusätzlich eine klar formulierte Zweckbestimmung sowie modulare Software, bei der sich nur bestimmte Module qualifizieren.

Wie SaMD risikoklassifiziert wird

Das IMDRF-Framework bildet die gemeinsame Sprache. Jede Regulierungsbehörde überführt es anschließend in ihre eigenen gesetzlichen Klassen.

Das IMDRF-Framework in N12 stuft SaMD anhand von zwei Faktoren ein. Der erste ist der Zustand der Gesundheitssituation: kritisch, schwerwiegend oder nicht schwerwiegend. Der zweite ist die Bedeutung der Information für die gesundheitsbezogene Entscheidung: Behandeln oder Diagnostizieren, Steuern des klinischen Managements oder Informieren des klinischen Managements. ¹⁰

Das IMDRF warnt, dass dies „keine regulatorische Klassifizierung ist“. Im Januar 2025 veröffentlichte es N81, das N12 um softwarespezifische Risikoerwägungen für jegliche Medizinprodukte-Software ergänzt, einschließlich Software, die Teil von Hardware ist. ¹¹

Regel 11 der EU-MDR setzt dieselbe Logik in Recht um:

„Software, die dazu bestimmt ist, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden, gehört zur Klasse IIa, es sei denn, diese Entscheidungen haben Auswirkungen, die Folgendes verursachen können: — den Tod oder eine irreversible Verschlechterung des Gesundheitszustands einer Person; in diesem Fall wird sie der Klasse III zugeordnet, oder — eine schwerwiegende Verschlechterung des Gesundheitszustands einer Person oder einen chirurgischen Eingriff; in diesem Fall wird sie der Klasse IIb zugeordnet. Software, die für die Kontrolle von physiologischen Prozessen bestimmt ist, gehört zur Klasse IIa, es sei denn, sie ist für die Kontrolle von vitalen physiologischen Parametern bestimmt, wobei die Art der Änderung dieser Parameter zu einer unmittelbaren Gefahr für den Patienten führen könnte; in diesem Fall wird sie der Klasse IIb zugeordnet. Sämtliche andere Software wird der Klasse I zugeordnet.“

MDCG 2019-11 Rev.1 enthält eine anschauliche Tabelle, die IMDRF-Kategorien den MDR-Klassen zuordnet. Unter Ausschluss von Klasse I entsprechen kritische Situationen der Klasse III (Behandeln oder Diagnostizieren), IIb (Steuern) und IIa (Informieren). Schwerwiegende Situationen entsprechen IIb, IIa und IIa und nicht schwerwiegende durchgehend IIa. Aufgrund von Regel 11 benötigt der Großteil der SaMD zur Entscheidungsunterstützung in der EU eine Benannte Stelle. Der Vorschlag der Europäischen Kommission vom Dezember 2025 zur Überarbeitung der MDR und IVDR würde Regel 11 anhand der IMDRF-Matrix neu fassen. Dieser Vorschlag ist noch anhängig, sodass weiterhin die aktuelle Regel 11 gilt. ¹² Das vollständige EU-Klassifizierungssystem finden Sie in unserem EU-MDR-Klassifizierungsleitfaden.

In den USA wird Software wie jedes andere Medizinprodukt klassifiziert: nach Produktcode und Klassifizierungsvorschrift. Der Großteil der SaMD fällt in Klasse II. Radiologische Bildverarbeitungssoftware (Produktcode QIH, 21 CFR 892.2050) und radiologische computergestützte Triage- und Benachrichtigungssoftware (QAS, 21 CFR 892.2080) sind typische Beispiele. Unser FDA-Klassifizierungsleitfaden erklärt, wie Sie den passenden Code finden.

Was die US-Marktdaten zeigen

KI-gestützte Software ist das am schnellsten wachsende Segment der Autorisierungen von FDA, und nahezu alles davon durchläuft 510(k).

Die Liste der KI-gestützten Medizinprodukte von FDA umfasste in ihrer Aktualisierung vom September 2026 1.614 Einträge, mit finalen Entscheidungen bis zum 29. Juni 2026. 1.553 (96,2 %) waren 510(k)-Freigaben, 40 waren De-Novo-Bewilligungen und 21 waren PMA-Zulassungen. Die Radiologie war für 1.230 davon (76,2 %) das federführende Prüfungsgremium, gefolgt von Herz-Kreislauf (154) und Neurologie (73). FDA weist darauf hin, dass die Liste „keine umfassende Ressource für KI-gestützte Medizinprodukte ist“.

Eine zweite Kennzahl stammt aus der Analyse des openFDA-510(k)-Exports durch Pure Global. Freigaben unter Produktcodes, deren FDA-Produktbezeichnung „software“ enthält, stiegen von 7 im Jahr 2016 auf 187 im Jahr 2025, von 0,2 % auf 5,8 % aller 510(k)-Freigaben. Im Jahr 2025 waren 94 dieser 187 automatisierte radiologische Bildverarbeitungssoftware (QIH). ¹³ Dies führt zu einer Untererfassung von SaMD, da viele Softwareprodukte unter Produktcodes geführt werden, die kein „software“ im Namen tragen. Dennoch bleibt es eine konsistente Trendlinie.

Was FDA bei einer SaMD-Einreichung erwartet

Der Weg ist derselbe wie für Hardware. Die Dokumentation ist softwarespezifisch und wird von vier Leitfäden geprägt.

1. Stufe der Softwaredokumentation. Der Leitfaden von FDA vom Juni 2023 ersetzte das frühere Konzept der „Level of Concern“ durch zwei Dokumentationsstufen. Enhanced Documentation gilt, „wenn ein Ausfall oder Fehler jeglicher Softwarefunktion(en) des Medizinprodukts eine Gefahrensituation mit dem wahrscheinlichen Risiko von Tod oder schwerer Verletzung darstellen könnte“. Die Bewertung erfolgt vor der Anwendung von Risikobeherrschungsmaßnahmen. Andernfalls gilt Basic Documentation. ¹⁴
2. Cybersicherheit. Section 524B des FD&C Act, in Kraft seit dem 29. März 2023, gilt für „Cyber Devices“. Dabei handelt es sich um Produkte, die Software enthalten, eine Verbindung zum Internet herstellen können und für Cybersicherheitsbedrohungen anfällig sein könnten. Einreichungen müssen einen Plan zur Schwachstellenüberwachung, Aktualisierungs- und Patch-Prozesse sowie eine Software-Stückliste (Software Bill of Materials) enthalten. ¹⁵ Der Cybersicherheitsleitfaden von FDA wurde zuletzt am 3. Februar 2026 überarbeitet, um ihn an die QMSR anzugleichen. ¹⁶
3. Vorab festgelegte Änderungskontrollpläne (PCCPs). Section 515C ermöglicht es FDA, geplante künftige Modifikationen im Voraus zu autorisieren, sodass im Rahmen des Plans vorgenommene Änderungen keine erneute Einreichung erfordern. Der PCCP-Leitfaden von FDA für KI-gestützte Softwarefunktionen von Medizinprodukten wurde am 4. Dezember 2024 finalisiert und am 18. August 2025 überarbeitet. Er deckt 510(k), De Novo und PMA ab. ¹⁷ Ein allgemeiner PCCP-Leitfaden für alle Medizinprodukte ist weiterhin ein Entwurf vom August 2024. ¹⁸
4. KI-Lebenszyklus. Der Leitfadenentwurf von FDA vom 7. Januar 2025 zu KI-gestützten Softwarefunktionen von Medizinprodukten formuliert Empfehlungen für den Lebenszyklus und für Einreichungen (Marketing Submissions). Diese behandeln Datenmanagement, Modellbeschreibung, Leistungsvalidierung, Bias, Transparenz und die Überwachung nach dem Inverkehrbringen (Post-Market Monitoring). Im Oktober 2026 lag dieser weiterhin als Entwurf vor. ¹⁹ FDA bat zudem bis zum 19. Oktober 2026 um Stellungnahmen zu einem Diskussionspapier über generative KI. ²⁰

Unter der QMSR gelten Design und Entwicklung (ISO 13485, Abschnitt 7.3) für jedes Produkt der Klassen II und III sowie für Produkte der Klasse I, die durch Software automatisiert sind. Die Softwarevalidierung ist daher sowohl im Qualitätsmanagementsystem als auch in der Einreichung verankert. Siehe unsere Gegenüberstellung von 21 CFR 820 zu ISO 13485.

EU-Anforderungen über Regel 11 hinaus

• Klinische Evidenz. MDCG 2020-1 fordert drei Komponenten für jede MDSW: eine valide klinische Assoziation (wissenschaftliche Validität), eine technische oder analytische Leistung sowie eine klinische Leistung. Diese folgen IMDRF N41. ²¹
• Grundlegende Sicherheits- und Leistungsanforderung 17. Anhang I verlangt, dass Software „nach dem Stand der Technik und unter Berücksichtigung der Grundsätze des Entwicklungslebenszyklus, des Risikomanagements, einschließlich der Informationssicherheit, der Verifizierung und der Validierung“ entwickelt wird.
• Der AI Act. Die Verordnung (EU) 2024/1689 stuft KI-Systeme in Medizinprodukten, die ein Konformitätsbewertungsverfahren durch eine Benannte Stelle erfordern, als Hochrisiko ein. Der Digital Omnibus, Verordnung (EU) 2026/1744, veröffentlicht im Amtsblatt am 24. Juli 2026, verschob diese Pflichten auf den 2. August 2028. ²² MDCG 2025-6 erklärt, wie die MDR und der AI Act zusammenwirken. Darin wird festgestellt, dass der AI Act „keine Auswirkungen auf die Risikoklassifizierung von Medizinprodukten hat“. Ihr Verweis auf ein Datum im August 2027 liegt zeitlich vor dem Omnibus. ²³

Wie andere wichtige Märkte SaMD behandeln

Quellen: ²⁴, ²⁵ und ²⁶. Für den KI-spezifischen Marktzugang in mehr als 30 Ländern siehe unseren Forschungsbericht zu KI als Medizinprodukt.

Die Normen hinter einer SaMD-Akte

• IEC 62304:2006+A1:2015 legt die Software-Lebenszyklus-Prozesse und die Software-Sicherheitsklassen A, B und C fest. Ausgabe 2 ist noch ein Komitee-Entwurf, und die IEC prognostiziert die Veröffentlichung für Oktober 2028. Planen Sie mit der konsolidierten Fassung von 2015. ²⁷
• IEC 82304-1:2016 deckt Gesundheitssoftware-Produkte ab, die auf allgemeinen Computerplattformen ohne dedizierte Hardware laufen, was für SaMD typisch ist. ²⁸
• IEC 81001-5-1:2021 legt Sicherheitsaktivitäten über den gesamten Lebenszyklus von Gesundheitssoftware fest. ²⁹
• ISO 14971-Risikomanagement und IEC 62366-1-Usability-Engineering gelten für SaMD wie für jedes andere Produkt. Unser ISO 14971-Leitfaden behandelt die Risikoakte.

SaMD versus SiMD: Was sich in Ihrer Akte ändert

Häufige Fehler

• Die Zweckbestimmung zuletzt zu verfassen. Klassifizierung, klinische Evidenz und der Status als Wellness-Produkt oder CDS leiten sich alle daraus ab. Entwerfen Sie sie zuerst und halten Sie Marketingaussagen innerhalb dieses Rahmens.
• Anzunehmen, dass „Entscheidungsunterstützung“ „kein Medizinprodukt“ bedeutet. In den USA müssen alle vier CDS-Kriterien erfüllt sein. In der EU stuft Regel 11 die meiste Software zur Entscheidungsunterstützung in Klasse IIa oder höher ein.
• Eine mobile App als niedrigere Stufe zu behandeln. Eine App, die die SaMD-Definition erfüllt, ist SaMD.
• Das alte „Level of Concern“ anzuführen. FDA hat dieses im Juni 2023 durch Basic und Enhanced Documentation ersetzt.
• Mit dem Datum des AI Acts von 2027 zu planen. Die Pflichten für Hochrisiko-Systeme bei KI-gestützten Medizinprodukten gelten nun ab dem 2. August 2028.
• Algorithmen-Updates ohne Plan auszuliefern. Ohne einen PCCP erfordert eine signifikante Änderung in der Regel eine neue Einreichung.

Wie Pure Global unterstützt

Wir ermitteln, ob Software ein Medizinprodukt ist, und verfassen die Zweckbestimmung. Wir klassifizieren die Software nach FDA, der EU-MDR-Regel 11 und anderen Systemen und erstellen Unterlagen für 510(k) und De Novo mit Basic oder Enhanced Documentation, Cybersicherheit und PCCP-Inhalten. Unser Team unterstützt zudem bei Einreichungen bei Benannten Stellen der EU und Registrierungen in mehr als 30 Märkten. Besuchen Sie unsere Seite zur SaMD-Regulierung oder kontaktieren Sie unser Team.

Wie wir die Zahlen ermittelt haben

• KI-gestützte Medizinprodukte: Unsere Auszählung der Liste von KI-gestützten Medizinprodukten (CSV) von FDA, wie im September 2026 aktualisiert. Die Entscheidungen reichen bis zum 29. Juni 2026, und 2026 ist ein unvollständiges Jahr. Die Anteile der Marktzugangswege leiten sich aus dem Präfix der Einreichungsnummer ab (K, DEN oder P).
• Produktcodes mit Software im Namen: Produktcodes in der Produktcodedatei von FDA vom 12. Oktober 2026, deren Produktbezeichnung „software“ enthält, abgeglichen mit dem openFDA-510(k)-Export vom 12. Oktober 2026. Pure Global hält beide im eigenen Data Lake vor. Die Zählungen erfolgen nach dem Kalenderjahr der Entscheidung.