Articolo
Il pattern: RAG clinico on-premise
Le architetture che stanno emergendo nei reparti IT sanitari condividono una scelta di fondo: tenere i dati clinici dentro il perimetro. Il pattern ricorrente è un RAG clinico on-premise, dove tre strati restano distinti e governati separatamente — l’interoperabilità, il modello linguistico e la governance dei dati.
Lo strato di interoperabilità poggia su FHIR. A oggi, la versione in produzione nelle implementazioni reali è R4: è lo standard su cui si costruisce. La R6 è ancora in fase di ballot e non va trattata come disponibile per ambienti clinici. Su R4 si modellano le risorse (Patient, Observation, DocumentReference, DiagnosticReport) che alimentano il contesto recuperato dal sistema di retrieval. Per una panoramica del meccanismo rimandiamo all’articolo dedicato al RAG clinico con LLM open weight; per il confronto fra standard, a openEHR, FHIR e CDA.
Gli LLM open weight biomedicali
Sul lato modello, l’ecosistema dei modelli open weight offre oggi opzioni mature per il dominio biomedicale. BioMistral è costruito su base Mistral con pretraining su PubMed Central. Meditron-7B e Meditron-70B, sviluppati da EPFL e Yale, sono adattati da Llama-2. A questi si aggiungono numerose varianti Llama e Mistral fine-tuned su corpora clinici.
Un chiarimento necessario: open weight vuol dire che i pesi sono scaricabili, non che le licenze siano tutte uguali. Alcuni modelli sono rilasciati con licenze permissive come Apache 2.0, altri con licenze che pongono restrizioni d’uso, e le varianti fine-tuned ereditano i termini del modello base. MedGemma di Google è un’opzione interessante, ma i suoi pesi sono distribuiti sotto i termini HAI-DEF (Health AI Developer Foundations), che non coincidono con una licenza open source approvata. La licenza va quindi letta modello per modello quando si valutano ridistribuzione, modifica e uso in un dispositivo regolato.
La governance dei dati
Il terzo strato — quello che spesso viene rimandato — è la governance. In un contesto clinico significa controllo su quali dati entrano nel contesto del modello, redaction dei dati identificativi dove non necessari, tracciabilità delle interrogazioni e residenza dei dati. Mantenere il modello in locale risolve solo il problema del trasferimento: il resto — chi accede, cosa viene recuperato, come si dimostra a posteriori — richiede policy esplicite applicate in modo bidirezionale, su richiesta e su risposta.
Il quadro EHDS: preparazione verso il 2027
Sul piano normativo, il riferimento è lo European Health Data Space (Regolamento UE 2025/327), in vigore da inizio 2025. Le prime scadenze scattano due anni dopo, nel 2027: riguardano in larga parte il primary use, l’obbligo di adesione a MyHealth@EU e gli ambienti di elaborazione sicuri con i relativi data permit. È bene leggere il 2027 come fase di preparazione e prime scadenze, non come avvio operativo di tutto.
In particolare, il secondary use sui dati delle cartelle elettroniche non parte nel 2027: è atteso intorno al 2029, con categorie residue ancora successive. Chi pianifica oggi un’infrastruttura clinica lavora quindi su un orizzonte a fasi, non su un’unica data. Abbiamo trattato la dimensione del riuso secondario nell’articolo su EHDS e secondary use.
AI Act e dispositivi medici
C’è un secondo binario regolatorio. Un sistema AI che è un dispositivo medico, o un componente di sicurezza di un dispositivo regolato da MDR/IVDR con valutazione di un Notified Body, ricade nella categoria high-risk dell’EU AI Act. Le scadenze di conformità per questi sistemi sono in evoluzione: l’accordo provvisorio sul Digital Omnibus (raggiunto a inizio maggio, in attesa di adozione formale) sposta i sistemi high-risk embedded in prodotti regolati verso agosto 2028, e gli stand-alone verso dicembre 2027. L’orizzonte realistico è quindi 2027-2028, non una singola data secca da assumere oggi. Per il dettaglio del provvedimento rimandiamo all’analisi sul Digital Omnibus.
Cosa significa in pratica
Per un’organizzazione sanitaria, il messaggio operativo è che i tre strati vanno progettati insieme fin dall’inizio. Un LLM locale senza FHIR a monte produce risposte non riconducibili al dato strutturato; FHIR senza governance espone il dato a usi non tracciati; e nessuno dei due, da solo, copre il percorso MDR se il sistema diventa un dispositivo.
È la direzione di AgenticHealth, l’AI on-premise di noze per la ricerca clinica: oggi ricerca con le fonti su protocolli, letteratura e normativa, con LLM locali; i connettori FHIR in sola lettura, su dati pseudonimizzati di una coorte di ricerca, sono in roadmap. Non è un software medicale: non supporta diagnosi né decisioni sulla cura dei pazienti. Maggiori dettagli sul nostro lavoro nel verticale sanità nella sezione digital health.
Link: European Health Data Space (EHDS) — Commissione UE · FHIR v6.0.0-ballot