Generating real-world evidence platform

play_circle_filled

Beaver Full

Piattaforma per la conduzione di studi osservazionali basati sui flussi amministrativi correnti.

star Caratteristiche Principali
L'interfaccia grafica user-friendly dispone di strumenti grafici semplificati per un'esperienza d'uso facile e intuitiva.
Gli studi vengono suddivisi in fasi sequenziali, garantendo la piena compatibilità con l'approccio scientifico tipico dei protocolli epidemiologici.
La reportistica viene generata in formato web, consultabile direttamente dalla piattaforma, e in formato PDF stampabile.
developer_board Intervalli Temporali e Criteri Logici
Sono disponibili strumenti di input grafici per la definizione di periodi temporali (distanze, date e gap).
La definizione dei criteri logici di selezione degli eventi è agevolata da strumenti interattivi dedicati.
I flussi possono essere combinati tramite dei criteri logici che tengono conto delle selezioni fatte su ciascun flusso.
domain Covariate
Possono essere estratte o generate diverse tipologie di covariate: caratteristiche anagrafiche, costi, indici di comorbosità, aderenza, durata e discontinuità della terapia, etc.
Per ciascuna covariata può essere definita la sua natura temporale, ovvero costante oppure tempo-dipendente.
Le covariate possono essere trasformate per generarne di nuove. Le trasformazioni previste sono: classificazione, aggregazione, combinazione, somma.
timeline Analisi Statistiche
La conduzione di analisi statistiche stratificate consente di effettuare la stima di modelli o il calcolo di tassi nei diversi strati di una specifica covariata.
Tra le analisi statistiche disponibili vi sono le curve Kaplan-Meier, il modello di regressione di Cox con covariate costanti e/o tempo-dipendenti, i modelli di regressione lineare e logistica, etc.
Beaver consente di calcolare i tassi standardizzati e di stratificarli.
translate Codifiche
Per le diagnosi e le procedure viene adoperata la codifica ICD9-CM.
Per gli esami ambulatoriali e le visite specialistiche, viene adoperata la codifica della Regione in cui è installato Beaver.
È prevista la presenza di codici che nel tempo vengono aggiunti o rimossi dalle codifiche in uso.
timelapse Prestazioni
Il software e le strutture dati sono altamente ottimizzati per massimizzare le prestazioni.
Le elaborazioni più impegnative vengono eseguite in parallelo, sfruttando tutta la potenza di calcolo della macchina.
Durante le operazioni di estrazione e analisi dei dati vengono profilati i tempi di elaborazione.
security Sicurezza
L'architettura della piattaforma è multi-utenza e prevede l'autenticazione tramite delle credenziali di accesso.
L'utente ha accesso solamente ai dati aggregati, ovvero ai risultati qualitativi e quantitativi delle elaborazioni.
Non vi è possibilità per l'utente di inserire istruzioni esplicite (codice): l'interazione avviene per via grafica.
toys Funzionalità Tecniche
Gli studi possono essere eseguiti in parallelo e l'avanzamento delle elaborazioni può essere monitorato in tempo reale e in modo asincrono dal proprio browser web.
Beaver implementa un sistema automatizzato di gestione degli eventi e degli errori relativi alle elaborazioni avviate dall'utente.
La disconnessione dalla piattaforma non comporta l'interruzione delle elaborazioni, le quali vengono gestite autonomamente dall'applicazione server.

Beaver Light

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.

star Caratteristiche Principali
Condivide il motore software di Beaver Full, estendendo le sue funzionalità e sfruttandone le potenzialità.
Automatizza l'intero processo di calcolo degli indicatori.
Le procedure sono state testate e validate con dei codici scritti con il software SASopen_in_new.
assignment Templates

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.

timelapse Prestazioni

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.

view_stream Stratificazione

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).

view_module Riproducibilità e Confrontabilità

L'adozione di procedure automatizzate garantisce la piena e totale riproducibilità dei risultati, nonché la loro confrontabilità per analisi condotte in Regioni differenti.

security Sicurezza

È 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.

ETL (Extract, Transform, Load)

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.

play_arrow Processo Automatizzato

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.

blur_on Aree di Interesse

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:

  • Diabete
  • Patologia cardiovascolare
  • Patologia respiratoria
  • Patologia oncologica
  • Materno-infantile

È inoltre in fase di definizione l'area Patologia neuropsichiatrica. Per la costruzione di un'area di interesse si seguono le seguenti due fasi:

  1. identificazione dei soggetti con contatti con il Servizio Sanitario suggestivi della patologia di interesse;
  2. estrazione di tutti i dati relativi a questa coorte di individui.

In questo modo, è possibile pianificare qualsiasi studio che riguarda quella specifica area.

tune Struttura Dati Ottimizzata

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:

search Diagnosi dei Dati

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:

  • presenza di codici non presenti nelle codifiche disponibili
  • trend sospetti nelle numerosità annuali di ciascun flusso
  • valori anomali nel numero di eventi per soggetti
  • assenza totale di valori per anni specifici
  • eventi fuori scala, verificatisi in istanti temporali eccessivamente remoti oppure non ancora verificatisi
Questi strumenti di diagnosi sono disponibili sia da Beaver Full che da Beaver Light, nella sezione Aree di Interesse.

timelapse Prestazioni

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.

security Sicurezza

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.

toys Funzionalità Tecniche

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.

Architettura

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.

desktop_windows Client

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.

layers Server

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.

Architettura Server
Stack architetturale lato server.

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.

Dati

I dati sanitari e amministrativi dell'Ente vengono importati nel database tramite il processo ETL e utilizzati in sola lettura durante le elaborazioni.

border_all Flussi
I dati sono costituiti da flussi, ovvero tabelle che contengono eventi di una determinata tipologia e che consentono di effettuare il record-linkage con i soggetti assistiti. Attualmente Beaver supporta i seguenti flussi:
  • anagrafe assistiti;
  • schede di dimissione ospedaliera (SDO);
  • farmaceutica territoriale;
  • farmaceutica ospedaliera (erogazione diretta);
  • esenzioni;
  • pronto soccorso;
  • specialistica ambulatoriale;
  • CeDAP (flusso materno-infantile).
blur_on Aree di Interesse
Durante il processo ETL, i flussi forniti dall'Ente vengono opportunamente importati all'interno del database in tabelle organizzate in schemi. Ciascuno schema rappresenta un'area di interesse, ovvero un insieme di flussi distinti contenenti eventi associati a soggetti che presentano segni suggestivi di una condizione clinica, oppure perché sperimentano un evento fisiologico (gravidanza). Le aree di interesse contengono quindi i dati per pianificare qualsiasi studio che riguarda quella specifica area.
settings_input_component Tabelle Modulari
Le elaborazioni eseguite da Beaver producono delle tabelle intermedie interne al database che consentono di costruire coorti dinamiche. La sequenzialità del protocollo deve consentire di avanzare alla fase successiva senza dover modificare le strutture generate durante le fasi precedenti. Per garantire questa funzionalità, le tabelle sono state progettate per essere modulari, ovvero slegate l'una dall'altra in termini di dipendenza funzionale. Ciò consente, tra le tante cose, di poter costruire coorti costanti e tempo-dipendenti e di combinare covariate con dipendenze temporali distinte.

Requisiti di sistema

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.

 Sistema Operativo

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.

memory CPU

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:

  • più utenti possono analizzare i dati in contemporanea;
  • i tempi di elaborazione delle operazioni parallele, come ad esempio il calcolo dell'aderenza alla terapia oppure la stima dei modelli di regressione di Cox con covariate tempo-dipendenti, verranno eseguite in minor tempo;
  • nello stesso istante possono essere calcolati gli indicatori ministeriali su più aree di interesse;
  • il processo ETL, che normalmente richiede alcune ore di elaborazione, viene velocizzato.
È bene notare che il numero di CPU disponibili deve essere bilanciato con la quantità di memoria RAM disponibile.

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.

straighten Memoria RAM

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:

  • 4 CPU → 16GB di memoria RAM
  • 8 CPU → 32GB di memoria RAM
  • 12 CPU → 48GB di memoria RAM
  • 16 CPU → 64GB di memoria RAM
La combinazione ottimale dei due parametri dipende comunque dall'effettiva dimensione del dato e dalle caratteristiche prestazionali del sistema di archiviazione. Ad esempio, un sistema con 16 CPU può richiedere 96GB oppure 128GB di memoria RAM.

dns Archiviazione

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.

Pubblicazioni

[1]
Federico Rea, Pietro Pugni, Dario Pescini, Luigi Palmieri, Simona Giampaoli, Flavia Carle, Giovanni Corrao.
Real-world assessment of healthcare provided by the National Health Service: The network of regional Beaver research platforms.
Epidemiology Biostatistics and Public Health - 2017, Volume 14, Number 3, Suppl. 2 open_in_new

Contatti

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

Coordinatore del Progetto

prof. Giovanni Corrao
Tel: +39 02 6448 5854
Email: giovanni.corrao@unimib.it

Supporto scientifico

dr. Federico Rea
Tel: +39 02 6448 5859
Email: federico.rea@unimib.it

Progettista e Sviluppatore

dr. Pietro Pugni
Email: pietro.pugni@unimib.it