Lombardia zona rossa, vittima dell'algoritmo di RT: ecco perché | Agenda Digitale

il caso

Lombardia zona rossa, vittima dell’algoritmo di RT: ecco perché

La Regione Lombardia, i suoi cittadini, sono vittime di problemi noti e ignorati. L’algoritmo per il calcolo dell’RT, che ha affibbiato una zona rossa ingiustamente, aveva problemi noti. Ma la vera colpa è della PA che ancora non riesce a lavorare in digitale

28 Gen 2021
Federico Fuga

ingegnere elettronico, coordinatore della commissione ICT dell’Ordine degli Ingegneri della provincia di Verona

La cosa peggiore è che tutti gli esperti sapevano che l’algoritmo per il calcolo dell’RT era ad alto rischio di errori. E che se i suoi dati sono imprecisi il disastro è in agguato.

La Regione Lombardia, i suoi cittadini, sono vittime quindi di problemi noti e ignorati. Figli di una cattiva cultura digitale della PA, che qui arriva persino a impattare sulla riduzione di diritti costituzionali (libertà di movimento, di attività economiche), a causa di un‘area rossa “ingiustamente” inflitta. Con conseguenti danni economici di cui qualcuno forse un giorno dovrà rispondere.

Già: fin dall’introduzione del sistema di definizione delle limitazioni regionali attuate dal DPCM di novembre 2020, più di qualcuno aveva sollevato dubbi sulla bontà del sistema.

Su queste pagine[1] avevo già rilevato alcune problematiche in merito sia alla trasparenza del cosiddetto algoritmo, il quale ha alcuni margini di discrezionalità che non lo rendono completamente replicabile, sia in merito alla bontà di un modello complesso e basato su un alto numero di parametri. In particolare, l’influenza del parametro Rt il quale è, per sua stessa natura, un parametro la cui stima è piuttosto sensibile alle misure.

In tale occasione scrivevo:

“Rt è un valore che definisce il numero medio di infezioni che una popolazione di individui infetti produce; è un parametro statistico che interpreta l’evoluzione dell’epidemia nel tempo e tiene conto degli effetti degli interventi di sanità pubblica e della situazione contingente locale. È un parametro utilissimo per stimare l’evoluzione dell’epidemia, ma la cui misura è soggetta inevitabilmente ad effetti statistici”

L’importanza dell’RT per decidere i colori

Questo aspetto è esploso in tutta la sua drammaticità nelle ultime settimane. Il peso del parametro Rt infatti determina da solo quale dei 4 scenari epidemiologici si deve applicare al passaggio finale dell’algoritmo, e pertanto pesa approssimativamente per un 50% del modello, mentre l’altro 50% è costituito da due indici che derivano con pesi più o meno rilevanti dai famosi 21 indicatori di monitoraggio.

WHITEPAPER
Come è cambiato in Italia il quadro normativo dei pagamenti digitali verso la PA?

E’ chiaro che in questo modo l’accuratezza di questo parametro Rt diventa critico al fine di avere una classificazione che sia accurata e verosimile.

Per sua stessa natura, Rt è un parametro stimato. Al tempo t è, letteralmente, “il numero medio di casi secondari che ciascun individuo infetterebbe se le condizioni (sanitarie, sociali, ecc… NdA) restassero com’erano al tempo t[2]”.

Rt is the average number of secondary cases that each infected individual would infect if the conditions remained as they were at time t.

Si tratta come detto di un parametro di un modello statistico, e quindi deve essere stimato con tecniche statistiche a partire dai dati epidemiologici e da assunti del modello. L’articolo citato sopra è il più recente e robusto metodo per la stima del parametro, ed è attualmente il metodo utilizzato dalla Fondazione Bruno Kessler per fornire i dati alla Cabina di Regia.

Come si legge dalla relazione della Fondazione Bruno Kessler datata 7 dicembre 2020, “per le stime si utilizzano le curve epidemiche dei casi sintomatici organizzati per data inizio sintomi“, per motivi prettamente statistici, è infatti estremamente difficile stimare con precisione la data dell’infezione mentre, avendo una distribuzione di probabilità per l’insorgenza di sintomi, è possibile limitare l’incertezza introdotta nel calcolo[3].

Ora, sempre nella relazione citata, si legge che vanno esclusi dal conteggio quei casi definiti asintomatici, poiché alcuni sistemi informativi regionali richiedono “l’inserimento obbligatorio di una data inizio sintomi anche per i casi asintomatici. “ Ciò può portare ad “escludere casi effettivamente sintomatici in caso di errori di assegnazione dello stato clinico“, aumentando dunque il numero di casi effettivamente conteggiati (Underreporting), tuttavia “Il metodo per la stima di R(t), comunque, è robusto rispetto a tassi costanti di sottonotifica e non c’è ragione di ipotizzare che la frazione di casi sintomatici eventualmente persi per via della definizione adottata possa cambiare nel tempo.“

L’errore introdotto dall’underreporting nel framework utilizzato non influisce sul valore medio di Rt, ma influisce sulla precisione della stima. L’algoritmo di assegnazione dei “colori” prevede che si utilizzi il limite inferiore del range di valori di Rt per definire lo scenario; a parità di Rt medio, con range più ampi ci si può aspettare dunque che la stessa regione venga assegnata ad uno scenario, e quindi ad una zona, a rischio più basso, contrariamente a quello che la prudenza suggerirebbe.

Regione Lombardia e il problema dell’algoritmo

Come si può leggere nella lettera inviata il 26/1 dall’Istituto Superiore di Sanità alla Regione Lombardia, tra maggio e gennaio la Regione ha inviato all’ISS un grandissimo numero di record con data di inizio sintomi a cui non è associato uno stato clinico. Per fare un confronto, mentre mediamente le altre regioni avevano un tasso di record senza stato clinico attorno al 2%, la Lombardia arrivava oltre il 50%.

Ciò ha fatto sì che l’Rt calcolato al 14 gennaio risultasse pari a 1,4, ponendo la regione, in forza dei cambiamenti alle soglie di indice degli scenari di riferimento, in zona rossa.

A seguito di questo la Regione ha dunque apportato le necessarie modifiche ai dati e dal ricalcolo, effettuato il 20/1, è risultato un Rt molto più basso, pari a 0,8.

Qual è, dunque, il problema? Se si controlla il manuale citato nella lettera, si vedrà che la Lombardia è precisamente uno dei casi citati dal rapporto della FBK, ossia di quelle regioni il cui sistema informativo obbliga l’inserimento della data di inizio sintomi, producendo dunque un alto numero di casi sintomatici con errori di assegnazione dello stato clinico.

La figura che segue riporta l’immagine del manuale “Istruzioni per gestione Segnalazioni sMAINF e Cruscotto Sorveglianza” alla sezione 1.3.1 “Scheda segnalazione” pagina 7.

I campi in rosso sono i campi obbligatori.

Non solo, nel procedimento di calcolo si tengono in considerazione anche i casi “non chiusi”, ossia quelli che avendo una data di inizio sintomi non hanno un esito clinico (deceduto o guarito).

Nello stesso manuale esiste anche una sezione “1.4.5. Conclusione di un caso” in cui si fanno espressamente menzione di diversi casi, ossia la chiusura su segnalazione del medico o su segnalazione ATS (tampone negativo). Purtroppo però, come rilevato da Vitalba Azzollini[5], a seguito della circolare di Ottobre 2020 un contagiato poteva considerarsi guarito dopo 21 giorni senza sintomi anche in assenza di tampone negativo. Ciò ha determinato che a ciascun “guarito” non corrispondesse automaticamente una chiusura del caso nel database e di conseguenza, come visto, il numero di infetti effettivamente comunicato settimanalmente fosse enormemente sovrastimato.

Ma ha dell’incredibile il fatto che la situazione fosse nota da tanto tempo. Nella stessa lettera si legge che “da maggio 2020 l’ISS ha inviato 54 segnalazioni di errore, incompletezze o incongruenze alla Regione Lombardia”, indicando espressamente, si evince dal successivo paragrafo, l’assenza del campo “Stato clinico”.

Tutti questi fatti, pare, hanno portato ad una enorme sovrastima del parametro Rt, cui si è posto rimedio soltanto quando è apparso evidente che l’attribuzione delle limitazioni delle regioni a rischio più alto era ingiustificata.

Pubblica amministrazione senza cultura digitale

Lungi dal voler assegnare colpe specifiche, pare evidente che in questo progetto come per molti altri caratterizzati dalla natura prettamente informatica, quali Immuni, il cashback di stato, i vari click day diventati crash day, la pubblica amministrazione abbia dimostrato di adattarsi con estrema fatica ai requisiti organizzativi. I progetti informatici sono spesso progetti complessi che prescindono dalla mera esecuzione di una serie di compiti atti a far funzionare un software; sono piuttosto progetti che coinvolgono l’intero processo di creazione, comunicazione, trattamento delle informazioni e di conseguenza tutti gli aspetti umani ed aziendali, e, ove applicabile, anche degli utenti coinvolti.

Tale mancanza di cultura del progetto digitale acquisisce un’importanza ancor più grande se si considera che nel caso specifico dei dati sanitari sono coinvolte pubbliche amministrazioni che sono indipendenti in forza dell’autonomia regionale, mentre la necessità di una centrale di organizzazione dei dati, l’ISS, richiede un coordinamento a livello sia tecnico che gestionale.

Un buon inizio in questo senso è stato dato dalla piattaforma PagoPA, che ha unificato le interfacce e i framework relativi ai pagamenti; tuttavia anche al fine di limitare il proliferare di soluzioni similari e l’adozione di strumenti uniformi, riutilizzabili, sarebbe auspicabile l’adozione di un framework comune di strumenti, procedure e know how, pur mantenendo libertà e indipendenza a livello di singola amministrazione.

Inoltre, sospetto che esista una errata cultura di quello che è il ciclo di vita di un progetto digitale. Nell’ingegneria dell’informazione raramente i progetti si completano con la realizzazione e l’installazione del software, ma oltre a iniziare ben prima che i coder si siedano alla scrivania per scrivere il codice, si completano ben oltre il deployment dei server in produzione.

E allora che fare?

Un team informatico allertato del problema delle incongruenze avrebbe probabilmente potuto intervenire con una serie di test e diagnosticare subito il problema dell’obbligatorietà della data di inizio sintomi, correggendo velocemente il software e attuando un aggiornamento dei sistemi; inoltre con una rigorosa procedura di verifica dei requisiti e di test funzionali, si sarebbe potuto identificare in anticipo il problema dei guariti-non-guariti evitando un malfuzionamento che ha avuto pesantissime ricadute sulla vita delle persone.

Un primo passo in questo senso è la creazione del Cert-PA, il team di gestione degli incidenti che coinvolgono la sicurezza informatica delle PA, ma estendere un simile concetto agli aspetti relativi alla progettazione e alla manutenzione dei software e dei sistemi sarebbe meraviglioso.

Il processo di crescita passa inevitabilmente attraverso sconfitte ed errori, e in questo anno il mondo digitale della pubblica amministrazione ne ha sperimentati parecchi. Dobbiamo solo sperare che ciò serva a migliorare effettivamente la digitalizzazione del paese.

[1] Anne Cori*, Neil M. Ferguson, Christophe Fraser, and Simon Cauchemez, “A New Framework and Software to Estimate Time-Varying Reproduction Numbers During Epidemics”, American Journal of Epidemiology, September 2013, DOI: 10.1093/aje/kwt133

[2] Si veda sempre Cori et al., Web Appendix 9.

[3] Ibid. Web Appendix 8.

WHITEPAPER
Come si paga con PagoPA e cosa è possibile pagare? Scopri di più
PA
Pagamenti Digitali
@RIPRODUZIONE RISERVATA

Articolo 1 di 4