doveyi sono i valori osservati,yè la loro media eyˆsono i lavori stimati.
6.2
Performance dei vari modelli predittivi
Di seguito una tabella comparativa di tutti i modelli predittivi analizzati:
Tabella 6.1: Tabella di confronto tra i vari modelli predittivi. L’errore viene espresso attraverso l’Errore Quadratico Medio (MSE). Gli errori sono rappresentati in minuti.
DS1 / DS1 SO DS2 / DS2 SO DS3 / DS3 SO DS4 / DS4 SO
Moving Average 3512 / - 3420 / - 3490 / - 3410 / -
Lasso 1951 / 620 1894 / 605 1923 / 615 1930 / 618
NNR 1712 / 541 1812 / 740 1750 / 693 1770 / 704
Il modello ad offrire la migliore prestazione è la NNR, con un MSE pari a 1761 si avvicina all’implementazione effettuata dai ricercatori della Stanford University al SMMC [1].
1Fonte: https://it.wikipedia.org/wiki/Errore_quadratico_medio 2
Come ben visibile nella tabella, effettuato il data cleaning, i risultati subiscono un netto mi- glioramento. Infatti, nel dataset originale erano presenti poche situazioni che generavano grandi problemi nel risultato finale.
Di seguito una tabella riassuntiva che mostra il coefficiente di determinazione in funzione del dataset e del modello:
Tabella 6.2: Coefficiente di determinazione (R2) per tutti i dataset con e senza data cleaning.
DS1 / DS1 SO DS2 / DS2 SO DS3 / DS3 SO DS4 / DS4 SO Lasso 0.388 / 0.643 0.363 / 0.625 0.394 / 0.589 0.386 / 0.578
NNR 0.416 / 0.714 0.403 / 0.697 0.425 / 0.715 0.414 / 0.696
Come ben visibile, a dare migliori performance è la NNR, in grado di raggiungere un coeffi- ciente di determinazione pari a 0.4145 (senza il data cleaning). Effettuando un data cleaning (rimozione di eventi eccezionali, come spiegato a pagina 50 nella sezione 5.2) il coefficiente di determinazione aumenta fino ad una media di 0.7055.
56 Risultati delle performance dei modelli studiati
Di seguito una figura che mostra la media del tempo d’attesa effettivo a confronto con Lasso ed una Neural Network Regression.
0
5
10
15
20
Fascia oraria
30
40
50
60
70
80
90
Tempo d'attesa in minuti
Tempo d'attesa medio
Tempo d'attesa stimato (NNR)
0
5
10
15
20
Fascia oraria
30
40
50
60
70
80
90
Tempo d'attesa in minuti
Tempo d'attesa medio
Tempo d'attesa stimato (Lasso)
Figura 6.1: Confronto tra la media del tempo d’attesa effettivo di pazienti non urgenti, stima del tempo d’attesa con Lasso e Neural Network Regression.
Come visibile nella tabella di confronto 6.1 a pagina 54, il modello che offre performance migliori è la NNR. Sebbene i due modelli diano performance molto simili, la NNR è in grado di seguire meglio la curva al mattino quando il PS è scarico e durante il picco di mezzogior- no.
eR2, potrebbe non essere sufficiente per capire la bontà del modello. Per questo motivo si è deciso di analizzare la percentuale di successo in funzione della dimensione della finestra, entro la quale la stima risulta accettabile e quindi corretta.
0
20
40
60
80
100
120
140
Margine d'errore in minuti
0
20
40
60
80
100
Precisione in percentuale
Senza data cleaning
Con data cleaning
Figura 6.2: Percentuale di successo in funzione della tolleranza in minuti (per pazienti non urgenti).
In Figura 6.2 è possibile notare che la percentuale di successo, applicando il data cleaning, raggiunge praticamente il 90% nel momento in cui la tolleranza dell’errore è di 30 minuti, per poi arrivare quasi al 100% con una tolleranza d’errore di ca. 40 minuti.
Occorre però prestare attenzione a non confondere il problema di regressione, in cui l’obiet- tivo è identificare una quantità, con un problema di classificazione. Per esempio, se con un margine di tolleranza di 10 minuti si ottiene una percentuale di successo del 75% circa, non significa che il restante 25% sia completamente sbagliato, ma semplicemente che sia fuori, magari anche di poco, dal margine di tolleranza.
Quest’analisi è utile per capire quali sono le aspettative dell’utente e come raggiungerle, identificando il margine di tolleranza considerato accettabile.
Capitolo 7
Implementazione del modello
predittivo
Con l’implementazione del modello predittivo, si è reso necessario conoscere lo stato del PS in tempo reale (quali pazienti sono presenti, dove si trovano, quali sono le loro condizioni, ecc.). Purtroppo non esiste un web service che permette di ottenere questa informazione in maniera semplice e veloce.
Le informazioni sono distribuite su 3 sistemi diversi: l’entrata in PS risiede in un sistema amministrativo per la gestione delle etichette (ADT - Admit Discharge Transfer), le informa- zioni sul triage in un componente dedicato al triage, mentre le entrate e le uscite dai box in un terzo sistema (RAP) sviluppato da un’azienda esterna all’EOC. Mentre per le prime due informazioni, ovvero l’entrata in PS ed il triage sono disponibili tramite web services, non è altrettanto vero per le entrate e le uscite dai box. Gli unici modi per ottenere queste in- formazioni sono: accedere direttamente al database del software, oppure ascoltare, tramite messaging system (NOTIF), le notifiche di cambiamento di stato emesse dal RAP.
A questo punto le opzioni sono due:
• Creare un nuovo componente in cui un addetto del PS mantiene aggiornate le infor- mazioni in tempo reale dello stato del PS
• Integrare i diversi sistemi evitando d’introdurre un ulteriore sistema con informazioni ridondanti
La prima variante, ovvero quella in cui viene creata un’interfaccia dalla quale è possibile in- serire la movimentazione dei pazienti e le informazioni del triage, è sicuramente la variante più semplice in termini di sviluppo, ma la più onerosa in termini di mantenimento delle infor- mazioni da parte del personale del PS. Sviluppare un applicativo assestante genererebbe
60 Implementazione del modello predittivo
un carico di lavoro maggiorato per il personale, rischiando di non essere sostenibile. Inoltre, creando un applicativo dedicato, si andrebbe a ridondare le informazioni, che di fatto, sono già esistenti.
È stato deciso di sviluppare un componente in grado di fornire lo stato del PS in tempo reale, integrando i 3 diversi sistemi informatici ed evitando così un lavoro inutile al personale del PS.
Qui di seguito vi è uno schema che illustra l’architettura che è stata implementata per realizzare l’integrazione tra i diversi sistemi:
PULL PULL
EDWT-STATE
PUSH
MESSAGING SYSTEM PUSH RAP
ADT TRIAGE
DB
PULL EDWT-PREDICTOR
Figura 7.1: Architettura del progetto
È stato deciso di sviluppare due componenti, ognuno con specifiche responsabilità.
I componenti che sono stati sviluppati sono EDWT-STATE ed EDWT-PREDICTOR.
Il componente EDWT-STATE, tramite una semplice interfaccia HTTP, è responsabile di for- nire lo stato del PS. Per stato del PS s’intende le informazioni di tutti i pazienti presenti in quell’istante in PS, quindi data e ora d’entrata, livello d’urgenza, il codice del motivo per il quale un paziente si trova in PS, data/ora del triage e se disponibile data e ora d’entrata nel box.
Il componente EDWT-PREDICTOR è responsabile di fornire una previsione del tempo d’at- tesa, per svolgere questo compito necessita dello stato attuale del PS, reso facilmente re- peribile dal componente EDWT-STATE. Il componente EDWT-PREDICTOR, ogni volta che necessita dello stato del PS, effettua una chiamata HTTP al componente EDWT-STATE.
Il compito del componente EDWT-STATE è ascoltare le notifiche di cambiamento (entrata / uscita box) del componente RAP e salvarle in un database. Questo approccio è necessario siccome non esistono interfacce verso il RAP.
Per capire meglio il funzionamento dei componenti EDWT-PREDICTOR e EDWT-STATE vi è un sequence diagram che mostra ciò che accade quando si richiede una stima del tempo d’attesa: ADT DB TRIAGE EDWTSTATE getTriageDataForPatients(...) last12HPatients() getEntryExitBoxPatientsForPatients(...) EDWT PREDICTOR getEDState() User getPrediction()
Figura 7.2: Sequence diagram riassuntivo che mostra le interazioni tra i vari componenti.
In Figura 7.2 vengono mostrate quali sono le interazioni tra i vari componenti nel momento in cui l’attore (in questo caso il paziente da casa) richiede una stima del tempo d’attesa.
La richiesta dell’utente viene effettuata al componente EDWT-PREDICTOR, ovvero al com- ponente responsabile di fornire una stima del tempo d’attesa. Quest’ultimo, per poter fornire una stima, necessita dello stato attuale del PS.
Tramite una richiesta HTTP viene quindi richiesto lo stato del PS al componente EDWT- STATE.
A questo punto il componente EDWT-STATE necessita di sapere quali sono i pazienti fisica- mente presenti in PS. Inizialmente si pensava che bastasse richiedere al componente ADT tutte le etichette ancora aperte, infatti, in una situazione ideale, l’etichetta, viene aperta al- l’arrivo di un paziente, chiusa all’uscita del paziente e marcata come trasferita per i pazienti che passano in degenza. Purtroppo questo non è possibile dato che le etichette dei pazienti dimessi vengono chiuse solo nel momento in cui è avvenuta la fatturazione. Richiedendo
62 Implementazione del modello predittivo
tutte le etichette ancora aperte al componente ADT risulterebbero quindi pazienti già usciti dal PS. Per ovviare a questo problema è stata implementata una "fuzzy-logic", ovvero sono stati incrociati i dati di ADT con quelli del RAP (entrate/uscite box). L’approccio implementa- to consiste nel richiedere tutte le etichette aperte create nelle ultime 12 ore, dopodiché, per ogni etichetta viene verificato se è presente un’uscita dal box. Se è presente un’uscita dal box significa che il paziente è già uscito dal PS, altrimenti significa che è ancora presente. Le 12 ore sono un valore approssimativo ed è stato scelto proprio questo valore (12 ore) perché difficilmente, sommando il tempo d’attesa ed il tempo di permanenza nel box si sfo- rano le 12 ore. Per maggiori informazioni consultare le figure 3.6 a pagina 30, 3.11 a pagina 38 e 3.2 a pagina 20.
A questo punto, il componente EDWT-STATE conosce tutti i pazienti presenti fisicamente in PS ed il loro stato (in attesa, in cura nel box). Questa informazione viene arricchita aggiun- gendo le informazioni del triage.
Per migliorare ulteriormente i tempi di risposta del componente EDWT-STATE è stata imple- mentata una cache dello stato del PS, la quale viene aggiornata ogni 5 minuti.
7.1
Accessibilità dall’esterno della rete EOC
Quanto descritto fino ad ora in realtà non basta per rendere la stima del tempo d’attesa accessibile anche dall’esterno della rete EOC. Questo perché sarebbe accessibile solo per i dispositivi interni alla rete LAN.
Per rendere accessibile la stima del tempo d’attesa da casa occorre sviluppare un compo- nente situato in DMZ, ovvero l’unica zona accessibile dall’esterno.
A questo punto risulta necessario creare un terzo componente situato in DMZ. Le imple- mentazioni possibili del nuovo componente sono due:
• Aprire una porta specifica sul router affinché il componente EDWT-EXTERNAL possa fare richieste HTTP al componente EDWT-PREDICTOR, accedendo quindi dalla DMZ alla rete LAN.
• Non effettuare nessuna configurazione a livello di rete, ma far sì che sia il componente EDWT-PREDICTOR ad effettuare in modalità PUSH/HTTP l’aggiornamento del tempo d’attesa verso il componente EDWT-EXTERNAL. Questo è possibile senza nessuna configurazione perché dalla LAN è possibile contattare macchine in DMZ, ma dalla DMZ non è possibile contattare macchine nella LAN.
È stato deciso di procedere con la seconda opzione, questo perché non aprendo nessun canale di comunicazione dall’esterno all’interno, si ha un sistema più sicuro.
Il componente EDWT-PREDICTOR ha quindi il compito di aggiornare periodicamente il tem- po d’attesa comunicandolo al componente EDWT-EXTERNAL.
Di seguito uno schema riassuntivo di quanto spiegato:
LAN DMZ WAN EDWT-PREDICTOR EDWT-EXTERNAL INTERNET
Figura 7.3: Architettura dell’applicativo a livello di rete