Clinical guideline & medical knowledge assistant

Clinical guidelines run to hundreds of pages, change regularly and are scattered across publishers, societies and hospital intranets. A retrieval-augmented assistant indexes them, retrieves the relevant recommendation and answers with a citation, so a physician can verify it in seconds. The decisive design question is regulatory: an assistant that retrieves and summarises knowledge for a professional is usually not a medical device; one that outputs patient-specific diagnoses or treatment proposals may be.

Problem & value

• Today: clinicians look up guidelines in AWMF/NICE/society PDFs, UpToDate-style subscription tools or colleagues' memory. Hospital SOPs and antibiotic guidelines live in separate intranets. Guidelines differ by country and are updated at different times, so outdated versions circulate.
• AI value: one natural-language entry point over guidelines, drug information and local SOPs, with citations and version dates; faster lookups; consistent use of local pathways; support for guideline authors and quality-management staff (find all passages affected by a change).
• Evidence base: retrieval clearly helps medical question answering. The MedRAG study (MIRAGE benchmark, 7,663 questions) reports accuracy gains of up to 18% over chain-of-thought prompting for six LLMs, and that retrieval lets smaller models approach GPT-4-level results [1]. Open-ended quality is harder to measure: OpenAI's HealthBench uses 5,000 multi-turn conversations graded with rubrics written by 262 physicians [2]. Benchmark scores are not evidence of patient benefit; prospective clinical studies remain rare.

Variants

• Guideline Q&A for hospitals: guidelines + local SOPs, antibiotic stewardship, pathways.
• Drug-information assistant: SmPC/Fachinformation, interactions, dosing in renal impairment (pharmacy).
• Primary-care / practice assistant: DEGAM and national disease-management guidelines for GPs.
• Guideline-development and quality support: compare recommendations across guidelines, find conflicts.
• Medical education: exam-style tutoring over textbooks and guidelines.
• Patient-facing information (private use): plain-language explanation of a diagnosis or patient guideline, strictly information, no personal diagnosis. Consumer symptom checkers are a separate, usually regulated category.
• Not covered here: ambient clinical documentation (see SPEECH-/DOC- families) and imaging AI.

How it works

1. guideline sources (AWMF, NICE, ESC, SmPC, local SOPs)
2. licence check + versioned ingestion (document parsing, section/recommendation-aware chunking)
3. metadata (guideline ID, version, date, grade of recommendation, population, specialty)
4. hybrid index (BM25 + embeddings)
5. reranker
6. question
7. query rewriting (abbreviations, ICD-10/ATC, German/English)
8. retrieval with metadata filters (valid version only)
9. LLM answer with mandatory citations
10. guardrails (scope check, no patient-specific orders, contradiction/outdated-source check)
11. clinician verifies in the source viewer
12. feedback + audit log

• Chunking matters: recommendations, evidence levels and tables must stay together with their grade (e.g. "starke Empfehlung", level of evidence). Plain page chunking loses them.
• Citation by construction: the answer is composed from retrieved passages; sentences without a supporting passage are removed or flagged. Refuse when evidence is missing or guidelines conflict.
• Human-in-the-loop: the clinician remains the decision maker and checks the cited source. Content owners (guideline officers) approve what enters the index and handle licence terms.

Data preparation

Needed sources are clinical guidelines (AWMF, specialist societies, international bodies), drug information, and internal SOPs and pathways. They live in guideline portals, hospital intranets, the DMS, file shares, PDF folders and, for older SOPs, on paper. Typical gaps: guidelines in many versions and validity states, scanned SOPs, tables and flow charts that parsers misread, conflicting local and national recommendations, and unclear ownership of who approves content. Patient data does not belong in the corpus.

Preparation steps: (1) define an authoritative source list with named content owners ([PREP-013], [PREP-004]); (2) check copyright and licence terms of each guideline; (3) OCR and parse with table and flow-chart handling ([PREP-006], [DOC-014], [DOC-018]); (4) tag guideline, version, specialty, validity and evidence level ([PREP-010]); (5) set up a review cycle so superseded guidelines are retired ([PREP-017]); (6) build an evaluation set of real clinical questions with physicians and pharmacists ([PREP-018]). Tools: Docling or Unstructured, Paperless-ngx. Preparation takes roughly 40 to 50 percent of the effort because correctness is critical. See [GUIDE-003].

Implementation paths

Which path for whom

• Enterprise (B): Hospitals and groups need integration with their own SOPs and clinical systems, so a cloud-API build with EU regions gives control at manageable cost.
• Developer (B): Cloud APIs with a curated guideline corpus and strong citation checks are the fastest route to a robust product.
• Public (C): Public hospitals and health authorities need sovereign hosting and open components; a larger GPU tier (HW3) is realistic for them.
• SMB (A): Practices and small pharmacies lack the capacity to run a clinical system, so a certified, EU-hosted product with maintained guideline content is the safer choice.

Path A — Buy (recommended for most organisations)

• Clinical knowledge products with AI: OpenEvidence (US; answers cited from journals, free for verified clinicians), UpToDate with Wolters Kluwer's generative AI features, Elsevier ClinicalKey AI, Doximity's assistant (US). In German-speaking markets, AMBOSS (Berlin, EU) and Thieme-based offerings are the natural fit for German content. Vendor features change quickly; verify availability and EU data handling per product before purchase (not re-verified for this entry).
• Enterprise RAG platforms (see KNOW-002) for hospital SOPs and intranet content, with EU hosting and access control; many hospital information system (KIS) vendors add assistants.
• Choose A when: public medical literature and a commercial content licence are enough, and the tool is used for information retrieval by clinicians, not wired into patient records.

Path B — Build on cloud APIs

• Models: a frontier LLM from an EU region of a major cloud (Azure OpenAI EU Data Zone, Google Vertex EU, AWS Bedrock Frankfurt) or an EU provider (Mistral AI). Use a reasoning model for conflicting evidence, a smaller model for query rewriting.
• Stack: embedding + reranker, a hybrid search engine (OpenSearch, Elasticsearch) or vector DB, an orchestration layer with citation enforcement; evaluation harness with physician-written test sets.
• Choose B when: you own the content (local SOPs, licensed guidelines) and need custom workflows, but can sign a DPA and avoid sending patient identifiers (de-identify before prompts).

Path C — Self-host (open source)

• Models: open-weight general models such as Mistral Small 3.2 (24B, Apache 2.0, about 55 GB GPU memory in bf16 [5]); medical-tuned options: Google MedGemma (4B and 27B, built on Gemma 3, under the Health AI Developer Foundations terms; the model card says outputs are preliminary and not meant to directly guide diagnosis or treatment [3][4]) and the research model MEDITRON-70B (Llama-2 based, 2023, now dated) [6]. Always evaluate against a general open model: medical tuning does not guarantee better grounded answers.
• Stack: Docling or similar parser, BGE-M3 or multilingual embeddings, a reranker, Qdrant/pgvector/OpenSearch, vLLM serving, the MedRAG toolkit as an evaluation starting point [1].
• Hardware: HW3 for 24–70B models with several concurrent users; HW2 is enough for a 4–8B pilot. Required when patient data or non-public SOPs must not leave the hospital network.

Path D — Custom training

Rarely the first step. Fine-tuning pays for specialised tasks (German clinical abbreviations, retrieval embeddings for a specialty, answer-style adaptation) and requires physician-labelled question/answer/evidence sets (hundreds to thousands). MedGemma reports that fine-tuning cut errors in EHR information retrieval by 50% in its evaluation [4]; this is a task-specific result, not a general guarantee. Fine-tuning for patient-specific recommendations pushes the product into medical-device territory.

State of the art (2026)

• Frontier and open models score very high on multiple-choice exams (MedGemma 27B text: 87.7 on MedQA zero-shot per its card [3]), but multiple-choice saturation says little about clinical usefulness. Rubric-based benchmarks such as HealthBench (including a harder subset where top scores were only about 32% at launch [2]) and physician-graded evaluations are now preferred.
• Retrieval beats memory: grounded answers with citations are the norm; hybrid search, reranking and recommendation-aware chunking give the largest gains. "Lost in the middle" effects are documented in medical RAG [1].
• Agentic search over PubMed, guideline registers and drug databases is replacing single-shot RAG (see KNOW-008, KNOW-015).
• Limits and failure modes: outdated or superseded guidelines; mixing countries' recommendations; wrong dose or unit; ignoring contraindications in the case context; over-confident synthesis of conflicting recommendations; prompt sensitivity (noted on the MedGemma card [3]); benchmark contamination; automation bias by busy clinicians. The WHO's guidance on large multimodal models in health stresses governance, transparency and human oversight [7].

Shared resources & combinations

• Same RAG stack as KNOW-002 (company documents), KNOW-004 (technical manuals) and KNOW-009 (standards Q&A): parser, embedding, reranker, vector/hybrid index and guardrails are shared; one HW3 server can host several of them.
• KNOW-008 (literature review) supplies the evidence beyond guidelines; KNOW-013 (GraphRAG) links diseases, drugs and recommendations; DOC-014 parses guideline PDFs and tables; DOC-018 anonymises any case text before it reaches an external API; LANG-009 handles German/English translation of sources.
• Natural extension: SOP and pathway Q&A in the hospital intranet (KNOW-003/KNOW-002 pattern).

Effort, cost & KPIs

• Path A: weeks (procurement, data-protection review, training); subscription per user.
• Path B: 3–6 months incl. content licensing, evaluation by clinicians and security review.
• Path C: 4–9 months; GPU server, MLOps and clinical content curation as a standing task.
• Cost drivers: content licences, clinical evaluation effort, regulatory work if medical-device status applies.
• KPIs: share of answers with correct, current citations (physician-rated sample), refusal rate when evidence is missing, lookup time, guideline-version freshness, user adherence to local pathways, incident reports. Do not claim patient outcomes without a study.

People & change

Start with management and the medical director, who own clinical responsibility, then the department leads and the pharmacy or quality team as content owners. Clinicians and pharmacists are the end users; include them in a pilot of 10 to 20 people ([GUIDE-009]). IT, IT security and the DPO join early for hosting, access rights and the AVV; legal or compliance clarifies whether the tool could qualify as a medical device and what liability applies.

Works council: depends. A pure document search without person-level logging may not trigger §87(1) no. 6 BetrVG, but usage logs per clinician are suited to monitor behaviour, so co-determination is likely in practice; inform the works council in any case under §90(1) no. 3 and consider an expert under §80(3) ([GUIDE-004]). Public hospitals involve the Personalrat. A DPIA is needed if queries can contain patient data or special categories ([GUIDE-005]); instruct staff not to enter identifiable patient data.

AI literacy: train staff to verify citations and recognise limits ([GUIDE-006]). Typical concern: liability and loss of clinical judgement. Address it by making the tool decision support only, requiring source display, and keeping the clinician responsible for every decision ([GUIDE-008]).

Risks, regulation & compliance

• EU AI Act: classification depends on purpose. A pure information-retrieval assistant for professionals is typically not high-risk and carries limited-risk transparency duties (Art. 50: users must know they talk to AI). If the software is a medical device (or safety component) that needs a notified body, it is high-risk via Art. 6(1) and Annex I; MDCG 2025-6 explains how MDR and AI Act requirements interplay [8]. Annex III point 5(d) lists emergency-healthcare patient triage systems as high-risk [9]. Per the consolidated text on artificialintelligenceact.eu, Annex III obligations are shown as applying from 2 December 2027 and Annex I obligations from 2 August 2028 (check the current legal status) [10].
• MDR: software intended to provide information used to take decisions for diagnosis or therapy can be a medical device (Rule 11 usually class IIa or higher). MDCG 2019-11 (rev. June 2025) is the qualification guide [8]. Keep the intended purpose narrow ("search and summarise published guidelines for professionals, no patient-specific recommendations") and document it; a new feature that ingests patient data can change it.
• GDPR: health data is special-category data (Art. 9); patient identifiers in prompts require a legal basis, a DPA and a DPIA; prefer de-identification and on-premises deployment. Hospital state laws (Landeskrankenhausgesetze) and professional secrecy (§ 203 StGB) apply to cloud use in Germany.
• Content licences: AWMF states that guidelines are legally non-binding and that responsibility lies with authors; the register page gives no reuse licence, so confirm indexing rights per guideline and publisher [11].
• Mitigations: show source and version beside every answer, expiry dates on indexed guidelines, evaluation sets per specialty, red-teaming for dosing, clear labelling, incident process, clinician sign-off.

Getting started

1. Define intended purpose in one sentence and decide whether the tool will touch patient data (if yes, involve regulatory affairs and the data-protection officer first).
2. Inventory content and licences: AWMF/DEGAM guidelines, SmPC, local SOPs; record version and owner of each.
3. Build or buy a pilot on 20–50 guidelines of one specialty; use recommendation-aware chunking and mandatory citations.
4. Have 2–3 physicians write 100–200 real questions with gold answers and sources; measure citation correctness, not only fluency, and include refusal cases.
5. Roll out to a small group, log usage and corrections, and set an owner for monthly guideline updates.

Sources

1. Xiong et al., Benchmarking Retrieval-Augmented Generation for Medicine (MedRAG / MIRAGE) — https://arxiv.org/abs/2402.13178
2. Arora et al., HealthBench: Evaluating Large Language Models Towards Improved Human Health — https://arxiv.org/abs/2505.08775
3. Google, MedGemma 27B model card (Hugging Face) — https://huggingface.co/google/medgemma-27b-it
4. MedGemma Technical Report — https://arxiv.org/abs/2507.05201
5. Mistral AI, Mistral-Small-3.2-24B-Instruct-2506 model card — https://huggingface.co/mistralai/Mistral-Small-3.2-24B-Instruct-2506
6. Chen et al., MEDITRON-70B: Scaling Medical Pretraining for Large Language Models — https://arxiv.org/abs/2311.16079
7. WHO, Ethics and governance of AI for health: Guidance on large multi-modal models (2025) — https://www.who.int/publications/i/item/9789240084759
8. European Commission, MDCG guidance list (MDCG 2019-11 rev.1 and MDCG 2025-6 on MDR/IVDR and AI Act) — https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en
9. AI Act, Annex III (point 5) — https://artificialintelligenceact.eu/annex/3/
10. AI Act, Article 6 (classification rules for high-risk systems) — https://artificialintelligenceact.eu/article/6/
11. AWMF Leitlinienregister — https://www.awmf.org/leitlinien
12. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj