Generating real-world evidence platform
play_circle_filledPiattaforma per la conduzione di studi osservazionali basati sui flussi amministrativi correnti.
Piattaforma per il calcolo degli indicatori per il monitaraggio e la valutazione dei percorsi diagnostico-terapeutico assistenziali (PDTA) previsti dal Ministero della Salute all'interno del "Nuovo Sistema di Garanzia per il monitoraggio dell'assistenza sanitaria".
Condivide lo stesso core di Beaver Full, offrendo all'utente la possibilità di condurre analisi automatizzate.
Il calcolo degli indicatori avviene tramite la parametrizzazione automatizzata di templates, ovvero strutture JSON (Javascript Object Notation) che rappresentano dei veri e propri studi di coorte osservazionale, generati in fase di sviluppo per mezzo di Beaver Full.
Condividendo lo stesso core di Beaver Full, i processi sono stati progettati per massimizzare le prestazioni. È inoltre possibile eseguire in parallelo il calcolo degli indicatori per più aree di interesse e per coorti estratte in anni differenti.
L'utente può richiedere il calcolo stratificato degli indicatori. Le variabili di stratificazione previste sono l'età, il genere, l'ASL di assistenza e l'indice di complessità clinica MCS (Multisource Comorbidity Score).
L'adozione di procedure automatizzate garantisce la piena e totale riproducibilità dei risultati, nonché la loro confrontabilità per analisi condotte in Regioni differenti.
È garantito lo stesso livello di sicurezza di Beaver Full. L'utente non ha la possibilità di accedere ai dati originali o di impartire istruzioni esplicite.
Beaver dispone di un modulo che automatizza il processo ETL sui dati sorgente. Tale processo consente di estrarre, trasformare e caricare nel database i dati messi a disposizione dall'Ente, in modo da renderli fruibili a Beaver Full e Beaver Light.
La struttura software è stata progettata per ridurre al minimo l'intervento dell'utente. Generalmente, i processi ETL prevedono la definizione delle strutture dati di input e di output. Questa operazione avviene a livello di sviluppo e non può essere effettuata dall'utente finale. Tuttavia, ciò garantisce il corretto funzionamento del sistema e la piena omogeneità delle strutture dati tra i diversi Enti che fanno uso di Beaver. Il processo ETL viene eseguito laddove sia necessario popolare il database con nuovi dati.
Il concetto di popolazione viene sintetizzato nel termine Area di Interesse, ovvero un sottoinsieme della popolazione complessiva che presenta determinate caratteristiche cliniche. Le aree attualmente previste da Beaver sono:
È inoltre in fase di definizione l'area Patologia neuropsichiatrica. Per la costruzione di un'area di interesse si seguono le seguenti due fasi:
In questo modo, è possibile pianificare qualsiasi studio che riguarda quella specifica area.
Le Aree di Interesse vengono istanziate tramite un processo di definizione, popolamento e ottimizzazione di tabelle all'interno del database. Queste tre attività possono essere descritte dai seguenti punti:
Il processo ETL provvede a produrre una serie di statistiche descrittive che permettono, con dei semplici grafici, di individuare a colpo d'occhio la presenza di anomali quali, ad esempio:
Il processo ETL è altamente ottimizzato. Facendo uso di tecnologie all'avanguardia quali SparkSQL, garantisce prestazioni elevate. La fase di ottimizzazione del database viene effettuata tramite pipeline parallele, che consentono di sfruttare oltremodo le potenzialità dei moderni server.
L'avvio del processo ETL avviene previa autenticazione a un pannello web dedicato, tramite cui non è possibile accedere in alcun modo al contenuto dei dati sorgente.
La fase di elaborazione viene costantemente monitorata da un sistema automatizzato di gestione degli eventi e degli errori. Inoltre, la disconnessione dalla piattaforma non comporta l'interruzione del processo ETL.
Beaver è un software web di tipo client-server, pertanto necessita di un browser web per poter interagire con l'applicazione e di una macchina server dedicata o virtualizzata per l'archiviazione dei dati e l'esecuzione delle elaborazioni.
L'interfaccia grafica è implementata utilizzando i linguaggi HTML e CSS. La componente dinamica di interazione è stata sviluppata in Javascript e fa uso della libreria jQuery. Le interazioni con l'applicazione server avvengono per mezzo di richieste asincrone GET e POST dall'applicazione client verso Apache HTTP.
L'applicazione server è costituita da un insieme di script PHP che si occupano di interpretare le richieste dell'applicazione client, produrre il codice HTML di risposta, gestire i processi di generazione delle pipeline di esecuzione delle elaborazioni, generare le transazioni SQL e tutto ciò che riguarda la manipolazione dei dati.
PostgreSQL costituisce il database delegato a ospitare, gestire e trattare i dati. Per alcune operazioni, come ad esempio il calcolo della copertura farmaceutica, i dati vengono portati in ambiente Scala per poter essere trattati con SparkSQL. In caso di esigenze particolari, è possibile installare l'istanza PostgreSQL su una macchina distinta rispetto all'applicazione web.
Le pipeline di elaborazione vengono gestite a livello di Shell script Linux. Ciò consente di parallelizzare agevolmente certe tipologie di query e di gestire blocchi sequenziali di transazioni parallele, all'interno delle quali possono coesistere invocazioni a PostgreSQL e a SparkSQL.
Il processo ETL fa uso di SparkSQL tramite uno script Python parametrico, invocato da una pipeline di esecuzione. Le operazioni di ottimizzazione dei dati, come ad esempio il partizionamento, la creazione di cluster e indici, viene effettuata per mezzo di svariate query eseguite da PostgreSQL.
La reportistica viene effettuata parzialmente in ambiente PostgreSQL e in buona parte per mezzo di Microsoft Open R. Quest'ultimo viene impiegato anche per la conduzione delle analisi statistiche. I risultati delle elaborazioni vengono archiviati all'interno del database in formato JSON, mentre il report visualizzato dall'utente viene generato su richiesta.
La produzione del report in formato PDF stampabile avviene per mezzo del tool PhantomJS, ovvero un ambiente di rendering web che consente di convertire lo spazio virtuale di una pagina HTML in uno spazio carta A4.
I dati sanitari e amministrativi dell'Ente vengono importati nel database tramite il processo ETL e utilizzati in sola lettura durante le elaborazioni.
Il trattamento e l'elaborazione di una grande mole di dati presuppone l'utilizzo di un ambiente operativo dedicato e di risorse hardware all'altezza. La definizione dei requisiti dipende pertanto dalla disponibilità temporale e dalla dimensione del dato, ovvero dal numero di soggetti presenti nell'anagrafe degli assistiti. Inoltre, Beaver deve essere vista come un'applicazione DWH (Data Ware House), in cui la maggior parte delle risorse viene dedicata a una singola elaborazione. Sebbene nello stack architetturale sia previsto un pooler di connessioni (pgBouncer), che ha lo scopo di limitare il consumo eccessivo di risorse da parte del database, è bene disporre di un sistema equilibrato e bilanciato in grado di garantire performance minime accettabili.
Beaver è compatibile con sistemi Ubuntu Server LTS (16.04 e successive) e Red Hat Enterprise (7 e successive). Sistemi Microsoft Windows non sono supportati per motivi di licenza, di costi e di architettura.
Per tutte le operazioni eseguite in parallelo, Beaver scala linearmente all'aumentare del numero di CPU logiche. È consigliato un numero minimo di 4 CPU logiche per garantire stabilità e responsività del sistema. All'aumentare della mole di dati, tuttavia, può essere necessario disporre di 16 o più CPU logiche. Un numero sempre maggiore di CPU consente di ottenere diversi vantaggi:
La frequenza di elaborazione delle singole CPU logiche gioca un ruolo fondamentale in termini di prestazioni, ma non di scalabilità. Tutte le operazioni single-core risentono significativamente di una frequenza di funzionamento elevata.
Un fattore spesso trascurato è la dimensione della cache L2, di fondamentale importanza in termini prestazionali per le operazioni effettuate dal database. Valori maggiori garantiscono velocità di elaborazione superiori.
La memoria RAM (Random Access Memory) è un parametro fondamentale che determina le prestazioni del database PostgreSQL e di Apache Spark. Un'installazione standard, costituita da una sola macchina, deve dividere la memoria RAM tra questi due servizi, pertanto una quota deve sempre rimanere disponibile. Siccome il numero di CPU determina il parallelismo, ovvero la quantità di operazioni eseguite in parallelo, la memoria totale deve andare di pari passo con il numero di CPU disponibili. In generale:
Lo spazio di archiviazione è fondamentale, in quanto i dati sono archiviati in un database. PostgreSQL, come qualsiasi altro
database ACIDopen_in_new,
dispone di un componente denonimato WALopen_in_new,
pertanto vengono effettuate operazioni di scrittura su disco anche laddove vengano richieste delle semplici letture.
Ciò significa che operazioni di JOINopen_in_new su tabelle di grandi dimensioni (decine o centinaia di milioni di record)
possono potenzialmente saturare lo spazio disponibile. Analogamente, Apache Spark è progettato per sfruttare quasi tutto
lo spazio disponibile, adattandosi più agevolmente di PostgreSQL ai casi in cui vi sia poco spazio residuo.
Le dimensioni occupate dalle aree di interesse, tuttavia, non sono identiche alla dimensione del dato originale in quanto
sono presenti indici che, in alcuni casi, possono assumere dimensioni pari o superiori a quelle della tabella cui appartengono.
A ciò bisogna aggiungere il fatto che le elaborazioni di Beaver producono tabelle che, a loro volta, occupano spazio.
Il calcolo di un indicatore può comportare la creazione di decine di tabelle.
Un'installazione di Beaver che funzioni in modo efficiente richiede almeno un terzo dello spazio libero disponibile calcolato rispetto
allo spazio occupato dall'intero database.
Il dimensionamento viene effettuato su richiesta e sulla base della dimensione del dato.
Per fare un esempio pratico, in presenza di 10 milioni di soggetti e 12 anni di disponibilità del dato, lo spazio richiesto può superare i 2TB. Per le piccole installazioni, si consiglia comunque di non scendere al di sotto dei 200GB di spazio di archiviazione.
Le prestazioni del sistema dischi sono di importanza fondamentale laddove il numero di CPU logiche è superiore a 4 e, in generale, laddove si voglia aumentare il parallelismo. Un fattore discriminante nei tempi di elaborazione è dato dal tempo di accesso in lettura e scrittura casuale su disco. Sistemi dischi di livello enterprise non soffrono di particolari problemi, tuttavia configurazioni più semplici ed economiche, come ad esempio due dischi SATA configurati in RAID0, rappresentano un collo di bottiglia non trascurabile.
Si consiglia pertanto un sistema dischi RAID10 costituito da almeno 6 dischi meccanici HDD SAS oppure una configurazione RAID1 da almeno 2 dischi allo stato solido SSD SATA/SAS. Un sistema costituito da dischi NVME offre prestazioni ottimali, a costi relativamente contenuti. Dai test effettuati, un sistema RAID0 con 6 dischi SSD SATA da 500GB ciascuno offre le stesse prestazioni di 2 dischi NVME RAID0 da 500GB ciascuno.
Healtcare Research & Pharmacoepidemiology - UNIMIB open_in_new
Università degli Studi di Milano-Bicocca
via Bicocca degli Arcimboldi 8
edificio U7, II piano, stanza 2059
20126, Milano
Tel: +39 02 6448 5847