In diesem Nachgelesen erfahren Sie,
- wann KI-Software ein Medizinprodukt ist,
- warum die Zweckbestimmung der zentrale Anknüpfungspunkt ist,
- warum Regel 11 MDR viele Softwareprodukte höher einstuft,
- welche Bedeutung der zentrale Auslegungsleitfaden hat,
- was aus der Einstufung als Medizinprodukt folgt,
- welche besonderen Herausforderungen KI mit sich bringt,
- welche zusätzlichen Pflichten der AI Act vorsieht,
- warum Datenschutz Pflicht bleibt,
- welche praktischen Punkte Hersteller, Anbieter und Betreiber prüfen sollten,
- was daraus für die Praxis folgt.
Wann ist KI-Software ein Medizinprodukt?
Maßgeblich ist die Verordnung (EU) 2017/745 über Medizinprodukte, kurz MDR. Sie regelt das Inverkehrbringen und die Überwachung von Medizinprodukten in der Europäischen Union. Ziel ist ein hohes Schutz- und Sicherheitsniveau für Patientinnen, Patienten und Anwender.[1][2]
Nach Art. 2 Nr. 1 MDR ist ein Medizinprodukt jedes Instrument, jede Software oder jeder Algorithmus, das beziehungsweise die vom Hersteller zur Verwendung für Menschen bestimmt ist und einen spezifischen medizinischen Zweck erfüllen soll. Maßgeblich ist daher nicht allein, wo die Software eingesetzt wird, sondern wofür sie nach der Zweckbestimmung des Herstellers vorgesehen ist.
Ein medizinischer Zweck kann insbesondere vorliegen, wenn die Software dazu bestimmt ist,
- Krankheiten zu erkennen oder zu überwachen,
- Krankheitsverläufe vorherzusagen oder Prognosen zu erstellen,
- Behandlungen zu unterstützen oder Beschwerden zu lindern,
- diagnostische oder therapeutische Entscheidungen vorzubereiten oder zu unterstützen.
Damit kann auch KI-Software ein Medizinprodukt sein – etwa eine Anwendung zur Auswertung radiologischer Bilder, ein System zur Erkennung von Hautveränderungen, eine Software zur Therapieplanung oder ein KI-basiertes Clinical Decision Support System, also ein System, das Ärztinnen und Ärzte bei diagnostischen oder therapeutischen Entscheidungen durch Auswertung medizinischer Informationen u
Nicht jede Software im Gesundheitswesen fällt automatisch unter die MDR. Reine Verwaltungs-, Abrechnungs-, Termin- oder Speicherlösungen sind regelmäßig keine Medizinprodukte, solange sie keine medizinische Entscheidungsfunktion übernehmen.
Zweckbestimmung: Der zentrale Anknüpfungspunkt
Der wichtigste Begriff der MDR ist die Zweckbestimmung. Nach Art. 2 Nr. 12 MDR kommt es darauf an, für welche Verwendung das Produkt nach den Angaben des Herstellers bestimmt ist — etwa in Kennzeichnung, Gebrauchsanweisung, Werbung, Verkaufsunterlagen oder klinischer Bewertung.
Eine Software wird nicht allein deshalb zum Medizinprodukt, weil sie in einer Arztpraxis oder Klinik genutzt wird. Entscheidend ist vielmehr, ob der Hersteller ihr einen medizinischen Zweck gibt. Soll die Software etwa Krankheiten erkennen, überwachen, prognostisch bewerten oder diagnostische beziehungsweise therapeutische Entscheidungen unterstützen, spricht dies für eine medizinische Zweckbestimmung.
Umgekehrt kann der Hersteller die Zweckbestimmung nicht beliebig eng formulieren. Wenn die tatsächlichen Funktionen, die Außendarstellung oder die Nutzerführung einen medizinischen Einsatz nahelegen, wird ein bloßer Hinweis wie „kein Medizinprodukt“ regelmäßig nicht ausreichen. Gerade bei KI-Systemen ist deshalb sorgfältig zu prüfen, welchen Eindruck die Anwendung bei Nutzerinnen und Nutzern erzeugt und welche Funktionen sie tatsächlich bereitstellt.[3] Für die Praxis bedeutet das: Anbieter sollten die Zweckbestimmung präzise formulieren und die Funktionen der Software daran ausrichten. Betreiber sollten prüfen, ob die tatsächliche Nutzung zur Zweckbestimmung passt.
Regel 11 MDR: Warum viele Softwareprodukte höher eingestuft werden
Ist eine Software als Medizinprodukt einzuordnen, muss sie einer Risikoklasse zugeordnet werden. Die MDR unterscheidet:
- Klasse I: niedriges Risiko,
- Klasse IIa: mittleres Risiko,
- Klasse IIb: erhöhtes Risiko,
- Klasse III: höchstes Risiko.
Für Software ist besonders Regel 11 des Anhangs VIII MDR relevant. Sie erfasst Software, die Informationen bereitstellt, die für diagnostische oder therapeutische Entscheidungen herangezogen werden. Gerade bei KI-Anwendungen ist diese Regel häufig entscheidend. Viele Systeme beschränken sich nicht auf reine Verwaltung, sondern werten medizinische Daten aus, markieren Auffälligkeiten, berechnen Risiken, priorisieren Fälle oder geben Hinweise für das weitere Vorgehen. Solche Informationen können ärztliche Entscheidungen beeinflussen, auch wenn die Software selbst keine abschließende Diagnose erstellt. Damit gehört diese Software grundsätzlich mindestens zur Klasse IIa.
Je nach möglicher Auswirkung einer Fehlentscheidung kann die Einstufung auch höher ausfallen:
- Klasse IIa, wenn Informationen für Diagnose- oder Therapieentscheidungen geliefert werden,
- Klasse IIb, wenn eine Fehlentscheidung schwerwiegende gesundheitliche Folgen oder einen chirurgischen Eingriff verursachen kann,
- Klasse III, wenn Tod oder irreversible Verschlechterungen des Gesundheitszustands möglich sind.
Die Klassifizierung ist damit kein bloßer Formalakt. Sie entscheidet darüber, welches Konformitätsbewertungsverfahren einzuhalten ist und ob eine benannte Stelle beteiligt werden muss.[4][2]
Eine benannte Stelle ist eine staatlich benannte und überwachte Prüforganisation, die Medizinprodukte im Rahmen des Konformitätsbewertungsverfahrens prüft und zertifiziert. In Deutschland ist die Zentralstelle der Länder für Gesundheitsschutz bei Arzneimitteln und Medizinprodukten, kurz ZLG, für die Benennung und Überwachung benannter Stellen zuständig; eine aktuelle Übersicht findet sich zudem in der NANDO-Datenbank der EU-Kommission.
Praktisch bedeutet das vor allem: Ab Klasse IIa steigt der regulatorische Aufwand deutlich.
https://www.zlg.de/medizinprodukte/benannte-stellen
https://webgate.ec.europa.eu/single-market-compliance-space/notified-bodies
Zentraler Auslegungsleitfaden
Die EU-Kommission hat den Leitfaden MDCG 2019-11 im Juni 2025 als Rev.1 aktualisiert. Die neue Fassung präzisiert insbesondere, wann Software als Medical Device Software einzuordnen ist, also als Software, die selbst ein Medizinprodukt ist oder eine medizinproduktbezogene Funktion erfüllt. Das kann auch KI-basierte Software betreffen, wenn sie einen medizinischen Zweck verfolgt.
Außerdem ergänzt die Revision Hinweise zu modularer Software, bei der einzelne Funktionen oder Bausteine getrennt zu betrachten sein können, zur Anwendung von Regel 11 MDR auf entscheidungsunterstützende Software, zu neuen Fallbeispielen sowie zur Schnittstelle mit elektronischen Gesundheitsakten und dem European Health Data Space, der einen europäischen Rahmen für die Nutzung und den Austausch von Gesundheitsdaten schaffen soll.
Praxisbeispiel Teledermatologie-App
Das OLG Hamburg hat bei einer App, über die Hautbilder und Anamnesedaten an Fachärzte übermittelt wurden, eine weite Auslegung von Regel 11 vertreten. Nach Auffassung des Gerichts kann es ausreichen, dass eine Software Informationen für ärztliche Diagnose- oder Therapieentscheidungen bereitstellt; sie muss nicht selbst eine Diagnose erstellen [5]. Auch wenn diese weite Auslegung in der Literatur umstritten ist, macht die Entscheidung deutlich, dass schon die strukturierte Bereitstellung medizinisch relevanter Informationen für die Klassifizierung relevant sein kann.[1]
Das abschließende Berufungsurteil des OLG Hamburg vom 20.06.2024 (Az. 3 U 3/24) bestätigt diese Linie im Hauptsacheverfahren: Dermanostic wurde verboten, die App ohne IIa-Zertifizierung in Verkehr zu bringen. Das Gericht betonte erneut die weite Wortlautauslegung von Regel 11 – Software ‚liefert‘ Informationen bereits dann, wenn sie strukturierte Daten für ärztliche Entscheidungen aufbereitet, ohne selbst Diagnosen zu erstellen. Das Urteil gilt als Leitentscheidung für die asynchrone Telemedizin.[6]
Was folgt aus der Einstufung als Medizinprodukt?
Wird KI-Software als Medizinprodukt eingestuft, ist damit ein erheblicher regulatorischer Aufwand verbunden. Hersteller müssen zunächst klar festlegen, wofür die Software bestimmt ist, und daraus die richtige Risikoklasse ableiten. Anschließend müssen sie nachweisen, dass das Produkt sicher ist und seine medizinische Leistung zuverlässig erfüllt. Dafür braucht es vor allem:
- ein Risikomanagement,
- eine technische Dokumentation,
- eine klinische Bewertung,
- ein Qualitätsmanagementsystem.
Je nach Risikoklasse muss außerdem ein Konformitätsbewertungsverfahren durchgeführt werden, ab Klasse IIa regelmäßig unter Beteiligung einer benannten Stelle. Erst danach können die EU-Konformitätserklärung ausgestellt und die CE-Kennzeichnung angebracht werden. Mit dem Marktzugang ist die Verantwortung aber nicht beendet: Hersteller müssen das Produkt weiter beobachten, Erfahrungen aus der Anwendung auswerten und schwerwiegende Vorkommnisse melden.
Eine zu niedrige Einstufung kann im Ergebnis bedeuten, dass das Produkt nicht ordnungsgemäß in Verkehr gebracht wurde.
Auch für Betreiber, etwa Krankenhäuser oder Arztpraxen, bleibt die Zweckbestimmung wichtig. Sie müssen darauf achten, dass das Produkt so eingesetzt wird, wie es vom Hersteller vorgesehen ist. Außerdem sollten Anwenderinnen und Anwender geschult sein und die Funktionsfähigkeit des Produkts im laufenden Einsatz im Blick behalten.[2]
Sonderweg Deutschland: DiGA und DiGAV
Ergänzend zum europäischen Rahmen existiert in Deutschland ein spezifischer Zugangs- und Erstattungsweg für digitale Gesundheitsanwendungen. Nach § 139e SGB V in Verbindung mit der DiGAV können bestimmte CE-gekennzeichnete Medizinprodukte der Klasse I oder IIa in das DiGA-Verzeichnis des BfArM aufgenommen werden. Nach der Aufnahme können sie als digitale Gesundheitsanwendungen ärztlich verordnet und von der gesetzlichen Krankenversicherung erstattet werden.
Für KI-basierte Software, die nach der MDR als Medizinprodukt einzuordnen ist und in Klasse I oder IIa eingestuft wird, kann dieser Erstattungsweg strategisch relevant sein.
Besondere Herausforderungen bei KI
Bei KI-Software stellen sich unter der MDR einige Fragen, die in der Praxis besonders häufig relevant werden.
Allgemeine KI-Systeme und Chatbots
Allgemeine Sprachmodelle wie ChatGPT sind nicht als Medizinprodukte in Verkehr gebracht. Nach klassischer Sicht spricht das zunächst gegen eine MDR-Einstufung, weil die Zweckbestimmung des Herstellers maßgeblich ist.
Gleichzeitig können solche Systeme konkrete medizinische Fragen beantworten. Vorberg/Gottberg argumentieren deshalb, dass bei komplexen Kommunikationssystemen nicht allein auf eine formale Zweckbestimmung abgestellt werden könne. Wenn ein Chatbot im konkreten Austausch medizinische Empfehlungen gibt oder diagnostische Hinweise liefert, könne dies für eine medizinische Zweckrichtung sprechen.[3]
Diese Auffassung ist nicht unumstritten. Für Anbieter und Betreiber folgt daraus jedenfalls, dass allgemeine KI-Systeme im medizinischen Kontext nicht unkontrolliert als Diagnose- oder Therapiehilfe eingesetzt werden sollten.
Selbstlernende Systeme
Besonders anspruchsvoll sind KI-Systeme, die sich nach dem Inverkehrbringen verändern oder weiterlernen. Die MDR verlangt, dass Medizinprodukte zuverlässig, wiederholbar und entsprechend ihrer Zweckbestimmung leistungsfähig sind. Bei kontinuierlich lernenden Systemen ist das schwierig, weil sich das Verhalten des Systems nachträglich ändern kann.
Dann stellt sich die Frage, ob das Produkt noch mit dem geprüften Zustand übereinstimmt oder ob eine neue Bewertung erforderlich wird. Hersteller sollten deshalb ein kontrolliertes Änderungsmanagement etablieren und bereits vorab festlegen, welche Updates oder Modelländerungen zulässig sind und wie sie validiert werden.[4]
Ärztliche Verantwortung
KI kann medizinische Entscheidungen unterstützen, aber nicht ersetzen. Die Verantwortung für Diagnostik, Indikationsstellung und Therapie bleibt grundsätzlich ärztliche Aufgabe. Ärztinnen und Ärzte dürfen KI-Ergebnisse nicht ungeprüft übernehmen, sondern müssen sie plausibilisieren und in den konkreten Behandlungskontext einordnen.[4]
AI Act: Zusätzliche Pflichten für KI-Medizinprodukte
Neben der MDR ist der AI Act, die Verordnung (EU) 2024/1689, relevant. Er ersetzt die MDR nicht, sondern ergänzt sie um KI-spezifische Anforderungen.
KI-Medizinprodukte können als Hochrisiko-KI-Systeme gelten, wenn sie nach der MDR ein Konformitätsbewertungsverfahren unter Beteiligung einer benannten Stelle durchlaufen müssen. Dann kommen zusätzliche Pflichten hinzu, etwa zu:
- Risikomanagement
- Datenqualität
- technische Dokumentation
- Protokollierung
- Transparenz
- menschliche Aufsicht
- Genauigkeit
- Robustheit und Cybersicherheit
In der Praxis überschneiden sich MDR und AI Act. Viele Anforderungen betreffen ähnliche Themen, etwa Dokumentation, Risikomanagement oder Überwachung nach dem Inverkehrbringen. Unternehmen sollten MDR- und AI-Act-Anforderungen deshalb nicht getrennt prüfen, sondern Dokumentation, Risikomanagement und Überwachung möglichst gemeinsam aufsetzen.[4][2]
Datenschutz bleibt Pflicht
KI-Systeme im Gesundheitswesen verarbeiten häufig Gesundheitsdaten. Diese gehören nach Art. 9 DSGVO zu den besonders geschützten personenbezogenen Daten. Für ihre Verarbeitung braucht es eine tragfähige Rechtsgrundlage, etwa die medizinische Versorgung oder eine ausdrückliche Einwilligung.
Zudem sind die Grundsätze der DSGVO einzuhalten: Transparenz, Zweckbindung, Datenminimierung, Integrität und Vertraulichkeit. Bei KI-Systemen ist regelmäßig eine Datenschutz-Folgenabschätzung erforderlich. Besonders sorgfältig zu prüfen sind cloudbasierte Dienste, Drittstaatentransfers, Trainingszwecke, Zugriffsrechte und Re-Identifikationsrisiken.[4]
Praktische Checkliste
Vor Entwicklung, Vertrieb oder Einsatz von KI-Software im Gesundheitswesen sollten die jeweils betroffenen Akteure insbesondere folgende Fragen klären:
Für Hersteller und Anbieter
- Hat die Software einen medizinischen Zweck?
- Unterstützt sie Diagnose, Therapie, Überwachung oder Prognose?
- Liefert sie Informationen für medizinische Entscheidungen?
- Welche Zweckbestimmung gibt der Hersteller an?
- Welche Risikoklasse kommt nach Regel 11 MDR in Betracht?
- Ist eine CE-Kennzeichnung erforderlich oder vorhanden?
- Muss eine benannte Stelle einbezogen werden?
- Sind technische Dokumentation, klinische Bewertung und Risikomanagement vorhanden?
- Fällt das System zusätzlich unter den AI Act?
- Sind Datenschutz, Datensicherheit und mögliche Drittstaatentransfers geprüft?
Für Betreiber, etwa Praxen und Krankenhäuser
- Passt die tatsächliche Nutzung zu der Zweckbestimmung des Herstellers?
- Wird das Produkt entsprechend den Herstellerangaben eingesetzt?
- Sind Anwenderinnen und Anwender geschult?
- Sind Datenschutz, Datensicherheit und mögliche Drittstaatentransfers für den konkreten Einsatz geprüft?
- Bleibt die ärztliche Letztentscheidung gesichert?
Fazit
KI-Software im Gesundheitswesen kann schnell in den Anwendungsbereich der Medizinprodukteverordnung fallen. Entscheidend ist, ob die Software einen medizinischen Zweck erfüllt oder Informationen für diagnostische oder therapeutische Entscheidungen liefert.
Gerade Regel 11 MDR führt dazu, dass viele medizinische Softwareprodukte mindestens in Klasse IIa eingeordnet werden können. Damit steigen die Anforderungen an Konformitätsbewertung, Dokumentation, klinische Bewertung, Risikomanagement und CE-Kennzeichnung erheblich.
Mit dem AI Act kommt eine weitere Regulierungsebene hinzu. Wer KI im medizinischen Umfeld entwickelt, vertreibt oder einsetzt, sollte deshalb früh prüfen, ob die MDR greift, welche Risikoklasse einschlägig ist und welche zusätzlichen Anforderungen nach AI Act und DSGVO zu beachten sind.
KI kann ärztliche Arbeit unterstützen. Die Verantwortung für Diagnose, Indikation und Therapie bleibt aber bei den behandelnden Personen.
Quellen und weiterführende Literatur
- Eichelberger Jan, Anmerkung zu OLG Hamburg, ZfPC – Zeitschrift für Product Compli-ance 2024, 58.
- Lange-Kulmann Karolina/Rammos Thanos in: Clausen/Schroeder-Printzen, Münchener Anwaltshandbuch Medizinrecht, 4. Aufl. 2026, § 26 Rn. 43–87.
- Vorberg Sebastian/Gottberg Friedrich, ChatGPT als Medizinprodukt, Recht Digital (RDI), 2023, 159.
- Katzenmeier Christian, Der Rechtsrahmen für KI in der Gesundheitsversorgung, Neue Juristische Wochenschrift (NJW), 2025, 3673.
- OLG Hamburg, Beschluss vom 22.9.2023 – 3 W 30/23, ZfPC 2024, 58.
- OLG Hamburg, Urt. v. 20.06.2024, Az. 3 U 3/24.
- Verordnung (EU) 2017/745, MDR.
- Verordnung (EU) 2024/1689, AI Act.
- Datenschutz-Grundverordnung, DSGVO.






