In a production clinical Retrieval-Augmented Generation (RAG) system the constraint that decides the architecture is the verifiability of each individual answer — which source backs it, which model version produced it, where it lands in the log — together with the data perimeter, which the clinical data must not leave. Taken seriously, these two requirements settle the architecture before the model is even chosen.

Problem

A general large language model (LLM) answers a clinical question by drawing on its parametric prior. Three consequences make it unusable on the ward: the answer is not anchored to an identifiable source, the model can generate plausible and false statements (hallucinations), and inference on a cloud service moves clinical data outside the controller’s perimeter. The first is a matter of traceability, the second of patient safety, the third of legal basis under the GDPR (health data falls within the special category of Art. 9).

The RAG paradigm, formalised by Lewis et al. in 2020, keeps knowledge separate from reasoning: an external document store is indexed, a retriever pulls the passages relevant to a query, and the LLM generates an answer conditioned on the retrieved documents rather than on the prior alone. In the clinical domain this shifts the problem from the model’s parametric memory to the quality and traceability of the document base — exactly where control is needed.

Architecture

The on-premise stack is organised into five layers with distinct responsibilities.

Ingest from structured data. The interoperability layer rests on FHIR (Fast Healthcare Interoperability Resources). In real deployments the version in production is R4 (v4.0.1): the REST API, the JSON and XML formats and the base datatypes are normative, hence stable and backward-compatible. The resources that feed the context are modelled here — Patient, Observation, DocumentReference, DiagnosticReport, Condition, MedicationRequest. Imaging enters via DICOM (Digital Imaging and Communications in Medicine, standard parts PS3.1–PS3.20, maintained by NEMA/MITA): series metadata and structured reports are indexed as text, while the pixels stay on the PACS and are pulled in by reference, without duplicating them in the index.

Local indexing and embedding. Documents — guidelines, literature, clinical notes extracted via FHIR, reports — are chunked and turned into vectors by an embedding model running locally, then stored in an internal vector database. At this stage no clinical text leaves the infrastructure.

Retrieval. At query time the question’s embedding is matched by similarity against the index; the most relevant passages are retrieved together with their provenance identifiers (document, section, originating FHIR resource). Provenance is part of the payload, not an incidental metadata field: it is what makes the answer citable.

Generation with a local biomedical LLM. The model runs on-premise. The open ecosystem offers documented base models for the domain: Meditron-70B (EPFL and Yale), derived from Llama-2 with continued pretraining on PubMed Central, PubMed abstracts and a corpus of international clinical guidelines; BioMistral, built on Mistral with pretraining on PubMed Central and released with a multilingual benchmark. Model choice affects the marginal quality of the answer, while verifiability is guaranteed by the retrieval layer.

Answer with verifiable citations. The output ties each statement to the retrieved passages that support it. Alongside the answer the system records input, retrieved context, citations and the model version that produced the inference. Without that record, an after-the-fact audit becomes impossible.

Critical point

Grounding reduces hallucinations but does not zero them out: the LLM can ignore the retrieved context or reach beyond what the sources say. Hence two non-negotiable mechanisms. The first is mandatory citation: a statement with no supporting retrieved passage is flagged, not served as an answer. The second is a complete audit trail — input, context, output, citations, model version — because a clinical recommendation must be reconstructable and contestable even months later.

Clinical evaluation is the second knot. A clinical RAG system is not measured by answer accuracy alone, but by hallucination rate and citation correctness (does the answer actually cite what supports it?). These are different from generic question-answering benchmarks and must be validated on the intended use.

The third knot is the Software-as-a-Medical-Device (SaMD) boundary. A system that provides information used for diagnostic or therapeutic decisions falls under Rule 11 of Annex VIII of the MDR (Regulation EU 2017/745) and starts as Class IIa, rising to IIb or III with the severity of the potential harm. An assistant that summarises a patient’s history for the treating clinician and an assistant that suggests a therapeutic course sit on the two sides of that line. Where the intended purpose lands determines the entire certification path.

Implications

The regulatory constraints translate into architectural choices, not into a compliance layer bolted on downstream.

The data perimeter (GDPR Art. 9) is met by running embedding, index and inference on-premise: no clinical data transits external services. A large-scale deployment still needs an impact assessment.

Verifiability (citations, model version, audit trail) is exactly what, under the EU AI Act (Regulation EU 2024/1689), a high-risk system must provide as transparency, human oversight and traceability. An AI system that is a medical device, or a safety component of a device subject to Notified Body assessment under MDR/IVDR, falls into high-risk under Art. 6(1). The AI Act rules for AI-based medical devices will apply from 2 August 2027.

The FHIR resources upstream are not an integration detail: without structured input, an answer cannot be traced back to the patient’s history, and the audit trail loses its anchor to the clinical record.

Limits

The documented open biomedical models are validated on question-answering benchmarks, not on multi-step clinical reasoning under a single patient’s real constraints; their strength is information recall, while constrained reasoning remains an area of development. RAG quality depends entirely on the care put into the document base: a poorly curated index produces irrelevant retrievals that grounding does not fix. The text-based DICOM pipeline described here indexes metadata and reports, not pixels: direct image analysis needs a separate vision model, with its own validation path. And the audit record, on its own, is not governance: who accesses the system, which FHIR resources enter the context, which fields are redacted before retrieval are explicit policies, not emergent properties of the architecture.

https://arxiv.org/abs/2005.11401 https://hl7.org/fhir/R4/ https://www.dicomstandard.org/current https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng https://eur-lex.europa.eu/eli/reg/2017/745/oj/eng https://arxiv.org/abs/2311.16079 https://arxiv.org/abs/2402.10373 https://www.noze.it/en/insights/clinical-rag-open-source-llm/

Cover image: Screenshot of the open-source Weasis DICOM viewer showing a chest X-ray with radiology workstation tools — screenshot by Borbély Márton, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:Weasis_4.4.0_english_CXR.png