Decision Support Systems als Medizinprodukt

Decision Support Systems, zu Deutsch Entscheidungsunterstützungssysteme, finden auch in der Medizin zunehmend Anwendung. Handelt es sich dabei um Medizinprodukte, müssen diese die gesetzlichen Anforderungen (z. B. die grundlegenden Anforderungen) erfüllen.

Der Hype um die künstliche Intelligenz, insbesondere das Machine Learning, und Anwendungen wie Watson wecken Hoffnungen an die Leistungsfähigkeit von Decision Support Systemen.

Dieser Artikel stellt die besonderen Herausforderungen vor, welche Hersteller von Decision Support Systems bewältigen müssen, und gibt Tipps, wie diese Herausforderungen gemeistert werden können. Er erläutert auch das entsprechende Guidance-Dokument der FDA.

1. Decision Support Systems: Definition und Beispiele

a) Definition

b) Abgrenzungen

Viele klassische Management-Informationssysteme und Data-Warehouses bereinigen und konsolidieren Daten und stellen diese in Form von Dashboards oder OLAP-Würfeln bereit. Die Zielgruppe dieser Systeme ist regelmäßig das Management.

Decision Support Systems (DSS) verfolgen zwar ähnliche Ansätze, basieren aber meist auf Modellen oder fortgeschrittenen mathematischen Verfahren. Sie haben den Anspruch, nicht nur Informationen, sondern entscheidungsrelevantes Wissen zu präsentieren. Viele DSS setzen daher auf Data Warehouses auf. Sie verwenden bei der Weiterverarbeitung der Daten, besonders in der Medizin, Verfahren der künstlichen Intelligenz.

c) Beispiele in der Medizin

Decision Support Systems in der Medizin, auch als „Clinical Decision Support Systems“ (CDSS) bezeichnet, dienen allen Facetten medizinischen Handelns, z. B.:

• Diagnoseunterstützung
  • Interpretation radiologischer Bilder insbesondere bei onkologischen und neurologischen Fragestellungen sowie der Infektionsdiagnostik
  • Pathologie und Histologie nicht nur im onkologischen Kontext
  • Dermatologie: z. B. Beurteilung von Hautläsionen
  • Ophthalmologie: Diagnose u. a. von Glaukomen
  • Differenzialdiagnostik auf Basis von Befunden, der Klinik und weiteren Parametern
• Therapieunterstützung
  • Arzneimitteltherapie z. B. Prüfung von Kontraindikationen und Wechselwirkungen oder die Auswahl der Medikamente z. B. Antibiotika oder Zytostatika.
  • Abwägung von Therapiealternativen oder Kombinationen (z. B. Chemotherapie versus Bestrahlung versus Operation versus palliative Versorgung)
  • Bestrahlungsplanung
  • Triage, Entscheidung über Priorität und nächste Schritte
• Monitoring
  • Alarmierung bei Intensivpatienten z. B. bei PDMS
  • Überwachung von Patienten zu Hause

2. FDA Guidance „Clinical Decision Support Software”

a) Einführung

Die FDA hat für Decision Support Systems 2017 ein eigenes Guidance-Dokument als ersten, 2019 als zweiten Entwurf und 2022 final veröffentlicht. Am 6. und am 29. Januar 2026 hat die FDA dieses Dokument ein weiteres Mal überarbeitet. Das Ziel dieser Überarbeitung bestand darin, das Kriterium des „time-critical decision-making“ weitgehend zu streichen, das zuvor eine automatische Regulierung als Medizinprodukt ausgelöst hätte.

Wer erhofft, im Guidane-Dokument Hilfestellungen zu finden, wie die regulatorischen Anforderungen für diese Produktklasse zu erfüllen sind, wird enttäuscht. Das Dokument grenzt lediglich ab – allerdings sehr ausführlich – wann ein CDSS zum Medizinprodukt wird.

Dazu stützt sich die FDA auf die Definition des Gesetzestextes, den Artikel 520(o)(1)(E) des Food, Drug and Cosmetic Acts, kurz FD&C. Leider ist dieser Text so verkorkst geschrieben, dass sich die FDA nun bemüßigt fühlt, diesen für den Fall von DSS zu interpretieren.

b) Interpretation des Gesetzestextes

Demnach ist eine Software nur dann kein Medizinprodukt, wenn alle der folgenden Bedingungen erfüllt sind:

1. Sie dient NICHT der Erfassung, Verarbeitung oder Analyse von
   1. medizinischen Bildern,
   2. Signalen, die von einem IVD Gerät stammen
   3. (physiologischen) Signalen wie EKGs oder EEGs und zugehörige Auswertesoftware.
2. Sie dient (nur) der Anzeige, Analyse oder dem Ausdruck medizinischer Informationen über einen Patienten oder der Anzeige anderer medizinischer Informationen wie Bücher, klinischer Veröffentlichungen oder Leitlinien, Medikamentenbeipackzettel oder Behördenempfehlungen, selbst dann, wenn das medizinische Fachpersonal diese Informationen für die Entscheidung über Vorbeugemaßnahmen, Diagnosen und Behandlungen nutzt.
3. Sie dient der Unterstützung des medizinischen Fachpersonals, in dem sie Empfehlungen gibt zur Vermeidung, Diagnose oder Behandlung von Krankheiten.
   Dies ist interessant, denn genau dies würde die Software in Europa als Medizinprodukt klassifizieren. Die FDA geht noch weiter und kündigt an, auch bei Software, die sich nicht an das Fachpersonal, sondern an Patienten wendet, die Einhaltung der regulatorischen Anforderungen nicht einzufordern.
   Allerdings schränkt der nächste Absatz diese Großzügigkeit wieder substanziell ein:
4. Die Software gibt diese Empfehlungen in einer so transparenten Art und Weise, dass die Anwender selbst zu diesen Empfehlungen kommen können, ohne sich primär auf die Software verlassen zu müssen. Das setzt Folgendes voraus:
   1. Die Zweckbestimmung der Software(-Funktion) ist klar benannt.
   2. Die Nutzergruppe ist klar bestimmt (z. B. Ultraschalltechniker, Gefäßchirurg).
   3. Die Inputs, auf denen die Empfehlungen basieren, sind genannt und auch öffentlich verfügbar.
   4. Das logische Grundprinzip und die Herleitung der Empfehlung sind transparent gemacht. Die FDA besteht auch darauf, dass diese Informationen nicht nur öffentlich verfügbar sind (z. B. in der medizinischen Fachliteratur), sondern dass die vorgesehenen Nutzer diese Information auch verstehen und die Empfehlung nachvollziehen können.

Die FDA versuchte, in den älteren Ausgaben des Dokuments, einen Teil dieser Entscheidungen in eine Tabelle zu übertragen:

Is the intended user a healthcare professional?	Can the user independently review the basis?	Is it Device CDS?
yes	yes	no, it is Non-Device-CDS because it meets all of section 520(o)(1) criteria
yes	no	yes, it is Device-CDS
no, it is a patient or caregiver	yes	yes, it is Device-CDS
no, it is a patient or caregiver	no	yes, it is Device-CDS

Diese Tabelle fehlt in der aktuellen Ausgabe. Allerdings unterscheidet die FDA weiterhin zwischen Device-CDS und Non-Device-CDS.

c) Änderungen durch die Version 2026 des Guidance-Dokuments

Das Update der finalen Richtlinie (veröffentlicht im Januar 2026) bringt vor allem Klarstellungen bei der Auslegung der vier gesetzlichen Kriterien des „21st Century Cures Act“, ändert diese jedoch nicht grundlegend. Zu den wichtigsten Änderungen gehören:

• Klare Definitionen (Kriterium 1 & 2): Die FDA hat präzisiert, was unter einem „Signal Acquisition System“ (Systeme, die Parameter für medizinische Zwecke am/im Körper messen, z. B. durch kontinuierliches Streaming) und einem „Pattern“ (Muster aus mehrfachen/sequenziellen Messungen) zu verstehen ist. Auch der Begriff „medizinische Informationen“ wurde genauer definiert als Informationen, die für die klinische Versorgung relevant sind.
• Verschiebung der Zeitkritikalität: Die Überlegung, ob eine Software zeitkritische Entscheidungen („time-critical decision-making“) unterstützt, wurde von Kriterium 3 in das Kriterium 4 verschoben.
• Automatisierungs-Bias (Kriterium 4): Bei der Prüfung, ob ein Arzt die Empfehlungen der KI eigenständig überprüfen kann (Kriterium 4), berücksichtigt die FDA nun explizit den Grad der Automatisierung sowie die Gefahr des „Automation Bias“ – also die menschliche Neigung, sich in zeitkritischen Situationen blind auf ein automatisiertes System zu verlassen.
• Neue „Enforcement Discretion“-Richtlinie: Es wurde eine Richtlinie zum Ermessensspielraum (Enforcement Discretion) für bestimmte Systeme hinzugefügt, die eigentlich Kriterium 3 nicht erfüllen.

Das Entscheidungsdiagramm enthält somit eine weitere Verzweigung.

d) Mapping mit dem IMDRF Dokument

Die FDA fühlte sich bemüßigt, ihre Abgrenzung mit dem Framework des IMDRF zu Software as a Medical Device abzustimmen. Sie kennen vielleicht diese Tabelle:

State of health care situation or condition	significance of information provided by SaMD to healthcare decision
	Treat or diagnose	Drive clinical management	Inform clinical management
Critical	IV	III	II
Serious	III	II	I
Non-serious	II	I	I

Die FDA sah die Non-CDS nur im Bereich der Spalte „Inform Clinical Management“. Die beiden anderen Spalten schloss die FDA aus:

SaMD functions that drive clinical management are not CDS, as defined in the Cures Act and used in this guidance […]

SaMD functions that treat or diagnose are not CDS, as defined in the Cures Act and used in this guidance […]

Clinical Decision Support Software – Draft Guidance for Industry and Food and Drug Administration Staff

In der aktuellen Ausgabe ist dieser starke Bezug zum IMDRF-Dokument nicht mehr enthalten.

Die FDA nennt Software-Funktionen, die als Medizinprodukt gelten, weil sie mindestens eines der vier Kriterien für Non-Device CDS nicht erfüllen.

Kriterium	Anforderung für Non-Device CDS
1	Nicht zur Erfassung, Analyse oder Auswertung von medizinischen Bildern oder Signalen bestimmt
2	Zur Anzeige, Analyse oder Ausgabe medizinischer Informationen bestimmt
3	Keine spezifische Diagnose oder Therapieanweisung, sondern Empfehlungen/Optionen
4	Anwender kann die Empfehlung unabhängig überprüfen (keine zeitkritische Entscheidung)

e) Beispiele

Decision Support Systeme, die kein Medizinprodukt sind

5 Illustrative Beispiele

#	Kategorie	Beispiel
1	Evidenzbasierte Verordnungs-Sets	Software, die einem Arzt eine Liste von Diagnose- und Therapieoptionen basierend auf klinischen Leitlinien für erwachsene Patienten mit Pneumonie-Symptomen anzeigt.
2	Abgleich mit Referenzinformationen	Software, die patientenspezifische Informationen (Diagnose, Allergien, Symptome) mit Behandlungsleitlinien für häufige Erkrankungen wie Influenza, Hypertonie oder Hypercholesterinämie abgleicht.
3	Wechselwirkungswarnungen	Software, die Arzneimittel-Wechselwirkungen und Allergie-Kontraindikationen identifiziert – z. B. Warnung, dass ein Patient mit Asthma keine nicht-selektiven Betablocker erhalten sollte.
4	Erinnerungen für Vorsorge	Software, die einen Arzt an präventive Maßnahmen erinnert (z. B. Brustkrebsvorsorge, Impfungen) basierend auf Leitlinien und der Patientenakte.
5	Liste von Therapieoptionen	Software, die basierend auf Diagnose, Familienanamnese und BRCA1-Status empfiehlt, eine erhöhte Mammografie-Frequenz oder ergänzende Brustultraschall-Untersuchungen in Betracht zu ziehen.

Gemeinsames Merkmal

Alle diese Beispiele haben gemeinsam, dass sie dem Arzt Informationen und Optionen liefern, die dieser eigenständig prüfen und bewerten kann, bevor eine klinische Entscheidung getroffen wird. Die Software trifft keine autonome Diagnose oder Therapieentscheidung.

Decision Support Systeme, die ein Medizinprodukt sind

Kategorie A: Bildanalyse für Behandlungsplanung

Beispiel	Nicht erfüllte Kriterien
Software erstellt aus CT/MR-Bildern individuelle Bestrahlungspläne	1, 2, 3
Software erstellt aus Röntgen-/CT-Daten 3D-Modelle für orthopädische/dentale OP-Planung	1, 2, 3
Software rekonstruiert CT-Daten in 3D zur Katheterplatzierung im Bronchialbaum	1, 2, 3

Kategorie B: Bildanalyse für Diagnose

Beispiel	Nicht erfüllte Kriterien
Software analysiert Nahinfrarot-Bilder zur Diagnose eines Hirnhämatoms	1, 2
Software berechnet Fraktaldimension einer Hautläsion zur Malignitätsbestimmung	1, 2, 3
Software berechnet aus CT-Bildern die fraktionelle Flussreserve (FFR) zur Ischämie-Beurteilung	1, 2, 3
Software differenziert in Bildern zwischen ischämischem und hämorrhagischem Schlaganfall	1, 2, 3
Software erstellt priorisierte Diagnoseliste basierend auf Bildanalyse (Größe, Form, Erscheinung)	1, 2
CADe/CADx-Software erkennt Auffälligkeiten und bewertet Schweregrad in Bildern	1, 2, 3
Software analysiert digitale Pathologie-Slides für Zellzählung und Morphologie	1, 2, 3

Kategorie C: Signalanalyse für Diagnose

Beispiel	Nicht erfüllte Kriterien
Software analysiert Wearable-Signale (Schweiß, Herzfrequenz, Atmung) zur Erkennung von Herzinfarkt/Narkolepsie	1, 2, 3, 4
Software analysiert Liquor-Spektroskopie zur Diagnose von Meningitis bei Kindern	1, 2, 3
Software analysiert Hustengeräusche/Sprache zur Diagnose von Bronchitis/Sinusitis	1, 2, 3
Software analysiert Atemmuster zur Diagnose von Schlafapnoe	1, 2, 3

Kategorie D: Zeitkritische Alarme/Diagnosen

Beispiel	Nicht erfüllte Kriterien
Software analysiert fetale Signale zur Bestimmung des Kaiserschnitt-Zeitpunkts	1, 2, 3, 4
Software erkennt lebensbedrohliche Zustände (Schlaganfall, Sepsis) und generiert Alarm	3, 4

5 Illustrative Beispiele (Auswahl)

#	Anwendungsfall	Warum Medizinprodukt?
1	Bestrahlungsplanung: Software erstellt aus CT/MR-Bildern einen individuellen Therapieplan für Strahlentherapie	Analysiert Bilder (K1 ✗), gibt spezifische Therapieanweisung (K3 ✗)
2	Schlaganfall-Differenzierung: Software unterscheidet in Bildanalyse zwischen ischämischem und hämorrhagischem Schlaganfall	Analysiert Bilder (K1 ✗), liefert spezifische Diagnose (K3 ✗)
3	Hautkrebs-Erkennung: Software berechnet Fraktaldimension einer Läsion und klassifiziert sie als maligne oder benigne	Analysiert Bilder (K1 ✗), liefert spezifische Diagnose (K3 ✗)
4	Sepsis-/Schlaganfall-Alarm: Software analysiert Patientendaten, erkennt lebensbedrohliche Zustände und löst Alarm aus	Spezifischer Diagnose-Output (K3 ✗), zeitkritisch (K4 ✗)
5	Kaiserschnitt-Timing: Software analysiert fetale Herzfrequenz und Uteruskontraktionen zur Bestimmung des OP-Zeitpunkts	Analysiert Signale (K1 ✗), zeitkritische Therapieanweisung (K3 ✗, K4 ✗)

f) Fazit

Kernunterschied zu Non-Device CDS

Non-Device CDS	Device CDS
Zeigt Optionen und Informationen	Liefert spezifische Diagnose oder Therapieanweisung
Arzt kann unabhängig prüfen	Arzt kann nicht unabhängig prüfen (oder keine Zeit dafür)
Analysiert keine Bilder/Signale	Analysiert Bilder, Signale oder Muster
Beispiel: Liste möglicher Medikamente	Beispiel: „Diese Läsion ist maligne“

Der amerikanische Gesetzgeber definiert so unverständlich, wann eine Software ein Medizinprodukt ist, dass sich die FDA gezwungen sieht, dies in einem eigenen Guidance-Dokument zu klären.

Viele Hersteller mögen es als Vereinfachung empfinden, wenn sie DSS ohne vorherige Clearance durch die FDA in den Verkehr bringen können. Das setzt aber u. a. voraus, dass die Algorithmen in der wissenschaftlichen Fachliteratur veröffentlicht und als valide bewiesen wurden.

Der Nachweis der klinischen Validität ist aber nicht ausreichend, um die Sicherheit der Patienten zu beweisen. Daher ist es verwunderlich, dass der amerikanische Gesetzgeber (nicht primär die FDA) an manchen Stellen großzügiger als die europäische Rechtsprechung ist.

3. Regulatorische Anforderungen in Europa

a) Grundlegende Anforderungen (MDD, MDR)

Einige Interpretationshilfen geben Hilfestellungen, wann eine Software als Medizinprodukt zu klassifizieren ist. Aber weder die Medizinprodukterichtlinie MDD noch die Medizinprodukteverordnung MDR stellen konkrete Anforderungen an Decision Support Systeme. Dies ist verständlich, weil Gesetzestexte nicht für jede Produktklasse spezifische Anforderungen formulieren können. Dass die MDR dies für mobile Plattformen doch getan hat, zählt zum Reigen der Inkonsistenzen und Verirrungen dieser EU-Verordnung.

b) Klassifizierung gemäß MDD

Klinische Decision Support Systems zählen zu den aktiven Produkten. Dienen sie der Diagnoseunterstützung, greift Regel 10 dann, wenn sie beispielsweise eine direkte Diagnose oder Kontrolle von vitalen Körperfunktionen ermöglichen. Dann fallen diese Produkte in die Klasse IIa, sonst greift Regel 12: „Alle anderen aktiven Produkte werden der Klasse I zugeordnet.“

Was eine „direkte Diagnose ist“, verrät die MDD nicht, dafür die MDR:

Klinische DSS können aber auch der Therapie dienen. Dann hängt die Klassifizierung davon ab, ob und welche therapeutischen Produkte direkt oder indirekt beeinflusst werden.

c) Klassifizierung gemäß MDR

Die Decision Support Systems dienen, wie der Name sagt, der Entscheidungsunterstützung. Sie liefern also Informationen, die die Entscheidungen über Diagnosen, Therapien, Überwachung oder Vorbeugung von Krankheiten und Verletzungen betreffen.

Damit fallen diese Produkte gemäß Regel 11 der MDR mindestens in die Klasse IIa.

4. Weitere regulatorische Anforderungen

Medizinische bzw. klinische Entscheidungsunterstützungssysteme benötigen medizinische Daten, darunter auch Daten, die Patienten direkt zugeordnet werden können. Entsprechend sind diese Daten besonders schutzwürdig. Hersteller müssen die Anforderungen an den Datenschutz berücksichtigen.

5. Decision Support Systems: Herausforderungen

Hersteller von klinischen DSS stehen vor Herausforderungen, denn nicht alles, was technisch machbar erscheint, ist technisch, regulatorisch und ethisch möglich.

Herausforderung 1: Zweckbestimmung

Die Hersteller müssen klar den Zweck und die versprochene Leistungsfähigkeit (die „Claims“) benennen. Das betrifft beispielsweise die Sensitivität und Spezifität bei Diagnosen. Das betrifft die Abhängigkeit dieser Claims von Randbedingungen wie Patientenkollektiv (Alter, Geschlecht, Co-Morbiditäten usw.).

Genau diese Klarheit können oder wollen viele Hersteller nicht schaffen.

Herausforderung 2: Leistungsnachweise, Verifizierung

Tests können nie die Korrektheit einer Implementierung bzw. eines Produkts nachweisen. Aber bei klassischen Algorithmen wie Entscheidungsbäumen lassen sich die erwarteten Ergebnisse spezifizieren.

Bei vielen Verfahren der künstlichen Intelligenz, insbesondere bei neuronalen Netzwerken, sind diese Ergebnisse nicht mehr deterministisch. Dies gilt auch, wenn die Datenbasis, auf der die Algorithmen operieren, nicht konstant ist oder die Software diese sogar selbstständig erweitert. Die Vorhersagbarkeit und Wiederholbarkeit von Testergebnissen sind zumindest erschwert.

In diesen Fällen gelingt es Herstellern häufig nicht, Pass-fail-Kriterien zu definieren und zu begründen.

Herausforderung 3: Risikomanagement

Falls die Ergebnisse von Decision Support Systems nicht deterministisch sind, wenn insbesondere nicht ausgeschlossen werden kann, dass diese sogar völlig falsche Empfehlungen geben, sind auch die Risiken kaum vorherzusagen.

Die Argumentation vieler Hersteller, dass ja noch ein Arzt die Ergebnisse prüfen würde, greift zu kurz. Die Ärzte werden hoffentlich die Wahrscheinlichkeit verringern, dass eine falsche Empfehlung zu einem Schaden führt. Aber das Risiko besteht dennoch, und der Nachweis, dass Ärzte die Wahrscheinlichkeit tatsächlich verringern, ist zu führen.

Auch die Nutzenargumentation mancher Hersteller ist angreifbar. Dies gilt besonders dann, wenn mit ökonomischen Einsparungen argumentiert wird. Hilfreicher ist eine Nutzenberechnung, die auf der Reduktion menschlicher Fehlhandlungen beruht. Aber auch diese gilt es zu beweisen, z. B. mithilfe der klinischen Fachliteratur.

Herausforderung 4: Validierung, klinische Bewertung

Die klinische Bewertung muss den Nachweis erbringen, dass der versprochene Nutzen erreicht wird und keine Risiken vorliegen, die nicht bereits bekannt und als akzeptabel bewertet wurden. Dieser Nutzennachweis setzt ein Nutzenversprechen voraus, das oft nicht ausreichend konkret ist (siehe Herausforderung 1).

Der Nutzen misst sich als Verbesserung gegenüber dem Stand der Technik. Doch was ist dieser Goldstandard? Viele Hersteller vergleichen die Ergebnisse des DSS mit den Empfehlungen, die Ärztinnen und Ärzte geben würden. Doch ist das wirklich der Goldstandard? Dies gilt es zu begründen.

6. Fazit

Die klinischen Entscheidungsunterstützungssysteme haben seit den Siebzigerjahren viele „Hypes“ mit überzogenen Erwartungen erlebt, die immer einer Ernüchterung gewichen sind. Doch mit jeder technischen Innovation wie aktuell dem „Machine Learning“ kommt man dem Ziel näher, menschliche Intelligenz durch Computersysteme zu unterstützen, manchmal sogar zu ersetzen.

Werbung wie die von IBM für Watson weckt Erwartungen, die bei betroffenen Patienten zu tiefer Enttäuschung führen können. Wie verantwortlich so ein Handeln ist, mag jeder für sich beantworten. Denn weder die technologischen noch die regulatorischen noch die medizinischen Hürden sind so gemeistert, dass diese Systeme in die breite Regelversorgung Einzug halten können.

---

Versionshistorie:

• 2026-03-18: Abschnitt 2.c) eingefügt, folgende Teilnummerierungen entsprechend angepasst.
• 2026-01-09: Abschnitt 2 komplett überarbeitet wegen aktuellen FDA Guidance
• 2022-09-30: Finalen Entwurf des FDA-Guidance-Dokuments Clinical Decision Support Software ergänzt