Progetto f8: una proposta per tutte le ASP del territorio + dati Comune di Bagheria

167 views
Skip to first unread message

GABA

unread,
Mar 26, 2021, 9:18:54 AM3/26/21
to opendatasicilia
Ciao a tutti, è per me una piacevolissima sorpresa scoprire il vostro progetto! Lo scorso Ottobre 2020 ho sviluppato un sistema CRUD per la gestione dei dati relativi ai pazienti positivi al COVID per il distretto ASP 39 (Bagheria, Santa Flavia, Casteldaccia, Ficarazzi, e Altavilla). Mio padre è un dipendente ASP ed era rimasto da solo a dover gestire la situazione, senza alcun framework nè training offerto dalle istituzioni...
Visti i metodi rudimentali che venivano utilizzati, e le sue lunghe ore lavorative fuori orario, ho deciso di regalargli questo sistema, sviluppato con Backpack for Laravel, che è attivo ormai da diversi mesi, ed è stato molto importante per la gestione dei dati, qualche statistica, date dei tamponi e anche l'individuazione di focolai e indirizzi per la gestione dei rifiuti speciali, e le comunicazioni dei dati al pubblico da parte dei Comuni interessati.

Il gestionale, chiamato f8 (letto faith, o anche fate), ha delle restrizioni di accesso esclusivo per i membri dell'ASP e non è raggiungibile dall'esterno...ma giusto una decina di giorni fa ho creato una specie di ponte per il pubblico, per comunicare i dati direttamente alla popolazione, senza dover necessariamente passare dai giornali, o dal Comune, per la città di Bagheria (il paese in cui attualmente vivo).

Questo è il link: https://f8lite.vercel.app 

Credevo di essere il solo ad offrire il mio lavoro volontariamente a supporto della causa...non vedo l'ora di poter scoprire di più riguardo opendatasicilia ed esplorare eventuali possibilita' di collaborazione!

Tenuto conto dei recenti messaggi scambiati sul canale Telegram, è emersa l'esigenza di implementare uno schema unico per la gestione dei dati, a fine di analisi statistica veritiera, ed eventuali previsioni per il futuro. F8 è un sistema che è nato dal basso, con l'intenzione di aiutare tutte le ASP in difficoltà in questo periodo di transizione. Confermo la mia totale disponibilità a fornire il gestionale a tutti gli enti che possano averne bisogno, e apertura a consigli e suggerimenti per rendere la piattaforma più utile, per tutti.

In allegato uno screenshot della dashboard di f8Resoconto al 26_3_2021, 14_10_11.png

Ciro Spataro

unread,
Mar 26, 2021, 10:53:40 AM3/26/21
to opendatasicilia

ciao Gaba
chiunque tu sia, sono sicuro che oggi nel 2021 le medaglie di cavaliere del lavoro dovrebbero essere date a persone come te, per il lavoro che hai svolto, in assenza di strumenti dell'ASP (ente pubblico) idonei alla situazione da fronteggiare.
Complimenti per il lavoro!
Le persone della comunità opendatasicilia ci arricchiremo nel confronto che avremo con te.
Benvenuto (o benvenuta?) nella comunità più stimolante che c'è in Italia sul tema #dati #open.
E grazie per questa interessantissima condivisione.
Fossi il presidente della Repubblica oggi ti avrei messo una medaglia al petto, solo per "come" hai raccontato il tuo lavoro!

Ciro Spataro



--
Sito: http://opendatasicilia.it
Facebook: https://www.facebook.com/groups/opendatasicilia/
twitter: http://twitter.com/opendatasicilia
Gruppo Telegram: https://t.me/opendatasicilia
---
Hai ricevuto questo messaggio perché sei iscritto al gruppo "opendatasicilia" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a opendatasicil...@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/opendatasicilia/39063813-4a10-474c-a2ac-46b3f34951e2n%40googlegroups.com.

Dennis Angemi

unread,
Mar 26, 2021, 12:52:13 PM3/26/21
to opendat...@googlegroups.com
Ciao Gabriele,
ti rinnovo i miei complimenti sia per l'iniziativa che per il risultato finale. Per quanto riguarda la proposta alle ASP - sicuramente @aborruo sta escogitando un piano d'azione - io potrei facilmente arrivare al direttore sanitario dell'ASP di Enna. Attendo istruzioni in merito.

Un abbraccio a tutti/e

Il giorno ven 26 mar 2021 alle ore 14:18 GABA <gab...@gmail.com> ha scritto:
--

Nino Galante

unread,
Mar 26, 2021, 2:29:23 PM3/26/21
to opendatasicilia
Caro Gabriele,
come ti avevo anticipato su Telegram, aspettavo l'apertura di questo thread per chiederti qualche informazione ed esporre qualche mia osservazione.

Come già ti accennavo, risalgono all'anno scorso i tentativi di Open Data Sicilia di dialogare con la Regione Siciliana per ottenere dati di dettaglio sulla pandemia a livello provinciale e comunale; tentativi che sono stati avviati con una prima lettera aperta, alcuni articoli pubblicati sul nostro blog, inframezzati da attività sui social ma anche offline, fino ad arrivare giusto nei giorni scorsi ad una seconda lettera aperta e al racconto della bella esperienza di Regalbuto (trovi tutto qui); in mezzo ci trovi anche l'adesione della nostra comunità alla campagna #datiBeneComune, lanciata a livello nazionale dall'associazione onData, e a cui hanno aderito ad oggi quasi cinquantamila persone e parecchie, più di 170, organizazioni di vario tipo (associazioni, comunità, testate giornalistiche e televisive, ecc.), e la crescente consapevolezza anche da parte di alcuni sindaci dell'importanza di disporre di dati epidemiologici a livello comunale e anche, come nel caso di grandi città come Palermo, di dati riguardanti i singoli quartieri.

Sapevamo già da tempo che la Regione Siciliana, dopo alcuni mesi di gestione che potremmo definire "artigianale", si era dotata di un sistema di raccolta dei dati provenienti dalla periferia, anche per rispondere all'obbligo di alimentare quotidianamente quel grande database che eroicamente, sin dall'inizio della pandemia, il Dipartimento della Protezione Civile rende disponibile a tutti noi con i dati pandemici aggregati a livello nazionale e per ogni singola regione. Svolgendo, tra l'altro, quel ruolo importantissimo di rendere tali dati comparabili tra loro e facilitando in tal modo il confronto tra i dati nazionali e quelli delle singole regioni e tra regione e regione. Il livello di dettaglio dei dati provinciali resi disponibili dal Dipartimento della Protezione Civile è purtroppo limitato al solo totale_casi (da cui l'unico altro valore che si possa ricavare è soltanto quello dei nuovi_positivi) ed è appunto dal bisogno di colmare questo vuoto informativo, che riguarda le più piccole realtà provinciali e comunali, che nasce la richiesta di dati di maggior dettaglio.

Visto ora che tu hai avuto modo di conoscere bene il sistema regionale siciliano che raccoglie i dati e visto che hai trovato il modo di filtrarne alcuni per renderli pubblici, volevo chiederti se secondo te è semplice implementare un sistema che rispetti lo schema adottato dal Dipartimento della Protezione Civile per i dati nazionali e regionali, in modo da renderli con loro comparabili. In altre parole, visto che i dati che la Regione trasmette al Dipartimento devono rispettare quella struttura, mi chiedo se sia o meno complicato rispettarla (e ottenere quindi quel tipo di output) anche per i dati provinciali, di distretto sanitario e comunale. Ad esempio l'anno scorso, con un'attività totalmente manuale, noi di Open Data Sicilia abbiamo alimentato un dataset con i dati provinciali che venivano pubblicati dalla Regione; questo ha permesso di colmare in parte quella lacuna sui dati provinciali di cui ti dicevo (ma è stato possibile farlo fino al 22 giugno, ultimo giorno in cui sono stati resi disponibili) e ha permesso di renderli comparabili con i dati nazionali e regionali. Oggi le sporadiche iniziative che consentono solo per poche realtà di avere dati di dettaglio a livello subregionale, spesso utilizzano termini tra loro difformi per individuare alcuni valori epidemiologici, difformi anche da quelli raccomandati dal Dipartimento di Protezione Civile, contribuendo in questo modo ad aumentare la confusione e a ridurre la comprensione del loro corretto significato.

La seconda questione che ti pongo è se, secondo te, con le conoscenze che hai avuto modo di maturare al Distretto ASP 38, pensi che si possa mettere in piedi un sistema che acceda lecitamente e senza violare la privacy al sistema di raccolta regionale e consenta di filtrare i dati dell'intera regione per esporli suddivisi per provincia e per comune (auspicabilemente secondo il suddetto schema del Dipartimento della Protezione Civile).

Ancora complimenti :)

N.

GABA

unread,
Mar 26, 2021, 6:24:47 PM3/26/21
to opendatasicilia
Caro Nino,
Grazie per i numerosi spunti, che mi hanno spinto giù per la tana del bianconiglio alla ricerca di incongruenze tra i dati provinciali, e quelli regionali.
Sinceramente non avevo idea del progetto del Dipartimento della Protezione Civile, clonato ed esaminato il repository, e dopo una breve consulta con mio padre, ecco alcune considerazioni a riguardo.

Per prima cosa, il distretto ASP39, fonte dei dati del progetto f8, ha accesso solo ad alcuni dei dati richiesti dallo schema indicato dalla Protezione Civile.
Lo schema che f8 segue, creato più per necessità diretta per l'organizzazione dati, sono i seguenti:

["id","nome","dob","indirizzo"]: dati sensibili ed accessibili solo al Sindaco, e allo staff sanitario.
["ric","dim","lib"]: booleans per lo stato di "Ricoverato", "Dimesso", e "Liberato". (Liberato è un termine inventato da mio padre che si riferisce a tutti i Negativi + i Positivi che non sono più in quarantena domiciliare.)
["stato"]: esito paziente: Positivo/Negativo/Deceduto
["dt1","et1","dt2","et2","dt3","et3","dt4","et4"]: date ed esiti di ciascun tampone, utile per calcolare l'incidenza giornaliera e la data di guarigione di un paziente. La data e' visualizzata in arancione per i tamponi positivi, e verde per quelli negativi. Formato: Date/boolean.
["ddec"]: data di decesso per pazienti in 'stato: "Deceduto"'. E' sulla data di decesso che e' derivabile il dato comulativo, e giornaliero dei decessi.
["comune","note"]: stringhe che contengono il comune di residenza del paziente, ed eventuali note.

Ci sono delle incongruenze e mancanze di dati in relazione allo schema fornito dalla Protezione Civile. Ciò è spesso causato dalla mancanza di comunicazione da parte degli ospedali, ai distretti di residenza dei pazienti.
Soprattutto per quanto riguarda lo stato di ricovero, la presenza o meno di sintomi, e gli stati di decesso. I dati che il distretto raccoglie, spesso tramite indagine personale e chiamate ai parenti dei pazienti per controllare il proprio stato, sono spesso ignorati dagli altri distretti che, non avendo un sistema che faciliti la raccolta dei dati, si limitano a comunicare il numero dei positivi totali alla Provincia.

Ma come fa la Regione ad ottenere quei dati, e quali sono i dati che potremmo fornire?

["ricoverati_con_sintomi","terapia_intensiva","totale_ospedalizzati","ingressi_terapia_intensiva"]
La comunicazione di questi attributi avviene direttamente tra gli ospedali e la Regione. Ma ci sono, nello specifico, alcuni ospedali che comunicano il numero di ricoverati alle ASP (ad esempio l'ospedale di Termini Imerese). Si presuppone che un paziente ricoverato sia comunque sintomatico, e il totale degli ospitalizzati sarebbe deducibile, in caso avessimo anche il numero dei pazienti in terapia intensiva. Al momento risultano solo "Ricoverati". La mancanza di comunicazione tra gli ospedali e i distretti sanitari potrebbe portare a dati parziali, o inaccurati. L'unico modo sarebbe quello di accedere ai dati Regionali, o di consentire ai distretti di ricevere pronte comunicazioni sugli esiti dei pazienti ricoverati. O, nel caso di mio padre, indagare personalmente, chiamando gli ospedali, e i parenti di quei pazienti che risultano ricoverati da molto tempo, per scoprire l'esito della loro condizione. Un metodo un po' all'antica, nato da necessita', e decisamente inclinato a potenziale inaccuratezza.

["totale_positivi_test_molecolare","totale_positivi_test_antigenico_rapido","tamponi_test_molecolare","tamponi_test_antigenico_rapido"]
I dati che la ASP39 riceve sono relativi solamente ai test molecolari positivi, non teniamo conto nè dei tamponi rapidi, nè dei primi tamponi negativi.
Quindi essenzialmente, ogni entità nel database, per essere ritenuto con 'Stato: "POSITIVO"' è necessariamente un paziente che è risultato Positivo al primo tampone molecolare. Nel caso in cui il paziente ripetesse il tampone e risultasse negativo, allora la data del tampone negativo viene registrata, e il paziente passa ad uno "Stato: Negativo".

["dimessi_guariti"]
Derivabile dallo stato "dim"&&"Stato:"Negativo"

["isolamento_domiciliare"]
Derivabile da tutti i Positivi - Liberati Positivi

["deceduti"]
Derivato dallo stato: Deceduto, previa comunicazione della data di decesso da parte dell'ospedale, dei familiari, o da parte del Sindaco.

["totale_casi", "totale_positivi", "casi_testati"]
Il totale casi è essenzialmente il totale di tutti i pazienti registrati al sistema. Gli attuali positivi sono da noi calcolati da totale_casi-deceduti-negativi-liberati_positivi
Nel nostro caso, il totale_casi e i casi_testati corrispondono allo stesso numero di pazienti. Poichè sono registrati su f8 solo i pazienti positivi al primo tampone molecolare.

["tamponi"]
Derivabile dalla somma di (t1+t2+...tn), ma non rientrerebbero i primi tamponi negativi. I tamponi negativi sono da noi calcolati solo nel caso in cui il paziente abbia avuto almeno un tampone positivo in precedenza.

["variazione_totale_positivi","nuovi_positivi"]
Questo dato non è registrato direttamente sul nostro database, ma calcolato all'occorrenza dalla Dashboard. Questa è una mancanza che ho sottovalutato, ma che potrebbe essere risolvibile in due modi:
1) La dashboard ha una funzione per fare screenshots giornalieri, che vengono mandati al Sindaco giornalmente, che potrei recuperare..
2) Ho una tabella che tiene conto di tutti i cambiamenti di stato raggruppati per ID. Probabilmente potrei calcolare i cambiamenti giornalieri con un algoritmo in Python.
..) in ogni caso facilmente implementabile fin dall'inizio, nelle nuove installazioni.


Essenzialmente credo di capire che i problemi maggiori su cui si possa lavorare siano:
1) Implementare un sistema standard per la raccolta dei dati, da fornire ad ogni distretto, e che rispetti lo schema fornito dal Ministero.
2) Assicurarsi che gli ospedali comunichino con i distretti, poichè al momento la Regione sembra essere l'unico ente ad avere tale autorità.

Questo se consideriamo lo scenario "interno verso l'esterno", scenario che reputo efficace, meno immediato, ma sicuramente più consapevole ed accessibile ad ogni provincia, comune e distretto; in un certo senso, restituendo il diritto di gestione dei dati alle piccole realtà, verso le grandi istituzioni.

Andando alla tua seconda domanda, qualora la Regione aprisse alla possibilità di analizzare i propri dati (approccio "esterno verso l'interno"...o anche magari approccio "middle-man"),
qualora usassero un qualsiasi sistema con supporto SQL, si potrebbe creare un CRON che faccia un mysqldump ogni mezzanotte (o altro orario conveniente), esportando la tabella dati per singola provincia/regione, poi usando Python per sistemare il dataset con i dati essenziali, e al termine dello script cancellare il file sorgente, e pushare i risultati direttamente sul Git del Ministero.
Il sistema dovrebbe idealmente essere messo in sicurezza e consentire solo le Incoming e Outcoming connections essenziali, un pò come ho blindato F8 per rifiutare ogni Incoming da qualsiasi IP che non sia quello dell'ufficio ASP di competenza. 

Questo è parte dell'approccio che utilizzo, con Python, per filtrare i dati dal database principale di f8, a f8lite. Dove viene presa in considerazione solo l'incidenza giornaliera, poi raggruppata per data in R. Sto attualmente lavorando al sistema CRON in modo tale che la conversione dei dati avvenga in maniera automatica e pushata sul Git di f8lite.

Snippet di esempio per estrarre l'incidenza giornaliera:
    import pandas as pd
    import csv
    import os
    url = './input/positivi.csv' //carica il dump dal db
    df = pd.DataFrame(data, columns = ["comune","dt1","et1"]) //seleziona le colonne necessarie
    f1 = df.loc[(df['comune'] == scope) & (df['dt1'].str.len()>1) & (df['et1'] == "POSITIVO")] //solo persone di un determinato comune, con primo tampone positivo
    f2 = f1.sort_values(by=['dt1']) //ordina per data tampone
    out = pd.DataFrame(f2, columns = ["dt1"]) //nuovo dataframe
    out.to_csv (r'./output/ind_'+scope+'.csv', index = False, header = True, quotechar='"', quoting=csv.QUOTE_NONNUMERIC) //esporta il csv
    os.remove(url) //cancella il dump originale

Dennis Angemi

unread,
Mar 28, 2021, 6:47:06 AM3/28/21
to opendat...@googlegroups.com
Buona domenica a tutti e a tutte!
A Regalbuto la situazione è abbastanza tragica: 3% della popolazione attualmente positiva. Risultato? Stanotte non riuscivoo a dormire e vi pensavo (della serie: la notte porta consiglio). 

Non riesco ancora a concepire il fatto che il lavoro di Gabriele non sia utilizzato e replicato ovunque. Di seguito vi riporto alcune elucubrazioni nottetempo originate.

Premetto che io non ho idea di cosa siano tecnicamente F8, CRUD (e tutti gli altri termini bellissimi utilizzati da Gabriele) tuttavia inviterei Gabriele, con la speranza che non sia una richiesta impossibile da realizzare, ad elaborare un sistema che permetta di estrarre più dati "da aprire" possibili. Mi riferisco ad esempio ai dati contenuti nella dashboard il cui screenshot viene inviato al sindaco con frequenza giornaliera: totale casi, nuovi casi, attualmente positivi, tamponi molecolari, tamponi rapidi... insomma tutto ciò che siamo abituati a vedere a livello nazionale e che manca a livello locale.

Dopo aver implementato in f8 questo sistema che restituisca gli open data di cui andiamo a caccia, direi di preparare una bella richiesta da inviare a tutte le ASP siciliane. (Esiste un'anagrafica come quella per le scuole in cui vengono raccolti tutti gli indirizzi email delle asp?)

---Template richiesta---

Oggetto: a gift for you

All'attenzione del SysMan 
Ciao bro! Ti scrivo per regalarti (?) un sistema di gestione dati per l'emergenza COVID. Non puoi rifiutarlo.
------

M1nch1@tə a parte (è colpa di Borruso e Paola se uso parolacce eh), credete sia possibile inviare delle mail alle asp con le quali si propone la sostituzione del loro sistema di gestione dati (sperando ne abbiano uno) con uno sviluppato appositamente per facilitarne l'immissione (sto sparando), la trasmissione (sto sparando) e la pubblicazione (sto sparando) dei dati? A quanto ho capito F8 è anche abbastanza userfriendly e questo potrebbe giocare a nostro favore. 

La favola che ho inventato si conclude così:
- Tutte le asp accettano F8;
- dagli F8 di ogni asp si genera giornalmente un csv;
- si raccolgono i csv

TADAA, come per magia abbiamo i dati covid siciliani con un livello di dettaglio impressionante!

Vi chiedo sinceramenge scusa se ho scritto delle cose non corrette, termini errati, idee irrealizzabili. Aspetto critiche, insulti, opinioni, feedback.

Un abbraccio a tutti/e <3

GABA

unread,
Mar 28, 2021, 8:51:37 AM3/28/21
to opendatasicilia
Ciao Dennis buona domenica!
Devo ammettere di avere dei grossi limiti per quanto riguarda spiegare le cose in maniera semplice, work in progress :)
In pratica l'acronimo CRUD sta per "Create/Read/Update/Destroy", queste operazioni sono di solito quelle più usate sui database a sistema SQL (come MySql ad esempio). Laravel (un bellissimo framework per PHP) ti permette di creare delle entità particolari, con delle determinate proprietà, come nome, cognome, data tamponi etc...Si possono quindi creare pazienti, leggerli, aggiornare i dati, o cancellarli. Ho sviluppato f8 partendo da Backpack for Laravel, il che rende la creazione di modelli molto semplice e flessibile. Backpack è open-source, tuttavia ci vuole una licenza per l'utilizzo in progetti gratuiti, che deve essere dimostrata. Sono in contatto con il creatore di Backpack per cercare di capire se possiamo estendere la mia licenza a tutte le potenziali istituzioni che potrebbero usare f8, o se una nuova licenza si deve ottenere per ogni istanza. Ad ogni modo, la sfida corrente è quella di adattare i dati allo schema ufficiale della protezione civile. Ci sto lavorando, avevo creato un bottoncino per fare gli screenshots, ora ne ho creato uno per fare un dump .csv, e sto lavorandoci per estrarre solo i dati essenziali dalla dashboard, che potremmo poi ulteriormente processare in Python con un CRON (uno script che parte ad una determinata ora). Teoricamente, dumpando la dashboard non sarebbe necessario nemmeno il filtro per non selezionare i dati sensibili, perchè nella dashboard ci sono solo i dati statistici. Con Python potremmo poi magare calcolare le differenze tra alcuni campi di giorno in giorno, per adattare lo schema a quello ufficiale e derivarne le variazioni.

In questo modo potremmo tenere lo schema interno pazienti, già esistente, per la gestione del database, e proporne uno per comuni, e distretti. Sto lentamente lavorando sui dati a nostra disposizione per comune, per poi cumulare quelli di distretto. Vedi Esempio.
Vista la mancanza del bottoncino dumpCsv nell'istanza del distretto di Bagheria, probabilmente mi ci vorrà più tempo per completare i dataset, ma partendo da zero in distretti che ancora non hanno implementato il sistema, il bottoncino per generare il csv potrà tenere conto di tutte le statistiche per ogni giorno, senza grossi grattacapi.

Ora, un piccolo problemino semantico riguardo la raccolta dei dati: i dati verrebbero raccolti per (data tampone, data ricovero, data dimissione etc...) o vengono raccolti per data di immissione dati? E quali dati il distretto riuscirebbe a recuperare, quali sono più necessari di altri? Ad ogni modo, implementata la funzionalità del csv, e previa approvazione di licenza da parte del team Backpack, potrei fornire un pacchetto pronto con le mie modifiche sotto forma di docker container, cosi da renderlo deployable un pò ovunque, l'importante è che ci sia una macchinina con supporto per Docker, PHP etc. Noi al momento stiamo usando una istanza free su AWS, ma ogni tanto singhiozza con il suo single core e 1GB di ram, con un volume di più di 4000 positivi...quindi la soluzione che avrei in mente sarebbe quella di tenere una istanza per distretto, anche per questioni di sicurezza e privacy.

Ad ogni modo, la tua favola è davvero splendida, ed è un pò anche il mio sogno: ogni rivoluzione che parte dal basso mi affascina molto, e credo nell'utilizzo della tecnologia per liberare i popoli, più che controllarli. La notte porta consiglio!
Mi rimetto al lavoro, e confermo la mia disponibilità a dare una mano, anche due, per quel che posso.

GABA

unread,
Mar 29, 2021, 7:09:30 AM3/29/21
to opendatasicilia
Dopo qualche ora di smanettamento e mapping tra PHP e Javascript, ho implementato una funzione dump direttamente dalla Dashboard, in questo modo i dati sensibili non vengono mai considerati, ma vengono estratti solo quelli statistici.
Ecco il bottoncino sulla Dashboard, ho usato un vecchio backup in locale, ancora non l'ho testato in produzione.....
dumpCsv.png
Al momento dumpa un array di oggetti in formato JSON, di giorno in giorno dovrebbero esserci diversi valori, la cui sottrazione potrebbe aiutarci a derivare le variazioni. Ancora su quello non ci ho lavorato, ma aspetto che passino un paio di giorni per vedere le differenze. Ad ogni modo, ecco l'output con i dati recuperabili per comune:

dpc-covid19-ita-pa-39-20210323.json

[

  {

    "data": "2021-03-23T10:59:15.668Z",

    "distretto": "39",

    "codice_comune": "082006",

    "denominazione_comune": "Bagheria",

    "lat": "38.078918",

    "long": "13.512365",

    "ricoverati_con_sintomi": null,

    "terapia_intensiva": null,

    "totale_ospedalizzati": "16",

    "isolamento_domiciliare": "185",

    "totale_positivi": "201",

    "variazione_totale_positivi": null,

    "nuovi_positivi": null,

    "dimessi_guariti": "1919",

    "deceduti": "85",

    "totale_casi": "2205",

    "tamponi": "4350",

    "casi_testati": "2205",

    "note": null,

    "ingressi_terapia_intensiva": null,

    "note_test": null,

    "note_casi": null

  },

  {

    "data": "2021-03-23T10:59:15.668Z",

    "distretto": "39",

    "codice_comune": "082067",

    "denominazione_comune": "Santa Flavia",

    "lat": "38.082460",

    "long": "13.527580",

    "ricoverati_con_sintomi": null,

    "terapia_intensiva": null,

    "totale_ospedalizzati": "3",

    "isolamento_domiciliare": "83",

    "totale_positivi": "86",

    "variazione_totale_positivi": null,

    "nuovi_positivi": null,

    "dimessi_guariti": "528",

    "deceduti": "11",

    "totale_casi": "625",

    "tamponi": "1296",

    "casi_testati": "625",

    "note": null,

    "ingressi_terapia_intensiva": null,

    "note_test": null,

    "note_casi": null

  },

  {

    "data": "2021-03-23T10:59:15.668Z",

    "distretto": "39",

    "codice_comune": "082035",

    "denominazione_comune": "Ficarazzi",

    "lat": "38.089272",

    "long": "13.468910",

    "ricoverati_con_sintomi": null,

    "terapia_intensiva": null,

    "totale_ospedalizzati": "9",

    "isolamento_domiciliare": "61",

    "totale_positivi": "70",

    "variazione_totale_positivi": null,

    "nuovi_positivi": null,

    "dimessi_guariti": "522",

    "deceduti": "4",

    "totale_casi": "596",

    "tamponi": "1237",

    "casi_testati": "596",

    "note": null,

    "ingressi_terapia_intensiva": null,

    "note_test": null,

    "note_casi": null

  },

  {

    "data": "2021-03-23T10:59:15.668Z",

    "distretto": "39",

    "codice_comune": "082023",

    "denominazione_comune": "Casteldaccia",

    "lat": "38.053730",

    "long": "13.529670",

    "ricoverati_con_sintomi": null,

    "terapia_intensiva": null,

    "totale_ospedalizzati": "4",

    "isolamento_domiciliare": "26",

    "totale_positivi": "30",

    "variazione_totale_positivi": null,

    "nuovi_positivi": null,

    "dimessi_guariti": "328",

    "deceduti": "15",

    "totale_casi": "373",

    "tamponi": "751",

    "casi_testati": "373",

    "note": null,

    "ingressi_terapia_intensiva": null,

    "note_test": null,

    "note_casi": null

  },

  {

    "data": "2021-03-23T10:59:15.668Z",

    "distretto": "39",

    "codice_comune": "082004",

    "denominazione_comune": "Altavilla Milicia",

    "lat": "38.042100",

    "long": "13.549010",

    "ricoverati_con_sintomi": null,

    "terapia_intensiva": null,

    "totale_ospedalizzati": "8",

    "isolamento_domiciliare": "81",

    "totale_positivi": "89",

    "variazione_totale_positivi": null,

    "nuovi_positivi": null,

    "dimessi_guariti": "269",

    "deceduti": "7",

    "totale_casi": "365",

    "tamponi": "696",

    "casi_testati": "365",

    "note": null,

    "ingressi_terapia_intensiva": null,

    "note_test": null,

    "note_casi": null

  }

]

Dubbi? Suggerimenti?
Grazie a tutti.


GABA

unread,
Mar 30, 2021, 4:41:10 AM3/30/21
to opendatasicilia
Piccolo aggiornamento: i dati disaggregati del distretto39 li trovate qua: https://github.com/gabacode/f8lite/tree/main/dati-distretto39
Ogni sera esporto il JSON e lo do in pasto a questo scriptino per calcolare le differenze e aggiornare i files https://github.com/gabacode/f8lite/blob/main/utilities/json2csv.py

GABA

unread,
Mar 31, 2021, 9:26:05 AM3/31/21
to opendatasicilia
I dati dei comuni di Bagheria, Santa Flavia, Ficarazzi, Casteldaccia, e Altavilla Milicia sono liberamente accessibili su https://covid19.totel.it

andy

unread,
Mar 31, 2021, 12:19:01 PM3/31/21
to opendatasicilia
Buonasera a tutte/i,
mi dispiace non essere stato presente in questo thread. Sono giorni per me intensi.

Però questo mi dà l'opportunità di guardarmi il percorso, che in un viaggio è spesso la cosa più bella.

Trovo di gran valore come il tempo dedicato da Gabriele al suo progetto, dopo uno scambio qui, e diventato un progetto che pubblica dati secondo uno schema "standard". 

Mi vengono in mente queste cose:
  • i dati per essere aperti, se prodotti non da Pubblica Amministrazione, devono essere associati a una licenza. Gabriele se aggiungi questo file nella cartella dati, completi il giro. È questa ed è una delle possibili licenze aperte "specializzate" per i dati. Chiunque userà questi dati potrà usarli a qualsiasi scopo con il solo obbligo di citare la fonte. Mettere una nota sulla licenza dei dati anche nella root del repo;
  • segnalerei questo tuo lavoro, con una nuova issue sul repo della protezione civile https://github.com/pcm-dpc/COVID-19/issues;
  • farei un blog post sul lavoro che hai fatto. Perché è una buona pratica e può creare emulazione, per fare sapere sempre di più che questi dati ci sono. Se vuoi, il blog di ODS è a disposizione e dovunque lo pubblicherai lo faremo girare nei nostri spazi con piacere;
  • se hai dati brutti o falsi in ingresso, ci saranno anche nella tua applicazione. Le ragioni per cui siano "brutti" possono essere enne. Se sono inservibili - e forse il giudizio che conta è quello di tuo padre - la app e i dati aperti diventano inutile. Ma se ho capito bene non siamo a questo punto;
  • i comuni su cui hai lavorato hanno dati che molti comuni di Italia si sognano.
Mi piacerebbe creare un unico punto di ingresso per avere una sorta di indice dei dati comunali, ma per farlo bene, per fare in modo che sia utile, ci vuole un po' di lavoro.
Io sino a fine aprile non sono messo bene.

Gabriele bel lavoro!


--
___________________

Andrea Borruso
website: https://medium.com/tantotanto
38° 7' 48" N, 13° 21' 9" E, EPSG:4326
___________________

"cercare e saper riconoscere chi e cosa,
 in mezzo all’inferno, non è inferno, 
e farlo durare, e dargli spazio"

Italo Calvino

Dennis Angemi

unread,
Mar 31, 2021, 2:50:18 PM3/31/21
to opendat...@googlegroups.com
Buonasera a tutti e tutte!
So che è oggi è stata una giornata pesante e non vi chiedo questo altro sforzo :).
Raccogliendo i suggerimenti di @aborruso, ho iniziato a scrivere un tracciato record (si chiama così?) che si potrebbe utilizzare come schema standard comunale, attingendo da dpc e da Gaba. Una volta completato e da voi approvato lo utilizzerò per uniformare anche i dati di Regalbuto. Trovate tutto nel google sheet allegato. Le mie domande sono le seguenti:
  • Sono essenziali tutti questi campi o andrebbero bene anche solo il codice_comune e denominazione_comune? 
    stato
    codice_regione
    denominazione_regione
    codice_provincia
    denominazione_provincia
    sigla_provincia
    codice_comune
    denominazione_comune

  • Ho inserito (alla fine) un campo che noi a Regalbuto utilizziamo (e credo sia abbastanza importante) ovvero contatti_stretti per indicare tutte quelle persone che sono interessate da provvedimenti di quarantena ma non sono positive. (Così facendo si potrebbe calcolare il totale delle persone attualmente in quarantena eseguendo la somma tra isolamento_domiciliare + contatti_stretti). Pensate anche voi possa essere utile? Lo lasciamo?
Ovviamente siete liberi (anzi, invitati) a modificare qualsiasi cosa non appena avrete 5 min.

Complimenti per oggi!
Un abbraccio a tutti e tutte e uno particolare per @aborruso che è distrutto

Dennis

--
Sito: http://opendatasicilia.it
Facebook: https://www.facebook.com/groups/opendatasicilia/
twitter: http://twitter.com/opendatasicilia
Gruppo Telegram: https://t.me/opendatasicilia
---
Hai ricevuto questo messaggio perché sei iscritto al gruppo "opendatasicilia" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a opendatasicil...@googlegroups.com.

Ciro Spataro

unread,
Mar 31, 2021, 4:50:11 PM3/31/21
to opendatasicilia
ciao @Dennis,
su una cosa mi sono soffermato nella bozza di tracciato record che hai condiviso, 
ci sono dei records come:
  • totale_positivi
  • nuovi_positivi  (totale_casi giorno corrente - totale_casi giorno precedente)
Quello che penso io è che:
ogni giorno nelle varie strutture sanitarie il personale si dovrebbe ritrovare davanti ad un software in cui (ripeto) ogni giorno inserisce dati.
Quindi il campo in cui deve fare data entry dovrebbe essere riferito a dati solo di OGGI!
Totale_positivi oppure nuovi_positivi secondo me sviano l'attenzione dal dato di OGGI.
Totale_positivi è un aggregazione e quindi non è un dato atomico.

I dati da inserire ogni giorno dovrebbero essere atomici, riferiti solo ad OGGI. Poi il software effettua automaticamente statistiche, somme, infografiche, cazzi mazzi e ramurazzi! Ma l'analisi è una seconda parte del lavoro, che il software fa automaticamente a valle della raccolta dati.

Il software unico da usare negli ospedali, negli hub di vaccinazione, ovunque si faranno tamponi e vaccinazioni, negli ospedali in cui si cureranno malati di covid e  si assisterà a morti di covid, dovrà avere un'interfaccia con campi in cui fare data entry del tipo:
  • sito (menù a tendina in cui scegli ospedale, o sito hub vaccinazione/tamponi)
  • nome, cognome, email, tel., residenza del tamponato - data entry continuo nelle 24 ore
  • nome, cognome, email, tel., residenza del vaccinato   - data entry continuo nelle 24 ore  
  • esito del tampone (menù a tendina: positivo o negativo)  - data entry continuo nelle 24 ore  
  • numero ricoverati di oggi in terapia non intensiva (il numero dei dimessi il software li calcola automaticamente per differenza tra presenze di ieri e oggi ma non è un dato per il quale fare data entry)  - data entry unica volta ad una certa ora del giorno, orario uguale per tutte le regioni  
  • numero ricoverati di oggi in terapia intensiva  - data entry unica volta ad una certa ora del giorno, orario uguale per tutte le regioni    
  • numero di deceduti di oggi per covid - data entry unica volta ad una certa ora del giorno, orario uguale per tutte le regioni    
  • ecc....
Questa bozza stupida di schema dati è per capire:
  1. che c'è bisogno di un minimo di regole per la gestione del data entry in un unico software (web service accessibile da pc connesso a internet con accesso via credenziali) che le strutture sanitarie aventi a che fare col covid dovrebbero usare. Cioè l'inizio del processo di gestione del dato, solo l'inizio!
  2. che i dati vanno raccolti atomicamente e non per somme o aggregazioni. L'aggregazione e analisi dei dati è demandata ad automatismi software.
NOTA SULLA DATA: 
la data di riferimento dei dati inseriti non è un dato da inserire, perchè è il software che ogni giorno dalle 00.00 alle 24.00 associa data ad ogni dato immesso.

NOTA SULLA IMMODIFICABILITÀ DEL DATO:
I dati immessi in un software non dovranno essere modificabili, manipolabili.
Solo nome, cognome, tel, email, residenza potrebbero essere modificati per correggere errori in fase di data entry, ma i dati sui tamponi effettuati, esiti di tamponi, morti, terapie intensive/sub intensive, vaccini,  sono dati che una volta immessi quotidianamente non dovrebbero essere modificabili per struttura del software stesso. E' lì che non permetti la manipolazione del dato, con il software che usi. Fin tanto che i dati saranno inviati come allegati in formato pdf, xlsx, docx di email da ente a ente, ci saranno manipolazioni, c'è poco da fare.
Per ora solo queste riflessioni che ritengo un punto di partenza per la raccolta dati. Poi la fase di analisi dati è un altro mondo a parte. Ma se non si parte bene con la raccolta dati giornaliera, brancoleremo sempre nel buio siderale.
Credo sia una criticità nazionale e non solo nostra siciliana.

Scusa la lunghezza
ciro
------------------------




GABA

unread,
Apr 1, 2021, 6:39:40 PM4/1/21
to opendatasicilia
Grazie Andrea per il feedback riguardo la piattaforma e spunti di riflessione riguardo le licenze. Ho lasciato la licenza del portale a GPLv3, e aggiunto le licenze per i dati a CC BY 4.0. Una issue (1123) è stata aperta sul repo del Dipartimento della Protezione Civile, riassumendo brevemente la questione. Come citato brevemente nei post precedenti, i dati ricevuti dall'ASP del nostro distretto sono in generale accurati, ma spesso non c'è molto dettaglio riguardo gli esiti dei ricoverati, e il numero dei pazienti in terapia intensiva. La mancata comunicazione tra gli ospedali e i distretti, rende i dettagli di quest'ultimi non completi, in quanto sembra che molti ospedali comunichino solo con la Regione, e spesso il recupero dei documenti riguardo i ricoveri e i decessi, sono frutto di personale investigazione, e di collaborazione tra i Sindaci dei Comuni, e i familiari dei pazienti. Non è sempre così, ma è un fenomeno ricorrente. A scanso di equivoci, come consigliatomi da Nino Galante, ho contestualizzato i dati dei ricoveri sotto il campo "totale_ospedalizzati", e i dati dei "casi_testati", essendo solo dati di tamponi positivi molecolari con esito positivo, corrispondono infine al "totale_casi". Sarebbe davvero l'ideale avere un unico punto di ingresso per tutti i dati comunali, e di distretto. Potete contare sulla mia massima disponibilità, nei limiti del possibile, sarebbe grandioso mettere su un team di sviluppo che possa dedicarsi ad un sistema che comunichi univocamente.

Dennis, lo schema che hai proposto mi sembra ottimo. Aspettiamo un eventuale responso dal DPC per capire cosa ne pensano. Effettivamente il numero dei contatti stretti è importante, è un dato che non teniamo per il distretto39 poichè entrano nel sistema solo i pazienti positivi a tamponi molecolari. Quindi, vengono inseriti i familiari, e i contatti stretti, solo nel momento in cui anch'essi risultino positivi ad un tampone molecolare. Lo schema del DPC però deriva il "totale_positivi"  dal numero ospedalizzati + isolamento domiciliare, considerandoli come "attuali positivi". Non sempre i contatti stretti risultano positivi, questo è un dato che andrebbe chiarito ulteriormente.

Ciro, per quanto riguarda l'atomicità del dato, sono d'accordo con te. Credo che sia i positivi, che i guariti, che i ricoverati, che i deceduti, debbano essere contati per data tampone, ricovero, e decesso, più che per data di inserimento. Ma questo comporterebbe anche un ritardo importante, conta che l'aggiornamento del primo Aprile per il distretto39 riguarda gli esiti tamponi fino al 30, e 31. Sulla chart di incidenza giornaliera di f8lite tengo conto delle date tamponi, ma credo i report ufficiali siano basati sulle date di inserimento. Non trovo alcun modo possibile per cui i dati ufficiali possano contenere gli esiti dei tamponi relativi al giorno stesso, visto che già arrivano all'ASP dai laboratori con 1-2 giorni di ritardo (e nei mesi passati, a volte anche con 5 giorni di ritardo). Credo non ci siano indicazioni a riguardo, ma qualora ci siano, mi piacerebbe molto trovarle. Per quanto riguarda la immodificabilità del dato, penso che fin quando i data entry saranno manuali, il margine di errore sarà sempre elevato. E' anche capitato di aver inserito una data tampone errata, giorno e mese esatti, ma anno precedente, un fenomeno che però è stato osservato solo 3 volte su 8833, sul nostro sistema. Sarebbe possibile rendere i dati "immutabili" dal lato client, ma penso che fin quando ci saranno degli umani addetti al data-entry, poter rimediare ad un errore di battitura, in modo veloce, sia una funzione importante. A quel punto è comunque necessario rendere accontabile il motivo di tale modifica, il nome dell'utente che ha modificato il dato, e in quale data, tramite tabella di revisione. Per quanto riguarda i dati dei "nuovi_positivi" contati per data tampone, e quindi riferiti alla data di oggi (ieri) li ho resi disponibili qui, mentre quelli per data di inserimento si trovano qui. E' possibile notare l'incongruenza, terrò aggiornate entrambe le versioni giornalmente, in attesa di ulteriori riscontri da parte del DPC.

Ciro Spataro

unread,
Apr 3, 2021, 2:25:01 AM4/3/21
to opendatasicilia
Gabriele
Grazie dei dettagli forniti.
Ci aiutano a comprendere meglio. Avremo opportunità di approfondire l'argomento.
Grazie per il tuo tempo.
Ciro

<scusa la brevità, rispondo da mobile>

Giuseppe Ragusa

unread,
Apr 9, 2021, 3:03:51 AM4/9/21
to opendat...@googlegroups.com
Buongiorno,
sto provando a risintonizzarmi e torno un attimo sul tema. Mi rivolgo in primis a Gabriele ma ovviamente sempre a tutti

Solo una domanda secca: Che tu sappia, alla luce di quello che leggo, quanto vale quindi questa circolare che dispone circa la registrazione obbligatoria giornaliera dell'esito dei tamponi da parte di tutti i laboratori regionali?

Vale nessuna mazza? una mazza, due o più mazze?

Giuseppe



GABA

unread,
Apr 12, 2021, 2:39:02 AM4/12/21
to opendatasicilia
Ho preso qualche giorno per indagare un minimo e cercare di capirne qualcosa. Se questo sistema funzionasse sarebbe un'ottima cosa. Sulla carta, dovrebbe funzionare, fino a prova contraria. Ma, come indicato precedentemente, mio padre non ha accesso a quella piattaforma, i dati dei pazienti gli vengono inviati via email sotto forma di PDF singolo per ogni paziente, quindi non abbiamo modo di esserne certi.

Giuseppe Ragusa

unread,
Apr 12, 2021, 2:42:26 AM4/12/21
to opendat...@googlegroups.com
Grazie Gabriele,
si conferma l'assurdità. Si potrebbe cercare di capire se effettivamente i vari laboratori lo usano giornalmente.

Giuseppe

Reply all
Reply to author
Forward
0 new messages