In un sistema di Retrieval-Augmented Generation (RAG) clinico destinato alla produzione, il vincolo che decide l’architettura è la verificabilità della singola risposta — quale fonte la sostiene, quale versione del modello l’ha generata, dove finisce nel log — insieme al perimetro del dato, che non deve uscire dall’infrastruttura. Presi sul serio, questi due requisiti fissano l’architettura prima ancora che si scelga il modello.

Problema

Un large language model (LLM) generico risponde a una domanda clinica pescando dal proprio prior parametrico. Tre conseguenze lo rendono inservibile in reparto: la risposta non è ancorata a una fonte identificabile, il modello può generare affermazioni plausibili e false (allucinazioni), e l’inferenza su un servizio cloud sposta i dati clinici fuori dal perimetro del titolare. La prima è una questione di tracciabilità, la seconda di sicurezza clinica, la terza di base giuridica sotto il GDPR (i dati sanitari rientrano nella categoria particolare dell’art. 9).

Il paradigma RAG, formalizzato da Lewis et al. nel 2020, tiene separata la conoscenza dal ragionamento: si indicizza una base documentale esterna, un retriever recupera i passaggi pertinenti a una query e l’LLM genera la risposta condizionata sui documenti recuperati anziché sul solo prior. Nel dominio clinico questo sposta il problema dalla memoria parametrica del modello alla qualità e alla tracciabilità della base documentale — cioè proprio dove serve avere il controllo.

Architettura

La pila on-premise si articola in cinque strati con responsabilità distinte.

Ingest da dati strutturati. Lo strato di interoperabilità poggia su FHIR (Fast Healthcare Interoperability Resources). Nelle implementazioni reali la versione in produzione è R4 (v4.0.1): l’API REST, i formati JSON e XML e i datatype di base sono normativi, quindi stabili e retrocompatibili. Qui si modellano le risorse che alimentano il contesto — Patient, Observation, DocumentReference, DiagnosticReport, Condition, MedicationRequest. L’imaging entra via DICOM (Digital Imaging and Communications in Medicine, standard PS3.1–PS3.20 curato da NEMA/MITA): i metadati delle serie e i referti strutturati si indicizzano come testo, mentre i pixel restano sul PACS e si richiamano per riferimento, senza duplicarli nell’indice.

Indicizzazione ed embedding locali. I documenti — linee guida, letteratura, note cliniche estratte via FHIR, referti — si segmentano e si trasformano in vettori con un modello di embedding eseguito in locale, poi si archiviano in un vector database interno. In questa fase nessun testo clinico esce dall’infrastruttura.

Retrieval. A ogni query si confronta per similarità l’embedding della domanda con l’indice; i passaggi più pertinenti si recuperano insieme ai loro identificatori di provenienza (documento, sezione, risorsa FHIR di origine). La provenienza fa parte del payload, non è un metadato accessorio: è ciò che rende la risposta citabile.

Generazione con LLM biomedicale locale. Il modello gira on-premise. L’ecosistema open offre modelli di base documentati per il dominio: Meditron-70B (EPFL e Yale), derivato da Llama-2 con pretraining continuato su PubMed Central, abstract di PubMed e un corpus di linee guida cliniche internazionali; BioMistral, costruito su Mistral con pretraining su PubMed Central e rilasciato con un benchmark multilingue. La scelta del modello incide sulla qualità marginale della risposta, mentre la verificabilità la garantisce lo strato di retrieval.

Risposta con citazioni verificabili. L’output lega ogni affermazione ai passaggi recuperati che la sostengono. Insieme alla risposta il sistema registra input, contesto recuperato, citazioni e versione del modello che ha prodotto l’inferenza. Senza questo record, un audit a posteriori diventa impossibile.

Punto critico

Il grounding riduce le allucinazioni ma non le azzera: l’LLM può ignorare il contesto recuperato o spingersi oltre ciò che le fonti dicono. Da qui due meccanismi non negoziabili. Il primo è la citazione obbligatoria: un’affermazione priva di un passaggio di supporto recuperato va segnalata, non servita come risposta. Il secondo è un audit trail completo — input, contesto, output, citazioni, versione del modello — perché una raccomandazione clinica si deve poter ricostruire e contestare anche mesi dopo.

La valutazione clinica è il secondo nodo. Un sistema RAG clinico non si misura solo con l’accuratezza sulle domande, ma con il tasso di allucinazione e la correttezza delle citazioni (la risposta cita davvero ciò che la sostiene?). Sono metriche diverse da quelle dei benchmark di question answering generici e vanno validate sul dominio d’uso.

Il terzo nodo è il confine del Software-as-a-Medical-Device (SaMD). Un sistema che fornisce informazioni usate per decisioni diagnostiche o terapeutiche ricade sotto la Regola 11 dell’Allegato VIII del MDR (Regolamento UE 2017/745) e parte come Classe IIa, per salire a IIb o III a seconda della gravità del danno potenziale. Un assistente che riassume la storia clinica per il curante e un assistente che suggerisce una condotta terapeutica stanno ai due lati di questa linea. Dove cade la destinazione d’uso determina l’intero percorso di certificazione.

Implicazioni

I vincoli normativi si traducono in scelte di architettura, non in uno strato di compliance attaccato a valle.

Il perimetro del dato (GDPR art. 9) è soddisfatto eseguendo on-premise embedding, indice e inferenza: nessun dato clinico transita su servizi esterni. Per un deployment su larga scala serve comunque una valutazione d’impatto.

La verificabilità (citazioni, versione del modello, audit trail) è proprio ciò che, sotto l’EU AI Act (Regolamento UE 2024/1689), un sistema ad alto rischio deve garantire come trasparenza, sorveglianza umana e tracciabilità. Un sistema AI che sia un dispositivo medico, o un componente di sicurezza di un dispositivo soggetto alla valutazione di un Organismo Notificato sotto MDR/IVDR, ricade nell’alto rischio per l’art. 6(1). Le regole dell’AI Act per i dispositivi medici basati su AI si applicheranno dal 2 agosto 2027.

Le risorse FHIR a monte non sono un dettaglio di integrazione: senza dato strutturato di partenza, una risposta non si riconduce alla storia del paziente e l’audit trail perde l’aggancio al record clinico.

Limiti

I modelli open biomedicali documentati sono validati su benchmark di question answering, non sul ragionamento clinico multi-step con i vincoli reali del singolo paziente; il loro punto forte è il richiamo di informazione, mentre il ragionamento vincolato resta un’area di sviluppo. La qualità del RAG dipende per intero dalla cura della base documentale: un indice curato male produce retrieval irrilevanti che il grounding non corregge. La pipeline DICOM testuale descritta qui indicizza metadati e referti, non i pixel: l’analisi diretta dell’immagine richiede un modello visuale separato, con un proprio percorso di validazione. E il record di audit, da solo, non è governance: chi accede, quali risorse FHIR entrano nel contesto, quali campi si oscurano prima del retrieval sono policy esplicite, non proprietà emergenti dell’architettura.

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/insights/rag-clinico-llm-open-source/

Immagine di copertina: Schermata del visualizzatore DICOM open-source Weasis con una radiografia del torace e gli strumenti della workstation radiologica — schermata di Borbély Márton, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:Weasis_4.4.0_english_CXR.png