Snowflake Hospital Data Platform

Cos'è il progetto

Snowflake Hospital Data Platform è una piattaforma dati dimostrativa per un contesto sanitario, costruita su Snowflake per integrare dati clinici, amministrativi e IoT. Il progetto mette insieme modellazione multi-schema, pipeline di pulizia, governance, RBAC, masking dei dati sensibili e query analitiche operative.

Contesto tecnico

Un sistema ospedaliero deve gestire dati clinici, amministrativi e segnali provenienti da dispositivi IoT, mantenendo relazioni coerenti tra pazienti, ricoveri, diagnosi, personale e parametri vitali.

Il problema non riguarda soltanto l'archiviazione. I dati sanitari includono informazioni personali sensibili, richiedono controlli di accesso differenziati e devono restare utili per analisi operative senza esporre informazioni non necessarie.

Il progetto affronta quindi tre esigenze collegate: organizzare domini diversi in un unico modello, validare rilevazioni IoT potenzialmente sporche e applicare regole di governance compatibili con un contesto sanitario.

Obiettivo

L'obiettivo era progettare una data platform dimostrativa su Snowflake capace di coprire l'intero ciclo del dato:

• separare dati clinici, amministrativi, IoT e audit in schemi dedicati;
• simulare rilevazioni da sensori con valori nulli, anomalie e duplicati;
• trasformare lo staging in una tabella validata tramite stored procedure SQL;
• definire accessi diversi per amministratori, medici, infermieri e analisti;
• mascherare codice fiscale, email e telefono in base al ruolo;
• produrre query dashboard per monitoraggio clinico e operativo;
• dimostrare recupero e isolamento degli ambienti con Time Travel e Zero-Copy Cloning.

Il risultato non è una singola tabella, ma un piccolo sistema dati governato nel quale modellazione, qualità, sicurezza e analytics fanno parte della stessa architettura.

Architettura

Il database HOSPITAL_DB è organizzato in cinque schemi logici:

• CLINICAL_DATA per pazienti, ricoveri e diagnosi;
• ADMINISTRATIVE per staff, reparti, appuntamenti e fatturazione;
• IOT_STAGING per rilevazioni grezze provenienti dai sensori;
• IOT_DATA per parametri vitali puliti e validati;
• AUDIT per il tracciamento degli accessi.

Il carico di lavoro è separato tra due virtual warehouse. WH_ETL_LOAD gestisce caricamento e trasformazioni, mentre WH_ANALYTICS è dedicato alle query di analisi e dashboard. Entrambi utilizzano auto-suspend e auto-resume per separare i workload e limitare il consumo quando non sono attivi.

Pipeline IoT e qualità del dato

La demo genera 150 rilevazioni IoT e aggiunge tre duplicati intenzionali. Nei dati grezzi vengono inoltre introdotti valori nulli e misurazioni fuori range, come frequenze cardiache impossibili, temperature anomale e saturazioni superiori al 100%.

La stored procedure SP_CLEAN_IOT_DATA trasferisce i dati dallo staging alla tabella finale applicando:

• validazione dei range clinici per ogni parametro;
• conversione dei valori non validi in NULL;
• ricalcolo del flag di allerta;
• controllo dei campi obbligatori;
• deduplicazione con QUALIFY ROW_NUMBER() su paziente e timestamp.

Dopo la pulizia, la tabella finale contiene 150 rilevazioni uniche e interrogabili. Una clustering key su paziente e timestamp rappresenta inoltre il pattern previsto per una tabella IoT destinata a crescere.

Governance e sicurezza

La sicurezza è modellata attraverso quattro ruoli:

• HOSPITAL_ADMIN con accesso completo;
• HOSPITAL_MEDICO con accesso ai dati clinici e IoT;
• HOSPITAL_INFERMIERE con accesso clinico in sola lettura;
• HOSPITAL_ANALYST orientato ad analisi senza esposizione diretta dei dati personali.

La gerarchia dei ruoli permette al medico di ereditare i privilegi dell'infermiere e all'amministratore di ereditare quelli del medico. Tre masking policy proteggono codice fiscale, email e numeri di telefono, restituendo valori completi, parzialmente mascherati o completamente nascosti in base al ruolo corrente.

Lo schema AUDIT completa il modello con log di accesso immutabili, includendo utente, paziente, azione, risorsa, autorizzazione e motivazione dell'accesso.

Analytics

Il progetto include cinque query analitiche con relativi output CSV:

1. pazienti con parametri vitali critici;
2. occupazione e performance dei reparti;
3. diagnosi più frequenti con distribuzione della gravità;
4. trend orario dei parametri vitali e variazione rispetto all'ora precedente tramite LAG;
5. KPI clinici per medico, ricoveri e casistica.

Queste query mostrano come il modello possa supportare sia il monitoraggio operativo sia analisi aggregate, utilizzando join cross-schema, window function, aggregazioni condizionali e indicatori derivati.

Continuità e ambienti

Il progetto dimostra due funzionalità native di Snowflake utili per la resilienza e lo sviluppo:

• Time Travel, testato simulando la cancellazione di un paziente e recuperando il record da una versione precedente della tabella;
• Zero-Copy Cloning, usato per creare HOSPITAL_DB_TEST, verificare l'isolamento delle modifiche e mantenere le masking policy anche nell'ambiente clonato.

Queste funzionalità rendono più semplice recuperare errori e creare ambienti di test senza duplicare immediatamente tutto lo storage del database.

Implementato e scenario produttivo

La demo eseguita utilizza dati sintetici generati direttamente in Snowflake. La procedura di pulizia, il modello dati, RBAC, masking, Time Travel, cloning e le query dashboard sono parte dello script operativo.

L'integrazione con AWS S3, le Directory Tables e Snowpipe sono invece documentate come estensione produttiva, ma non sono state eseguite nella demo. Anche il task ogni 15 minuti è creato ma lasciato sospeso per evitare rielaborazioni dei dati statici; in un flusso continuo dovrebbe essere affiancato da Snowflake Streams per processare soltanto i nuovi record.

Risultati

• 5 schemi separano i diversi domini del sistema;
• 2 warehouse isolano workload ETL e analytics;
• 153 record IoT grezzi vengono ridotti a 150 rilevazioni uniche validate;
• 4 ruoli definiscono accessi e responsabilità differenti;
• 3 masking policy proteggono i principali dati personali;
• 5 query dashboard producono output clinici e operativi;
• Time Travel e Zero-Copy Cloning vengono verificati con scenari di recupero e isolamento.

Evoluzioni future

• usare storage integration e secret management al posto di credenziali statiche nello stage S3;
• attivare Snowpipe con notifiche reali e Snowflake Streams per l'incremental processing;
• aggiungere secure view dedicate al ruolo analyst;
• introdurre test automatici e controlli di qualità versionati;
• collegare le query a una dashboard BI completa;
• aggiungere monitoring, alerting e CI/CD per gli oggetti Snowflake.

FAQ tecniche

Perché separare i dati in cinque schemi?

La separazione rende espliciti i confini tra dati clinici, amministrativi, IoT grezzi, IoT validati e audit. Questo migliora leggibilità, gestione dei privilegi e manutenzione del modello.

Come vengono gestiti valori IoT non validi e duplicati?

La stored procedure controlla i range ammessi, converte le misurazioni impossibili in valori nulli e usa QUALIFY ROW_NUMBER() per conservare una sola rilevazione per paziente e timestamp.

Qual è la differenza tra RBAC e masking?

RBAC stabilisce quali oggetti e operazioni sono accessibili a ciascun ruolo. Il masking interviene invece sul valore restituito da una colonna sensibile, permettendo accessi differenziati anche sulla stessa tabella.

Snowpipe è realmente in esecuzione?

No. Lo script documenta stage S3, file format e Snowpipe come scenario produttivo, ma la demo utilizza dati sintetici generati direttamente in Snowflake. Questa distinzione è mantenuta esplicita nella pagina.

Perché usare Time Travel e Zero-Copy Cloning?

Time Travel aiuta a recuperare dati cancellati o modificati accidentalmente. Zero-Copy Cloning permette invece di creare rapidamente un ambiente di test isolato senza una copia fisica iniziale completa dei dati.