Wann Software zum Medizinprodukt wird — und wann nicht
Ob eine Anwendung als Medizinprodukt reguliert wird, entscheidet nicht die Technik, sondern die Zweckbestimmung. Derselbe Code kann harmlose Auswertung oder zulassungspflichtige Software sein — je nachdem, was er laut Hersteller leisten soll. Dieser Beitrag zeigt, woran die Einordnung hängt und wie Sie sie früh und bewusst treffen.
Viele Teams stellen die Frage zu spät: Ist die Software, die wir bauen, ein Medizinprodukt? Die Antwort steckt selten in der Technik. Sie steckt in dem, was die Software laut ihrem Hersteller leisten soll. Wer das früh klärt, spart sich später teure Kehrtwenden — in beide Richtungen.
Die Zweckbestimmung entscheidet, nicht die Technik
Ausgangspunkt ist die Definition in Artikel 2 Nummer 1 der Medizinprodukteverordnung (MDR). Danach ist ein Produkt ein Medizinprodukt, wenn der Hersteller es für einen medizinischen Zweck bestimmt: Vorbeugung, Diagnose, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung von Krankheiten sowie von Verletzungen oder Behinderungen. Dieser erklärte Verwendungszweck heißt Zweckbestimmung (englisch intended purpose).
Entscheidend ist damit die Aussage, nicht die Implementierung. Zwei Anwendungen mit identischem Quellcode können unterschiedlich eingeordnet sein, wenn die eine nur Werte anzeigt und die andere eine medizinische Entscheidung stützt. Die Leitlinie MDCG 2019-11 der europäischen Koordinierungsgruppe führt hierfür durch nachvollziehbare Entscheidungsschritte — sie ist der praktische Einstieg in die Frage „Medizinprodukt: ja oder nein?".
Ein Beispiel
Nehmen Sie ein Dashboard, das Laborwerte einer Patientin darstellt. Solange es die Werte lediglich sammelt, speichert und anzeigt, verfolgt es keinen eigenen medizinischen Zweck. Ergänzen Sie dieselbe Oberfläche um einen Hinweis wie „Wert kritisch, Dosis prüfen", liefert die Software Information für eine diagnostische oder therapeutische Entscheidung. Aus der Anzeige ist eine Entscheidungsunterstützung geworden — und damit sehr wahrscheinlich ein Medizinprodukt. Der Unterschied liegt nicht im Datensatz, sondern in der Zweckbestimmung.
Wie die Risikoklasse zustande kommt
Ist die Software ein Medizinprodukt, richtet sich ihre Risikoklasse nach den Regeln in Anhang VIII der MDR. Für Software ist Regel 11 maßgeblich. Vereinfacht: Software, die Informationen für diagnostische oder therapeutische Entscheidungen liefert, wird regelmäßig in Klasse IIa eingeordnet. Je schwerer der mögliche Schaden einer falschen Entscheidung wiegt, desto höher die Klasse — bis hin zu Klasse III, wenn eine Entscheidung zum Tod oder zu einer irreversiblen Verschlechterung des Gesundheitszustands führen kann. Software zur Überwachung physiologischer Prozesse folgt eigenen Schwellen. Die Klasse I bleibt für medizinische Software die Ausnahme.
Die überarbeitete Fassung der Leitlinie (MDCG 2019-11 Rev.1, Juni 2025) schärft diese Beispiele nach und behandelt ausdrücklich Software mit künstlicher Intelligenz. Enthält Ihr Produkt KI-Anteile, kommt neben der MDR die KI-Verordnung (EU) 2024/1689 hinzu; beide Rahmen greifen nebeneinander.
Vorgehen
Praktisch hat sich diese Reihenfolge bewährt:
- Zweckbestimmung schriftlich festlegen — was das Produkt medizinisch tun soll und ausdrücklich, was nicht.
- Anhand MDCG 2019-11 qualifizieren: Medizinprodukt ja oder nein?
- Bei „ja" die Klasse über Regel 11 bestimmen und den KI-Anteil zusätzlich an der KI-Verordnung spiegeln.
- Nachweise und klinische Bewertung früh planen, nicht erst nach der Entwicklung.
Einordnung
Nicht jede Software im Gesundheitswesen ist ein Medizinprodukt. Reine Dokumentation, Abrechnung, Terminverwaltung oder allgemeine Wellness-Anwendungen ohne medizinische Aussage fallen in der Regel nicht darunter. Auch Systeme, die Daten nur speichern, weiterleiten oder unverändert anzeigen, ohne sie zu interpretieren, sind meist keine Medizinprodukte.
Die Kehrseite ist ebenso wichtig: Sie können in die Regulierung hineinrutschen, ohne es zu wollen. Für die Einordnung zählt die tatsächliche Aussage über das Produkt — nicht die Absicht, Aufwand zu vermeiden. Eine werbliche Formulierung, die einen medizinischen Nutzen verspricht, kann eine Zweckbestimmung begründen, obwohl das Team die Zulassungspflicht gar nicht anstrebte. Grenzfälle sind außerdem nicht immer eindeutig; im Zweifel klärt die zuständige Behörde.
Fazit
Die Zweckbestimmung ist keine Formsache am Ende, sondern die Weiche am Anfang: Sie bestimmt Klasse, Evidenz und Kosten. Beide Fehler sind teuer — die zu hohe Einstufung bremst ein harmloses Werkzeug aus, die zu niedrige stellt ein zulassungspflichtiges Produkt ohne Nachweise ins Feld. Wer die Frage früh und bewusst beantwortet, verliert später keine Zeit.
Quellen: Verordnung (EU) 2017/745 (Medizinprodukteverordnung, MDR), Artikel 2 Nummer 1 und Anhang VIII Regel 11. Medical Device Coordination Group: MDCG 2019-11 Rev.1, Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR, Juni 2025. Verordnung (EU) 2024/1689 (KI-Verordnung).
Wir beginnen mit einer Prozessanalyse und zeigen belegbar, was möglich ist.
Gespräch vereinbaren