Atlante Lombardo Epidemiologico ed Economico dell'Attività Ospedaliera

Abstract

E' finita la prima fase del progetto della Regione Lombardia per la realizzazione di un Atlante Lombardo Epidemiologico ed Economico Ospedaliero, il cui acronimo è ALEE-AO. Questo progetto è frutto della esperienza e competenza del CILEA e della collaborazione con vari enti, come risulta dalla provenienza degli autori del presente articolo. Di seguito si vuole illustrare in cosa consiste questo progetto, quali risultati sono stati conseguiti durante il primo anno di lavoro e gli obiettivi che ci prefiggiamo per la prosecuzione del progetto stesso.

Full text

SANITA'
4BOLLETTINO DEL CILEA N. 80 DICEMBRE 2001
Atlante Lombardo Epidemiologico ed
Economico dell’Attività Ospedaliera
Maurizio Camnasio, Claudia Montalbetti, Alessandro Romussi (*)
Maura Dal Cason (**), Cesare Cislaghi (***), Carlo Zocchetti (****),
Walter Cossutta, Carolina Vastola (*****)
(*) CILEA, Segrate
(**) Consulente Informatico
(***) Università degli studi di Milano
(****) Regione Lombardia – Direzione Generale Sanità
(*****) Lombardia Informatica
Abstract
E’ finita la prima fase del progetto della Regione Lombardia per la realizzazione di un Atlante Lombardo
Epidemiologico ed Economico Ospedaliero, il cui acronimo è ALEE-AO. Questo progetto è frutto della esperienza e
competenza del CILEA e della collaborazione con vari enti, come risulta dalla provenienza degli autori del presente
articolo. Di seguito si vuole illustrare in cosa consiste questo progetto, quali risultati sono stati conseguiti durante il
primo anno di lavoro e gli obiettivi che ci prefiggiamo per la prosecuzione del progetto stesso.
Keywords: Sanità, Statistica, Epidemiologia.
Scopo del progetto
Scopo del progetto è quello di costruire un
atlante epidemiologico ed economico
dell’attività ospedaliera capace di rendere
disponibile ai diversi utilizzatori tutto il
patrimonio informativo oggi disponibile e che
non trova ancora adeguato e sufficiente utilizzo
da parte di tutti coloro che potrebbero ricavarne
indicazioni di indirizzo programmatorio e
valutativo.
La sfida che ci siamo proposti è quella di poter
rendere fruibili tali informazioni via Internet,
implementando anche tutti i moduli necessari
per garantire a tali informazioni un accesso
sicuro e protetto anche in considerazione dei
vincoli posti dalla legge 675/1996 in relazione ai
dati sensibili.
L’innovazione tecnologica del progetto, che
verrà sviluppata soprattutto nella fase
seguente, è la possibilità di lanciare
elaborazioni statistiche personalizzate, accedere
ai risultati intermedi e finali prodotti
utilizzando come interfaccia solamente un Web
Browser.
Utenti naturali di tale sistema sono, oltre agli
appartenenti al gruppo di ricerca, studio e
sviluppo del progetto, le ASL, e i dirigenti delle
strutture ospedaliere
Il progetto nasce dalla collaborazione ormai
consolidata tra il Prof. Cislaghi e il CILEA che
negli ultimi anni ha portato alla realizzazione
di più versioni del progetto, denominato G.I.S.
Mortalità (vedi Bollettini n. 51, 1996 pagg. 27-
35, n. 64, 1998 pagg. 4-12, n. 67, 1999 pagg. 12-
14), alla cui metodologia ci stiamo rapportando
per ALEE-AO.
La prima parte del progetto si è conclusa con
una presentazione dei risultati conseguiti l’8
ottobre 2001, in presenza di tutte le persone
coinvolte e interessate al progetto stesso.
Questo stadio era diviso in 7 fasi.
1. Individuazione di hardware e software
2. Definizione delle informazioni fonda-
mentali necessarie e progettazione della
procedura di caricamento dati
3. Implementazione delle procedure di
caricamento, filtro, controllo.
4. Progettazione e implementazione delle
procedure per la costruzione delle unità
elementari di elaborazione.
5. Fruizione dei dati via Internet: il limite
della mole dei dati trattati.
6. Realizzazione prime semplici statistiche
7. Identificazione delle basi per gli sviluppi
futuri.
Hardware e software

SANITA'
BOLLETTINO DEL CILEA N.80 DICEMBRE 2001 5
La fase iniziale del progetto è servita per
individuare le caratteristiche di hardware e
software necessarie.
La scelta delle caratteristiche hardware è
partita da quelle che il servizio ALEEAO dovrà
fornire:
v Gestione di grossi moli di dati
v velocità nel reperire le informazioni
v velocità di elaborazione (soprattutto in
previsione del successivo sviluppo del
progetto).
v sicurezza nella gestione e nel mantenimento
delle informazioni.
La scelta è caduta su un server UNIX
biprocessore, con almeno 512MB di RAM,
possibilmente espandibile all’occorrenza.
Tutto lo sviluppo del progetto si basa sul
prodotto SAS versione 8 di SAS Institute. La
scelta è stata dettata sia dalla precedente
esperienza legata alla progettazione e
realizzazione dell’Atlante di mortalità italiano,
sia per il fatto che, essendo il presente un
progetto di ricerca, avevamo bisogno di un
ambiente che non fosse di sola gestione e
amministrazione di database, ma che
permettesse anche calcoli di tipo matriciale o la
possibilità di compiere elaborazioni statistiche
avanzate.. Inoltre la possibilità di elaborazioni
dinamiche via Web facevano di questo
ambiente quello che ha le caratteristiche più
idonee allo sviluppo del progetto in essere.
I moduli che serviranno per la successiva
attivazione del servizio sono i seguenti:
v SAS/Connect,
v SAS/BASE
v SAS/GRAPH,
v SAS/INTRNET
v SAS/STAT
v SAS/CONNECT
v SAS/IML
È da considerare la possibilità che nel corso
dello sviluppo delle fasi successive del progetto
emerga la necessità di apportare delle
variazioni alla suite dei moduli segnalati.
La gestione di archivi di dati di notevole
dimensione e la natura statistica del progetto
vengono bene supportati dal modulo
SAS/BASE. Il modulo SAS/IML è stato scelto
grazie alle sue capacità di gestione e di calcolo
su matrici. La necessità di realizzare mappe
trova in SAS/GRAPH un valido strumento. Il
modulo SAS/STAT fornisce degli strumenti utili
per compiere statistiche avanzate.
Il progetto è stato concepito per essere utilizzato
via Web. Per tale motivo si è testato e scelto il
modulo SAS/IntrNet, ovvero una soluzione
dinamica tramite CGI, denominate
Application Dispatcher. Consente agli
utilizzatori di creare applicazioni dinamiche che
permettano agli utenti un accesso alle
potenzialità del software SAS dal loro browser
Web. Fornisce la possibilità di eseguire
qualsiasi programma SAS che possa essere
eseguito in modalità batch. L'Application
Dispatcher consente l’uso di questi programmi a
qualsiasi numero di utenti (indipendentemente
dal fatto che abbiano o meno installato il
software SAS sui loro client).
Definizione delle informazioni fondamen-
tali necessarie e progettazione della pro-
cedura di caricamento dati
In questa fase sono state definite le
informazioni necessarie per lo svolgimento del
progetto, che sono:
a) schede di dimissione ospedaliera (schede
SDO) dei ricoverati in Lombardia per gli
anni 1998 e 1999 (circa 2.100.000
record/anno).
b) SDO di lombardi ricoverati fuori Lombardia
per gli anni 1998 e 1999 (circa 70.000
record/anno).
c) anagrafica assistiti (circa 12.000.000 di
record), comprendenti anche i record delle
variazioni anagrafiche.
Per ognuna di questi input sono stati
individuati gli standard di trasmissione dati e
l’estrazione dei dati necessari per le analisi
successive.
La procedura di caricamento è stata realizzata
in modalità client-server, utilizzando i moduli
SAS/AF, CONNECT, BASE.
La progettazione e la realizzazione della
procedura di caricamento ha avuto come idea
prevalente quella di realizzare un prodotto che
permettesse di valutare anche la bontà dei dati.
Infatti i dati originali vengono controllati,
puliti, aggiornati (come vedremo in seguito), per
ottenere dei dati statisticamente coerenti, e di
queste operazioni viene tenuta traccia e ne
viene data informazione esauriente al gestore
della procedura mediante report ad hoc.

SANITA'
6BOLLETTINO DEL CILEA N. 80 DICEMBRE 2001
Figura 1 - Procedura di caricamento dati
La
procedura di caricamento dati viene eseguita da
un utente privilegiato dotato di un client SAS
con installati i prodotti SAS/BASE e CONNECT
ed eventualmente altri moduli a seconda dei
report che verranno richiesti, soprattutto per
analisi su quelli scartati (perché privi di
informazioni fondamentali per le analisi
successive).
In questa prima fase la procedura ha come
input i dati in formato ascii.
Una ipotesi che si sta valutando è quella di
utilizzare SAS/ACCESS TO ORACLE,
consultando il DataMart dei Ricoveri mediante
una apposita interfaccia dati che si costruirà ad
hoc per le esigenze del progetto.
Il flusso di caricamento parte dalle tabelle di
codifica (la prima volta sono caricate tutte ex
novo, ovviamente). Per gli anni successivi al
primo tali tabelle verranno solo aggiornate.
Successivamente vengono caricati gli
aggiornamenti all’anagrafe.
Solo da ultimo sono caricate le schede SDO
sulle quali vengono compiuti i controlli di
consistenza sui campi necessari per le
elaborazioni successive, oltre ad operazioni più
complesse che verranno illustrate più avanti.
Per la consistenza dei dati, deve esserci un ben
preciso ordine nel caricamento delle
informazioni: prima le tabelle di codifica (per
esempio i comuni, le loro coordinate, le codifiche
delle diagnosi di dimissione…), poi l’anagrafica,
e solo infine le informazioni relative alle SDO.
Per ogni anno di schede SDO, il caricamento
viene fatto al 30 di giugno dell’anno successivo,
in quanto i dati sui ricoveri sono considerati, dai
responsabili del flusso informativo, consistenti
già ad Aprile.
Implementazione delle procedure di
caricamento, filtro e controllo
Nella implementazione di tale sistema, si è
tenuto conto delle problematiche che emergono
dalle fasi successive del progetto.
E’ stato necessario fin da subito definire alcuni
concetti fondamentali riguardanti le variabili
elementari da trattare nella statistica e i
concetti di prevalenza ed incidenza ospedaliera.

SANITA'
BOLLETTINO DEL CILEA N.80 DICEMBRE 2001 7
Le unità elementari che sono state analizzate
e che devono essere utilizzate nelle analisi
statistiche sono le seguenti:
Unità elementare Riaggregazioni
Ricovero Ospedale, comune di
residenza, ASL, medico
di Medicina Generale….
Ricoverato Ospedale, comune di
residenza, ASL, medico
di Medicina Generale….
Caso clinico Ospedale, comune di
residenza, ASL, medico
di Medicina Generale….
INCIDENZA Ospedale, comune di
residenza, ASL, medico
di Medicina Generale….
PREVALENZA Ospedale, comune di
residenza, ASL, medico
di Medicina Generale….
Il tasso di incidenza è la frequenza di persone
che hanno iniziato un processo di ricovero per
una data patologia in quel periodo, per esempio
sul periodo di un anno, rapportato alla
popolazione.
La prevalenza è una percentuale e può essere
calcolata come prevalenza puntuale in un
istante (per i ricoveri utilizziamo un giorno) la
percentuale di abitanti che sono ricoverati ad
una data per una certa patologia.
La prevalenza periodale è la percentuale di
abitanti che hanno avuto almeno un ricovero
per quella causa in quel determinato periodo.
Dopo una prima analisi dei dati, e con
l’obiettivo sopra esplicitato, risultava urgente in
questa fase poter disporre dei dati dell’anagrafe
per risolvere alcuni problemi di incongruenza
riscontrati nelle schede SDO. La mancanza dei
dati anagrafici impediva di utilizzare circa
450.000 schede di dimissione ospedaliera
all’anno, in cui la identificazione dei records
era con codice regionale e non codice fiscale
NON permettendo così di poter compiere le
analisi sopra definite.
A questo punto entravano in tutta la loro
complessità i problemi legati alla privacy su
dati anagrafici e sanitari ( la legge 675/1996 sul
rispetto della riservatezza).
Nel rispetto della legge della privacy è stato
creato mediante un apposito algoritmo un
nuovo codice irriconoscibile che permettesse di
associare i dati delle schede di dimissione
ospedaliera ai dati anagrafici. Con la creazione
di questo codice si svincola tutt’ora il record
‘ricoverato’ dalla sua identità anagrafica.
Sul file con i dati anagrafici originali è stato
necessario effettuare le seguenti operazioni:
• Consistenza sintattica del codice regio-
nale (necessario per l’individuazione del
ricoverato)
• Controllo di validità del campo sesso
(necessario per le elaborazioni statisti-
che)
• Controllo di validità della data di na-
scita
• Controllo di validità del comune di na-
scita
• Controllo di validità del codice fiscale
• Creazione del codice fiscale per quei
record che ne sono privi, prevedendo
anche la creazione di un codice fiscale
tronco con comune di nascita fittizio.
• Validità del campo “stato”. Più
precisamente il campo stato
(D=deceduto, A=attivo, E=emigrato,
C=cancellato, T=trasferito) risulta di
fondamentale importanza per la
definizione della popolazione assistita.
Infatti, per l’analisi del ricoverato e del
caso clinico è necessario sapere quali
sono gli individui esposti a rischio
di essere ricoverati a carico della
Regione Lombardia. Si è convenuto
che sono quei soggetti che, nall’anagra
fe_lombardi hanno lo stato valorizzato
come A (=Attivo).
• Creazione del campo flag_CF che
misura ‘la bontà’ del campo codice
fiscale, secondo le seguenti regole:
Flag_cf=0 mancante o sbagliato (posto
da noi a blank) Flag_cf=1 originale e
sintatticamente valido Flag_cf=2
calcolato completo Flag_cf=3 calcolato
tronco (con comune di nascita fittizio).
• Applicazione del blind code, basato su
un algoritmo proprietario e da noi
costruito ad hoc per il progetto.
Viene così creato il dataset sas che contiene un
record per ogni assistito e che deve essere
annualmente aggiornato.
Per la progettazione delle procedure di
riorganizzazione delle schede SDO è stato
necessario analizzare preventivamente i dati al
fine di permettere una individuazione molto

SANITA'
8BOLLETTINO DEL CILEA N. 80 DICEMBRE 2001
efficiente delle unità elementari definite in fase
di analisi, tra le quali il ricovero e il ricoverato.
Per l’identificazione del ricoverato si sono dovuti
risolvere alcuni problemi soprattutto legati alla
non univocità del codice identificativo: sono
stati identificati record diversi, riconducibili
allo stesso paziente ma con codici individuali
diversi (codice regionale o codice fiscale), oppure
record riconducibili allo stesso paziente ma con
sesso diverso o età diversa.
Più laborioso è stato il caricamento delle SDO
relative ai lombardi ricoverati fuori regione, in
quanto è stato necessario un intenso lavoro di
pulizia e di normalizzazione delle informazioni:
partendo da file MS-Access, forniti direttamente
dalla Regione Lombardia, sono stati costruiti
dei file di testo con tracciato record analogo a
quello delle SDO dei ricoverati in Lombardia. E’
stato poi necessario implementare un modulo di
caricamento dedicato.
In entrambi i casi è stata applicata la procedura
per creare un linkage statistico tra queste
informazioni e l’anagrafe degli assistibili.
Tale operazione si traduce nella valorizzazione
del seguente flag:
tip_abb al file delle SDO (tipo abbinamento
all’anagrafe)
•1=abbinabile all’anagrafe con codreg
•2=abbinabile all’anagrafe con codfisc
•3=abbinabile all’anagrafe con codfisc calcolato
tronco
•4=non abbinabile
Mediante questo flag è possibile misurare in
ogni momento la ‘bontà’ della corrispondenza
scheda SDO-ricoverato
E’ importante segnalare che, una volta attivato
il linkage statistico, le informazioni
fondamentali (sesso, comune di residenza, ecc.)
vengono prese dall’anagrafica e ‘sostituite’ a
quelle esistenti sul file SDO.
Abbiamo così raggiunto il primo obiettivo:
quello di poter associare univocamente le
schede SDO all’anagrafica. In numeri questo
significa che per il 1998 abbiamo ottenuto un
abbinamento schede SDO – anagrafe degli
assistibili pari al 96,72%, e ancora migliore
risulta la situazione per il 1999 dove
l’abbinamento raggiunge quasi il 98,00%.
La procedura di caricamento così strutturata
produce in output dataset di informazioni,
codifiche e dataset sommarizzati atti ad essere
input della procedura fruibile via Internet di
analisi di tali dati, il vero cuore di tutto il
progetto.
Fruizione dei dati via Internet: il limite
della mole dei dati trattati
La procedura Internet realizzata ha la seguente
struttura:
• Modulo di selezione temporale;
• modulo di selezione geografica;
• modulo di selezione nosologia;
• modulo di selezione statistica (oggetto
dello stadio 2 del progetto)
Vi è la possibilità di scegliere se compiere tale
selezione prendendo come punto di vista quello
dell’azienda ospedaliera o quello del comune di
residenza del paziente.
Tralasciando per il momento l’impostazione
grafica, che è comunque uno dei punti del
futuro eventuale sviluppo del progetto,
illustriamo brevemente i problemi incontrati in
questa fase.
Per esempio la figura 2 mostra il bacino di
utenza di due ospedali selezionati.
Nonostante siano state applicate tutte le
tecniche di indicizzazione e ottimizzazione del
database, i tempi di risposta via Internet
risultavano ancora alti, anche tenendo conto
della numerosità delle informazioni in gioco.
Infatti abbiamo a che fare con più di 2.000.000
di record di schede SDO per anno e con una
anagrafica di circa 12.000.000 di unità
elementari di elaborazione (nati e morti
compresi).
Realizzazione prime semplici statistiche
Per visualizzare le prime semplici statistiche
abbiamo dovuto anche costruire le prime
procedure di interrogazioni modulari, in modo
che il loro tempo di elaborazione fosse
compatibile con i vari time-out imposti dal
sistema descritto nella figura 3.
In questo modo i moduli di selezione temporale,
geografico, e nosologico sono stati corredati di
semplici statistiche che descrivono l’insieme
delle SDO selezionate.
Nonostante questo, con una struttura come
quella descritta in figura 3, spesso si incorreva
in problemi di time-out.

SANITA'
BOLLETTINO DEL CILEA N.80 DICEMBRE 2001 9
Figura 2 - Esempio di bacino d’utenza di due aziende ospedaliere
Figura 3 - Schema fruizione dei dati via Internet inizialmente adottato

SANITA'
10 BOLLETTINO DEL CILEA N. 80 DICEMBRE 2001
Figura 4 - Nuovo schema indagato
Basi per gli sviluppi futuri
Per lo sviluppo della procedura via Internet
siamo giunti alla conclusione che un atlante
flessibile come quello ipotizzato sia ottenibile
solo implementando Query totalmente flessibili
su dati originali (SDO ed ANAGRAFE
SANITARIA) in modalità ‘batch’, con
salvataggio dei risultati intermedi.
Questo necessita una pesante ingegnerizzazione
della procedura, con definizione delle sessioni
utente e di zone ‘personalizzate’, definite sul
server.
Più in dettaglio, una procedura pienamente
flessibile e atta alle esigenze del cliente avrà i
seguenti vantaggi e i seguenti svantaggi.
Vantaggi
• È possibile lanciare una elaborazione
complessa;
• NON è necessario attendere ‘in linea’ la
risposta, ma ci si può scollegare;
• Si possono salvare e riutilizzano i
risultati intermedi: ci si può ricollegare
in un secondo momento per analizzare il
risultato e, partendo dal risultato
precedentemente ottenuto, lanciare
un’altra elaborazione;
• si mantiene traccia delle elaborazioni
effettuate: le elaborazioni intermedie
possono essere mantenute, in modo che
possano essere riutilizzate come nuovo
punto di partenza per ulteriori
elaborazioni.
Svantaggi
• È necessaria la gestione della
definizione di ogni nuovo utente
(necessaria la figura di un
amministratore del sistema);
• spazio disco e definizione delle
caratteristiche dell’utente al momento
dell’inserimento o al momento della
ingegnerizzazione del sistema allo scopo
di distribuire in modo ragionevole le
risorse del sistema;
• si affida all’utente finale, che è un
utente ad alto livello, la responsabilità
di mantenere ordine nelle proprie
informazioni.
Su questo è stato sviluppato un servizio con i
prodotti SAS, al momento installato sul server
del CILEA e raggiungibile via Internet solo se
precedentemente autorizzati dal nostro sistema
di sicurezza interno.
Questa risulta essere la base per lo sviluppo
dello stadio 2 del progetto, basato sulla
tecnologia mostrata nella figura 4 e illustrata
ai committenti durante la riunione di
conclusione lavori tenutasi presso la Regione
Lombardia l’8 ottobre 2001.