Behandelnde entscheiden unter Zeitdruck, bei wachsenden Leitlinien, Arzneimitteldaten und Patientenakten. Klinische Entscheidungsunterstützung (Clinical Decision Support, CDS) bringt patientenspezifisches Wissen in den Arbeitsablauf: Klassische Regel- Systeme markieren Wechselwirkungen und Dosierungsfehler, Risikomodelle bewerten Patientinnen und Patienten, und seit 2023 beantworten LLM-basierte Assistenten klinische Fragen mit belegter Evidenz. In der EU ist CDS, die Diagnose oder Therapie steuert, meist ein Medizinprodukt und mit der KI-Verordnung ein Hochrisiko-KI-System.
Problem & Nutzen
- Heute: Ärztinnen und Ärzte schlagen Leitlinien und Arzneimittelreferenzen manuell nach (UpToDate, AMBOSS, Pschyrembel, nationale Leitlinien wie die der AWMF), während Krankenhausinformationssysteme regelbasierte Warnungen auslösen, die oft übergangen werden. Alarmmüdigkeit (Alert Fatigue) ist ein gut dokumentiertes Problem, und das Wissen ändert sich schneller, als es jemand lesen kann.
- KI-Nutzen: schnellere Antworten mit Quellenangaben am Behandlungsort; kontextbezogene statt allgemeiner Warnungen; weniger Verordnungsfehler und weniger übersehene leitlinienempfohlene Maßnahmen; Unterstützung für jüngeres Personal und für ländliche oder personell unterbesetzte Einrichtungen.
- Die Evidenz ist gemischt: Klassische CDS (computergestützte Verordnungseingabe mit Wechselwirkungsprüfung) hat jahrzehntelange Evidenz für die Senkung von Medikationsfehlern, während die Evidenz dafür, dass LLM-Assistenten die Behandlungs- ergebnisse verbessern, noch dünn ist; die meisten veröffentlichten Ergebnisse stammen aus Benchmark- oder Fallvignetten-Studien [1][2].
Varianten
- CDS zur Medikationssicherheit: Prüfungen auf Wechselwirkungen, Dosis, Nierenanpassung, Allergien und Doppelverordnungen; die ausgereifteste Form.
- Wissens-/Leitlinien-Assistent: Fragebeantwortung über Leitlinien und Fachliteratur (siehe KNOW-010).
- Diagnostische Unterstützung: Differenzialdiagnose aus Anamnese, Laborwerten und Bildbefunden.
- Im KIS eingebettete Risikovorhersage: Scores zu klinischer Verschlechterung und Sepsis (HLTH-012).
- Unterstützung bei Anordnungssets und Behandlungspfaden: vorgeschlagene Anordnungen, Vorbereitung von Tumorboards in der Onkologie.
- Symptom-Checker für Patientinnen und Patienten: Verbraucher-Variante (Ada Health, Deutschland; Infermedica, Polen), als Medizinprodukte reguliert.
- Öffentliche Gesundheit / Primärversorgung: Unterstützung bei Triage und Überweisung für Hausärztinnen und Hausärzte.
So funktioniert es
- KIS-/FHIR-Daten + klinische Fragestellung
- Kontextaufbau (Patientenzusammenfassung, Medikationsliste, Laborwerte, Allergien)
- Wissensabruf (Leitlinien, Arzneimitteldatenbank, Literatur; hybride Suche + Reranker)
- Schlussfolgerung (Regeln, Risikomodell und/oder LLM mit belegten Quellenangaben)
- Leitplanken (Geltungsbereich, harte Kontraindikationsprüfungen, Unsicherheitskennzeichen)
- Empfehlung im KIS mit Quellen angezeigt
- Behandelnde übernehmen / ändern / verwerfen (protokolliert)
- Ergebnis- und Override-Feedback
- Monitoring und Revalidierung
- Deterministischer Kern: Arzneimittelwechselwirkungen, Dosierung und Kontraindikationen sollten aus kuratierten, versionierten Wissensbasen stammen, nicht aus freier LLM-Generierung.
- LLM-Schicht: Retrieval-Augmented Generation (RAG) über lizenzierte Inhalte; jede Aussage verweist auf eine Quellenpassage; das Modell enthält sich, wenn Evidenz fehlt.
- Integration: HL7 FHIR und CDS Hooks erlauben es, einen CDS-Dienst aus dem KIS zu definierten Zeitpunkten aufzurufen (Anordnungseingabe, Öffnen der Akte) und „Karten“ zurückzugeben [3].
- Mensch-in-der-Schleife (Human-in-the-Loop): Die Behandelnden entscheiden immer; das System berät nur, und Entscheidung und Begründung werden von den Behandelnden dokumentiert.
Datenaufbereitung
Klinische Entscheidungsunterstützung stützt sich auf strukturierte Patientendaten (Diagnosen, Laborwerte, Medikation, Vitalwerte) aus dem KIS, auf Freitext-Notizen und Briefe sowie auf eine verlässliche Wissensbasis aus Leitlinien und Arzneimittelinformationen. In einer Praxis oder Klinik mittlerer Größe (KMU) liegen diese im KIS, im Laborsystem, im DMS und in PDF-Briefen. Typische Lücken: Freitext statt kodierter Daten, uneinheitliche Kodierung (ICD-10, LOINC), fehlende Medikationslisten, gescannte externe Briefe, doppelte Patientenakten, veraltete lokale Standardarbeitsanweisungen (SOPs) und strikte rollenbasierte Zugriffsrechte.
Schritte der Aufbereitung: (1) Datenquellen erfassen und die Kodierqualität für die anvisierte Indikation prüfen; (2) externe Briefe digitalisieren und per OCR erfassen (PREP-006); (3) Daten über Standardschnittstellen wie HL7 FHIR statt über Ad-hoc-Exporte extrahieren (PREP-005); (4) die Basis aus Leitlinien und SOPs mit Verantwortlichen und Prüfterminen kuratieren (PREP-013, PREP-017); (5) die Regeln festlegen, welche Daten die KI erreichen dürfen (PREP-024), und pseudonymisieren, wo Forschung oder Feintuning beteiligt ist (PREP-022); (6) mit den Behandelnden einen Testdatensatz aus realen Fällen aufbauen (PREP-018); (7) Übersteuerungen durch die Behandelnden als Feedback erfassen (PREP-021).
Aufwand: mittel. Datenzugang und Wissenskuratierung sind am wichtigsten; ein zertifiziertes Produkt bringt seine eigene Wissensbasis mit und verringert den Kuratierungsaufwand. Siehe GUIDE-003 und DOC-018.
Umsetzungswege
Welcher Weg für wen
- Unternehmen (Klinik, Praxisnetz): Weg A, weil CE-gekennzeichnete CDS-Module, die in das KIS integriert sind, die Verantwortung für das Medizinprodukt und die Pflege der Leitlinien tragen.
- Entwickler: Weg B, weil sich CDS-Prototypen auf Cloud-LLMs mit Leitlinien-Retrieval schnell bauen lassen, der produktive Einsatz dann aber Medizinprodukte-Konformität braucht.
- Öffentlicher Sektor (Universitätsklinikum oder kommunale Klinik): Weg A mit zertifizierten Produkten, weil Vergaberecht und Haftung nachvollziehbare, zertifizierte Anbieter begünstigen.
Weg A — Kaufen (Standardsoftware)
- Evidenz- und Wissensplattformen: UpToDate Expert AI (Wolters Kluwer), ClinicalKey AI (Elsevier), OpenEvidence, AMBOSS (Deutschland, EU) mit seinem KI-Assistenten, DynaMed/Dyna AI (EBSCO).
- Medikationssicherheit: Medi-Span und Lexicomp (Wolters Kluwer), Datenbanken im Stil von Medscape; in Deutschland die ABDA-Datenbank und die Informationsdienste der Roten Liste; AiDKlinik (EU, Deutschland) für Wechselwirkungsprüfungen.
- Im KIS eingebettet: Epic, Oracle Health, Dedalus (EU, Italien/Deutschland), CGM (EU, Deutschland) und Meierhofer (EU, Deutschland) bieten zunehmend CDS- und Assistenzfunktionen.
- Weg A wählen, wenn: Sie ein CE-gekennzeichnetes, betreutes Produkt brauchen, bei dem der Hersteller die regulatorische Verantwortung trägt. Prüfen Sie: MDR-Klasse und Zweckbestimmung, EU-Hosting, Lizenzierung der Inhalte, Abdeckung lokaler Leitlinien, Qualität der deutschen Sprache.
Weg B — Auf Cloud-KI-Diensten aufbauen
- RAG auf lizenzierten oder offenen Leitlinien mit Spitzen-LLMs über EU-Regionen (Azure OpenAI, Google Vertex AI mit Datenstandort EU, AWS Bedrock Frankfurt) oder mit EU-Anbietern wie Mistral.
- FHIR-Server (HAPI FHIR, Azure Health Data Services, Google Cloud Healthcare API) für den Kontext und CDS Hooks für KIS-Auslöser nutzen.
- Embeddings und Reranker für hybrides Retrieval; strukturierte Ausgaben für Zitatobjekte.
- Vorsicht: Ein selbst gebautes Werkzeug mit diagnostischer oder therapeutischer Zweckbestimmung macht die Klinik zum Hersteller; die Ausnahme für Eigenherstellung nach MDR Art. 5 Abs. 5 hat strenge Bedingungen [4].
Weg C — Selbst betreiben (Open Source)
- Modelle: LLMs mit offenen Gewichten wie die Familien Llama, Qwen, Mistral und Gemma sowie medizinisch abgestimmte Varianten (z. B. Google MedGemma), betrieben mit vLLM; Embeddings wie BGE-M3, multilingual-e5.
- Stack: HAPI FHIR, OpenSearch oder Qdrant/pgvector, ein offener CDS-Hooks-Server, OpenEHR, wo im Einsatz.
- Hardware: HW3 (eine GPU mit 48-96 GB) für Modelle mit 30-70 Mrd. Parametern; HW2 für kleine Modelle mit striktem Retrieval.
- Passt zu Universitätskliniken, die Patientendaten nicht außerhalb des Klinik-Netzwerks versenden dürfen.
Weg D — Eigenes Training
Lohnt sich für einrichtungsspezifische Risikomodelle (tabellarisches ML auf KIS-Daten) oder für das Feintuning auf lokale Sprache und Leitliniensätze. Erfordert Tausende gelabelte, mit Ergebnissen verknüpfte Datensätze, ein Ethikvotum und einen zeitlichen/externen Validierungsplan. Föderiertes Lernen über Kliniken hinweg (z. B. über den Europäischen Gesundheitsdatenraum) ist eine Forschungsrichtung.
Stand der Technik (2026)
- Spitzen-Reasoning-Modelle erreichen bei Prüfungen im Stil medizinischer Zulassungsexamen und bei Benchmarks wie MedQA und HealthBench (OpenAI, 2025) [5] das Bestehensniveau oder mehr; das lässt sich nicht direkt in sicheren klinischen Einsatz übersetzen.
- Belegte Antworten: Bewährt ist RAG mit lizenzierten Quellen und sichtbaren Quellenangaben; Anbieter vermarkten solche Assistenten als Evidenzrecherche statt als Diagnose, um außerhalb des Medizinprodukte-Anwendungsbereichs zu bleiben.
- Studien zeigen, dass allein der Zugang zu LLMs das diagnostische Denken von Ärztinnen und Ärzten nicht zuverlässig verbessert, und Automationsbias ist ein reales Risiko [2].
- Grenzen und Fehlerbilder: halluzinierte Quellen oder Dosen, veraltete Leitlinien, Gefälligkeitsverhalten (Sycophancy) bei Suggestivfragen, schlechter Umgang mit seltenen Erkrankungen, Verzerrungen über Populationen hinweg und unbemerkte Leistungs- drift nach Änderungen im KIS oder im Fallmix. Alarmmüdigkeit bleibt bestehen, wenn zu viele wenig wertvolle Warnungen angezeigt werden.
Gemeinsame Bausteine & Kombinationen
- Gleicher Stack (LLM + RAG + FHIR): KNOW-010 Leitlinien-Assistent, HLTH-018 Zusammenfassung von Patientenakten, HLTH-030 Entwurf von Patientennachrichten, HLTH-011 Entlassbriefe.
- Vorgelagerte Daten: DOC-007 Extraktion aus Akten und HLTH-028 Terminologie-Mapping (SNOMED CT, LOINC) liefern strukturierte Eingaben.
- Risikomodelle: HLTH-012 Sepsis-Frühwarnung ist eine spezialisierte CDS mit denselben Governance-Anforderungen.
- Erfassung: HLTH-003 ambienter Scribe liefert die klinische Erzählung, die CDS lesen kann.
- Ein GPU-Server (HW3) und eine FHIR-/Vektorschicht können mehrere davon bedienen.
Aufwand, Kosten & Kennzahlen
- Weg A: Wochen bis Monate für Beschaffung, Sicherheitsprüfung, Integration; Lizenz pro Nutzer oder pro Standort.
- Weg B: 6-12 Monate einschließlich klinischer Validierung, MDR-Bewertung und Integration.
- Weg C/D: 12+ Monate, spezialisiertes Team (klinische Informatik, ML, Regulierung); Kostentreiber sind Validierung, Inhaltslizenzen, Integration und Überwachung nach dem Inverkehrbringen statt Rechenleistung.
- Kennzahlen: Akzeptanz-/Übersteuerungsrate der Warnungen, Verordnungsfehler und unerwünschte Arzneimittelereignisse, Leitlinien- treue, Zeit bis zur Antwort, von Behandelnden bewertete Korrektheit der Antworten und Genauigkeit der Quellenangaben, Leistung in Untergruppen, Drift-Indikatoren, gemeldete Vorfälle.
Menschen & Veränderung
Geschäftsleitung und ärztliche Leitung entscheiden und benennen eine klinische Verantwortliche bzw. einen klinischen Verantwortlichen, da der Anwendungsfall Behandlungsentscheidungen und Haftung berührt. Beziehen Sie von Anfang an die Abteilungsleitungen sowie die Ärztinnen, Ärzte und Pflegekräfte ein, die die Warnungen sehen werden, zusammen mit IT und IT-Sicherheit für die KIS-Integration und Recht/Compliance für Fragen zu Medizinprodukten und Haftung. Die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte klärt Rechtsgrundlage, AVV und eine wahrscheinliche DSFA für Gesundheitsdaten (GUIDE-005). Die Dateneigentümer der Leitlinien- und Arzneimitteldatenbanken müssen die Pflege zusagen.
Betriebsrat: abhängig vom Einzelfall. Wo einer besteht, muss er frühzeitig informiert werden (§ 90 Abs. 1 Nr. 3 BetrVG). Die Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG ist wahrscheinlich, wenn das System protokolliert, welche Behandelnden Empfehlungen befolgt oder verworfen haben, da die objektive Eignung zur Überwachung genügt; die Hinzuziehung eines Sachverständigen kann nach § 80 Abs. 3 nötig sein. Öffentliche Kliniken beziehen den Personalrat ein (GUIDE-004).
KI-Kompetenz: Unterstützen Sie die Behandelnden mit Schulungen zum Einsatzbereich des Systems, zur Evidenz hinter den Empfehlungen, zum Halluzinationsrisiko und zum Automationsbias (GUIDE-006). Führen Sie einen Pilotbetrieb auf einer Station oder für eine Indikation mit einer kleinen Gruppe freiwilliger Behandelnder durch und werten Sie im stillen Modus aus, bevor Warnungen live gehen (GUIDE-009). Typische Bedenken sind Alarmmüdigkeit, Haftung und der Verlust klinischer Autonomie: Stimmen Sie die Schwellenwerte der Warnungen mit den Nutzenden ab, zeigen Sie die Quelle jeder Empfehlung, lassen Sie die Behandelnden die endgültige Entscheidung treffen und verwenden Sie Übersteuerungsraten nicht zur Beurteilung Einzelner (GUIDE-008, GUIDE-011).
Risiken, Regulierung & Compliance
- MDR: Software, die Informationen für diagnostische oder therapeutische Entscheidungen liefert, wird nach Regel 11 als Medizinprodukt eingestuft (in der Regel Klasse IIa oder höher); MDCG 2019-11 erläutert Qualifizierung und Klassifizierung. Reine Nachschlagewerke ohne patientenspezifische Verarbeitung können außerhalb liegen [4][6].
- KI-Verordnung (AI Act): Eine CDS, die ein Medizinprodukt mit Konformitätsbewertung durch Dritte ist, gilt als Hochrisiko nach Art. 6 Abs. 1/Anhang I, mit Pflichten (Risikomanagement, Daten-Governance, Protokollierung, menschliche Aufsicht, Genauigkeit), die nach dem in der KI-Verordnung festgelegten Zeitplan und späteren Anpassungen gelten; aktuelle Termine prüfen. Die KI-Kompetenz nach Art. 4 gilt für alle Nutzenden [7]. Nicht nach Art. 5 verboten.
- DSGVO: Gesundheitsdaten sind Daten besonderer Kategorien (Art. 9); eine DSFA ist erforderlich (Art. 35); Rechtsgrundlage für die Versorgung (Art. 9 Abs. 2 Buchst. h) und nationale Krankenhausgesetze; Auftragsverarbeitungsverträge und Hosting in der EU; Art. 22 ist relevant, wenn Entscheidungen automatisiert werden, daher die Behandelnden als Entscheidende belassen.
- Europäischer Gesundheitsdatenraum (Verordnung (EU) 2025/327) ergänzt Regeln zu Interoperabilität und Zweitnutzung.
- Haftung: Die Behandelnden bleiben verantwortlich; die Produkthaftungsrichtlinie (EU) 2024/2853 erfasst nun auch Software.
- Gegenmaßnahmen: lokale Validierung vor dem Produktivstart, Schattenmodus, Überwachung von Übersteuerungen und Ergebnissen, versioniertes Wissen, klare Angabe des Einsatzbereichs in der Oberfläche, Vorfallprozess.
Erste Schritte
- Definieren Sie die klinische Fragestellung und die Zweckbestimmung und entscheiden Sie dann, ob es sich um ein Medizinprodukt handelt.
- Beginnen Sie mit einem risikoarmen, wertvollen Ausschnitt wie Warnungen zur Medikationssicherheit oder Leitlinien-Recherche mit Quellenangaben.
- Führen Sie einen Pilotbetrieb mit einem Anbieter von Weg A oder einen Prototyp im Schattenmodus an historischen, de-identifizierten Fällen mit Bewertung durch die Behandelnden durch.
- Schließen Sie DSFA, Sicherheitsprüfung und Bewertung nach KI-Verordnung/MDR ab, bevor es einen Einsatz mit Patientenbezug gibt.
- Führen Sie das System auf einer Station ein, protokollieren Sie die Gründe für Akzeptanz und Übersteuerung und prüfen Sie monatlich mit einem Gremium für klinische Governance.
Quellen
- Sutton RT et al. — An overview of clinical decision support systems — npj Digital Medicine 2020 — https://www.nature.com/articles/s41746-020-0221-y
- Goh E et al. — Large language model influence on diagnostic reasoning, JAMA Network Open 2024 — https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2825395
- HL7 CDS Hooks specification — https://cds-hooks.hl7.org/
- Regulation (EU) 2017/745 (MDR) — https://eur-lex.europa.eu/eli/reg/2017/745/oj
- OpenAI — HealthBench — https://openai.com/index/healthbench/
- MDCG 2019-11 Guidance on qualification and classification of software — https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en
- Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Regulation (EU) 2025/327 (European Health Data Space) — https://eur-lex.europa.eu/eli/reg/2025/327/oj