Testo della relazione

Progetto di “Informatica Medica”
matricola 640926
Introduzione
Questo progetto, si pone l’obiettivo di illustrare le funzioni che l’Ufficio Relazioni con il
Pubblico (d’ora in poi URP), realizza all’interno di una grande struttura (nel mio caso
un’Azienda Ospedaliera), concentrandosi successivamente, sul processo di informatizzazione
ed elaborazione dei dati raccolti dall’URP stesso, come vedremo, tramite questionari compilati
dal cittadino-paziente (che chiameremo d’ora in poi “utente”).
L’elaborato è stato diviso in due parti: la prima parte, di tipo teorico, definisce l’URP
attraverso le leggi dello Stato Italiano, individuando tre aree di interazione con l’utente:

l’area di informazione del cittadino;

la gestione dei reclami;

la “customer satisfaction”.
Nella seconda parte, di tipo pratico, analizzerò due classi di software per l’office
automation: i software commerciali ed i software open source.
Infine, dopo aver definito il tipo di problema progettuale assegnatomi, illustrerò i programmi
che ho creato, volti a risolvere semplici problemi di carattere informatico. Progredendo nella
discussione, non verranno esclusi anche brevi accenni sul tipo di linguaggio impiegato nello
sviluppo dei suddetti programmi.
Prima di concludere questa breve introduzione, è bene tener conto, che la mia
relazione, con i relativi programmi implementati, non si propone di essere la risoluzione ottima
e generale per l’informatizzazione di un ufficio ma, ha il solo obiettivo di fornire una descrizione
del problema, fornire delle ipotesi di risoluzione ed elaborare una soluzione ad “hoc” che
secondo me era più adatta alla situazione.
Ciò significa, che mentre la prima parte “teorica e generale”, descrive lo stato di fatto di un
URP e quindi può essere considerata generale (a meno di modifiche sostanziali nella
legislazione Italiana a riguardo), la seconda parte al contrario, è una soluzione personale che,
può benissimo essere migliorata in futuro, con altre tecnologie.
Cavenaghi Mattia
1
Progetto di “Informatica Medica”
matricola 640926
Parte prima – L’Ufficio Relazioni con il Pubblico (URP)
Cos’è l’URP?
Prima di dare una nozione su che cos’è l’URP, è opportuno individuare le caratteristiche
generali che un ufficio amministrativo deve possedere; per essere il più precisi in questo breve
itinerario, ci avvarremo di alcune, tra la moltitudine delle Leggi Italiane inerenti a questo
argomento, senza tralasciare di descrivere le attività che un ufficio deve svolgere.
La Legge Italiana, individua tre principali entità:

l’ufficio;

i documenti;

il personale.
La parola ufficio, secondo il Lessico Universale Italiano dell’Istituto della Enciclopedia
Italiana Treccani, assume significati diversi, ma ciò che a noi interessa, corrisponde alla
definizione: “Complesso di impiegati che, in una propria sede, svolgono ciascuno una
determinata attività, affine e coordinata alle altre e all’organo stesso di cui essi ne fanno
parte”.
La prima traccia, per ricostruire giuridicamente il percorso di
istituzione dell’ufficio amministrativo, la si può individuare nella Legge
n°241, del 7 Agosto 1990 con la quale, si designa un’unità amministrativa
(l’ufficio per l’appunto) costituita da un dirigente (o funzionario) e dei
dipendenti che dipendono da esso, i quali tutti insieme, formano il
personale.
Scorrendo tale Legge, si ritrovano gli articoli a cui ogni ufficio, deve stabilire
il proprio campo di competenza; in sostanza, deve definire il tipo di
procedimenti, chiamati istruttorie che intende amministrare, con il relativo
tipo di documenti (basti pensare alle differenze che intercorrono tra un
ufficio legale, un ufficio acquisti ed un ufficio del personale)
Inoltre, in tale unità amministrativa, durante un’istruttoria, deve essere assegnato ad essa un
membro del personale che ne sarà il responsabile e provvederà a concluderla entro i tempi
stabiliti da tale Legge, cioè 30 giorni dall’avvio del procedimento amministrativo.
Infine, l’utente può richiedere all’ufficio il quale ne detiene la custodia, il rilascio di copie (su
pagamento del solo costo di riproduzione ed eventuale marca da bollo) o la visione (gratuita)
di un determinato documento, ma solamente presentando valide motivazioni.
Con l’avvento della Direttiva del Presidente del Consiglio dei Ministri dell’11 Ottobre
1994, vengono ufficialmente istituiti gli Uffici Relazione con il Pubblico (URP) i quali devono
presentare alcune caratteristiche, al fine di rendere al meglio l’accessibilità e l’interazione tra il
personale e l’utente.
In particolare, viene posta maggiore attenzione sulla formazione del personale dell’URP,
definendone i processi di qualificazione che il personale deve sostenere ed relativi i titoli di
studio che deve possedere; tali norme, verranno generalizzate anche agli altri uffici, grazie al
Decreto del Presidente della Repubblica n°422 del 21 Settembre 2001.
Ma è stato solo grazie alla Legge n°150 del 7 Giugno 2000 con la quale si rendono gli
URP obbligatori e gli uffici, vengono “informatizzati”, ossia possono avvalersi di mezzi di
comunicazione di massa, quali internet e la pubblicità, per la diffusione delle informazioni agli
utenti ed impiegare strumenti tecnologici ed informatici per elaborare le informazioni a loro
preposte.
Successivamente, viene eliminato il “burocratese”, ossia la barriera culturale che divide
la burocrazia e l’utente, favorendo la chiarezza, la semplicità e la sinteticità ma al tempo stesso
garantendo la completezza e la correttezza dell’informazione fornita al cittadino-utente.
Avendo ora acquisito tutte le nozioni necessarie alla nostra presentazione, quali ufficio,
documenti e personale, possiamo dire che l’URP è: “l’ufficio preposto a coordinare le attività di
tutela e di informazione agli utenti, nell’ambito di un’azienda o ente (sia pubblico che privato)”.
Cavenaghi Mattia
2
Progetto di “Informatica Medica”
matricola 640926
Le attività dell’URP
L’attività svolta all’interno di un URP può essere sintetizzata con un unico termine:
comunicazione; sempre grazie al Lessico Universale Italiano, ritroviamo tale parola come
sinonimo di: “far parte”, “rendere noto”, “partecipare”, “trovarsi in contatto”, “relazionare”,
“accomunare”. Possiamo quindi identificare l’atto comunicativo come: “il processo in cui due
soggetti, si mettono in relazione”.
Tale processo è in realtà, un entità più complessa, i cui elementi costituitivi sono:
 l’obiettivo: ossia le finalità che si vogliono ottenere compiendo il processo di
comunicazione.
La fase di definizione degli obiettivi è molto importante, poiché quest’ultimi, devono
essere coerenti alle esigenze degli utenti;
 l’emittente (o fonte) ed il ricevente (o destinatario): sono i soggetti che compiono l’atto
comunicativo, entrambi hanno differenti caratteristiche, le quali influenzano la
comunicazione.
Solitamente, è opportuno fare degli studi approfonditi sul tipo di emittente e
destinatario che si vogliono coinvolgere in tale relazione;
 il messaggio: è l’oggetto della comunicazione che deve presentare un certo contenuto
ed una determinata forma. Anche il messaggio deve essere studiato, in modo da
renderlo conforme agli obiettivi, ai soggetti e come vedremo, al canale di
comunicazione;
 i canali di comunicazione: sono i mezzi con cui l’emittente invia il messaggio
al
ricevente. Come per i precedenti elementi, anch’esso deve essere studiato, in base al
contesto in cui verrà impiegato;
 l’ascolto: è un processo in cui si verifica che il messaggio sia stato recepito, compreso e
sia soddisfacente ai bisogni del destinatario.
Non bisogna infine dimenticare, che l’atto comunicativo ed ogni elemento incluso in
esso, devono essere coerenti al contesto in cui vengono impiegati, ciò significa che se viene
messo in atto un uso illecito od errato di uno qualsiasi degli elementi appena descritti, ossia al
di fuori del campo specifico per cui sono stati studiati, potrebbero sorgere dei problemi di
comprensione tra i due soggetti comunicanti.
L’informazione del cittadino
Il Decreto Legge n°163 del 12 Maggio 1995, istituisce
obbligatoriamente per tutti gli Uffici dell’Amministrazione
Pubblica, la Carta dei Servizi, ossia uno strumento di
informazione del cittadino, redatto sulla base di schemi generali
di riferimento che, per il settore sanitario, è stato adottato con la
Direttiva del Presidente del Consiglio dei Ministri del 19 Maggio
1995.
La Carta dei Servizi, che l’URP è tenuto a mettere a disposizione
dei propri utenti, descrive le finalità, i modi, i criteri e le strutture
attraverso cui il servizio ospedaliero viene attuato, inoltre
permette l’informazione del cittadino sui diritti, i doveri e le
procedure che ha a sua disposizione all’interno di esso.
Tale documento, si basa inoltre, sull’articolo 3, 30, 33 e 34 della Costituzione Italiana la quale
sancisce e tutela il rispetto dei principi di uguaglianza, di imparzialità e di tutela della dignità
della persona, inoltre vieta ogni forma di discriminazione basata sul sesso, sull’appartenenza
etnica e sulle convinzioni religiose, infine impegna tutti gli operatori e la struttura pubblica nel
rispetto di tali principi.
Cavenaghi Mattia
3
Progetto di “Informatica Medica”
Il procedimento di redazione e divulgazione della Carta
principalmente in quanto riportato nel seguante nel seguente schema:
matricola 640926
dei
Servizi,
consiste
Figura 1 - Il processo di redazione della Carta dei Servizi
(1) Raccolta ed analisi delle esigenze di comunicazione dei cittadini: in questa fase,
attraverso opportuni strumenti, si cerca di individuare le carenze inerenti al processo
informativo, che spesso porta all’instaurarsi di un certo disagio tra l’utente e l’Azienda
Ospedaliera.
Gli strumenti maggiormente impiegati sono:

i moduli di reclamo (di cui ne discuteremo in seguito);

i questionari di gradimento (di cui ne discuteremo in seguito);

le rassegne stampa;

le mappe delle esigenze di comunicazione degli utenti: è una tecnica di
immedesimazione nell’utente, da parte del personale ospedaliero, al fine di
simulare il precorso che il cittadino deve compiere per accedere ad un certo
servizio (ad esempio la prenotazione di una visita specialistica);

il dialogo con il personale: oltre a mettere a proprio agio il cittadino, questo
strumento perfeziona la catena di dialogo tra le varie unità ospedaliere
(infermiere  medico  impiegato);
(2) Costruzione di una rete di referenti per aggiornare od organizzare la banca dati dei
servizi: consiste nella raccolta, in un opportuno database, di qualsiasi informazione
relativa ai documenti ed alle unità mediche presenti all’interno dell’Azienda Ospedaliera.
Tale database è gestito da un referente, vale a dire un individuo professionalmente
formato, preparato e responsabile che ne cura l’aggiornamento e verifica l’attendibilità
dei dati in esso contenuti;
La Carta dei Servizi, non è semplicemente la versione cartacea della banca dati, difatti
spetterà all’URP estrarre le informazioni dal database, ed elaborare tale documento.
(3) Realizzazione e comunicazione della Carta dei Servizi come patto con l’utenza: come
accennato nel paragrafo precedente, la Carta dei Servizi dovrà contenere le
informazioni essenziali, coerenti ed effettivamente utili al cittadino, in un formato
comprensibile e verificabile. Un eccesso di informazioni difatti, può impedire la
comunicazione invece che facilitarla.
La Carta, non è destinata solamente all’informazione dei cittadini, ma anche alle
collaborazioni con gli interlocutori istituzionali dell’Azienda Ospedaliera, quali:

le associazioni di volontariato e tutela dei diritti;

la Regione;

i medici di medicina generale ed i medici specialisti ambulatoriali;

i sindaci dei Comuni;

le principali istituzioni pubbliche interessate: quali il Dipartimento di Funzione
Pubblica, il Ministero della Sanità, il Commissario Regionale di Governo e altre
istituzioni locali;
(4) Pianificazione della comunicazione, della differenziazione dei canali e degli strumenti, in
relazione ai destinatari: in questa fase, è opportuno studiare il messaggio contenuto
nella Carta dei Servizi e dei canali di comunicazione con cui viene messa a disposizione
degli utenti.
Cavenaghi Mattia
4
Progetto di “Informatica Medica”
matricola 640926
È essenziale ricordare che: differenti tipologie di utente (dal cittadino, alla Regione, al
Ministero della Sanità) necessitano di una formulazione diversa del messaggio e di un
diverso tipo di canale di comunicazione;
(5) Ascolto e verifica del livello di soddisfazione e di comprensione del patto, da parte dei
cittadini: tale fase, sarà illustrata più in dettaglio nei prossimi due paragrafi; basti
ricordare che, grazie al sistema di feed-back realizzato con i reclami ed i questionari di
gradimento, l’Azienda Ospedaliera percepisce il grado di soddisfazione del cittadino nei
servizi ospedalieri ottenuti.
La gestione dei reclami
Quando si parla di reclamo, si tende sempre a pensare ad un
qualcosa di negativo, quasi ad una punizione per chi lo riceve; in
realtà con tale termine si identifica “l’espressione di un disagio o di
una insoddisfazione che aspetta una risposta dall’organizzazione” ed
è un potente mezzo di comunicazione a disposizione del cittadinoutente.
A seconda del tipo di raccolta di informazioni che si vuole effettuare, si impiegano metodiche di
reclamo differenti, come i questionari od i colloqui: non essendoci leggi, normative o standard
di riferimento, ogni Azienda Ospedaliera, tende a scegliere e strutturare il processo di reclamo,
sulla base dei propri bisogni e su delle “regole di buon comportamento” nei confronti del
cittadino.
Nonostante questa breve premessa, lo strumento maggiormente utilizzato, lo si può
identificare nel questionario, la quale non deve essere troppo lungo o complesso, al fine di
evitare di scoraggiare gli utenti e raccogliere informazioni ridondanti o superflue; inoltre, è
buona regola, non formulare domande troppo complesse, le quali porterebbero a delle
incomprensioni con l’utente.
Il motivo per cui viene affiancato il questionario di reclamo al questionario di
gradimento (di cui ne discuteremo nel prossimo paragrafo), lo si può sintetizzare in tre punti:
 Poiché l’utente patisce il disagio, ovvero ha esperienza di un servizio o di una
prestazione che gli genera una profonda insoddisfazione, la prestazione può talvolta non
risultare oggettivamente scadente ma è percepita dall’utente al di sotto delle sue
aspettative.
Tale disagio ha quindi una componente percettiva che varia con le caratteristiche
socioculturali dei diversi tipi di utenti e una componente oggettiva che dipende dalla
qualità della prestazione e del servizio offerto;
 In secondo luogo, il disagio è espresso e non è solo subito o soffocato, ma
intenzionalmente comunicato dall’utente, all’organizzazione. L’insoddisfazione quindi
non rimane un fatto privato, ristretto solo nella cerchia familiare o sociale, ma viene
portato all’attenzione dell’organizzazione che fornisce il servizio;
 In terzo luogo, chi reclama, aspetta una risposta dall’organizzazione perché il reclamo
esprime fondamentalmente fiducia nell’istituzione, nella sua capacità di tenerne conto e
di correggersi. È per questo che il reclamo è una risorsa positiva a disposizione
dell’Azienda, anche se a volte, per l’assenza di abitudine al dialogo con l’istituzione, il
reclamo è espresso in maniera vivace (per esempio con espressioni agitate o alterate).
Figura 2 - Lo schema di funzionamento del reclamo
Cavenaghi Mattia
5
Progetto di “Informatica Medica”
matricola 640926
Come si osserva dall’immagine, il reclamo risulta utile all’Azienda Ospedaliera poiché ha
una grande forza di innovazione: oltre a migliorare il servizio per l’utente, difatti, garantisce un
netto miglioramento dei processi aziendali.
La risposta, comporterà l’analisi, l’interpretazione e la classificazione del reclamo, con la
conseguente individuazione dei punti di sofferenza degli utenti, innescando azioni correttive
adeguate a rimuovere errori e incongruenze che si riscontrano nei servizi ospedalieri.
Solo così, si costruisce progressivamente, un codice culturale che consente di utilizzare
il reclamo come risorsa aziendale positiva e, superando gli atteggiamenti difensivi che portano
l’utente a vivere il reclamo come una minaccia od una punizione nei confronti dell’Ospedale.
La “Customer satisfaction”
Dopo aver ampiamente discusso sul processo di comunicazione tra
l’URP (o meglio l’Azienda Ospedaliera) ed il cittadino, rimane ben poco da
dire riguardo all’area di indagine sulla soddisfazione degli utenti, poiché
quest’ultima è molto simile al processo di gestione dei reclami: l’unica
differenza risiede nel fatto che la “customer satisfaction” definisce il livello di
soddisfazione percepita dall’utente, durante l’erogazione del servizio
ospedaliero e contribuisce maggiormente (rispetto al reclamo) alla creazione
di un’immagine più vicina all’ideale che il cittadino ha dell’Ospedale.
I questionari di gradimento, possono variare a seconda del tipo di ricerca da effettuare
e del tipo di obiettivo da raggiungere inoltre, devono avere un obiettivo prefissato ben preciso,
in caso contrario si otterrebbero informazioni ridondanti od inutili; i colloqui diretti con il
cittadino invece, possono essere utili per sperimentare nuovi campi di ricerca delle
informazioni.
Infine l’URP, una volta che i dati sono stati raccolti nel database ospedaliero ed
opportunamente elaborati, si occuperà di redigere la già citata, Carta dei Servizi.
Cavenaghi Mattia
6
Progetto di “Informatica Medica”
matricola 640926
Parte seconda – L’Informatica e l’URP
L’“Office automation” : software commerciale od “open source”?
Proseguendo nel mio elaborato, dedicherò questo breve capitolo all’analisi delle
caratteristiche, dei pregi e degli eventuali difetti che si possono incontrare durante l’impiego di
due principali classi di software: i software commerciali ed i software liberi, questi ultimi meglio
conosciuti come software open source.
Con questi due termini, spesso usati in modo equivoco, possiamo classificare diversi tipi
di licenze d’uso dei programmi:
 software libero: con tale denominazione, indichiamo il software open source o GNU;
questa classe di software può essere ridistribuita in modo tale che chiunque possa
usarla, copiarla e modificarla: gratuitamente od a pagamento. Il codice sorgente, deve
quindi venir incluso nella distribuzione assieme al programma. Infine, il software libero,
può essere incluso in sistemi operativi liberi (ad esempio Linux);
 software semilibero: non è un software libero ma concede agli utenti non commerciali,
di usarlo, copiarlo, ridistribuirlo e modificarlo senza fini di lucro. Purtroppo, tale classe
di software, non può essere inserita in un sistema operativo libero;
 software freeware: è un software che si può ridistribuire ma non modificare, quindi non
vi è allegato il codice sorgente. È bene notare che non si tratta di software libero;
 software di pubblico dominio: è un software che può essere modificato e ridistribuito,
sia a pagamento che gratuitamente;
 software con permesso d'autore (copyleft): è un software libero, a patto che i
distributori non impongano restrizioni al software, all’atto della ridistribuzione o della
modifica;
 software libero senza permesso d'autore: è un software al copyleft ma, il distributore
dopo la modifica, ha la facoltà di imporre ulteriori restrizioni;
 software shareware: è un software che si può ridistribuire ma, l’azienda produttrice,
impone a chi lo usa oltre il periodo di prova, di acquistare una licenza. Tale classe di
software, non la si può considerare ne libera ne semilibera poiché:
 nella maggior parte del software shareware il codice non è disponibile, perciò
non possono essere effettuate delle modifiche al programma;
 non può essere ridistribuito ne copiato senza acquistare una licenza, neanche se
l’utente lo impiega in attività commerciali;
 software proprietario: è un software ne libero ne semilibero, quindi la modifica, la
ridistribuzione e la copia, sono proibiti o vincolati da autorizzazioni particolari da
richiedere appunto, al proprietario legale del software;
 software commerciale: è un software sviluppato da una azienda, il cui unico scopo è di
ricavarne un guadagno dalla sua vendita e dal suo uso, da parte degli utenti. I software
commerciali e proprietario sono completamente diversi: sebbene molti software
proprietari siano commerciali, esistono anche dei software liberi ma commerciali.
Cavenaghi Mattia
7
Progetto di “Informatica Medica”
matricola 640926
Per comprendere meglio, quali legami ci siano tra le licenze appena descritte, riportiamo il
seguente grafico:
Figura 3 – I legami tra le licenze (di Chao-Kuei)
Sebbene siano stati concepiti poco più di dieci anni fa, gli open source, si stanno
sviluppando maggiormente solo in questi ultimi anni, grazie soprattutto al diffondersi
dell’impiego dei computer nella vita quotidiana e all’introduzione di Internet, specie delle
connessioni a banda larga. Tale situazione ha incentivato gli utenti alla ricerca di nuovo
software, facilmente reperibile sulla rete e non a pagamento.
Le caratteristiche fondamentali dell’open source si possono ritrovare nella GPL del 1991,
ossia la GNU General Public License, una licenza la quale tutela il software libero e ne definisce
la catteristiche:
 la distribuzione libera: la licenza GPL, non può ne impedire ne limitare a qualcuno, di
vendere o donare i programmi come componenti, facenti parte di un pacchetto software
e contenenti programmi di varia origine;
 la disponibilità del codice sorgente: il programma software, deve essere distribuito
liberamente, sia con il suo codice sorgente che come forma compilata.
Se il codice non è incluso, il programma deve contenere un riferimento al fine di
agevolarne il reperimento gratuito. Inoltre, non è ammessa alcuna altra forma di
pseudo-codice. Il motivo di tale principio, è quello di permettere a più persone di poter
modificare e migliorare il programma, al fine di tenerlo il più aggiornato ed efficiente
possibile;
 lo sviluppo di software derivati: il programma licenziato, deve consentire la modifica e
l’uso come base di programmi derivati, ridistribuibili con le stesse modalità del software
originale;
 l’integrità del codice sorgente dell'autore: la licenza può richiedere che le modifiche al
codice sorgente, vengano evidenziate, cambiando il nome o la versione del programma.
Ciò rende possibile un certo livello di rintracciabilità da parte dell'utente, di chi ha
prodotto il programma o una sua versione;
 nessuna discriminazione contro persone o gruppi: non è consentita alcuna limitazione,
relativamente all’esportazione del software licenziato, in paesi differenti da quello
produttore;
 nessuna discriminazione contro i campi di d'applicazione: nessun programma open
source può essere dedicato ad un unico campo di applicazione;
 la distribuzione della licenza: il programma coperto dalla licenza GPL, non può essere
licenziato in altro modo che ne possa “chiudere” il codice;
 la licenza non deve essere specifica ad un prodotto: se il software verrà impiegato come
modulo in altri programmi (ossia come parte di un programma), anch’essi devono
essere licenziati come open source;
Cavenaghi Mattia
8
Progetto di “Informatica Medica”
matricola 640926
 la licenza non deve porre vincoli su altro software: se il software viene ridistribuito
assieme ad altri programmi non open source, non è indispensabile che questi ultimi
siano licenziati come software GPL.
Nel panorama dei calcolatori per l’ufficio, si individuano applicativi
utilizzati anche da normali utenti di PC e, si possono suddividere nelle
seguenti tipologie:
 elaboratori di testo: sono software che permettono di creare e
modificare i testi, a differenza degli editor di testo, gli elaboratori
consentono di formattare i caratteri tramite l’uso di font ossia
degli insiemi coordinati di caratteri, aventi ognuno un certo
design;
 fogli di calcolo elettronico: in questa categoria, ricadono tutti
quegli applicativi utilizzati per la produttività personale,
caratterizzati da una tabella composta da celle, il cui contenuto
può variare dal carattere alfanumerico alla formula matematica;
 gestore di basi di dati: chiamati anche DBMS (Database management systems), sono
programmi in grado di archiviare ed elaborare grandi quantità di dati, contenuti in
tabelle compilate dall’utente;
 elaboratore di presentazioni: permettono di creare delle presentazioni multimediali,
costituite da collezioni di diapositive virtuali, visualizzabili su un qualsiasi computer
dotato di lettore software apposito;
 client di posta: consentono la composizione, la trasmissione, la ricezione e
l’organizzazione di e-mail (posta elettronica) sul proprio computer;
 browser per il Web: sono programmi che interpretano il linguaggio HTML (linguaggio di
descrizione del contenuto di una pagina Internet), permettendo la consultazione del
Web, tramite gli ipertesti;
 lettore e generatore di files in formato PDF: tale applicativi, consentono la lettura di
programmi in formato PDF, ossia in linguaggio di descrizione di pagina, impigato per
leggere documenti indipendentemente dal tipo di hardware o software presenti nel
calcolatore. Questo formato è stato creato dalla Adobe Systems;
 programmi di uso generale: installati a discrezione dell’utente, a seconda della loro
natura consentono la gestione e l’utilizzo del calcolatore in svariate modalità (basti
pensare ai programmi antivirus, anti spyware, i lettori di files multimediali, ect…).
Comunemente, gli elaboratori di testi, i fogli elettronici, i DBMS e gli elaboratori di
presentazioni, sono forniti in un unico pacchetto applicativo, come ad esempio Microsoft Office
(software commerciale), OpenOffice.org (software libero) o StarOffice (software libero ma
commerciale).
Nonostante la disponibilità di software liberi per l’office automation, presso le Pubbliche
Amministrazioni si continuano ad impiegare programmi di tipo commerciale, senza capire i
vantaggi che si otterrebbero dall’impiego degli open source:
 la riduzione dei costi: con il software libero, i costi dovuti all’acquisto delle licenze d’uso,
si ridurrebbero, permettendo l’investimento dei fondi in altre applicazioni;
 la maggiore affidabilità del software: grazie al coinvolgimento di più utenti e
sviluppatori, il software libero ridurrebbe i tempi di sviluppo e di testing;
 l’indipendenza dal proprietario: l’utente, non sarebbe più dipendente dal fornitore per
eventuali aggiornamenti software;
 la maggiore sicurezza del prodotto: il software libero, garantisce la trasparenza rispetto
a possibili sistemi di spionaggio informatico che violano la privacy;
 la libertà di utilizzo: evita di dover accettare condizioni limitative delle proprie libertà,
garantendo la possibilità di personalizzazione del software e favorendone la portabilità
su diversi sistemi operativi.
Purtroppo, si potrebbero riscontrare anche degli aspetti negativi, quali:
 l’incompatibilità di certi software con alcuni standard commerciali;
Cavenaghi Mattia
9
Progetto di “Informatica Medica”
matricola 640926
 il supporto immediato non garantito (ottenibile in poche ore via internet);
 il coinvolgimento anche dell'utente inesperto nell’attività di debugging e testing;
 la ridotta disponibilità di software e drivers di supporto alle periferiche, in ambito Linux.
Il progetto
Veniamo ora all’ultimo capitolo di questo elaborato, incentrato sull’analisi del problema
progettuale assegnatomi dall’URP, presso cui ho avuto modo di collaborare.
La descrizione del problema progettuale
Il processo di interazione tra l’Azienda Ospedaliera ed il cittadino, come già discusso
nella prima parte di questa relazione, consta di tre elementi: l’area di informazione del
cittadino, i moduli di reclamo ed i questionari di gradimento.
L’area di informazione del cittadino, viene approfondita tramite la Carta dei Servizi
redatta dall’URP la quale può essere fornita in formato cartaceo dall’Azienda Ospedaliera o,
eventualmente, in formato elettronico scaricabile dal sito internet della stessa.
I reclami ed i questionari invece vengono compilati dal cittadino su un modulo cartaceo, il cui
contenuto è studiato dall’URP in collaborazione con l’Ospedale, successivamente i dati
contenuti nei moduli, vengono raccolti, catalogati in un foglio elettronico e forniti alla Regione,
la quale li userà per apportare migliorie al Servizio Ospedaliero o redigere dei rapporti sulla
qualità del Servizio stesso.
La necessità dell’ufficio che è stato motivo principale del mio lavoro, è quella di avere
un supporto informatico per la gestione dei dati raccolti, al fine di generare sia un report
cartaceo (ad uso interno dell’Ospedale) che files esportabili in formato di foglio elettronico (e,
come vedremo di seguito, in formato XML).
Possiamo quindi individuare i seguenti obiettivi da soddisfare:

velocità di elaborazione dei dati;

esportabilità dei dati in formato di foglio elettronico (ed XML);

possibilità di stampare i dati, tramite dei report.
I linguaggi impiegati
Prima di addentrarci nella descrizione vera e propria dei
programmi, è opportuno fare una breve panoramica sugli strumenti ed i
linguaggio impiegati per lo sviluppo.
Ogni singolo programma creato (due in totale), è stato realizzato con
Microsoft Access, ossia un gestore di basi di dati relazionale, con cui è
possibile interagire tramite l’ausilio di interfacce grafiche; l’aggettivo
relazionale invece, fa riferimento al fatto che una tabella, può essere
connessa ad un'altra tramite una o più relazione ossia una dipendenza
che può intercorrere tra due campi separati.
L’interfaccia grafica però, non è l’unico strumento di lavoro attraverso cui è possibile
lavorare in Access, difatti è possibile creare delle maschere che agevolano l’immissione e
l’elaborazione dei dati, da parte dell’utente: inoltre, per le funzionalità più avanzate come ad
esempio, le caselle combinate, le liste od i pulsanti, è prevista una procedura guidata o, la
programmazione di pezzi di codice, chiamati script, associati agli eventi (la pressione di un
pulsante, ad esempio) scritti in linguaggio Visual Basic for Application che d’ora in avanti,
chiameremo VBA.
Il VBA, è una versione del più noto Visual Basic, incluso in molte applicazioni Microsoft ed
anche in diversi prodotti di altre aziende sviluppatrici di software; si tratta in sostanza, di un
linguaggio di programmazione molto semplice, orientato agli eventi ed utilizzabile sia dai
principianti che dagli sviluppatori più esperti. Inoltre, essendo gli script associati ad elementi
preesistenti, VBA è stato uno dei primi linguaggi ad avviare il mercato dei componenti software
riutilizzabili.
Cavenaghi Mattia
10
Progetto di “Informatica Medica”
matricola 640926
Gli script servono essenzialmente ad “abbellire” le maschere ma, non permettono
all’utente di effettuare una manipolazione più efficiente dei dati, motivo per cui è stato inserito
in Access anche lo Structured Query Language, meglio noto come SQL.
SQL è un linguaggio creato dall’IBM e, standardizzato dall’ANSI (nel 1986) e dall’ISO (nel
1987), per lavorare con dati residenti in database che seguano il modello relazionale; il
processo di standardizzazione, mirava soprattutto a creare un linguaggio standard da
impiegare in tutti i DBMS relazionali ma, tale obiettivo non fu mai raggiunto, poiché ogni
produttore di software, implementò una sua versione.
La caratteristica principale dell’SQL è di non richiedere la specifica delle sequenze di operazioni,
ma solo le proprietà logiche delle informazioni ricercate.
Bisogna però riscontrare anche qualche pecca, nell’utilizzo pratico dell’SQL:
 il linguaggio è piuttosto complesso;
 non viene fornito uno standard per spezzettare un comando lungo, in comandi più
brevi, a cui ci si possa riferire tramite una parola chiave od una etichetta;
 le implementazioni delle diverse aziende, sono generalmente incompatibili tra loro;
 si fa troppo affidamento sui valori NULL, ossia un metavalore che secondo alcuni
dovrebbe indicare l'assenza di un valore, secondo altri dovrebbe indicare un valore
sconosciuto, mentre nella pratica finisce per essere usato in entrambi i modi o in uno
solo, ma in modo incoerente.
Come già accennato nel precedente paragrafo, i dati da fornire alla Regione, devono
essere esportati in un file XLS (formato proprietario del foglio elettronico Microsoft), ciò implica
un certo tipo di “dipendenza”, sia da parte dell’Azienda Ospedaliera che della Regione, di avere
il programma di lettura e/o modifica del file.
Nel mio progetto, ho rispettato questa scelta ma, ho voluto includere una funzione, la quale
permette di esportare i dati in un file formattato, secondo il linguaggio XML (acronimo di
eXtensible Markup Language).
L’XML è un metalinguaggio relativamente recente (è stato standardizzato dalla W3C,
solo nel 1998), simile al suo parente prossimo l’HTML: anch’esso è basato sulla
gerarchizzazione dei dati tramite i tag, ossia delle etichette elettroniche che ne stabiliscono la
posizione gerarchica e le proprietà, a seconda del contesto in cui i dati operano.
Un documento XML, affinché sia leggibile, valido (o meglio well-formed) e quindi usabile, deve
presentare certe caratteristiche, riassumibili nei seguenti punti:
 header: viene posto all’inizio del documento, descrive la codifica dei caratteri impiegati
per creare il documento (può variare a seconda della zona geografica in cui è stato
creato) e specifica se il file XML è stand alone, ossia non necessita di nessun file di
supporto che ne descriva la struttura: in caso contrario, sarà necessario indicarne il link
od il percorso ove rintracciarlo.
Nell’header infine, è possibile inserire anche l’indirizzo del namespace, un insieme di
parole chiave utilizzate per denominare i tag e gli attributi degli stessi;
 tag root: ogni documento XML deve contenere un tag radice, nel quale vengono
racchiusi tutti gli altri tag;
 tag nidificati: i tag che vengono aperti per primi, devono anche chiudersi per primi;
 sintassi dei tag: come nell’HTML, anche in XML un tag si definisce come: <etichetta>
dato </etichetta> oppure, se l’etichetta non contiene dati, si può scrivere: <etichetta
/>. Sebbene le etichette si possano nominare a piacere, vi sono poche ma importanti
regole da rispettare nella denominazione:




il nome deve cominciare con un carattere alfabetico, o con il carattere “_”;
il nome non può iniziare con un numero;
il nome non può contenere degli spazi;
il nome è case sensitive, quindi se viene scritto <etichetta> </ETICHETTA>,
verrà generato un messaggio di errore;
 il nome non può contenere la parola “xml” o, parole chiave che vengono definite
nel namespace.
Cavenaghi Mattia
11
Progetto di “Informatica Medica”
matricola 640926
 attributi del tag: è possibile associare un attributo ad un tag, inserendolo tra gli apici:
<etichetta attributo=“valore”> </etichetta>;
 caratteri speciali: se si necessita di inserire dei caratteri speciali (ad esempio à, ò, è,
ect…), dovrò inserire “&” seguito dalla codifica ASCII del carattere stesso: <età />
diventerà quindi <et &(codifica ASCII del carattere “à”) />.
Essendo un linguaggio semplice da appendere, utilizzare ed indipendente sia dal software che
dall’hardware presente nel calcolatore su cui risiede, l’XML sta prendendo sempre più piede nel
mondo dell’informatica e non solo nelle applicazioni Web ma, soprattutto, anche negli
applicativi aziendali: in un prossimo futuro quindi, non è del tutto scontato che venga
largamente adottato dalle Amministrazioni Pubbliche per migliorare gli scambi di dati tra i vari
Enti (od aziende) Nazionali (od Internazionali).
I programmi
Il database di gestione dei moduli di reclamo
La prima richiesta fattami dall’URP, consisteva nella creazione di un programma di
raccolta manuale dei dati, in cui fosse possibile compiere dei filtraggi, per estrapolare dati
corrispondenti a criteri impostati dall’utente: successivamente il risultato sarebbe dovuto
essere stampato su dei report cartacei, ad uso interno dell’Azienda Ospedaliera.
La quantità di informazioni da memorizzare, è stata tale da comportare la realizzazione di sei
tabelle così definite:
 DB_Classi_modulo: in questa tabella sono state inserite tutte le classi, fornite dalla
Regione tramite una lista, a seconda del motivo per cui un reclamo può essere
presentato. Con tale lista, ad esempio, possiamo sapere se un reclamo, reclamizzante
un reparto, si riferisce alla relazione tra il paziente ed il medico piuttosto che alle
prestazioni del servizio ospedaliero.
I campi contenuti in tale tabella sono:
 cod_classe: (la chiave primaria) corrisponde ad una sigla identificativa univoca,
della classe di appartenenza del modulo;
 classe_modulo: è il nome che descrive la classe del modulo.
 DB_Moduli: questa può essere considerata una “tabella-madre”, dove vengono
memorizzati i dati veri e propri relativi ad un modulo compilato; i suoi campi sono:
 cod_utente: è la chiave esterna riferita all’omonimo campo, presente nella
tabella DB_Utenti;
 n_protocollo: (chiave primaria) è un codice, definito a discrezione dell’URP che
identifica univocamente il modulo, sia nel database che nell’archivio cartaceo in
possesso dell’ufficio stesso;
 tipo_modulo: anche questa, è una chiave esterna riferita all’omonimo campo,
presente nella tabella DB_Tipi_documento;
 cod_classe_modulo: (chiave esterna) è il riferimento al campo cod_classe,
presente nella tabella DB_Classi_modulo;
 classe_modulo: (chiave esterna) si riferisce al campo classe_modulo, presente
anch’esso nella tabella DB_Classi_modulo;
 cod_reparto:
(chiave esterna) identifica il codice
reclamizzato, memorizzato nella tabella DB_Reparti;
univoco
del
reparto
 nome_reparto: (chiave esterna) nome identificativo del reparto reclamizzato, la
cui lista è presente nella tabella DB_Reparti;
 data_compilazione: corrisponde alla data in cui il modulo cartaceo di reclamo, è
stato compilato dall’utente;
 data_accaduto: è la data in cui l’episodio reclamizzato nel modulo, si è
verificato;
 ora_accaduto: ora in cui l’episodio reclamizzato è accaduto nel reparto;
Cavenaghi Mattia
12
Progetto di “Informatica Medica”
matricola 640926
 documenti_selezionati: è una lista di documenti che l’utente, al momento del
reclamo, ha allegato al reclamo e consegnato all’URP;
 info_raccolte: informazioni raccolte dall’URP, in merito all’istruttoria di reclamo.
 DB_Reparti: come per la tabella DB_Classe_modulo, anche questa tabella, è una lista
contenente tutti i reparti presenti all’interno dell’Azienda Ospedaliera.
I campi che la compongono sono:
 cod_reparto: (chiave primaria) è un codice numerico univoco che identifica il
reparto reclamizzato;
 nome_reparto: è il nome del reparto reclamizzato nel modulo.
 DB_Tipi_documento: qui sono contenuti tutti i tipi di documento che l’utente, al
momento della consegna potrebbe allegare al modulo:
 cod_documento: (chiave primaria) è un codice alfabetico da me ideato che,
identifica il documento in modo univoco all’interno del database;
 tipo_documento: nome il quale identifica il tipo di documento allegato.
 DB_Tipi_modulo: in questa tabella, ho inserito le classificazioni sul tipo di modulo
presentato dall’utente: difatti esso, può presentarsi come reclamo, reclamo con
procedura semplice o come segnalazione:
 cod_tipo: (chiave primaria) è il codice alfabetico da me ideato che, identifica
univocamente il tipo di modulo nel database;
 tipo_modulo: come accennato precedentemente, il modulo può essere un
reclamo, un reclamo con procedura semplice od una segnalazione.
 DB_Utenti: come la tabella DB_Moduli anche questa, può essere considerata una
tabella-madre poiché contente i dati sensibili relativi agli utenti compilatori:
 cod_utente: (chiave primaria) è un numero autoincrementante che, definisce in
modo univoco, un utente tra gli altri nel database;
 nome;
 cognome;
 indirizzo: i dati presenti in questo campo, poiché non sono soggetti a
manipolazioni tramite interrogazioni, sono memorizzati come “Memo”, ossia un
campo alfanumerico composto da un massimo di 65536 caratteri;
 telefono.
Grazie a quanto detto finora, possiamo notare che ogni singola tabella, ha una chiave
primaria, la quale viene replicata nella tabella DB_Moduli tramite una o più relazioni. Ciò
permette di selezionare un certo dato (ad esempio nella tabella DB_Reparti) che il database si
occuperà di copiare automaticamente nel campo replica (cod_reparto e nome_reparto della
DB_Moduli), legato dalla relazione stessa.
Le relazioni create nel database, sono riportate nella seguente figura:
Cavenaghi Mattia
13
Progetto di “Informatica Medica”
matricola 640926
Figura 4 - Le relazioni presenti tra le tabelle, del database
Per evitare che, durante il normale lavoro di immissione dei dati, si potessero
inavvertitamente modificare i parametri di uno o più campi contenuti nelle tabelle, con la
conseguente perdita od il danneggiamento dei dati stessi, ho creato delle semplici interfacce
grafiche chiamate maschere, dotate di tutti i possibili comandi utili e, necessari al lavoro
dell’impiegato.
Aprendo il file DB_gestione_reclami.mdb, viene avviata automaticamente la maschera
principale di gestione del database:
Figura 5 - La maschera principale
Attraverso tale maschera e, cliccando su uno dei pulsanti si può decidere che tipo di dati si
vogliono elaborare: ad esempio, cliccando sul pulsante “Gestione dei moduli”, si aprirà un
foglio di reclamo “pulito”, pronto alla compilazione, mentre cliccando sul pulsante “Gestione
delle interrogazioni”, si potrà filtrare dalla collezione di moduli già compilati ed archiviati, una
certa classe, avente determinate caratteristiche impostate dall’utente; infine l’icona con la
figura di una porta, serve per uscire dal programma.
Cavenaghi Mattia
14
Progetto di “Informatica Medica”
matricola 640926
Cliccando sul pulsante “Gestione dei moduli”, comparirà tale maschera:
Figura 6 - La maschera di gestione dei moduli
Essa è formata da due maschere: la “MSK_Gestione_moduli” (principale), dove vengono
raccolti e memorizzati i dati degli utenti (nella tabella DB_Utenti) e la sottomaschera
“SUBMSK_Gestione_moduli”, dove vengono raccolti e memorizzati i dati dei moduli (nella
tabella DB_Moduli).
È bene notare che tale interfaccia, è stata concepita in modo tale da permettere la
corrispondenza di uno o più moduli compilati per ogni singolo utente.
La parte relativa all'immissione dei dati utente si presenta così:
Figura 7 - L'area di immissione dati degli utenti
Sotto tale area, è presente una pulsantiera composta da sei pulsanti, riportata in più interfacce
e così strutturata:
(1) cliccando tale pulsante, comparirà una finestra in cui è possibile ricercare un dato di cui
se ne conosce il valore.
Dapprima, è necessario inserire il nome del dato nel campo “Trova:”, successivamente
si seleziona un valore nel campo “Confronta:”, se il nome inserito precedentemente è
parte del dato ricercato, o rappresenta il nome completo (per esempio, se voglio
cercare un utente avente cognome “DeRossi”, posso fare una ricerca inserendo nel
campo “Trova:” il nome “DeRossi” o “derossi” e nel campo “Confronta:” selezionare
“Campo intero”; oppure posso mettere in “Trova:” il valore “Rossi” o “rossi”, e
Cavenaghi Mattia
15
Progetto di “Informatica Medica”
matricola 640926
selezionare “Confronta:” con valore “Parte del campo”). Una volta riempiti i campi, è
sufficiente premere il pulsante “Trova successivo” affinché la ricerca abbia inizio.
Figura 8 - La finestra per la ricerca dei dati
(2) e (3) tali frecce, permettono di navigare avanti ed indietro nei dati memorizzati;
(4) permette di creare un nuovo utente;
(5) permette di salvare un utente o le modifiche apportate ad un utente già salvato;
(6) permette di eliminare un utente, tale operazione è possibile solo se per l'utente, sono
stati eliminati dapprima, tutti i moduli associati.
Sempre nella maschera “Gestione dei moduli”, sono riportati i seguenti campi, utili
all’immissione dei dati dei moduli compilati:
Figura 9 - L'area di immissione dei dati relativi al modulo
Questi campi, sono già stati illustrati nella precedente descrizione delle tabelle (più
precisamente, nella tabella DB_Moduli) ma, è interessante soffermarci su alcuni di essi: ad
esempio, per definire i “Documenti allegati:”, ossia i documenti che l’utente, allega al modulo
di reclamo, è sufficiente selezionare una o più voci, presenti nella lista “Tipo di documento:” e
successivamente, cliccare il pulsante “Allega documenti” il quale salverà in un campo di tipo
“memo” (documenti_selezionati) la nostra selezione. Infine, i campi “Classe del modulo:” e
“Reparto:”, si presentano come lista composta da due colonne dove, ad ogni selezione,
vengono memorizzati nella tabella sia la chiave primaria che il valore stesso del dato.
Anche in questa parte di sottomaschera, sono presenti i pulsanti di navigazione e di gestione
dei dati.
Tornando alla maschera principale e, cliccando sul pulsante di “Gestione delle
interrogazioni”, verrà visualizzata tale finestra:
Cavenaghi Mattia
16
Progetto di “Informatica Medica”
matricola 640926
Figura 10 - Maschera di gestione delle interrogazioni
Questa maschera, è basata sulla query avente nome “QRY_Conteggio” dove, per ogni campo,
è stata inserita come criterio di ricerca, una funzione del tipo If… Then… Else, così formulata:
iif([nome_campo]=“valore”;“*”;[nome_campo])
Se il campo contraddistinto con [nome_campo], è uguale ad un certo “valore”, nel nostro caso
lo 0 a cui corrisponde la dicitura “- Tutti -”, la query restituirà tutti i valori, di quel campo,
presenti in tabella; mentre se tale condizione, non viene rispettata, vengono riportati tutti e
solamente, i moduli corrispondenti al valore [nome_campo].
Quindi, selezionando nei tre campi, il tipo di valore voluto e, premendo il pulsante per la
creazione dei report, si filtreranno tutti i moduli presenti nel database contando quanti
rispondono ai criteri selezionati.
Arriviamo ora ad analizzare, in breve, le finestre dei dati precompilati, ossia delle
maschere le quali si basano su liste che, possono essere modificate nel tempo: un esempio di
queste, può essere la maschera MSK_Gestione_tipi_documento.
Figura 11 - La maschera di gestione dei tipi di modulo
In questa maschera (come nella “Gestione dei reparti”, “Gestione delle classi di modulo” o la
“Gestione dei tipi di modulo”), sono presenti due campi di immissione dati: la prima, "Sigla del
tipo:", permette di inserire un codice di identificazione del valore posto nel secondo campo
(“Tipo di documento:”).
Anche in questo caso, sono presenti due file di pulsanti: la prima fila, è del tutto simile a quella
presentata durante la “Gestione dei moduli” mentre la seconda, permette la creazione di un
report pronto per la stampa (icona a forma di quaderno) e la chiusura della maschera stessa.
Infine, possiamo notare nella maschera principale, un pulsante centrato rispetto agli
altri: premendo tale elemento, si avvierà la finestra per l’importazione o l’esportazione dei dati
presenti nelle tabelle:
Cavenaghi Mattia
17
Progetto di “Informatica Medica”
matricola 640926
Figura 12 - La maschera di importazione ed esportazione dei dati
Per esportare i dati, è possibile scegliere tra uno od entrambi i formati: Excel (XLS) od
XML (con relativo file di schema XSD), dopodiché è necessario selezionare la tabella da
esportare, utilizzando la casella combinata avente etichetta “Tabella da esportare:” ed
impostare una cartella in cui esportare il tutto.
Se ad esempio, non vengono selezionati il formato di file, la tabella da esportare o la cartella di
esportazione, l’operazione non andrà a buon termine, generando un messaggio di errore.
Analogamente, per importare i dati in una tabella, è necessario compiere il precedente
procedimento, utilizzando i comandi presenti nella cornice “Importa dati”.
In questo programma e nei seguenti due, si può notare che la funzione di importazione
dei files in formato XML, è presente ma disabilitata. Tale decisione è stata presa poiché in
Microsoft Access, è presente un piccolo bug di programmazione che, pur permettendo
l’importazione tramite interfaccia grafica implementata da Microsoft, la programmazione di tale
evento in VBA, genera un errore: con ciò ho deciso di lasciare all’utente la capacità di utilizzare
la procedura guidata, eseguibile dal menù File  Carica dati esterni  Importa… e
dettagliatamente illustrata nella guida di Access.
Per visionare un articolo, in riferimento
http://www.oreillynet.com/pub/wlg/6649.
a
tale
bug,
è
possibile
visitare
il
sito:
Qualora in futuro, verranno rilasciate delle patch per rimediare a questo errore di
programmazione, sarà possibile riabilitare il comando con i relativi pezzi di codice VBA.
Cavenaghi Mattia
18
Progetto di “Informatica Medica”
matricola 640926
Il database di gestione dei questionari di gradimento sulla degenza
Questo secondo database, è nato con l’intenzione di rendere più agevole la ricerca dei
dati all’interno di una data tabella, fornita in formato Excel.
Il file mdb, allegato in questa relazione, di discosta leggermente da quello fornito
all’URP poiché nell’ufficio, è presente una versione di Access piuttosto datata che ha reso
necessario apportare lievi modifiche alle funzionalità principali. Inoltre, nella tabella principale,
sono stati eliminati alcuni campi, non necessari nella trattazione del mio progetto.
La struttura dell’intero programma, è molto semplice poiché, consta solamente di due tabelle:
 DB_Globale: è la tabella principale, contenente tutti i dati che possono comparire nel
modulo ed i cui campi sono:
 n_questionario:
definita come chiave primaria è un valore numerico
autoincrementante il quale premette l’identificazione univoca di un modulo,
all’interno del database;
 data_compilazione: è la data, in formato gg/mm/aaaa, in cui l’utente ha
compilato il questionario;







sesso: riporta di quale sesso sia l’utente;
età: riporta l’età dell’utente che ha usufruito del servizio ospedaliero;
nazionalità: riporta la nazionalità di appartenenza dell’utente;
scolarità: esprime il livello di istruzione del cittadino;
reparto: (chiave esterna) identifica il reparto in cui l’utente è stato curato;
medico_ricoverante: riporta quale medico ha imposto il ricovero al paziente;
da domanda_g1 a domanda_m23: sono le domande che compongono il
questionario.
 DB_Reparti: come per il database sui moduli di reclamo, anche in questo, vengono
riportati i reparti con i relativi codici di identificazione: a differenza del precedente, il
contenuto di tali campi è differente, poiché la Regione ha formulato, per i diversi tipi di
questionario, differenti classificazioni dei reparti ospedalieri:
 cod_reparto;
 reparto.
Proseguendo nella nostra analisi, possiamo notare che l’unica relazione stabilita tra le
due tabelle, risulta essere quella instaurata tra la chiave primaria della tabella dei reparti e, la
sua chiave esterna, presente nella tabella globale:
Figura 13 - Lo schema relativo alle relazioni presenti nel database
Cavenaghi Mattia
19
Progetto di “Informatica Medica”
matricola 640926
Visualizzando il contenuto della tabella DB_Globale, è immediato accorgersi che sono
presenti solamente codici numerici, questo perché le risposte, devono essere fornite alla
Regione, tramite codifica numerica.
Per ogni domanda, oltre alle possibili risposte, è stato inserito anche un “campo nullo”, avente
associata la descrizione: “- Nessuna risposta -”, difatti un paziente all’atto della compilazione,
molto spesso omette risposte le quali, al fine del corretto funzionamento della query,
necessitano di essere convertite in un valore alfanumerico. Tale procedimento, è stato reso
possibile grazie all’adozione di una funzione di conversione, chiamata Nz ed avente sintassi:
Nz([nome_campo];“valore”)
Se il campo (identificato con [nome campo]) è nullo, la funzione restituisce un valore “valore”
il qule, nel nostro caso, è stato impostato a 0, permettendo così anche l’elaborazione dei
campi vuoti.
Ricordo infine che, sebbene i campi nulli, durante l’esecuzione della interrogazione, vengono
convertiti, ciò non implica modifiche di valore nella tabella DB_Globale: in sostanza, la funzione
Nz, “fa vedere” alla query un valore “Null” come valore 0.
Avendo presentato, la parte più interessante di questo database, non ci rimane che fare
un breve excursus relativo alle maschere create col fine di agevolare il lavoro dell’impiegato
URP.
All’apertura del file DB_gestione_gradimento_degenza.mbd, viene
classica maschera principale:
visualizzata la
Figura 14 - La maschera principale
Come per il database di gestione dei moduli, anche in questo caso, premendo dei pulsanti in
essa contenuti, si potrà accedere a diverse aree per la manipolazione dei dati: con la pressione
del pulsante “Gestione dei questionari”, ad esempio, si potranno modificare i dati contenuti
nella tabella DB_Globale mentre, con la pressione del pulsante “Gestione delle interrogazioni”,
si potranno effettuare delle ricerche sui dati contenuti nella tabella principale.
Poiché la maschera di “Gestione dei questionari” e la maschera di “Gestione della
interrogazioni”, sono del tutto simili, riporto di seguito, a titolo di esempio, l’immagine di parte
(a causa delle grandi dimensioni) della maschera di gestione dei questionari:
Cavenaghi Mattia
20
Progetto di “Informatica Medica”
matricola 640926
Figura 15 - La maschera di "Gestione dei questionari"
Per inserire le risposte nel modulo vuoto, si utilizza esclusivamente, una serie di caselle
combinate aventi i codici e le relative descrizioni delle risposte, già integrate: ciò restringe il
campo dei valori che l’impiegato può immettere, riducendo drasticamente, il numero di
possibili errori di trascrizione. È immediato notare anche la già citata pulsantiera per la
gestione dei dati (spostamento, salvataggio, ect…).
Tornando alla maschera principale, ritroviamo la maschera per la “Gestione delle
importazioni / esportazioni” dei dati mentre, fa la sua comparsa, un nuovo tipo di documento,
ossia il “Foglio di riferimento delle risposte”
Ricordando che, i report creati tramite le interrogazioni, vengono stampati e distribuiti ai
singoli reparti interessati, tali “fogli di riferimento”, permettono la facile comprensione dei
codici di risposta che un utente ha fornito, consentendo, al personale ospedaliero di
interpretare i dati ricevuti.
Cavenaghi Mattia
21
Progetto di “Informatica Medica”
matricola 640926
Ringraziamenti
Essendo giunto al termine della mia relazione, vorrei ringraziare il Responsabile
dell’ufficio “Flussi Informativi” e tutto il Personale dell’“Ufficio Relazioni con il Pubblico”,
dell’Azienda Ospedaliera, presso cui ho svolto la mia attività progettuale.
Cavenaghi Mattia
22