Software-Qualifizierung nach MDCG 2019-11: wann Software ein Medizinprodukt ist und welche Klasse gilt

§ IDie Zweckbestimmung entscheidet, nicht die Technik

Art. 2 Nr. 1 MDR nennt Software ausdrücklich als mögliches Medizinprodukt. Entscheidend ist, ob sie dem Hersteller zufolge für Menschen bestimmt ist und einen medizinischen Zweck erfüllen soll. Dazu zählen: Krankheiten diagnostizieren, verhüten, überwachen, vorhersagen, prognostizieren, behandeln oder lindern; Verletzungen oder Behinderungen diagnostizieren, überwachen, behandeln, lindern oder kompensieren; die Anatomie oder einen physiologischen oder pathologischen Vorgang untersuchen, ersetzen oder verändern.

Was der Hersteller bestimmt, ergibt sich aus seinen Angaben auf der Kennzeichnung, in der Gebrauchsanweisung, im Werbe- und Verkaufsmaterial und bei der klinischen Bewertung (Art. 2 Nr. 12 MDR). Dazu gehören auch App-Store-Text, Website und Vertriebsunterlagen. MDCG 2019-11 verlangt in der Fassung vom Juni 2025 eine Zweckbestimmung, die alle Funktionen mit medizinischem Zweck vollständig und eindeutig beschreibt. Unklarheiten führen nach der Leitlinie zu Fehleinstufungen und damit zu Problemen beim Marktzugang.

Werbung und Zweckbestimmung müssen zueinander passen. Art. 7 MDR verbietet Angaben, die über Zweckbestimmung, Sicherheit oder Leistung irreführen, etwa indem sie dem Produkt Funktionen zuschreiben, die es nicht besitzt. In Deutschland ist ein solcher Verstoß strafbar (§ 93 Abs. 2 Nr. 1 MPDG). Medizinische Aussagen müssen nach der Leitlinie zudem durch klinische Nachweise gedeckt sein.

Dass Software nicht im oder am Körper wirkt, schließt die Einstufung nicht aus. Der Gerichtshof der EU hat das schon zur früheren Richtlinie 93/42/EWG entschieden: Software, deren Funktion Patientendaten nutzt, um Kontraindikationen, Wechselwirkungen und Überdosierungen festzustellen, ist in Bezug auf diese Funktion ein Medizinprodukt (Urteil vom 07.12.2017, C-329/16, Snitem und Philips France).

§ IIDie fünf Prüfschritte nach MDCG 2019-11

Die Leitlinie prüft in fünf Entscheidungsschritten, ob Software unter die Medizinprodukte-Verordnungen fällt (Abschnitt 3.3, Abbildung 1):

• Schritt 1 – Software? Ist das Produkt Software im Sinne der Leitlinie, geht es weiter. Wenn nicht, gilt die Leitlinie nicht; die MDR kann trotzdem greifen.
• Schritt 2 – Anhang XVI, Zubehör oder Steuerung? Ist die Software ein Produkt nach Anhang XVI MDR oder Zubehör eines Medizinprodukts? Steuert sie ein Medizinprodukt oder beeinflusst sie seine Anwendung? Dann wird sie mit diesem Produkt reguliert, als Zubehör eigenständig.
• Schritt 3 – mehr als Speichern? Software, die Daten nur speichert, archiviert, übermittelt, einfach durchsucht oder verlustfrei komprimiert, ist keine Medizinprodukte-Software. Erst eine Verarbeitung darüber hinaus kann sie dazu machen.
• Schritt 4 – für einzelne Patienten? Nicht erfasst sind Auswertungen allein von Bevölkerungsdaten, allgemeine Diagnose- oder Behandlungspfade, Fachliteratur, medizinische Atlanten, Modelle und Vorlagen sowie Software nur für epidemiologische Studien oder Register.
• Schritt 5 – medizinischer Zweck? Erfüllt die Software die Definition des Art. 2 Nr. 1 MDR, ist sie Medizinprodukte-Software (englisch MDSW).

Prüfen Sie jede Funktion einzeln. Schon eine Funktion mit medizinischem Zweck unterliegt der MDR.

Schritt 3 ist enger, als er klingt. Eine „einfache Suche“ ist keine Medizinprodukte-Software. Trägt die Suche aber zu einem medizinischen Zweck bei, etwa als Suche mit Sprachverarbeitung in Befunden, gilt die Ausnahme nach der Leitlinie nicht. Software, die medizinische Informationen verarbeitet, analysiert, interpretiert, berechnet, erzeugt oder verändert, kann Medizinprodukte-Software sein, wenn ihre Zweckbestimmung einen medizinischen Zweck umfasst. Beispiele der Leitlinie sind die Suche nach Befunden in medizinischen Bildern und eine Kontrastverstärkung, die als Entscheidungshilfe dient. Eine Darstellung, die nur der Optik oder der Kompatibilität dient, genügt nicht.

Zwei Kriterien spielen keine Rolle. Der Ort ist gleichgültig: Cloud, Smartphone, Server oder virtuelle Umgebung ändern die Qualifizierung nicht. Den früheren Begriff „Standalone-Software“ verwendet die Leitlinie deshalb nicht mehr. Auch das Schadensrisiko ist nach Abschnitt 3.1 kein Kriterium dafür, ob Software ein Medizinprodukt ist; es wirkt sich erst bei der Klasse aus.

§ IIIMDR oder IVDR: Welche Verordnung gilt?

Ein In-vitro-Diagnostikum ist nach Art. 2 Nr. 2 IVDR auch Software, die der Hersteller zur In-vitro-Untersuchung von Proben aus dem menschlichen Körper bestimmt, um Informationen zu liefern. Diese betreffen etwa physiologische oder pathologische Zustände oder die Prädisposition für eine Krankheit oder dienen der Festlegung oder Überwachung therapeutischer Maßnahmen (Buchst. a bis f).

Die Leitlinie ordnet in drei Schritten zu (Abschnitt 3.4, Abbildung 2). Liegt die Information im Bereich der IVDR-Definition? Stammen die Daten ausschließlich von In-vitro-Diagnostika, ist die Software ein In-vitro-Diagnostikum. Stammen sie aus In-vitro-Diagnostika und aus Medizinprodukten, kommt es darauf an, welche Datenquelle die Zweckbestimmung im Wesentlichen trägt. Dafür sieht die Leitlinie eine Gewichtung der Daten nach ihrer Bedeutung für das Ergebnis vor, mit Beispielen in ihrem Anhang II.

Ein Beispiel der Leitlinie: Software, die die optische Dichte eines ELISA-Lesegeräts mit klinischen Algorithmen für diagnostische oder prognostische Zwecke auswertet, ist ein In-vitro-Diagnostikum. Steuert Software dagegen ein Gerät oder beeinflusst seine Anwendung, folgt sie der Verordnung des gesteuerten Geräts.

Nach der IVDR wird Software in die Klassen A bis D eingestuft (Anhang VIII IVDR). Auch dort gilt: Software, die ein Produkt steuert oder dessen Anwendung beeinflusst, gehört zu dessen Klasse; ist sie unabhängig, wird sie für sich klassifiziert (Durchführungsvorschrift 1.4). Ohne Benannte Stelle kommen nur Produkte der Klasse A aus, die nicht steril sind (Art. 48 Abs. 10 IVDR).

§ IVRegel 11: Welche Klasse gilt für Software?

Regel 11 in Anhang VIII MDR hat drei Teile. Software, die Informationen für diagnostische oder therapeutische Entscheidungen liefert, gehört zur Klasse IIa. Sie gehört zur Klasse IIb, wenn die Entscheidungen eine schwerwiegende Verschlechterung des Gesundheitszustands oder einen chirurgischen Eingriff verursachen können. Bei möglichem Tod oder irreversibler Verschlechterung gehört sie zur Klasse III. Software zur Überwachung physiologischer Prozesse gehört zur Klasse IIa, bei vitalen Parametern, deren Änderung eine unmittelbare Gefahr bedeuten kann, zur Klasse IIb. Alle sonstige Software ist Klasse I.

Der erste Teil beschreibt nach MDCG 2019-11 die Wirkungsweise praktisch jeder Medizinprodukte-Software und ist deshalb grundsätzlich auf jede Software mit medizinischem Zweck anzuwenden (Abschnitt 4.2.1). Die Revision vom Juni 2025 hat das mit einem Beispiel präzisiert: Software, die durch Analyse physiologischer Parameter dem Risiko von Krankheiten vorbeugen soll, liefert Informationen für Entscheidungen mit diagnostischem Zweck und gehört zur Klasse IIa. Klasse I bleibt damit die Ausnahme.

Ob IIb oder III gilt, richtet sich nach der Bedeutung der Information für die Entscheidung und nach dem Zustand des Patienten. Die Leitlinie lehnt sich dafür an das Risikoschema des International Medical Device Regulators Forum an (Anhang III). Daneben sind die Durchführungsvorschriften des Anhangs VIII Kapitel II zu beachten:

• Nr. 3.3: Software, die ein Produkt steuert oder dessen Anwendung beeinflusst, gehört zu dessen Klasse; unabhängige Software wird für sich klassifiziert. Hat sie einen eigenen medizinischen Zweck und steuert zugleich ein Gerät, wird sie nach der Leitlinie für sich klassifiziert, aber nicht niedriger als das Gerät.
• Nr. 3.5: Sind mehrere Regeln oder Unterregeln anwendbar, gilt die strengste. Software zur Melanom-Bildanalyse, die einen Laserscanner der Klasse IIa steuert, ordnet die Leitlinie nach Regel 11 der Klasse III zu.
• Weitere Regeln: Für aktive Produkte sind auch die Regeln 9, 10, 12, 13, 15 und 22 zu prüfen; Software zur Empfängnisverhütung ist nach Regel 15 Klasse IIb, geschlossene Regelkreise sind nach Regel 22 Klasse III.

Von der Klasse hängt das Verfahren ab. In Klasse I erklärt der Hersteller die Konformität selbst, nachdem er die technische Dokumentation erstellt hat; eine Benannte Stelle wirkt nur bei sterilen Produkten, Produkten mit Messfunktion und wiederverwendbaren chirurgischen Instrumenten mit (Art. 52 Abs. 7 MDR). Ab Klasse IIa ist eine Benannte Stelle Pflicht. Wer Software der Klasse IIa, IIb oder III ohne das vorgeschriebene Verfahren in Verkehr bringt, macht sich in Deutschland strafbar (§ 93 Abs. 3 Nr. 3 bis 5 MPDG).

§ VModule, Plattformen und Updates

Viele Produkte bestehen aus Modulen, von denen nur einige einen medizinischen Zweck haben. Nach Abschnitt 7 der Leitlinie unterliegen nur diese Module der MDR oder IVDR. Der Hersteller muss Grenzen und Schnittstellen der Module festlegen, die regulierten Module ausdrücklich benennen und den Anwendern mitteilen, welche Module das Produkt bilden und welchem Recht sie unterliegen.

Die Abgrenzung hat Grenzen. Nicht medizinische Funktionen, die für den Betrieb der Medizinprodukte-Software nötig sind, dürfen aus ihrer Beschreibung nicht herausgenommen werden. Der Hersteller muss bewerten, wie sie Sicherheit und Leistung beeinflussen, und das Zusammenspiel dokumentieren. Läuft ein medizinisches Modul über die Oberfläche einer nicht regulierten Plattform, gehört deren Schnittstelle nach der Leitlinie in die Bewertung von Gebrauchstauglichkeit und klinischer Leistung.

Neu in der Revision vom Juni 2025 sind Zusatzfunktionen, die sich in Produkten am Markt zu- oder abschalten lassen, etwa eine erweiterte Bildanalyse. Erfüllt ein solches Modul die Definition, ist es Medizinprodukte-Software und durchläuft die Konformitätsbewertung nach seiner eigenen Klasse.

Jede Änderung kann die Einstufung verschieben. Der Hersteller muss bewerten, wie sich Änderungen an Funktion, Zweckbestimmung, Design und Herstellung auf Qualifizierung und Klasse auswirken (Abschnitt 8). Eine neue Funktion kann Software erstmals zum Medizinprodukt machen oder ihre Klasse erhöhen; ein neues Modul kann für sich Medizinprodukte-Software sein. Software, die selbst kein Medizinprodukt ist, aber als Zubehör eines Medizinprodukts bestimmt ist, fällt ebenfalls unter die MDR (Art. 2 Nr. 2 MDR) und wird gesondert klassifiziert (Anhang VIII Nr. 3.2).

§ VITypische Einordnungen nach Anhang I der Leitlinie

Anhang I der Leitlinie ordnet häufige Softwaretypen aus dem Gesundheitswesen ein. Die Beispiele sind nicht abschließend:

• Krankenhausinformationssysteme für Aufnahme, Terminplanung, Versicherung und Abrechnung sind für sich keine Medizinprodukte. Zusätzliche Module können eigene Medizinprodukte sein.
• Software zur Entscheidungsunterstützung, die medizinisches Wissen und Algorithmen mit Patientendaten verbindet und Empfehlungen zu Diagnose, Prognose, Überwachung oder Behandlung gibt, ist ein Medizinprodukt. Dazu zählen Bestrahlungsplanung, Dosisberechnung für Chemotherapie und computerunterstützte Erkennung in Röntgenbildern oder EKG.
• Informationssysteme, die Daten nur übertragen, speichern, umwandeln, formatieren oder archivieren, sind keine Medizinprodukte. Elektronische Patientenakten, die die Papierakte ersetzen, ebenfalls nicht; Module darin, die etwa Bilder mit Messwerkzeugen auswerten, Arrhythmien melden oder Wechselwirkungen anzeigen, können es sein.
• Wellness- und Fitness-Apps, Abrechnung, Personalplanung, E-Mail und Textverarbeitung sind keine Medizinprodukte-Software (Abschnitt 3.1).

Beansprucht eine Software Interoperabilität mit Systemen für elektronische Patientenakten nach der EHDS-Verordnung (EU) 2025/327, sind nach der Leitlinie die Anforderungen beider Regelwerke zu erfüllen. Für Software mit KI kommt die KI-Verordnung hinzu; ob sie ein Hochrisiko-KI-System ist, folgt aus der Klasse nach der MDR. Einzelheiten im Beitrag „KI-VO und MDR: doppelte Konformitätsbewertung?“.

§ VIIWas gehört in den Qualifizierungsvermerk?

Das Ergebnis der Prüfung sollte schriftlich, datiert und begründet vorliegen. Benannte Stelle, Importeur und Behörde fragen danach, und bei jeder Änderung ist es der Ausgangspunkt. Nach unserer Einschätzung gehört in einen belastbaren Vermerk:

• die Zweckbestimmung im Wortlaut, mit Version und Datum, und die ausgewerteten Quellen nach Art. 2 Nr. 12 MDR: Kennzeichnung, Gebrauchsanweisung, App-Store-Text, Website, Vertriebsunterlagen, klinische Bewertung
• die Liste der Funktionen und Module mit ihrer Einordnung, einschließlich der Schnittstellen
• die fünf Prüfschritte der Leitlinie mit Begründung und die Zuordnung zu MDR oder IVDR
• die Klasse mit Regel, Unterregel und den Durchführungsvorschriften Nr. 3.3 und 3.5 sowie die geprüften weiteren Regeln
• bei KI-Komponenten die Einstufung nach Art. 6 Abs. 1 KI-VO
• die Auslöser für eine Neubewertung: neue Funktion, geänderte Werbeaussage, neue Nutzergruppe oder neuer Markt

Bleiben Zweifel, gibt es zwei förmliche Wege. In Deutschland entscheidet die zuständige Bundesoberbehörde auf Antrag des Herstellers, seines Bevollmächtigten oder seiner Benannten Stelle mit Sitz in Deutschland über die Klassifizierung und über den rechtlichen Status als Medizinprodukt. Sie soll binnen drei Monaten entscheiden (§ 6 Abs. 2 MPDG). Streiten Hersteller und Benannte Stelle über die Klasse, entscheidet die zuständige Behörde (Art. 51 Abs. 2 MDR, § 6 Abs. 1 MPDG). Auf EU-Ebene kann die Kommission auf Ersuchen eines Mitgliedstaats den Status eines Produkts durch Durchführungsrechtsakt festlegen (Art. 4 Abs. 1 MDR).

Einen ersten Anhaltspunkt gibt der Software-Check auf der Seite Digital Health Regulatory: fünf Fragen nach der Leitlinie und eine vorläufige Klasse nach Regel 11, ausgewertet nur in Ihrem Browser. Den Vermerk ersetzt er nicht.