FHIR e LLM Open Source on-premise: RAG clinico e governance dei dati sanitari

RAG clinico on-premise con FHIR come strato di interoperabilità, LLM Open Source biomedicali e governance dei dati. Quadro normativo EHDS verso il 2027 e AI Act per i dispositivi medici, con aggancio ad AIHealth.

Digital HealthAIOpen SourceComplianceGovernance FHIRLLMRAGOpen SourceBioMistralMeditronMedGemmaDICOMEHDSEU AI ActMDRDigitalHealth

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 Source; per il confronto fra standard, a openEHR, FHIR e CDA.

Gli LLM Open Source biomedicali

Sul lato modello, l’ecosistema Open Source 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: MedGemma di Google è un’opzione interessante, ma non è Open Source in senso pieno. È un modello open-weights distribuito sotto licenza HAI-DEF (Health AI Developer Foundations): i pesi sono accessibili, ma i termini di licenza non coincidono con una licenza Open Source approvata. La distinzione conta 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.

È l’impostazione di AIHealth, la piattaforma clinica on-premise di noze: LLM locali, RAG su FHIR e DICOM, governance dei dati e percorso MDR trattati come parti dello stesso impianto. 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

Vuoi supporto? Sei sotto attacco? Stato dei servizi
Vuoi supporto? Sei sotto attacco? Stato dei servizi