OpenDataSicilia

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

Posted by GABA on
URL: http://opendatasicilia.195.s1.nabble.com/opendatasicilia-Progetto-f8-una-proposta-per-tutte-le-ASP-del-territorio-dati-Comune-di-Bagheria-tp7087p7113.html

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.

On Wednesday, 31 March 2021 at 22:50:11 UTC+2 cirospat wrote:
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
------------------------




Il giorno mer 31 mar 2021 alle ore 20:50 Dennis Angemi <[hidden email]> ha scritto:
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

Il giorno mer 31 mar 2021 alle ore 18:19 andy <[hidden email]> ha scritto:
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

--
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 [hidden email].
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/opendatasicilia/CAHEdGZN3dajK3uT3WK-QN1dfoYgdLTpTAOm4jH2Aje0Oxj35xQ%40mail.gmail.com.

--
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 [hidden email].

--
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 [hidden email].
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/opendatasicilia/79774ac6-3f43-45d4-a07a-0aa3e653efb1n%40googlegroups.com.
Free forum by Nabble Edit this page