Open Pronto Soccorsi

In occasione di doversi recare presso un Pronto Soccorso (ovviamente per cose
non gravi, per quelle vale sempre la regola di contattare 112 / 118 …), sulla
base di quali informazioni prendiamo la decisione di dove andare?
Abbiamo delle informazioni disponibili, certe ed aggiornate, che ci possano
guidare nella decisione?
Oppure ci affidiamo all’abitudine (ci “fidiamo” dell’ospedale che conosciamo
meglio, siamo sempre andati in quello, ecc … ), o, peggio andiamo a caso?

Rendere disponibili, ed accessibili, i dati, di numeri e tempi di attesa per
tipologia, dei pronto soccorsi italiani
Dare la disponibilità di tali informazioni in modo aperto, standardizzato e
«machine readable»

Non è una cosa del tutto innovativa: in rete ci sono diverse applicazioni (dai siti
web alle app per smartphone), che offrono queste informazioni, ma per lo più
per zone territoriali limitate o per specifiche Aziende Sanitarie Locali.
Open Pronto Soccorsi prova a farlo sull’intero territorio nazionale usando i dati
disponibili, siano essi open data (o open services …), o sfruttando i siti web che
pubblicano queste informazioni andandoli a “leggere” in tempo reale, in modo
del tutto analogo a come farebbe un utente che acceda al sito stesso
Open Pronto Soccorsi, per quanto funzionante in tutte le sue parti, è
comunque da considerarsi una sorta di “proof of concept” ed esperienza
prototipale e, al tempo stesso, anche un esempio di come non si fanno alcune
cose (mi spiegherò più avanti …).

Open Pronto Soccorsi
usa i dati disponibili
sull’intero territorio
nazionale, siano essi
open data o sfruttando i
dati pubblicati tramite i
siti web:
questi dati ci sono?
quanti sono?
sono uniformemente
distribuiti?

I dati sono distribuiti a macchia di leopardo sul territorio nazionale (242 Pronto
soccorsi censiti …), quindi NON in modo uniforme. Da qui un alcune domande:
 esiste un qualche dispositivo di legge che vincolerebbe (uso il
condizionale …), i proprietari di questi dati a renderli pubblicamente
disponibili (es l’art. 52 CAD)
 Se no … perché?
 Se si …. non è stato uniformemente rispettato e questo è il primo
esempio di come “non” si dovrebbero fare le cose

Esistono anche dati disponibili come «opendata», nel senso di esposti tramite
un portale open data in un formato machine readable, documentati e dotati di
opportuna licenza:
 Regione Lazio: http://dati.lazio.it/catalog/it/dataset/pronto-soccorso-accessi-in-
tempo-reale
Nella realtà, volendo, anche il Friuli Venezia Giulia esporrebbe questi dati in
un formato «machine readable», ma non lo fa in modo ufficiale attraverso un
portale open data.
 Regione Fiuli Venezia Giulia: https://servizionline.sanita.fvg.it/psonline/#/index
La maggior parte dei dati è “contenuta” all’interno di pagine web dei diversi siti
delle aziende ospedaliere locali o degli ospedali (non sono riuscito a recuperare
informazioni relative a quanti sono i comuni che hanno almeno un pronto
soccorso e nemmeno quanti sono in totale di pronto soccorsi in Italia)

Regione Lazio è sicuramente un esempio virtuoso in quanto è l’unico ente che
espone questi dati in modo ufficiale attraverso il suo portale degli open
data, http://dati.lazio.it/catalog/it/dataset/pronto-soccorso-accessi-in-tempo-
reale (con tanto di metadati e licenza d’uso), e lo fa anche poi usando un
portale web usando i medesimi servizi
(https://www.regione.lazio.it/accessiprontosoccorso/?ORDINAMENTO=SA).
Regione Friuli Venezia Giulia, nel suo formato dati, offre anche le coordinate
spaziali di localizzazione del pronto soccorsi quindi un’informazione
sicuramente di maggiore qualità per chi debba poi riusarla. Credo che questo
derivi dal fatto che la Regione Friuli Venezia Giulia ha reso open data i propri
numeri civici georiferiti (rif. http://irdat.regione.fvg.it/consultatore-dati-
ambientali-territoriali/chooseOperation.do ) che poi, a loro volta, sono stati
importati in OpenStreetMap (https://wiki.openstreetmap.org/wiki/Friuli-
Venezia_Giulia/Import_Civici_FVG)

I due esempi virtuosi tuttavia NON offrono le informazioni con le medesima
struttura dati, per quanto ampiamente simili (se vogliamo altro esempio di
come “non” si dovrebbero fare le cose …)
Partendo quindi da questi due casi, ognuno virtuoso per alcuni aspetti, la
prima cosa che ho cercato di fare e provare a rendere omogenea la struttura
dati con la quale distribuire questa informazione.
La struttura, in formato JSON, valorizzata per un caso reale, che
OpenProntoSoccorsi propone è la seguente
http://www.cesaregerbino.it/OpenProntoSoccorsi/API/getProntoSoccorsoDeta
ilsByMunicipality.php?municipality=Torino&distance=0 , quindi un array di
risorse corrispondenti ai singoli pronto soccorsi attinenti ad un determinato
comune italiano, ognuno con i suoi dati di dettaglio (indirizzo, coordinate, ecc ..
), e l’informazione del numero e dei tempi di attesa per ogni singolo livello di
urgenza classico dei pronto soccorsi (bianco, verde, giallo e rosso).

Il grosso del lavoro è stato quindi quello di convertire le diverse fonti dato
disomogenee (in formato e contenuto ..), in una struttura dati omogenea,
esponendola come servizio “machine readable” così da renderla consultabile ed
utilizzabile per poi costruire applicazioni fruitrici che rendessero tali
informazioni direttamente utilizzabili dagli utenti finali attraverso diversi canali
e modalità.

Anche nella modalità con cui è stato fatto questo lavoro ci sono degli aspetti
che evidenziano come “non” andrebbero fatte le cose, e questa volta a carico
mio.
A parte i casi di Regione Lazio e Regione Fiuli Venezia Giulia, la maggior parte
dei pronto soccorsi che pubblicano i loro dati lo fanno attraverso pagine web.
In questi casi non era possibile convertire le informazioni nella struttura JSON
di cui sopra, ma era necessario fare dell’ulteriore lavoro.
La strada adottata (e unica adottabile …), è stata quella di fare dello “scraping”
delle pagine web, andando a “leggere” i dati in esse contenuti e convertendoli
nel formato di cui sopra per rendere il tutto omogeneo e trasparente.

L’adozione dello scraping, seppure a buon fine, non è il modo con cui fare
correttamente le cose:
 perchè lo scraping delle pagine web è un’operazione un pò “borderline”, anche
dal punto di vista delle licenze d’uso. E’ pur vero che, nel caso specifico, la
soluzione adottata NON preleva dati dalle pagine per memorizzarle nel
sistema (non avrebbe senso perchè è un dato che cambia continuamente
…..), ma effettua, “live” una lettura del contenuto delle pagine web in quel
preciso istante e lo ripresenta, in formato diverso (e solo per i dati di interesse
… ), all’utente. Potremmo dire che, per certi versi, si sostituisce all’occhio
dell’utente che altrimenti leggerebbe la pagina del sito web (ma dovrebbe
conoscerne la url .. ), dal suo dispositivo di consultazione. In tale contesto
OpenProntoSoccorsi NON crea o genera nemmeno ulteriore traffico di rete o
carico sui sistemi finali

 lo scraping è una soluzione “debole” e che dipende fortemente dal
mantenimento della struttura della pagina web di origine. Se questa cambia,
anche minimanente, questa modifica può impattare sul risultato dello
scraping, e quindi impedire di recuperare le informazioni generando errori sul
sistema

Il risultato finale è sintetizato in un servizio web che risponde alla seguente url
http://www.cesaregerbino.it/OpenProntoSoccorsi/API/getProntoSoccorsoDeta
ilsByMunicipality.php?municipality=Torino&distance=0 , dove è possibile
modificare il nome del comune e in cui il parametro distance indica, se
valorizzato a zero, che la ricerca viene svolta per i pronto soccorsi che si
trovano all’interno del territorio comunale del comune indicato, altrimenti
permette di fare una ricerca nell’intorno del comune stesso, ad
esempio distance=10000 indica una ricerca nell’intorno di 10 km dal comune
indicato.

Apartire dei servizi di OpenProntoSoccorsi, e per rendere fruibili queste
informazioni, ho provato ad implementare alcune applicazioni di esempio e
precisamente:
 Una web application:
http://www.cesaregerbino.it/OpenProntoSoccorsi/WebApp/OpenProntoSocc
orsiForm.php
 Un’applicazione di web mapping:
http://www.cesaregerbino.it/OpenProntoSoccorsi/WebMapping/OpenPronto
Soccorsi.php
 un bot telegram (OpenProntoSoccorsiBot)

Immettendo il nome del
comune di interesse ed un
raggio di ricerca nel suo
intorno restituisce l’elenco
dei pronto soccorsi con
relative info sui numeri e
tempi di attese per tipologia
(rif. http://www.cesaregerb
ino.it/OpenProntoSoccorsi
/WebApp/OpenProntoSocc
orsiForm.php )

Visualizzare la
distribuzione sul territorio
italiano dei pronto soccorsi
e interrogare
interattivamente i dati del
singolo pronto soccorso
(rif. http://www.cesaregerb
ino.it/OpenProntoSoccorsi
/WebMapping/OpenPronto
Soccorsi.php )

OpenProntoSoccorsiBot:
indicare il nome del comune
di interesse ed un raggio di
ricerca nel suo intorno:
restituisce l’elenco dei pronto
soccorsi con relative info sui
numeri e tempi di attese per
tipologia. E’ anche possibile
indicare la posizione, ed un
raggio di ricerca nel suo
intorno, ed ottenere il
medesimo risultato: in
questo caso il bot permette
anche di avere l’informazione
del percorso per raggiungere
il pronto soccorso di
interesse tra quelli proposti.

L’architettura è la
seguente:
 è ospitato su una
macchina Ubuntu 14.0.4
LTS
 utilizza come database
SQLite3 + Spatialite 4.4.0
 implementa la logica di
business in PHP 5
 si avvale di servizi di
OpenStreetMap, OSM
Buildings, Mapquest e
Google ShortLink

I dati principali utilizzati sono:
 i dati geografici dei comuni italiani
 Per i dati geografici dei comuni italiani la fonte dati è ISTAT:
 https://www.istat.it/it/archivio/124086 (e precisamente lo scarico dei dati in WGS84
UTM32,
quindi http://www.istat.it/storage/cartografia/confini_amministrativi/non_generalizzati/20
16/Limiti_2016_WGS84.zip)
 i dati della localizzazione dei pronto soccorsi italiani
 Per i dati dei pronto soccorsi italiani questo dato non esiste in modalità “open”: alcuni dati
sono su OpenStreetMap ma non tutti quelli che servono
 Una fase preliminare delle attività è quindi stata quella di verificare, puntualmente, se sulla
base dati OSM fosse presente il dato di interesse relativi ai singoli Pronto Soccorsi e, se non
presente, provvedere ad inserire la localizzazione dell’ingresso dei pronto soccorsi

1. Open Pronto Soccorsi: rendere disponibili, ed accessibili, i dati, di numeri e
tempi di attesa per tipologia, dei pronto soccorsi italiani (rif.
https://cesaregerbino.wordpress.com/2018/07/24/open-pronto-soccorsi-
rendere-disponibili-ed-accessibili-i-dati-di-numeri-e-tempi-di-attesa-per-
tipologia-dei-pronto-soccorsi-italiani/)
2. Open Pronto Soccorsi: come è fatto “dentro” (rif.
come-e-fatto-dentro/)
3. Open Pronto Soccorsi: aggiornamento con nuovi dati (rif.
aggiornamento-con-nuovi-dati/)

1. Mail: cesare.gerbino@gmail.com
2. Skype: cesaregerbino
3. Twitter: @CesareGerbino

Open Pronto Soccorsi

Recommended

Recommended

More Related Content

Similar to Open Pronto Soccorsi

Similar to Open Pronto Soccorsi (20)

Open Pronto Soccorsi