Clinical decision support

Clinicians decide under time pressure, with growing guidelines, drug data and patient records. Clinical decision support (CDS) brings patient-specific knowledge into the workflow: classic rule engines flag interactions and dosing errors, risk models score patients, and since 2023 LLM-based assistants answer clinical questions with cited evidence. In the EU, CDS that drives diagnosis or therapy is usually a medical device and, with the AI Act, a high-risk AI system.

Problem & value

• Today: physicians look up guidelines and drug references manually (UpToDate, AMBOSS, Pschyrembel, national guidelines such as AWMF), while hospital information systems fire rule-based alerts that are often overridden. Alert fatigue is a well-documented problem, and knowledge changes faster than anyone can read.
• AI value: faster, cited answers at the point of care; context-aware instead of generic alerts; fewer prescribing errors and missed guideline-recommended actions; support for junior staff and for rural or understaffed settings.
• Evidence is mixed: classic CDS (computerised provider order entry with interaction checks) has decades of evidence for reducing medication errors, while evidence that LLM assistants improve patient outcomes is still thin; most published results are benchmark or vignette studies [1][2].

Variants

• Medication safety CDS: interaction, dose, renal adjustment, allergy and duplicate checks; the most mature form.
• Knowledge/guideline assistant: question answering over guidelines and literature (see KNOW-010).
• Diagnostic support: differential diagnosis from history, labs and imaging findings.
• Risk prediction embedded in the EHR: deterioration and sepsis scores (HLTH-012).
• Order-set and pathway support: suggested orders, oncology tumour-board preparation.
• Patient-facing symptom checkers: consumer variant (Ada Health, Germany; Infermedica, Poland), regulated as medical devices.
• Public health / primary care: triage and referral support for general practitioners.

How it works

1. EHR / FHIR data + clinical question
2. context assembly (patient summary, medication list, labs, allergies)
3. knowledge retrieval (guidelines, drug DB, literature; hybrid search + reranker)
4. reasoning (rules, risk model and/or LLM with grounded citations)
5. guardrails (scope limits, contraindication hard-checks, uncertainty flag)
6. recommendation shown in EHR with sources
7. clinician accepts / modifies / dismisses (logged)
8. outcome and override feedback
9. monitoring and re-validation

• Deterministic core: drug interactions, dosing and contraindications should come from curated, versioned knowledge bases, not from free LLM generation.
• LLM layer: retrieval-augmented generation over licensed content; every statement links to a source passage; the model abstains when evidence is missing.
• Integration: HL7 FHIR and CDS Hooks let a CDS service be called from the EHR at defined moments (order entry, chart open) and return "cards" [3].
• Human-in-the-loop: the clinician always decides; the system only advises and the decision and rationale remain documented by the clinician.

Data preparation

Clinical decision support draws on structured patient data (diagnoses, lab values, medication, vital signs) from the KIS/EHR, free-text notes and letters, and an authoritative knowledge base of guidelines and drug information. In an SMB-sized practice or hospital these sit in the KIS, the lab system, the DMS and PDF letters. Typical gaps: free text instead of coded data, inconsistent coding (ICD-10, LOINC), missing medication lists, scanned external letters, duplicate patient records, outdated local SOPs, and strict role-based access rights.

Preparation steps: (1) inventory data sources and check coding quality for the targeted indication; (2) digitise and OCR external letters (PREP-006); (3) extract data through standard interfaces such as HL7 FHIR instead of ad-hoc exports (PREP-005); (4) curate the guideline and SOP base with owners and review dates (PREP-013, PREP-017); (5) define the rules for which data may reach the AI (PREP-024) and pseudonymise where research or tuning is involved (PREP-022); (6) build a test set of real cases with clinicians (PREP-018); (7) capture clinician overrides as feedback (PREP-021).

Effort: medium. Data access and knowledge curation matter most; a certified product brings its own knowledge base and reduces curation effort. See GUIDE-003 and DOC-018.

Implementation paths

Which path for whom

• Enterprise (hospital, practice network): Path A, because CE-marked CDS modules integrated into the KIS/EHR carry the medical-device responsibility and guideline maintenance.
• Developer: Path B, because building CDS prototypes on cloud LLMs with guideline retrieval is fast, while productive use then needs medical-device conformity.
• Public (university or municipal hospital): Path A with certified products, because procurement rules and liability favour auditable, certified suppliers.

Path A — Buy (recommended for hospitals and practices)

• Evidence and knowledge platforms: UpToDate Expert AI (Wolters Kluwer), ClinicalKey AI (Elsevier), OpenEvidence, AMBOSS (Germany, EU) with its AI assistant, DynaMed/Dyna AI (EBSCO).
• Medication safety: Medi-Span and Lexicomp (Wolters Kluwer), Medscape-type databases; in Germany ABDA-Datenbank and Rote Liste information services; AiDKlinik (EU, Germany) for interaction checks.
• EHR-embedded: Epic, Oracle Health, Dedalus (EU, Italy/Germany), CGM (EU, Germany) and Meierhofer (EU, Germany) increasingly include CDS and assistant features.
• Choose A when: you need a CE-marked, supported product with a vendor carrying regulatory responsibility. Check: MDR class and intended purpose, EU hosting, content licensing, local-guideline coverage, German-language quality.

Path B — Build on cloud APIs

• RAG on licensed or open guidelines using frontier LLMs through EU regions (Azure OpenAI, Google Vertex AI with EU data residency, AWS Bedrock Frankfurt), or EU providers such as Mistral.
• Use FHIR servers (HAPI FHIR, Azure Health Data Services, Google Cloud Healthcare API) for context and CDS Hooks for EHR triggers.
• Embeddings and reranker for hybrid retrieval; structured outputs for citation objects.
• Caution: a self-built tool with a diagnostic or therapeutic intended purpose makes the hospital the manufacturer; in-house exemption under MDR Art. 5(5) has strict conditions [4].

Path C — Self-host (open source)

• Models: open-weight LLMs such as Llama, Qwen, Mistral and Gemma families, plus medically tuned variants (e.g. Google MedGemma), served with vLLM; embeddings such as BGE-M3, multilingual-e5.
• Stack: HAPI FHIR, OpenSearch or Qdrant/pgvector, an open CDS-Hooks server, OpenEHR where used.
• Hardware: HW3 (one 48-96 GB GPU) for 30-70B models; HW2 for small models with strict retrieval.
• Fits university hospitals that cannot send patient data outside the hospital network.

Path D — Custom training

Worth it for institution-specific risk models (tabular-ml on EHR data) or fine-tuning for local language and guideline sets. Needs thousands of labelled, outcome-linked records, ethics approval and a temporal/external validation plan. Federated learning across hospitals (e.g. via the European Health Data Space) is a research direction.

State of the art (2026)

• Frontier reasoning models score at or above passing level on medical licensing-style exams and on benchmarks such as MedQA and HealthBench (OpenAI, 2025) [5]; this does not translate directly into safe clinical use.
• Grounded answers: best practice is RAG with licensed sources and visible citations; vendors market such assistants as evidence retrieval rather than diagnosis to stay outside device scope.
• Studies show that LLM access alone does not reliably improve physician diagnostic reasoning, and automation bias is a real risk [2].
• Limits and failure modes: hallucinated references or doses, outdated guidance, sycophancy to leading questions, poor handling of rare conditions, bias across populations, and silent performance drift after EHR or case-mix changes. Alert fatigue persists when too many low-value alerts are shown.

Shared resources & combinations

• Same stack (llm + RAG + FHIR): KNOW-010 guideline assistant, HLTH-018 chart summarisation, HLTH-030 patient message drafting, HLTH-011 discharge letters.
• Upstream data: DOC-007 record extraction and HLTH-028 terminology mapping (SNOMED CT, LOINC) feed structured inputs.
• Risk models: HLTH-012 sepsis early warning is a specialised CDS with the same governance needs.
• Capture: HLTH-003 ambient scribe provides the clinical narrative that CDS can read.
• One GPU server (HW3) and one FHIR/vector layer can serve several of these.

Effort, cost & KPIs

• Path A: weeks to months for procurement, security review, integration; per-user or site licence.
• Path B: 6-12 months incl. clinical validation, MDR assessment and integration.
• Path C/D: 12+ months, specialised team (clinical informatics, ML, regulatory); cost drivers are validation, content licensing, integration and post-market monitoring rather than compute.
• KPIs: alert acceptance/override rate, prescribing errors and adverse drug events, guideline adherence, time to answer, clinician-rated answer correctness and citation accuracy, subgroup performance, drift indicators, incidents reported.

People & change

Management and the medical director decide and appoint a clinical owner, since the case touches treatment decisions and liability. Involve the department leads and the physicians and nurses who will see the alerts from the start, together with IT and IT security for KIS integration, and legal/compliance for medical-device and liability questions. The DPO covers legal basis, AVV and a likely DPIA for health data (GUIDE-005). Data owners of the guideline and drug databases must commit to maintenance.

Works council: depends. Where one exists, it must be informed early (§90(1) no. 3 BetrVG). Co-determination under §87(1) no. 6 BetrVG is likely if the system logs which clinician followed or dismissed recommendations, since objective suitability for monitoring is enough; engaging an expert can be necessary under §80(3). Public hospitals involve the Personalrat (GUIDE-004).

AI literacy: support clinicians with training on the system's scope, evidence behind recommendations, hallucination risk and automation bias (GUIDE-006). Run a pilot on one ward or indication with a small group of volunteer clinicians and silent-mode evaluation before alerts go live (GUIDE-009). Typical concerns are alert fatigue, liability and loss of clinical autonomy: tune alert thresholds with the users, show the source of every recommendation, keep the clinician as final decision-maker, and do not use override rates to rate individuals (GUIDE-008, GUIDE-011).

Risks, regulation & compliance

• MDR: software that provides information used for diagnostic or therapeutic decisions is qualified as a medical device under Rule 11 (generally class IIa or higher); MDCG 2019-11 explains qualification and classification. Pure reference lookup without patient-specific processing may fall outside [4][6].
• EU AI Act: a CDS that is a medical device requiring third-party conformity assessment is high-risk via Art. 6(1)/Annex I, with obligations (risk management, data governance, logging, human oversight, accuracy) applying on the schedule set by the AI Act and later adjustments; confirm current dates. Art. 4 AI literacy applies to all users [7]. Not prohibited under Art. 5.
• GDPR: health data is special-category data (Art. 9); DPIA required (Art. 35); legal basis for care (Art. 9(2)(h)) and national hospital laws; processor agreements and EU hosting; Art. 22 is relevant if decisions become automated, so keep the clinician as decision-maker.
• European Health Data Space (Regulation (EU) 2025/327) adds interoperability and secondary-use rules.
• Liability: clinician remains responsible; product liability directive (EU) 2024/2853 now covers software.
• Mitigations: local validation before go-live, shadow mode, override and outcome monitoring, versioned knowledge, clear scope statement in the UI, incident process.

Getting started

1. Define the clinical question and intended purpose, then decide whether it is a medical device.
2. Start with a low-risk, high-value slice such as medication-safety alerts or guideline lookup with citations.
3. Run a Path A vendor pilot or a shadow-mode prototype on historical, de-identified cases with clinician rating.
4. Complete DPIA, security review and AI Act/MDR assessment before any patient-facing use.
5. Roll out on one ward, log accept/override reasons, review monthly with a clinical governance board.

Sources

1. Sutton RT et al. — An overview of clinical decision support systems — npj Digital Medicine 2020 — https://www.nature.com/articles/s41746-020-0221-y
2. Goh E et al. — Large language model influence on diagnostic reasoning, JAMA Network Open 2024 — https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2825395
3. HL7 CDS Hooks specification — https://cds-hooks.hl7.org/
4. Regulation (EU) 2017/745 (MDR) — https://eur-lex.europa.eu/eli/reg/2017/745/oj
5. OpenAI — HealthBench — https://openai.com/index/healthbench/
6. 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
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Regulation (EU) 2025/327 (European Health Data Space) — https://eur-lex.europa.eu/eli/reg/2025/327/oj