Infrastrutture IT per la medicina di precisione: come gestire Petabyte di dati omici in ospedale?

Come CIO di un istituto di ricerca oncologica, conosci bene questa sensazione: i server sono pieni, i ricercatori lamentano la lentezza delle analisi e il budget per l’IT è sempre sotto pressione. L’esplosione dei dati omici, generati dal sequenziamento di nuova generazione (NGS), ha trasformato i data center ospedalieri in vere e proprie bombe a orologeria computazionali. Ogni singolo paziente oncologico può generare terabyte di dati, rendendo inadeguata qualsiasi infrastruttura pensata solo pochi anni fa. La risposta comune del mercato è proporre soluzioni apparentemente semplici: storage più veloce, più capiente o un generico “passaggio al cloud”.

Queste soluzioni, però, trattano solo il sintomo, non la causa. Il problema non è semplicemente lo spazio disco, ma l’intero ciclo di vita del dato. Continuare ad aggiungere capacità senza una strategia è come cercare di svuotare l’oceano con un secchio. La vera sfida è progettare un’infrastruttura che governi il flusso del dato genomico in ogni sua fase: dalla sua generazione in laboratorio alla sua analisi ad alte prestazioni, dalla sua condivisione in progetti multicentrici fino alla sua archiviazione a lungo termine a basso costo, il tutto nel più rigoroso rispetto delle normative. Questo articolo non vi venderà un nuovo server, ma vi fornirà una mappa strategica per costruire un’infrastruttura IT per la medicina di precisione che sia potente, efficiente e sostenibile nel tempo, pensata da chi, come voi, deve far quadrare i conti con le esigenze della ricerca.

In questo approfondimento, analizzeremo le componenti tecnologiche e strategiche fondamentali per governare la valanga dei dati omici. Esploreremo come trasformare le sfide normative e tecniche in vantaggi competitivi per la ricerca del vostro istituto.

Sequenziamento NGS: quale potenza di calcolo serve per processare un genoma umano in 24 ore?

Il punto di partenza della valanga di dati è il laboratorio. Un sequenziatore di nuova generazione (NGS) non produce un risultato pulito e ordinato, ma un torrente di dati grezzi. Stiamo parlando dei file BCL (Base Call) che devono essere convertiti, allineati a un genoma di riferimento e analizzati per l’identificazione delle varianti. Questo processo, noto come “secondary analysis”, è estremamente intensivo dal punto di vista computazionale e dello storage. I dati grezzi, i dati allineati (BAM) e i dati delle varianti (VCF) possono facilmente accumularsi. Infatti, l’intero workflow per un genoma umano può occupare fino a 5 terabyte di spazio di archiviazione.

Moltiplicatelo per decine o centinaia di pazienti all’anno e la vostra attuale SAN (Storage Area Network) arriverà rapidamente alla saturazione. Per processare un genoma umano in meno di 24 ore, non è sufficiente una CPU potente. È necessaria un’architettura bilanciata che includa: storage primario ad alte prestazioni (preferibilmente NVMe-oF, NVMe over Fabrics) per accelerare le fasi di I/O-bound, una rete a bassa latenza (almeno 25/100 GbE) per trasferire rapidamente i dati tra i nodi di calcolo e lo storage, e una potenza di calcolo parallela, spesso affidata a cluster HPC (High-Performance Computing) o a soluzioni con accelerazione GPU per specifici algoritmi di allineamento. Pensare di gestire questo carico di lavoro con server generici è il primo passo verso il fallimento del progetto.

L’obiettivo non è solo la velocità, ma la riproducibilità. Ogni analisi deve essere tracciata e documentata. Questo introduce la necessità di pipeline computazionali containerizzate (usando tecnologie come Docker o Singularity) e sistemi di workflow management (come Nextflow o Snakemake) che garantiscano che la stessa analisi, eseguita a distanza di mesi, produca esattamente lo stesso risultato. L’infrastruttura deve quindi supportare nativamente questi strumenti, andando oltre la semplice fornitura di “potenza bruta”.

L’infrastruttura federata su scala europea consentirebbe di superare l’enorme frammentazione del gran numero di progetti di Medicina di Precisione nazionali ed europei, garantendo la massima condivisione

– Graziano Pesole, Coordinatore nazionale del nodo italiano di ELIXIR – CNR

La potenza di calcolo è solo l’inizio del viaggio. Una volta generati, questi dati devono essere gestiti con estrema cura, partendo dal più grande ostacolo e al contempo abilitatore della ricerca: la privacy del paziente.

Pseudo-anonimizzazione: come rendere i dati genomici utilizzabili per la ricerca rispettando il GDPR

I dati genomici sono, per definizione, i dati personali più sensibili che esistano. Il GDPR impone vincoli stringenti al loro trattamento, ma non ne vieta l’uso per la ricerca, a patto che vengano adottate misure tecniche e organizzative adeguate. La chiave di volta è la pseudo-anonimizzazione. A differenza dell’anonimizzazione (spesso tecnicamente impossibile senza perdita di valore scientifico), la pseudo-anonimizzazione permette di separare i dati clinici e genomici dagli identificatori diretti del paziente (nome, codice fiscale). Ciò consente di utilizzare i dati per le analisi, mantenendo la possibilità di ri-identificare il paziente solo in casi specifici e autorizzati, ad esempio per comunicare un risultato clinicamente rilevante.

Dal punto di vista infrastrutturale, questo non è un semplice esercizio legale, ma richiede un’architettura precisa. La soluzione più robusta prevede la creazione di repository fisicamente o logicamente separati: uno per i dati identificativi (anagrafica), gestito con i massimi livelli di sicurezza e accessi ristrettissimi, e un altro per i dati clinico-genomici pseudonimizzati. La “chiave” che collega i due mondi deve essere essa stessa conservata in un terzo sistema, separato e cifrato. Questo approccio a tre livelli minimizza il rischio: un’eventuale violazione di un repository non compromette l’intero sistema. Il vostro data center, che vede ogni singolo ospedale produrre ormai petabyte di informazioni all’anno, deve essere progettato per imporre questa separazione a livello di rete e storage.

Implementare questo modello significa dotarsi di strumenti di Data Governance che automatizzino il processo di pseudonimizzazione al momento dell’ingestione dei dati e che applichino policy di accesso granulari (Role-Based Access Control). Il ricercatore vedrà solo i dati pseudonimi necessari per il suo studio, mentre il personale autorizzato potrà, tramite una procedura tracciata, risalire al paziente. Il Garante della Privacy italiano ha fornito linee guida precise che devono diventare il blueprint per la vostra architettura.

Una volta che i dati sono stati resi sicuri e utilizzabili, la sfida successiva è farli “parlare” tra loro e con i sistemi di altri istituti, superando le barriere dei formati proprietari.

Interoperabilità semantica: l’errore di usare formati proprietari che bloccano la ricerca multicentrica

Avete i dati, sono pseudonimizzati e pronti per l’analisi. Ma sono intrappolati. Intrappolati in formati proprietari dei macchinari di laboratorio, nei database specifici di un reparto o nei sistemi informativi regionali che non comunicano tra loro. Questo è il più grande freno alla medicina di precisione in Italia: la mancanza di interoperabilità semantica. Non basta scambiare file; i sistemi devono capire il significato dei dati che ricevono. Se il “gene BRCA1” è codificato in tre modi diversi in tre ospedali, ogni tentativo di ricerca multicentrica diventa un incubo di data cleaning manuale, costoso e prono a errori.

L’errore strategico che molti istituti compiono è continuare a investire in soluzioni verticali che creano silos di dati. La soluzione è adottare standard aperti e riconosciuti a livello internazionale. Per i dati clinici, lo standard de facto sta diventando HL7 FHIR (Fast Healthcare Interoperability Resources), che definisce “risorse” standard per concetti come Paziente, Osservazione, Terapia. Per i dati omici, si stanno consolidando formati come il VCF per le varianti e standard promossi da consorzi come la GA4GH (Global Alliance for Genomics and Health). L’infrastruttura IT deve essere progettata per “parlare” nativamente questi linguaggi, o quantomeno per integrare motori di trasformazione (ETL – Extract, Transform, Load) che convertano i dati in formati standard al momento dell’ingestione.

Questa standardizzazione è l’unica via per abilitare progetti di ricerca su larga scala, come dimostrano iniziative europee. Ad esempio, il progetto Genome of Europe, che vede coinvolti 27 Paesi UE nel tentativo di standardizzare 100.000 genomi, sarebbe impensabile senza un framework comune. In Italia, il progetto Health Big Data, che mira a creare una rete tra 51 IRCCS, si basa proprio su questo principio: creare una piattaforma federata dove i dati rimangono localmente ma possono essere interrogati in modo standardizzato.

L’immagine sopra rappresenta visivamente l’obiettivo: una rete interconnessa, non una collezione di isole isolate. Per un CIO, investire in sistemi che supportano FHIR e altri standard aperti non è un costo, ma un investimento strategico che aumenta il valore dei dati dell’istituto, rendendoli compatibili per future collaborazioni nazionali e internazionali.

Il seguente quadro sinottico riassume il passaggio da un modello frammentato a uno integrato, un obiettivo cruciale per il sistema sanitario italiano.

Con dati sicuri e interoperabili, si può finalmente raggiungere lo scopo ultimo: fornire ai medici strumenti potenti per migliorare le decisioni terapeutiche.

Algoritmi predittivi: come supportare il medico nella scelta della terapia senza sostituirlo

Il fine ultimo della raccolta massiva di dati omici è trasformarli in conoscenza azionabile al letto del paziente. Questo avviene tramite algoritmi predittivi e sistemi di supporto decisionale (DSS – Decision Support System). Questi strumenti software analizzano il profilo genomico del tumore di un paziente, lo confrontano con migliaia di altri casi presenti nel database e suggeriscono le terapie più efficaci o i trial clinici più adatti. È fondamentale chiarire un punto: l’obiettivo non è sostituire il medico, ma potenziarlo. L’algoritmo fornisce probabilità e opzioni basate sull’evidenza, ma la decisione finale, che tiene conto del contesto clinico completo e dell’esperienza, rimane saldamente nelle mani dell’oncologo e del team multidisciplinare.

Dal punto di vista dell’infrastruttura, supportare questi algoritmi richiede più che semplice capacità di storage. Richiede piattaforme di Machine Learning Operations (MLOps). Queste piattaforme gestiscono l’intero ciclo di vita del modello di IA: dal training su set di dati certificati, alla validazione, al deployment in un ambiente controllato e, soprattutto, al monitoraggio continuo delle sue performance. Un modello predittivo non è statico; deve essere costantemente ri-allenato con nuovi dati per mantenere e migliorare la sua accuratezza. L’infrastruttura deve quindi allocare risorse di calcolo (spesso GPU) non solo per la ricerca, ma anche per il training e l’inferenza di questi modelli in un ambiente quasi-produzione.

In Italia, iniziative come il progetto Health Big Data (HBD) stanno ponendo le basi per questo futuro. Il progetto, coordinato dal Ministero della Salute, sta creando una piattaforma federata per l’integrazione di dati omici, clinici e di imaging provenienti da decine di IRCCS. Uno degli obiettivi espliciti è proprio lo sviluppo di sistemi di supporto decisionale basati su AI per i Molecular Tumor Boards, i gruppi multidisciplinari che già oggi in molti centri oncologici discutono i casi complessi. La vostra infrastruttura deve essere pronta a integrarsi con queste piattaforme nazionali, esponendo i dati in modo standardizzato per alimentare gli algoritmi e, viceversa, ricevendo i risultati delle analisi per integrarli nella cartella clinica elettronica.

Ma i dati omici sono solo una parte del quadro. Un ospedale moderno genera enormi volumi di dati anche da altre fonti, come l’imaging diagnostico, che presentano sfide infrastrutturali altrettanto complesse.

PACS in Cloud: come gestire la latenza quando il radiologo deve vedere una risonanza 3D

Oltre ai dati genomici, l’altro grande produttore di “Big Data” in un ospedale è il reparto di radiologia. I sistemi RIS/PACS (Radiology Information System / Picture Archiving and Communication System) gestiscono l’archiviazione e la visualizzazione di immagini diagnostiche come TAC, PET e risonanze magnetiche. Secondo l’analisi di Pure Storage per il mercato healthcare italiano, questi sistemi possono arrivare a gestire centinaia di terabyte, se non petabyte di dati critici. La tendenza è quella di spostare questi archivi verso il cloud o architetture ibride per migliorare l’accessibilità e ridurre i costi di gestione on-premise.

Tuttavia, il cloud introduce una sfida critica per la radiologia: la latenza. Un oncologo che analizza una scansione PET o un radiologo che manipola una ricostruzione 3D di una risonanza magnetica non può aspettare minuti per il caricamento di un’immagine. Ogni secondo di ritardo interrompe il flusso di lavoro e può avere un impatto sulla diagnosi. Gestire un PACS in cloud non significa semplicemente “caricare” i file DICOM su un server remoto. Richiede un’architettura intelligente che combini i vantaggi del cloud (scalabilità, archiviazione a lungo termine) con le prestazioni di una soluzione locale.

La soluzione è un’architettura ibrida o “edge-to-cloud”. Questa prevede un Vendor Neutral Archive (VNA) on-premise, basato su storage flash ad alte prestazioni, che funge da cache per le immagini più recenti e di uso frequente (i cosiddetti “priors”). Le immagini più vecchie o meno consultate vengono migrate automaticamente su uno storage a oggetti in cloud, più economico. Quando un medico richiede un esame, il sistema controlla prima la cache locale: se l’immagine è presente, viene servita istantaneamente. Se è in cloud, viene pre-caricata in background. Questo approccio, noto come “intelligent tiering”, bilancia perfettamente performance e costi. L’esperienza del servizio sanitario nazionale britannico (NHS), che durante la pandemia ha sfruttato il cloud per monitorare risorse in tempo reale, ha dimostrato come un’architettura cloud ben progettata, anche se in un contesto diverso, possa fornire un modello di resilienza e accessibilità replicabile anche per la gestione dei PACS negli ospedali italiani.

Questa logica di differenziare i dati in base alla loro frequenza di accesso è il principio cardine per rendere sostenibile, anche economicamente, l’intera infrastruttura.

Hot vs Cold Data: come spostare i dati grezzi su nastro per risparmiare 100.000€ l’anno

L’infrastruttura IT di un istituto di ricerca non può basarsi unicamente su storage flash ultra-veloce. Sarebbe economicamente insostenibile. Il segreto per gestire petabyte di dati risiede nel concetto di Information Lifecycle Management (ILM), ovvero la classificazione dei dati in “hot”, “warm” e “cold” in base alla loro frequenza di accesso. I dati “hot” sono quelli in uso attivo: il genoma del paziente appena sequenziato, l’analisi in corso. Questi richiedono le massime prestazioni e risiedono su storage NVMe. I dati “warm” sono quelli a cui si accede occasionalmente, come i risultati di ricerche recenti. Possono stare su storage flash meno performante o dischi SAS. Infine, i dati “cold” sono la stragrande maggioranza: dati grezzi dei sequenziatori, risultati di studi conclusi anni fa, dati conservati per obblighi di legge. Questi dati devono essere mantenuti, ma è improbabile che vengano acceduti. È qui che entra in gioco l’archiviazione a freddo.

Spostare i dati “cold” da costosi dischi attivi a soluzioni di storage a basso costo può generare risparmi enormi, sia in termini di hardware che di consumo energetico. Le due tecnologie principali per l’archiviazione a freddo sono lo storage a oggetti (on-premise o in cloud, come Amazon S3 Glacier) e le librerie a nastro magnetico (LTO). Contrariamente a quanto si pensi, il nastro è tutt’altro che obsoleto. Le moderne cartucce LTO-9 possono contenere fino a 45 TB di dati compressi e hanno un costo per gigabyte e un consumo energetico ordini di grandezza inferiori rispetto ai dischi. Un’analisi di Healthtech360 ha evidenziato che solo il 3% dei circa 50 petabyte di dati mediamente generati dagli ospedali viene utilizzato. Questo significa che il 97% è potenzialmente “cold” e potrebbe essere archiviato a un costo molto più basso.

Implementare una strategia di tiering automatico, dove il sistema sposta autonomamente i dati tra i vari livelli di storage in base a policy predefinite (es. “sposta su nastro tutti i file BAM più vecchi di 180 giorni”), può portare a risparmi diretti di decine, se non centinaia di migliaia di euro all’anno su consumi e manutenzione. La chiave è dotarsi di un software di gestione dati (spesso parte delle soluzioni di Scale-Out NAS o di data fabric) che renda questo tiering trasparente all’utente. Il ricercatore vedrà sempre il suo file, senza sapere se il sistema lo sta recuperando da un disco flash o da un nastro. Una strategia di archiviazione a freddo ben pianificata include:

• Identificazione dei dati genomici grezzi con accesso sporadico (es. non acceduti da oltre 6 mesi).
• Definizione dei periodi di conservazione obbligatoria secondo la normativa italiana (es. per la ricerca).
• Implementazione di policy automatiche di migrazione su storage a nastro LTO o object storage a basso costo.
• Calcolo del TCO (Total Cost of Ownership) che includa i costi energetici specifici italiani e il personale.
• Mantenimento di un catalogo indicizzato per permettere il recupero rapido dei dati quando necessario.

L’efficienza economica è strettamente legata a quella energetica, un’altra voce di costo che un CIO non può ignorare.

Power Usage Effectiveness: come abbassare il tuo indice sotto 1.2 grazie al liquido

Un data center che elabora petabyte di dati genomici è un sistema estremamente energivoro. La potenza di calcolo e lo storage generano un’enorme quantità di calore, che deve essere smaltito da costosi sistemi di condizionamento. Per un CIO, il costo dell’energia elettrica è una delle principali voci di spesa operativa (OPEX) del data center. La metrica standard per misurare l’efficienza energetica di un data center è il PUE (Power Usage Effectiveness). Questo indice è il rapporto tra l’energia totale consumata dal data center e l’energia utilizzata esclusivamente dall’hardware IT. Un PUE ideale è 1.0 (impossibile nella pratica), mentre un valore di 2.0 significa che per ogni watt usato dai server, un altro watt viene sprecato in raffreddamento e altre infrastrutture. L’obiettivo per un data center moderno è scendere sotto un PUE di 1.2.

Raggiungere un PUE così basso con il tradizionale raffreddamento ad aria è quasi impossibile, specialmente con i rack ad alta densità richiesti dall’HPC. L’aria è un pessimo conduttore di calore. La soluzione più efficace è il raffreddamento a liquido. Esistono diverse tecnologie:

• Direct-to-chip: piccoli tubi portano un liquido refrigerante direttamente a contatto con le CPU e le GPU, i componenti che scaldano di più.
• Immersione: l’intero server viene immerso in un liquido dielettrico non conduttivo.

Questi sistemi sono fino a 4000 volte più efficienti nel trasferire il calore rispetto all’aria. I benefici sono enormi: drastica riduzione dei consumi energetici legati al condizionamento, possibilità di aumentare la densità dei rack (più potenza di calcolo a parità di spazio) e recupero del calore, che può essere riutilizzato per riscaldare altri ambienti dell’ospedale. L’investimento iniziale in un sistema a liquido può essere maggiore, ma il ritorno sull’investimento (ROI) in termini di risparmio energetico è spesso rapidissimo. Un caso emblematico di attenzione all’efficienza in Italia è l’IRCCS CROB della Basilicata, che è risultato primo in Italia per efficienza nel 2024 secondo il laboratorio MeS della Scuola Superiore Sant’Anna di Pisa, anche grazie all’applicazione di politiche di contenimento della spesa energetica.

L’immagine mostra la complessità e l’eleganza di un sistema di raffreddamento a liquido, una tecnologia non più futuristica ma essenziale per la sostenibilità dei moderni data center sanitari. Abbassare il PUE non è solo una questione di “green washing”, ma una leva strategica per liberare risorse economiche da reinvestire nella ricerca.

Tutta questa complessa e costosa infrastruttura poggia però su un fondamento imprescindibile: il consenso informato del paziente.

Come permettere al paziente di ritirare il consenso all’uso dei suoi dati in qualsiasi momento

Il GDPR sancisce un principio fondamentale: il paziente ha il “diritto all’oblio” e può ritirare il consenso al trattamento dei propri dati in qualsiasi momento. Per un CIO, questa non è una questione legale astratta, ma una sfida tecnica di enorme complessità. Se un paziente revoca il consenso, l’istituto ha l’obbligo di cessare l’utilizzo dei suoi dati e, ove possibile, di cancellarli. Ma cosa significa “cancellare” un dato genomico che è stato replicato, analizzato, archiviato su nastro e potenzialmente integrato in un modello di machine learning già allenato?

L’implementazione del diritto al ritiro del consenso richiede un’infrastruttura con capacità di data cataloging e data lineage estremamente robuste. Non è pensabile cercare manualmente i dati di un paziente su decine di sistemi. È necessario un catalogo centralizzato che mappi ogni singolo dato (dal file FASTQ grezzo al risultato VCF, passando per le immagini DICOM) al suo identificativo pseudonimo. Quando arriva una richiesta di revoca, il sistema deve essere in grado di:

1. Individuare tutti i dati relativi a quell’identificativo su tutti i livelli di storage: primario, di backup e di archiviazione a freddo.
2. Cancellare i dati dove tecnicamente fattibile. Per i dati su nastro in archivi WORM (Write Once, Read Many), la cancellazione fisica potrebbe essere impossibile; in tal caso, si deve procedere a rendere i dati inaccessibili, ad esempio distruggendo le chiavi di cifratura o cancellando il riferimento dal catalogo.
3. Gestire i dati derivati: se i dati del paziente hanno contribuito ad allenare un modello di IA, non è possibile “dis-allenare” il modello. La normativa riconosce questa complessità. La cessazione del trattamento si applica agli usi futuri; i risultati aggregati e anonimizzati (come un modello già addestrato) possono essere mantenuti.
4. Tracciare l’operazione: ogni fase del processo di cancellazione deve essere registrata in un log di audit per dimostrare la conformità in caso di ispezione.

Senza un sistema di governance del dato che fornisca questa visione a 360°, il diritto al ritiro del consenso rimane una promessa vuota e un enorme rischio legale per l’istituto. La scelta della piattaforma di gestione dati diventa quindi tanto critica quanto quella dello storage sottostante.

Per tradurre questi principi in un’infrastruttura concreta e su misura per le esigenze del vostro istituto, il prossimo passo consiste nell’avviare un audit completo del vostro attuale ciclo di vita del dato, identificando i colli di bottiglia, i rischi di compliance e le opportunità di ottimizzazione.