Algoritmi e noi: così la Lombardia poteva evitare la “zona rossa” | Agenda Digitale

ontologia del lockdown

Algoritmi e noi: così la Lombardia poteva evitare la “zona rossa”

L’errore che ha portato la Lombardia a finire in zona rossa è stato provocato da un fallimento semantico nello scambio dei dati epidemiologici tra la Regione e l’Istituto Superiore di Sanità. Si poteva facilmente evitarlo adoperando uno schema concettuale condiviso e software già in uso. Vediamo come

28 Gen 2021
Guido Vetere

Università degli Studi Guglielmo Marconi

Per molti giorni, milioni di persone residenti in Lombardia sono state sottoposte a restrizioni di contenimento della pandemia Covid-19 più severe di quelle avrebbero dovuto essere. Si tratta di un fatto di gravità inaudita, anche solo per gli aspetti economici, ai quali tra l’altro gli amministratori di quella Regione prestano molta attenzione. Come poi si è chiarito, questo colossale errore è stato causato da un fallimento semantico nello scambio dei dati epidemiologici tra la Regione e l’Istituto Superiore di Sanità (Iss). Evitarlo sarebbe stato molto semplice e alla portata di un’amministrazione quale quella lombarda.

Integrazione dei dati della PA, all’origine del problema lombardo

Spiace dirlo, tra l’altro, ma situazioni di questo tipo erano ampiamente prevedibili, avendo a che fare col problema dell’integrazione dei dati, problema nel quale la Pubblica Amministrazione si strugge da decenni. Se n’è parlato anche qui.

WHITEPAPER
La guida definitiva al lavoro resiliente. Tutto cambia, soprattutto sul lavoro: non restare indietro
Digital Transformation
Risorse Umane/Organizzazione

Sulla dinamica della vicenda si può consultare un fact checking di Pagella Politica. A quanto pare, nel dataset (un file XML, sembra di capire derivato da un foglio di calcolo) che la Lombardia trasmetteva periodicamente mancavano “data di inizio sintomi” e “stato clinico” associati ai casi positivi. «La compilazione di tali campi» – si legge – «non è obbligatoria, ma rimane necessaria se si vuole ottenere una valutazione il più possibile accurata e standardizzata della situazione epidemiologica del territorio. Ciò è dovuto ai criteri secondo i quali viene effettuato il calcolo dell’indice Rt nel monitoraggio settimanale dell’Iss».

Pur nella loro incompletezza, i dati venivano processati, in quanto le lacune venivano colmate per congettura, cioè ritenendo che i pazienti censiti fossero sintomatici by default, il che poi falsava il calcolo dell’indice Rt. Sembra infatti che un caso sia classificato come sintomatico se “stato clinico” ha valore “sintomatico”, “severo”, “critico” o qualche altra lugubre dicitura, ma anche quando è soltanto nota la data di inizio sintomi e il campo è vuoto. Viene in mente quello sketch di Marco Marzocca in cui un grottesco funzionario pubblico diceva: «i casi sono tre: è possibile, non è possibile, è impossibile», ma qui si va ben oltre: il dato (o la sua assenza) viene interpretato in un modo diverso da come lo intende (anche omettendolo) chi lo fornisce. Come volevasi dimostrare, il problema ha una natura semantica, cioè relativa all’interpretazione, a come si stipula tra le parti e come si implementa nel sistema.

È interessante che problema fosse noto e segnalato, come si legge in una lettera pubblicata dal Fatto Quotidiano: «Caro, ti ricordo il problema dei vostri dati con data inizio sintomi e mai uno stato clinico a conferma di questo». Il tono confidenziale fa pensare a qualcuno che chiede ad un amico di mandargli le foto della vacanza in alta risoluzione perché le vuole stampare. Di mezzo, invece, c’è la vita delle persone. Il regime di lockdown che i lombardi hanno subito è frutto dell’atavica carenza nella gestione della semantica dei dati essenziali per il funzionamento delle amministrazioni, una carenza che è tutta riassunta in un quel “Caro amico”.

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

Tutto il sistema è colpevole

Nella caccia al colpevole, la Regione Lombardia è l’Istituto Superiore della Sanità si sono accusati reciprocamente. Senza entrare in questa discussione, si può dire, con spirito bipartisan, che il sistema è colpevole nel suo complesso. Quando una coppia litiga, il problema è nella relazione. E per essere ancora più magnanimi, si può dire che la carenza semantica nella gestione dei dati pubblici ha origini costituzionali, in particolare nel regime delle autonomie locali. Questo caso ne fornisce un esempio da manuale.

Tuttavia, anche nell’oggettiva difficoltà di implementare un piano nazionale per l’integrazione semantica dei dati che realizzi in qualche modo le previsioni dell’AgID, qualcosa di più si deve fare subito, e si può fare con poco.

La soluzione: uno schema concettuale condiviso

Quando si ha a che fare con uno scenario distribuito, cioè uno in cui i dati sono prodotti da una pluralità di sorgenti autonome, una semplice regola che è quella di fare il possibile per codificare le convenzioni di interpretazione in uno schema concettuale condiviso, così che vi sia la massima corrispondenza tra le intenzioni di chi legge e quelle di chi scrive. Questi schemi concettuali si chiamano ontologie, e da più di vent’anni il consorzio W3C promulga standard per supportarle. La circostanza non è affatto ignota alla Pubblica Amministrazione, che di ontologie ne ha un intero repertorio.

Dato un modello concettuale condiviso, il problema si riduce a mettere in piedi una base di conoscenza centralizzata (in questo caso, verosimilmente, presso l’Iss) nella quale caricare i dataset prodotti dalle Regioni, con opportune verifiche di integrità e completezza. Beninteso: queste verifiche si potrebbero fare anche su un dataset XML, ma nel caso in cui qualche sorgente pubblichi dati incompleti rispetto ad una concettualizzazione formalizzata e stipulata, si può fare qualcosa di più convincente che scrivere una letterina. Per formalizzare il fatto che un paziente debba avere un determinato stato clinico in una certa data basta veramente poco.

Una base di conoscenza fatta sullo stampo di qualche ontologia si può modernamente chiamare Knowledge Graph. Il software per gestirle esiste, è facile ed è anche molto spesso open source. Nella PA, non mancano esperienze di basi di conoscenza fatte così, ad esempio nel settore dei Beni Culturali. Non ci sono veramente scuse.

@RIPRODUZIONE RISERVATA

Articoli correlati