.
SCUOLA DI INGEGNERIA
DIPARTIMENTO DI INGEGNERIA DELL’INFORMAZIONE CORSO DI LAUREA MAGISTRALE IN INGEGNERIA BIOMEDICA
TESI DI LAUREA:
Biomedical Framework: Progettazione e sviluppo di un Sistema di Governo per Aziende Sanitarie
Relatore: Candidata:
Prof. Maurizio Mangione Giulia Andreuccetti
Sessione di Laurea 2 Dicembre 2016 Anno Accademico 2015/2016
Indice
1
Introduzione
12
Il Contesto
23
Il Sistema di Governo (SDG)
43.1 Gli obiettivi . . . 4
3.2 Esempi di alcune funzionalit´a . . . 5
3.3 La struttura . . . 6
4
I sistemi di Warehousing: breve
descrizione e principali features
7 4.1 Caratteristiche e confronto con i Data Base: . . . 74.2 Il modello Multidimensionale: concetti basilari . . . 8
5
Preparazione dell’ ambiente di
la-voro
10 5.1 Descrizione dell’ architettura e dei software da utilizzare . . . 105.2 Creazione dell’ ambiente di lavoro . . . 11
6
Costruzione della webapp
14 6.1 Creazione di un nuovo utente . . . 146.2 Gesione delle app con il Tomcat . . . 16
6.3 Import del sistema di governo . . . 17
7
Dal BMF 2.X al BMF 3.0
19 7.1 Il Database del BMF . . . 197.2 Principali differenze ed analogie tra le due versioni . . . 22
7.3 Il Json . . . 24
7.4 Studio ed esempi delle funzionalit´a del BMF 3.0 . . . 27
8
Realizzazione del nuovo SDG
39 8.1 Struttura dell’ SDG . . . 398.2 Conversione degli oggetti . . . 47
8.3 Alcuni problemi incontrati e loro risoluzione . . . 53
8.4 Trasferimento del nuovo SDG . . . 55
10
Acronimi
601
Introduzione
Lo scopo di questa tesi ´e stato quello di realizzare un applicativo web che consentisse ai responsabili delle strutture sanitare di monitorare l’ andamento dei costi, rendimenti e risultati di esercizio, garantire una corretta gestione delle risorse, fornire in modo tempestivo gli
indicatori della situazione aziendale ed essere d’ aiuto in ambito decisionale, il tutto nel rispetto delle normative sulla privacy che tutelano i pazienti della struttura. In particolare lo strumento ´e rivolto al personale sanitario della Fondazione Toscana Gabriele Monasterio (che opera a Pisa e Massa) in modo da permettere agli operatori l’ inserimento, modifica, navigazione e la visualizzazione dei dati clinici ed amministrativi, con l’ obiettivo di facilitare l’ attivit´a di ricerca e di statistica in ambito clinico. L’ applicativo prende il nome di Sistema di Governo (SDG), ed attinge i propri dati dal Data Warehouse di Governo e da altri Data Base di dimensioni minori. La qualit´a dell’ applicazione destinata all’ utente finale assume dunque un ruolo fondamentale nell’ ambito della gestione di una Struttura Ospedaliera: determina il modo in cui l’ utente potr´a relazionarsi con i dati stessi, la chiarezza della loro visualizzazione (e quindi la loro stessa utilit´a) e permette di stabilire chi potr´a accedere o meno a quali dati.
La fondazione dispone di un applicativo in grado di fornire
informazioni di governo sviluppato con tecnologia BMF versione 2, ma tale tecnologia ´e ormai superata dalla versione 3. Gran parte del lavoro che verr´a descritto nei paragrafi seguenti ha riguardato quindi lo studio della nuova release del framework per capirne il
funzionamento e le novit´a rispetto alla precedente e la migrazione delle funzionalit´a dal vecchio sistema al nuovo.
Dall’analisi dei desiderata aziendali in merito di attivit´a di governo e la valutazione delle funzioni disponibili ´e emersa l’esigenza di
apportare delle modifiche evolutive al BMF 3, mettendo le basi per la release 3.1.
2
Il Contesto
Il progetto ´e stato voluto dalla Fondazione Toscana Gabriele Monasterio, un ente pubblico specialistico del Servizio Sanitario Regionale toscano. La Fondazione opera in ambito clinico in stretta collaborazione con l’ Istituto di Fisiologia Clinica del CNR e le Universit´a, occupandosi della gestione e sviluppo delle attivit´a sanitarie specialistiche e di ricerca di interesse del SSR Toscano. In particolare costituisce un centro altamente specializzato nella cura delle patologie cardiopolmonari, comprese quelle rare di interesse specifico.
La Fondazione opera in due sedi: a Pisa presso l’ Istituto di Fisiologia Clinica CNR, e a Massa presso l’ Ospedale del Cuore ”G.
Pasquinucci”.
Presso la Fondazione, il paziente ´e al centro di un sistema multidisciplinare che offre i pi´u moderni ed appropriati percorsi preventivi, diagnostico-terapeutici e riabilitativi, grazie all’ alto profilo delle competenze disponibili, alla disponibilit´a delle tecnologie pi´u avanzate per la diagnostica funzionale, d’ immagine e di laboratorio ed alla completa informatizzazione delle attivit´a cliniche e di gestione. Oltre all’ attivit´a clinica, presso la Fondazione ´e estremamente
rilevante anche quella di ricerca nell’ ambito sanitario e delle tecnologie applicate alla sanit´a: dall’esperienza dell’attivit´a clinica ogni dipartimento ed unit´a operativa trae spunti per l’investigazione di ricerca e, dai risultati dalla ricerca e dell’innovazione nascono nuovi suggerimenti per il miglioramento della pratica clinica.
Ultime, ma non per importanza, sono le attivit´a svolte in ambito di formazione e didattica, tese all’ aggiornamento del personale sanitario e del training degli allievi ordinari e dei perfezionandi nelle Discipline Mediche e delle Professioni Sanitarie.
Dal punto di vista organizzativo la FTGM ´e suddivisa in quattro dipartimenti clinici principali:
dipartimento cardiotoracico dipartimento pediatrico dipartimento di imaging area critica
Al loro fianco si pone il dipartimento per le tecnologie,
particolarmente avanzato ed integrato nella pratica quotidiana delle attivit´a sanitarie e di ricerca. A completare l’ assetto organizzativo troviamo infine le unit´a operative ed uffici della direzione sanitaria e della direzione amministrativa, oltre allo staff della direzione generale.
3
Il Sistema di Governo (SDG)
Il primo Sistema di Governo per Aziende Ospedaliere ´e nato all’ interno della Fondazione Toscana Gabriele Monasterio (da qu´ı FTGM), ed ´e in produzione dal 1999. Nel 2004, per rispondere ai cambiamenti della normativa sui software open-source nella Pubblica Amminitrazione, ´e stato trasformato utilizzando il framework BMF. Con questo progetto ci si propone di aggiornarlo nuovamente, per avere sempre un sistema al passo con i tempi e garantire una risposta sempre adeguata alle richieste che deve soddisfare, pur mantenendo tutte le sue funzionalit´a.
3.1 Gli obiettivi
SDG si propone innanzi tutto come software open-source, come tutti i sistemi sviluppati all’ interno di FTGM. Questo rapperesenta
ovviamente un grosso vantaggio per le aziende che ne usufruiscono, in quanto permette loro di avere un sistema all’ avanguardia e di
risparmiare molto capitale.
Figura 1: Come si presentava ad oggi SDG
E’ inoltre accessibile in modo molto semplice, solo utilizzando una comune interfaccia web.
Il sistema permette di ottenere in real-time tutti i dati sia clinici (quindi informazioni sui pazienti) che amministrativi (ad esempio il costo per l’ azienda di ogni prestazione effettuata) ed ´e quindi in grado di rispondere sia alle necessit´a di tipo operativo ed
organizzativo, che a quelle di tipo gestionale e decisionale, ponendosi come strumento di supporto nelle decisioni aziendali strategiche. Tra i principali obiettivi che il Sistema di Governo garantisce abbiamo:
raccolta ed archiviazione di informazioni puntuali, come report di attivit´a e misurazione di performances.
permettere ad ogni utente di effettuare ricerche ed analisi personalizzate.
permettere ad ogni usufruitore di avere un sistema di supporto decisionale personalizzato e configurabile.
possibilit´a di effettuare confronti inter ed intra struttura. 3.2 Esempi di alcune funzionalit´a
SDG mette a disposizione numerose funzionalit´a con le quali gli utenti possono valutare rapidamente gli esiti e andamenti delle scelte di gestione, confrontare i risultati di attivit´a o archi temporali
differenti, effettuare confronti anche inter struttura ed in generale navigare tra i dati in modo semplice ed efficiente. Di seguito un breve elenco di quelle principali:
consultazione di grafici per il monitoraggio dei trend economici. pianificazione delle attivit´a (ad esempio attraverso calendari). costruzione di reports per la determinazione dei costi (ad es. per
centro di responsabilit´a) e dei ricavi (ad es. le tariffe per prestazione).
consultazione in real-time dei dati provenienti da Cup, Cartelle cliniche ed ADT.
3.3 La struttura
Ma come fa il Sistema di Governo a fornire tutte queste informazioni ai suoi utenti? Attraverso query piuttosto complesse (alcune lo sono davvero molto) SDG richiede tutti i dati amministrativi al Data Warehouse di Governo e con tali dati vengono costruiti i reports con il BMF. Il Data Warehouse lo si pu´o vedere come un enorme
contenitore nel quale confluiscono i dati provenienti da Database minori: i principali sono il G2 (per i dati del CUP e ADT) e i LABPI e LABMS (per i dati di Laboratorio di Pisa e Massa). Il CUP,
acronimo di Centro Unico di Prenotazione, ´e il servizio che consente ai cittadini di prenotare online l’ accesso ai servizi sanitari con una notevole riduzione dei tempi d’ attesa. ADT invece sta per
Accettazione/Dimissione/Trasferimento e, come suggerisce il nome, ´e il sistema software che consente la gestione dei flussi legati alle ammissioni dei pazienti, i loro eventuali trasferimenti di reparto e le dimissioni. Per quanto riguarda i dati clinici, questi vengono richiesti direttamente ad un altro Database: l’ ARCA-C7.
4
I sistemi di Warehousing: breve
descrizione e principali features
I Data Warehouse, nati negli anni ’90, sono sistemi che raccolgono grandi quantit´a di dati provenienti da fonti (sistemi operazionali) differenti, che sono stati aggregati, integrati e strutturati in modo da facilitare l’ analisi di una certa attivit´a e consentire supporto
decisionale nella stessa.
Nell’ ambito di questo progetto, come gi´a accennato, il Data Warehouse contiene i dati amministrativi e li organizza in modo diverso rispetto ai comuni Database. Vista la quantit´a di dati che vengono richiesti con ogni singola query sarebbe stato impossibile realizzare il Sistema di Governo senza l’ ausilio del Sistema di Warehousing.
4.1 Caratteristiche e confronto con i Data Base:
Di seguito vengono elencate le principali caratteristiche di un sistema di Warehousing:
DISOMOGENEITA’: i dati possono provenire da sorgenti diverse e quindi non essere omogenei tra loro. Non ´e raro, ad esempio, scoprire che uno stesso item ´e stato chiamato con nomi differenti. Per questo i dati stessi necessitano di un’ operazione di filtraggio e pulizia da eseguire precedentemente al loro inserimento nel Data Warehouse (tale operazione avviene nella cos´ı detta ”staging area”).
ARCO TEMPORALE: la mole di dati memorizzata nel
Warehouse ´e elevata e copre un lungo intervallo temporale (dai 5 ai 10 anni). Si vuole infatti avere su tali dati una visione globale e d’ insieme per poterne estrarre trend, reports e statistiche: guardiamo quindi oltre l’ informazione fornita dal singolo dato e record.
CARICAMENTO DATI: dopo l’ operazione di trasformazione dei dati che li rende adatti ad entrare nel sistema, questi vengono inseriti con una certa periodicit´a dai soli
amministratori. L’ inserimento, inoltre, viene fatto esclusivamente quando il Warehouse ´e offline.
QUERYING: i dati, una volta inseriti, non vengono mai modificati: si capisce quindi come la principale operazione effettuata sia la loro lettura attraverso query. Nei DB invece i dati possono essere modificati, cancellati e caricati anche dagli utenti.
DENORMALIZZAZIONE: Per Normalizzazione si intende il processo di eliminazione o massima limitazione della ridondanza dei dati, nonch´e della loro incoerenza. Questo comporta di organizzare i dati in tabelle che rispettino precise regole di normalizzazione, collegarle tra loro con l’ uso di primary-key e foreign-key ed effettuare operazioni di join in runtime. Mentre nei DB i dati seguono questo processo, nel Data Warehouse non sono normalizzati. La principale ragione ´e che le interrogazioni ai Warehouse sono in genere complesse e accedono a grandi quantit´a di dati, quindi la normalizzazione renderebbe il loro costo computazionale e tempo di esecuzione eccessivi.
MULTIDIMENSIONALITA’: Al contrario dei DB, che
utilizzano principalmente il modello relazionale per definire la propria struttura, i sistemi di Warehousing usano quello Multidimensionale, che ´e brevemente spiegato nel successivo paragrafo.
4.2 Il modello Multidimensionale: concetti basilari
Il Modello Multidimensionale ´e stato proposto per la prima volta da Ralph Kimball nei primi anni ’90, con l’ obiettivo di rendere il Data Warehouse pi´u veloce limitando il numero di operazioni di join tra le tabelle. Con questo modello la struttura del Warehouse e l’
organizzazione delle sue tabelle ´e rappresentata nel cos´ı detto Schema a stella (Star Scheme).
I principali elementi che costituiscino tale schema sono:
FATTO: tabella molto ampia che pu´o contenere milioni di record riguardanti un evento dinamico sul quale vogliamo svolgere ricerche. La primary-key di questa tabella ´e costituita dalla sequenza delle sue foreign-keys.
DIMENSIONI: sono le caratteristiche del fatto rispetto alle quali si potrebbero raggruppare gli eventi. Ad ogni dimensione
corrisponer´a una tabella in fase di implementazione. Tali tabelle sono relativamente piccole e contengono colonne di tipo
descrittivo.
MISURA: caratteristica del fatto di dominio numerico sulla quale vogliamo svolgere delle operazioni (ad esempio somma o media).
Il modello largamente pi´u utilizzato ´e quello tridimensionale.
Da questa breve descrizione del sistema di Warehousing e del perch´e venga utilizzato possiamo dedurre la sua importanza nei passi successivi di questo progetto: fornire agli utenti finali i risultati di query complesse che restituiscono una grande mole di dati sopratutto di tipo numerico e rappresentare tali risultati attraverso reports, grafici e viste in modo da renderli comprensibili e adatti ad effettuare analisi e statistiche.
5
Preparazione dell’ ambiente di
lavoro
La FTGM dispone di un Data Warehouse di Governo che raccoglie dati sia clinici che amministrativi e di un applicativo web che, tramite un’ interfaccia utente, permette alle figure autorizzate di accedere in real time ai dati relativi alle varie prestazioni effettuate, ai costi ed ai ricavi, in modo da poter fare previsioni future sulle quali basare le scelte amministrative che ´e necessario prendere all’ interno di una Struttura Ospedaliera. Tuttavia tale interfaccia era stata realizzata usando la vecchia versione del framework BMF, uno strumento noto conosciuto durante i corsi accademici, che oggi non risulta pi´u avere i giusti requisiti per soddisfare l’ utente. Il nuovo applicativo doveva invece sfruttare la versione 3.0 del framework, tutta da scoprire. E’ sorta cos´ı la necessit´a di creare un ambiente di lavoro
”multi-applicativo”, che permettesse cio´e una prima fase di studio del nuovo BMF e successivamente la creazione della nuova interfaccia utente.
5.1 Descrizione dell’ architettura e dei software da utilizzare
L’ utilizzo del BMF per la creazione di applicazioni obbliga il programmatore a predisporre di una piattaforma a tre livelli
(Web-Application Server-Database) in grado di eseguire codice Java. L’ utente che decide di utilizzare l’ applicazione utilizzer´a un comune browser di ricerca ( per questo progetto si ´e scelto Mozilla Firefox) per collegarsi al web ed inviare la propria richiesta di accesso all’ Application Server. Web ed Application comunicano infatti tramite protocollo TCP-IP utilizzando la porta 8080. Ciascun utente deve possedere delle credenziali d’ accesso (login e password) e tali credenziali devono essere memorizzate all’ interno del DB cos´ı che quando l’ Application lo interroga tramite query per ottendere i dati dell’ utente, la sua autenticazione va a buon fine. Application e Database comunicano tramite protocollo SQL*Net utilizzando la porta 1521. A questo punto tutti gli oggetti associati al profilo con cui l’ utente si ´e autenticato vengono caricati in una nuova sessione. La scelta dei software con i quali implementare tale architettura si ´e basata sull’ esperienza passata: quella decennale del team di
Figura 2: Architettura a 3 livelli
accademici. Come Database si ´e quindi optato per Oracle Database 11g Release 2.0 dell’ azienda Oracle, sicuramente leader nella gestione delle banche dati.
Per quanto riguarda l’ Application Server la scelta ´e invece ricaduta su Apache Tomcat 7.0 dell’ azienda Apache Software Foundation, un software open-source che fornisce una piattaforma per l’esecuzione di applicazioni web sviluppate in linguaggio Java. All’ interno del Tomcat coesistono in realt´a sia l’ Application Server che il Web Server.
Era necessario installare anche un software per la gestione delle tabelle, degli indici e delle viste: ´e stato scelto un altro strumento gi´a ampiamente conosciuto sia all’ interno della fondazione che dagli studenti, il Toad for Oracle Release 10.6: in particolare questo strumento ha il ruolo di client nell’ architettura. Poich´e fa anch’esso parte della famiglia Oracle ´e stata garantita la massima compatibilit´a tra gli strumenti.
5.2 Creazione dell’ ambiente di lavoro
L’ ambiente di lavoro ´e stato creato all’ interno di una macchina virtuale, installata su un computer portatile Sony modello Vaio
fornito dalla FTGM. L’ uso della macchina virtuale permette di poter effettuare il backup dell’ intero sistema in modo semplice, qualora fosse necessario.
La macchina virtuale ´e stata creata utilizzando il software Oracle VM Virtual Box, che permette, semplicemente specificando il nome da assegnare alla macchina e il sistema operativo, di creare un
ambiente del tutto indipendente rispetto a quello del Pc sul quale ´e installato il software.
Come sistema operativo ´e stato scelto Windows 7 Professional Edition a 32bit, perch´e ´e quello maggiormente compatibile con la versione del Database Oracle utilizzata.
Una volta ottenuta la macchina pronta all’ uso vi sono state
importate sopra entambe le versioni del BMF necessarie: la seconda per accedere ai report del vecchio SDG, la terza per creare quelli del nuovo. Ma era solo l’ inizio e mancavano ancora i dati con cui
popolare tali report; ´e stato quindi caricato anche il file di estensione .dmp (file derivanti dall’ export di database) corrispondente all’ SDG, per fare successivamente l’ import vero e proprio dei dati.
Ovviamente tutti questi trasferimenti di files (compresi quelli dei software da installare) dal computer esterno al computer virtuale non potevano essere fatti direttamente. Per ovviare al problema ´e stata creata un’ apposita cartella condivisa che mettesse ”in congiunzione” i due sistemi e all’ interno della quale ´e stato messo tutto ci´o che doveva essere passato da un pc all’ altro. La condivisione di una cartella con un sistema virtuale ´e un’ operazione molto semplice che si pu´o effettuare selezionando l’ opzione ”Condividi Cartelle” dalle impostazioni della macchina virtuale alle quali si accede direttamente da Virtual Box.
Il passo successivo sarebbe stato quello di creare un nuovo utente che potesse accedere all’ SDG ed assegnargli uno spazio di lavoro
(tablespace), ma all’ atto della creazione di tale spazio si ´e riscontrato che la macchina virtuale creata aveva una memoria troppo piccola per contenere le tablespace. Si ´e quindi cercata una soluzione al problema e alla fine, grazie all’ aiuto di un membro dello staff della FTGM, ´e stata trovata la procedura adatta per poter estendere la memoria della macchina virtuale. Di seguito una breve descrizione dell’ intera procedura: a partire dal disco piccolo esistente se ne deve creare una copia utilizzando l’ apposito comando delle impostazioni della nostra macchina su Virtual Box. Si deve avere cura di salvare la copia con estensione .vdi, perch´e questo ´e l’ unico formato estendibile. Si deve poi obbligatoriamente creare una nuova macchina virtuale (chiamata BMFEstesa) e nella GUI che si apre si deve scegliere l’ opzione ”Usa un file di disco fisso virtuale esistente” andando a specificare il disco appena copiato. Purtroppo sia la procedura di copia che quella di
creazione della macchina hanno richiesto un tempo abbastanza lungo. Poi si deve digitare dal prompt dei comandi la riga di codice
C : \P rogramF iles\Oracle\V irtualBox >
V BoxM anagemodif yhd”P ERCORSODELDISCO” − −resize e specificare dopo il resize la nuova dimensione da dare al disco: questo comando opera l’ estensione. E’ stata estesa di 100 GB.
Arrivati a questo punto ´e stato riscontrato un nuovo problema, infatti il comando effettuato dal prompt falliva perch´e non si avevano i diritti di amministratore per eseguirlo. Allora per essere certi di non avere pi´u questo problema ´e stato disinstallato e re installato Virtual Box eseguendo la procedura come amministratore ed ´e stato poi necessario ri eseguire l’ intera procedura di estensione effettuando ogni operazione con un click sul tasto destro del mouse e scegliendo ”Esegui come amministratore”. Cos´ı facendo si ´e potuta completare l’ estensione: gli ultimi passi consistevano nell’ avviare la BMFEstesa ed eseguire la procedura ”Estensione guidata volume” per utilizzare anche lo spazio appena aggiunto all’interno del disco fisso virtuale VirtualBox.
6
Costruzione della webapp
In questo capitolo verranno descritti i passaggi fondamentali che ´e necessario eseguire per tirare su una webapp che si appoggi su un Database e che sia accessibile tramite il web.
In realt´a per questo progetto si sono utilizzate non una, ma ben tre applicazioni: il vecchio SDG in produzione che sfrutta il BMF 2, il nuovo SDG ed un’ ultima app che semplicemente ha permesso lo studio del BMF 3.
Le operazioni fondamentali che devonono essere eseguite sono la creazione di un proprio utente, permettere al Tomcat di gestire le webapps ed effettuare gli import dei due SDG.
6.1 Creazione di un nuovo utente
Per creare un nuovo utente che possa lavorare con i dati si deve innanzi tutto accedere al Toad e connettersi come uno degli utenti interni del db (SYS o SYSTEM) che sono sempre presenti e hanno i diritti per accedere a tutto e compiere qualsiasi operazione.
Si deve poi creare una TABLESPACE per i dati. La tablespace ´e il luogo di archiviazione di tabelle, indici ecc... In un Database sono sempre presenti una o pi´u tablespace e ciascuna contiene uno o pi´u datafiles. Per crearala si deve eseguire, nell’ apposita GUI del Toad, l’ istruzione SQL che comincia con CREATE TABLESPACE nella quale si specifica il nome da assegnare e lo spazio da destinare (sono stati dati 5 GB). Si ´e ripetuta un’ istruzione della stessa forma anche per creare gli Indici (CREATE INDEX ), ai quali ´e stata assegnata una dimensione di 1.5 GB.
Ora ´e possibile creare l’ utente: dopo avere cliccato su ”Database” e poi ”Create” e ”User” si pu´o inserire il nome dell’ utente, stabilire la sua password e assegnargli tutti i diritti (GRANT) di cui disporr´a. Gli sono stati assegnati: DBA (Database Adminitsrator), EXPORT, IMPORT, CONNECT e RESOURCES (permette di accedere a tutte le risorse). Le seguenti immagini illustrano degli esempi dei vari passaggi.
Figura 3: Connessione
Figura 5: Assegnazione diritti
Infine il profilo dell’ utente appena creato si deve aggiungere come nuovo record nella tabella T PROFILO del BMF e automaticamente lo troveremo anche all’ interno della REL UTENTE PROFILO che ci mostra, per ogni utente, tutti i suoi profili.
6.2 Gesione delle app con il Tomcat
Ogni application costruita tramite il Tomcat ´e definita da un insieme di cartelle, ognuna contenente file specifici, raccolte sotto una
directory principale che ha lo stesso nome dell’ applicazione stessa. Questa directory deve essere copiata nel file system al percorso
C : \P rogrammi\ApacheSof twareF oundation\T omcat7.0\webapps. Come detto precedentemente per questo progetto sono state
necessarie tre applications e quindi tre directories da copiare: la SDG, la SDGBMF3 e la BMF3.
Tra le varie sottocartelle particolarmente importanti sono la
WEB-INF, all’ interno della quale troviamo il file di log e un’ altra cartella, la classes, che contiene i file .class delle classi Java che compongono il nostro sito Web, e la cartella LIB che invece contiene le opportune librerie in file di tipo Jar.
Si devono poi configurare le singole webapps in modo da permettergli la connessione con il Database tramite il Tomcat. Per fare ci´o si deve accedere ad uno specifico file al percorso T omcat \ conf e all’ interno
del file specificare l’ indirizzo a cui si trova il server e le credenziali dell’ utente (username e password). Per semplicit´a abbiamo assegnato le stesse credenziali a tutte e tre le applicazioni.
Compiendo queste operazioni ogni applicazione pu´o gestire le proprie connessioni in autonomia e per collegarsi ad una di esse tramite il web sar´a sufficiente digitare l’ URL http://127.0.0.1:8080:nome
applicazione, dove il 127.0.0.1 ´e il cos´ı detto localhost e 8080 ´e la porta di comunicazione.
Infine, per completare la configurazione e rispettare le regole di sicurezza, login e password devono essere criptate.
6.3 Import del sistema di governo
Per fare l’ import del vecchio SDG ´e stato innanzi tutto necessario copiare il corrispondente file di estensione .dmp (sdg.dmp) nella cartella che si trova al percorso C : \app \ admin \ orcl \ dpdump. E’ molto importante assicurarsi di copiare il file sotto la cartella giusta perch´e ´e l´ı che Oracle lo andr´a a cercare per importarlo.
Si deve poi aprire il prompt dei comandi e lanciare il seguente comando: impdp<username>/<password>directory=
<directoryname>dumpfile=<filename>.dmp logfile=<filename>.log full=y, sosotituendo con gli opportuni parametri i tag tra le parentesi < >. Dopo aver eseguito il comando ´e possibile accedere tramite il Toad alle varie tabelle importate. Dopo aver importato il vecchio SDG ci si ´e accorti che alcune di queste avevano degli errori e ci´o era dovuto al fatto che si appoggiavano ad un sistema per la gestione degli accessi che per´o non era presente sul db. Quando un utente cerca di accedere all’ applicazione, infatti, tale sistema procede alla sua autenticazione tramite la verifica delle sue credenziali e questo viene fatto attraverso delle funzioni che accedono ai dati memorizzati nelle tabelle del sistema di autenticazione stesso. Per evitare di dover importare anche questo si sono sostituite tali funzioni con i nomi delle tabelle e viste gi´a presenti nel nostro schema (come la V UTENTE, V UTENTE PROFILO o la V PROFILO) in modo da poter accedere agli stessi dati, ma in modo diretto bypassando il compito del sistema di autenticazione.
Tutti i passi si sono dovuti ripetere anche per il nuovo SDG: il file da copiare era questa volta l’ SDGBMF3.dmp, poi si ´e eseguito dal
prompt il comando descritto sopra e nuovamente si sono sostituite le funzioni che si basavano sul sistema di autenticazione.
Durante questa fase di import, poich´e si ´e lavorato con due files .dmp diversi, oltre a posizionare tali files al percorso giusto ´e stato
essenziale rinominarli con due nomi distinti altrimenti durante l’ esecuzione dell’ import si pu´o incorrere in errori.
7
Dal BMF 2.X al BMF 3.0
Il Biomedical Framework, in seguito BMF, ´e un tool di sviluppo che permette di realizzare applicazioni web dinamiche basate su
piattaforma open-source. Tramite queste applicazioni ´e possibile sia effettuare le classiche operazioni di ricerca, visualizzazione in forma tabellare o di grafici e data entry, sia gestire questionari, documenti e file, alberi, motore di ricerca, sicurezza ed altro ancora.
Grazie all’ uso del BMF il programmatore ´e facilitato nello sviluppo della propria applicazione in quanto pu´o disporre di templates pre realizzati che necessitano solo di una minima parte di
personalizzazione ed ´e richiesta la sola conoscienza approfondita del linguaggio SQL e HTML di base.
La prima versione del framework risale al 2004 ed era stata utilizzata per realizzare il Sistema di Governo dell’ ASL 12 di Viareggio. Da allora ´e stato utilizzato in numerosi progetti sia in ambito
amministrativo che clinico, di governo e di ricerca. La seconda release si ´e sviluppata dal 2005 al 2015 come frutto della collaborazione di programmatori, ricercatori e studenti. L’ ultima versione, la 3.0, ´e nata ed ha iniziato a diffondersi nel 2015.
Chiaramente nel corso di questa evoluzione sia il BMF che il
Database su cui si poggia hanno subito una serie di aggiornamneti e modifiche, ma alcune caratteristiche fontamentali sono rimaste inalterate e verranno presentate nel prossimo paragrafo.
7.1 Il Database del BMF
Per utilizzare il BMF ´e innanzi tutto necessario che le tabelle del suo Database (di tipo relazionale) cos´ı come quelle dell’ applicativo che si intende realizzare, rispettino delle precise regole di naming:
Il nome della tabella deve essere del tipo T NOME TABELLA La Primary Key deve essere sempre il primo campo della tabella
e deve avere nome del tipo T NOME TABELLA CODICE La Foreing Key deve avere nome del tipo T NOME TABELLA
COLLEGATA CODICE
Tutti gli altri campi devono avere nome del tipo T NOME TABELLA NOME CAMPO
I Constraint per la Primary Key e la Foreign Key devono obbligatoriamente cominciare con PK e FK
Regole analoge devono essere rispettate anche per tutti gli altri oggetti del Database, ad esempio:
Le Viste si devono chiamare V NOME VISTA I Trigger si devono chiamare T NOME TRIGGER
Le Procedure si devono chiamare P NOME PROCEDURA eccetera.
Il Database del BMF ´e molto vasto e contiene molte tabelle, ognuna ovviamente con un ruolo ben preciso. L’ utilizzo di alcune di queste ´e facoltativo, ma altre, quelle fondamentali, vengono sempre gestite dagli utenti del BMF. Queste tabelle rappresentano il cuore del funzionamento del sistema e sono:
T OGGETTO: contiene tutti gli oggetti costruiti con il BMF T LABEL: permette la gestione multilingua
T TIPO: contiene le informazioni riguardo alla tipologia dell’ oggetto che si ´e creato (pulsante, tabella, vista ecc..)
T PERIODO: contiene le informazioni riguardo al periodo di validit´a degli oggetti
REL MENU OGGETTI: permette di costruire la navigazione del sito
T PROFILO: contiene tutti i profili da associare ai vari utenti T UTENTE: contiene le informazioni riguardanti gli utenti, tra
cui, molto importanti, sono login e password
REL OGGETTO PROFILO: permette di associare ad un profilo i vari oggetti che esso pu´o gestire. In questo modo se un utente ha pi´u profili ´e possibile diversificare gli oggetti sui quali pu´o agire con ciascuno
REL UTENTE PROFILO: permette di associare i vari profili agli utenti ai quali appartengono
T PASSWORD: contiene le password (criptate) scadute dei vari utenti. Ciascun utente ha infatti l’ obbligo di rinnovare la propria password ogni 3 mesi e pu´o ri utilizzare una vecchia password solo dopo 3 cambi. Questo, insieme all’ utilizzo di certificati a 128 bit, l’ uso del protocollo HTTPS e la
cancellazione logica dei dati, permette di gestire la sicurezza nel BMF.
T SEQ: permette di gestire in automatico i codici numerici progessivi dei record di ogni tabella
T LOGSTAMPA T STAMPA EXPORT
A parte le ultime tre, le altre tabelle sono fondamentali per la
gestione degli oggetti e dei profili. Il modo in cui sono legate tra loro ´e rappresentato dallo Schema Concettuale della figura seguente.
Lo Schema Concettuale completo del Database del BMF ´e
ovviamente molto pi´u ampio e non sar´a qui rappresentato. Oltre alla gestione degli utenti e dei profili i suoi ”moduli” principali
comprendono la gestione dei documenti, la gestione dei questionari, la gestione degli alberi e la gestione del data entry per riga, uno speciale tipo di data entry che permette di costruire tabelle con un numero di campi variabile.
Nel passaggio dalla versione 2.x alla 3.0 questa struttura fondamentale ´e rimasta intatta, ma numerosi sono stati gli aggiornamenti.
7.2 Principali differenze ed analogie tra le due versioni La prima cosa che si pu´o notare accedendo ad una applicazione realizzata con il BMF 3.0 ´e sicuramente un aggiornamento della grafica, resa molto pi´u moderna. L’ aspetto grafico nel BMF viene gestito esternamente all’ applicazione, utilizzando file css, cio´e file che permettono la personalizzazione dell’ aspetto di una pagina web senza dover agire sul codice della stessa.
Per quanto riguarda gli oggetti astratti che ´e possibile creare per realizzare il proprio applicativo, quelli presenti nella versione 2.x sono stati tutti resi disponibili anche nella nuova, ma alcuni di essi hanno cambiato le loro carateristiche e ne sono stati aggiunti altri. Con il BMF 2.x era possible creare:
PULSANTI
REPORT: Corrisponde a fare un data entry. Pu´o essere semplice (standard) oppure paginato o per riga e vi ´e la possibilit´a di inserire combo collegate, pop up, campi con l’ autocomplete e sottomen´u (pulsanti interni).
VISTE: Consentono la sola visualizzazione dei dati e non l’ inserimento. Vi ´e la possibilit´a di rappresentare i dati per riga o per colonna.
FILTRI: Possono essere semplici oppure consentire anche la modifica dei dati. Si possono inoltre realizzare filtri dinamici, filtri confronto (quando i parametri di ricerca devono essere fissi), filtri con range sullo stesso campo e filtri per la visualizzazione degli alberi.
GRAFICI: Si possono creare torte, istogrammi, aree, grafici XY o il tachimetro. Vi ´e la possibili´a di calcolare totali e percentuali. HELP
CALENDARI QUESTIONARI
ALBERI: Vi ´e la possibilit´a di definire tutte le strutture dell’ albero (radici, rami e foglie) ed associare un link ad ogni nodo. DOCUMENTALE
Altrettanto rilevanti sono le rimanenti funzionalit´a: gestione della navigazione del sito, abilitazione degli utenti (per determinare chi pu´o vedere cosa), storicizzazione dei dati, chiamate a store procedure, upload e download di file, possibilit´a di saltare da un sito all’ altro e di collegarsi a pi´u Database.
Tutto ci´o lo si pu´o ritrovare nel BMF 3.0, ma con qualche modifica ed aggiunta. Gli oggetti Report prendono ora il nome di Input Form ed oltre al tipo di base, paginato e tutti gli altri che era possibile
realizzare con in BMF 2.x, ora ´e disponibile anche l’ Imput Form con Inserimenti Multipli (utile per gestire le associazioni 1:N) e la
variante con Primary Key Automatica. Inoltre ´e possibile inserire per ogni campo delle caselle di tipo Checkbox oppure dei Radio Button. Per quanto riguarda i grafici (pi´u precisamente chiamati charts) i tipi disponibili sono aumentati: oltre alla torta, istogramma, area, grafico xy, tachimetro sono stati aggiunti la rappresentazione per colonna, il grafico a barre, la mappa geografica con regioni cliccabili e i Sub Reports. Questi ultimi consentono, avendo a disposizione un grafico di partenza, di selezionare uno dei suoi elementi (ad esempio lo spicchio di una torta) e ottenere un grafico secondario che mostra una
rappresentazione pi´u dettagliata dell’ elemento selezionato.
Per la realizzazione dei Report con Sottomen´u sono stati introdotti i Group Buttons, speciali pulsanti che compaiono sopra ad un Report (cio´e una ex Vista) e che consentono di passare da questo ad un altro che mosta informazioni di dettaglio maggiore su uno dei record del report ”primario”. L’ appellativo Group deriva dal fatto che con uno solo di questi oggetti se ne possono in realt´a creare molti, da legare allo stesso report ”primario”. Non devono essere confusi con i
Buttons, che consentono anch’ essi di passare da un oggetto all’ altro, ma sono slegati dall’ oggetto primario, cio´e non necessitano della selezione di un record per funzionare.
Tra i nuovi oggetti ci sono i Calendar, (per la realizzazione della visualizzazione per mese), le Action (che consentono di realizzare due tipi di pulsanti specifici: uno per ottenere gli Help e uno per ottenere la stampa in PDF) e i Subtitles (che consentono di inserire dei
sottotitoli tra in nome dell’ oggetto realizzato e l’ oggetto stesso). Infine totalmente nuovo ´e il modo di realizzare i link (prima si doveva specificare il nome della Servlet necessaria per realizzare l’ oggetto a cui il link rimandava, ora si creano tutti con la stessa forma) e le Query strig che ´e possibile inserire all’ interno di essi.
Gli aggiornamenti sopra descritti riguardano le funzionalit´a e gli oggetti messi a disposizione dal BMF 3.0, ma il cambiamento senza dubbio principale sta nel modo in cui questi oggetti vengono gestiti, configurati e personalizzati. Di tutto questo adesso si occupa il Json.
7.3 Il Json
Json, acronimo di JavaScript Object Notation, ´e un formato per la serializzazione dei dati e lo scambio di messaggi all’ interno di un’ applicazione Client/Server. Il suo nome si deve al fatto che ´e basato su linguaggio JavaScript, anche se ne ´e indipendente. La sua
diffusione e il suo successo sono molto recenti, e si devono alla sua facilit´a di utilizzo da parte del programattore, la rapidit´a di
elaborazione da parte della macchina ed il fatto che sia un formato universale e supportato da tutti i principali linguaggi di
programmazione. Grazie ai formati di questo tipo oggi il modo di navigare ´e cambiato notevolmente. Prima, in seguito ad una richiesta HTTP, veniva generata una pagina HTML da consultare con un Browser. Tale pagina doveva (e deve ancora oggi) esssere realizzata lato server e per aggiornare i suoi contenuti si doveva effettuare una nuova richiesta per una nuova pagina. Oggi invece se vogliamo aggiornare solo una parte dei contenuti della pagina ´e sufficiente inviare al server un messaggio, ad esempio in formato Json, e saranno restituiti solo tali dati.
In pratica il principale grande vantaggio dell’ utilizzo di questo
formato ´e che permette di scollegare completamente la parte server da quella client: con il nuovo sistema si potrebbe anche montare sul
server una parte client diversa, mentre nel vecchio erano strettamente legate.
Dal punto di vista della sintassi, l’ uso del Json si basa principalmente su due strutture: coppie nome/ valore ed elenchi ordinati di valori. Una serie non ordinata di coppie nome/ valore costituisce un oggetto, che deve essere necessariamente definito all’ interno delle parentesi {}. Le coppie inserite all’ interno devono essere del tipo ”nome” :
”valore” e devono essere separate da una virgola. Il valore pu´o essere una stringa (deve essere contenuta tra apici), un numero, un booleano (vero o falso) o altro. Un oggetto pu´o contenere anche degli array, cio´e raccolte ordinate di valori. Questi devono essere racchiusi tra le parentesi [] e gli elementi devono essere separati da una virgola. Quando si utilizza il Json ´e essenziale rispettare tutte queste regole sintattiche perch´e se il sistema riscontra una loro violazione
restituisce un errore.
Figura 7: Esempio di definizione di un oggetto con il Json
L’ uso del Json all’ interno del BMF ha permesso di rivoluzionare completamente la creazione e configurazione di tutti gli oggetti, semplificandola enormemente.
Quando si crea un nuovo oggetto si deve valorizzare una serie di campi ad esso associati. Nel BMF 2.x questi erano:
Nome: nome dell’ oggetto, da attribuire seguendo le regole di naming del BMF.
Link: link nel quale ´e specificata la Servlet di riferimento per l’ oggetto.
Etichetta/ Titolo: titolo da visulaizzare in testa alla pagina. Titolo stampa: titolo da visualizzare nella stampa.
Descrizione estesa: descrizione letterale dell’ oggetto.
Sottomen´u: codici dei sottomen´u da associare a tale oggetto. Elenco campi: elenco dei campi della tabella e dei textfield per l’
inserimento dei dati. Questo ´e anche il campo che doveva essere gestito per inserire eventuali Combo Collegate, Pop up o
Autocomplete e per calcolare totali e percentuali.
Query per vista: query per generare e popolare una tabella. Query per editing campi: query per generare i textfield. Tipo: tipo dell’ oggetto (ad esempio Tabella o Vista). Ordine: numero che determina la posizione dell’ oggetto se
questo viene inserito in un elenco (Men´u).
Classe java: nome della classe java di riferimento, che doveva necessariamente essere generata prima di poter usare l’ oggetto nel BMF.
DB: nome di un eventuale Database esterno al quale ci si vuole collegare.
Refresh: numero che indica i secondi ogni quanto si vuole attivare il refresh della pagina.
Controlli aggiuntivi js: da valorizzare con il riferimento ad un file JavaScript qualora si volesse aggiungere un controllo js. Save as: da valorizzare con S se si vuole permettere il save as di
Salva Editing maiuscolo: se valorizzato con S salva i dati tutti in maisuscolo.
Non tutti i campi sono obbligatori per ogni oggetto.
La lista di configurazione nel BMF 3.0 si ´e notevolmente ridotta: i campi da valorizzare sono il nome, descrizione, link, DB, query (solo una, la ex query per vista), ordine e il nuovo campo per il codice Json. E’ qui che viene fatto tutto il resto del lavoro andando a definire un oggetto all’ interno del quale si inseriscono le coppie nome-valore che permettono di personalizzare l’ oggetto stesso. Alcune chiavi (cio´e nomi) principali sono ”type” per il tipo dell’ oggetto, ”label” per definire il titolo che sar´a visualizzato in testa alla pagina, ”fields” che definisce sotto forma di array i campi che si trovano dopo l’ istruzione SELECT della query in caso si voglia realizzare un Report, oppure i campi sui quali effettuare un filtraggio in caso di Filtro, e ”idx” per elencare i campi che si vogliono
visualizzare come colonne di una tabella.
Nell’ array che contiene i campi ogni elemento ´e a sua volta una coppia nome-valore dove il valore ´e in realt´a un oggetto all’ interno del quale si definiscono tutte le caratteristiche del campo (ad esempio se si vuole l’ Order By o se vi si vuole associare una Combo).
Rispetto al vecchio sistema forse talvolta ´e necessario scrivere qualche riga in pi´u, ma l’ utilizzo del Json rende tutto molto pi´u intuitivo.
7.4 Studio ed esempi delle funzionalit´a del BMF 3.0
Per acquisire familiarit´a con le nuove caratteristiche del BMF ´e stato opportuno iniziare con lo studio approfondito della Guida al BMF 3.0, disponibile semplicemente accedendo al sistema. La guida offre una descrizione per ogni oggetto e funzionalit´a che ´e possibile realizzare ed un esempio applicativo per ciascuno di essi. Dopo lo studio teorico si ´e passati alla pratica andando ad implementare una serie di esempi, almeno uno per ogni tipo di oggetto e concentrandosi soprattutto su quelli che costituiscono una novit´a del sistema. Per realizzarli si ´e utilizzata l’ applicazione creata appositamente, la BMF3. Per accedervi ci si deve collegare all’
indirizzo localhost:8080/ bmf3.x, dopo aver avviato il servizio del Tomcat.
Per prima cosa si ´e creata una nuova menu folder chiamata Menu prove 2016 che ´e stata inserita all’ interno del Menu Principale dell’ applicazione. Questa far´a da sottomen´u all’ interno del quale inserire tutti i report realizzati come esempi.
Figura 8: Menu prove 2016 inserito nel Menu Principale
Per inserire un item all’ interno di un men´u ci si serve dell’ apposito template che permette la Navigazione Sito e si seleziona il men´u padre desiderato.
Per creare i report si possono percorrere due strade: seguire la procedura guidata messa a disposizione dal sistema (Configura
oggetti ), oppure fare il Save as di uno gi´a esistente. In questo modo si ottiene una copia dell’ oggetto della quale cambiare il nome e la
configurazione per creare quello voluto. E’ essenziale ricordarsi di modificare l’ oggetto solo dopo averne fatto la copia, altrimenti l’ originale andr´a perso.
Gli esempi realizzati si basano su tabelle che sono state create usando il Toad e per ogni nuova tabella si ´e creata anche la corrispondente Sequenza, cio´e l’ oggetto che permette l’ incremento automatico della Primary Key (nel nuovo sistema non si usa pi´u la tabella T SEQ). Il codice SQL per la creazione di una sequenza ´e il seguente:
CREATE SEQUENCE BMF NOME TABELLA
INCREMENT BY 1 START WITH 1 MAXVALUE 1.0E27 MINVALUE 1 NOCYCLE
Per realizzare l’ Esempio di InputForm Semplice ´e stata creata la tabella T PROVA con campi T PROVA ID, T PROVA NOME, T PROVA COGNOME, T PROVA CITTA’ e T PROVA CAP. La figura sottostante mostra il risultato della configurazione: dopo aver inserito i record ´e possibile selezionarne uno cliccando sull’ ID (Primary Key) per poterlo modificare o eliminare.
Figura 9: Esempio di InputForm Semplice
Il codice Json con cui si ´e valorizzato l’ omonimo campo per ottenere l’ oggetto mostrato ´e il seguente:
{
”type”:”inputForm”, ”inputForm”:{
”title”:”Esempio InputForm Semplice”, ”tableName” :”T PROVA”,
”pk”:{”auto”:”S”,”fields”:[”T PROVA CODICE”]}, ”fields”:[{
”id”:”T PROVA CODICE”, ”name”:”T PROVA CODICE”, ”label”:”ID”, ”enable”:”N”, ”session”:”N”, ”type”:”text” }, {
”id”:”T PROVA NOME”, ”name”:”T PROVA NOME”, ”label”:”Nome”,
”session”:”N”, ”type”:”text” },
{”id”: ”T PROVA COGNOME”, ”name”: ”T PROVA COGNOME”, ”label”:”Cognome”,
”session”:”N”, ”type”:”text”, },
{
”id”:”T PROVA CITTA”, ”name”:”T PROVA CITTA”, ”label”:”Citt”,
”session”:”N”, ”type”:”text”, },
{
”id”:”T PROVA CAP”, ”name”:”T PROVA CAP”, ”label”:”CAP”,
”session”:”N”, ”type”:”text”, }], ”customization”:””, ”buttons”:[{”id”:”btn save”, ”name”:”btn save”,”label”:”Salva”,”iconClass”:”glyphicon glyphicon–floppy –saved”},
{”id”:”btn delete”, ”name”:”btn delete”,”label”:”Elimina”}, {”id”:”btn save as”, ”name”:”btn save as”,”label”:”Save As”}] } }
Di seguito sono descritti alcuni degli altri esempi realizzati:
Esempio di InputForm con Sottomen´u
Le tabelle usate sono la T REGIONE, con campi
T REGIONE CODICE e T REGIONE DESCRIZIONE e la T PROVINCE con campi T PROVINCE CODICE,
T PROVINCE DESCRIZIONE e T REGIONE CODICE come Foreign Key. E’ stato realizzato un Report che mostra il contenuto della T REGIONE, poi selezionando un record e cliccando sul GroupButton si ottiene un secondo Report che mostra i soli record della T PROVINCIE che hanno Foreign Key uguale all’ ID scelto. La figura precedente mostra inoltre i pulsanti per ottenere il PDF del Report, fare l’ export o mandarlo in stampa.
L’ oggetto GroupButton va configurato in questo modo:
{ ”type”:”group buttons”, ”group buttons”: { ”items”:[{ ”label”:”GB” ”link”:”#dispatcher/idObject=V Provincia&resetGB=N”} ]} }
Figura 10: Report ottenuto dalla T REGIONE
Prova InputForm con CheckBox e RadioButton
E’ stata innanzi tutto creata la tabella T VISITA con campi
T VISITA CODICE, T VISITA MEDICO e T VISITA PAZIENTE. Poi ´e stato configurato un oggetto InputForm in modo che ai possibili valori assunti dal campo MEDICO fossero associati dei RadioButton, mentre a quelli di PAZIENTE sono state associate delle CheckBox. I valori assumibili dai campi possono essere settati a mano se sono fissi, oppure tramite una SELECT su una tabella.
Figura 12: Prova InputForm con CheckBox e RadioButton
Un report cos´ı costruito permette di effettuare l’ inserimento di pi´u record alla volta. Infatti, mentre i RadioButton vincolano a dover scegliere un solo valore per il campo MEDICO, le CheckBox
consentono la selezione multipla sul campo PAZIENTE e per questo motivo la Primary Key della tabella ´e costituita dall’ insieme di tutti i campi.
E’ a questo punto necessario fare una precisazione che vale sia per gli esempi appena descritti sia per quelli che saranno presentati in seguito in questo paragrafo: questi Reports sono stati realizzati con il solo
obiettivo di esercitarsi nell’ uso del BMF 3.0 e nella configurazione degli oggetti tramite il Json in particolare, pertanto a questo scopo non ´e stato necessario curare la loro effettiva usabilit´a. Nel caso specifico del Report sulle Visite, ad esempio, la tabella T VISITA non ´e normalizzata (si dovrebbe avere una associazione 1:N tra una
tabella contenente i dati dei medici ed una contenente i dati dei pazienti) e non pu´o essere usata in un contesto diverso. Analogamente sarebbe impossibile avere un elenco di pazienti tra cui scegliere con delle CheckBox. Sempre per gli stessi motivi si ´e scelto di creare tabelle semplici e con pochi campi e le query alla base dei reports sono molto intuitive. Nella realizzazione del Sistema di Governo, al contrario, ciascun Report ´e generato legando tra loro numerosi oggetti diversi e le query sono quasi sempre molto lunghe e complesse.
Di seguito ´e riportata la configurazione Json per l’ InputForm con Checkbox e Radiobutton:
{
”type”:”inputForm”, ”inputForm”:{
”title”:”Esempio InputForm con Checkbox e Radiobutton”, ”tableName” :”T VISITA”,
”pk”:{”auto”:”S”,”fields”:[”T VISITA CODICE”]}, ”fields”:[{
”id”:”T VISITA CODICE”, ”name”:”T VISITA CODICE”, ”label”:”CODICE”, ”enable”:”N”, ”session”:”N”, ”type”:”text” }, {
”id”:”T VISITA MEDICO”, ”name”:”T VISITA MEDICO”, ”label”:”MEDICO”,
”session”:”N”, ”type”:”checkbox” },
”name”: ”T VISITA PAZIENTE”, ”label”:”COGNOME”, ”session”:”N”, ”type”:”radio”, } ], ”customization”:””, ”buttons”:[{”id”:”btn save”, ”name”:”btn save”,”label”:”Salva”,”iconClass”:”glyphicon glyphicon–floppy –saved”},
{”id”:”btn delete”, ”name”:”btn delete”,”label”:”Elimina”}, {”id”:”btn save as”, ”name”:”btn save as”,”label”:”Save As”}] } }
Esempio filtro dinamico
Per realizzarlo ´e stata creata la tabella T PAZIENTI con campi T PAZIENTI CODICE, T PAZIENTI NOME,
T PAZIENTI COGNOME, T PAZIENTI CITTA’ e
T PAZIENTI CAP. Si ´e poi configurato un oggetto filtro in modo da avere come parametro di ricerca il nome del paziente e si ´e impostato l’ attributo ”dynamic”:S per non avere un filtro semplice, ma di tipo dinamico.
Figura 13: Esempio filtro dinamico
Questo permette di decidere prima del filtraggio quali campi andare a visualizzare e tali campi possono essere scelti tramite CheckBox. Ovviamente ´e stato creato anche un oggetto Report semplice la cui query preleva i dati dalla T PAZIENTI.
{
”type”: ”filter”, ”filter”: {
’title’: ”Prova filtro dinamico”, ”collapse”:’S’
”dynamic”:’S’, ”fields”: [{
id: ’P Pazienti Nome id’, name: ’P Pazienti Nome’, label: ’Nome’, session:’S’, default: ”, placeholder: ’—’, type: ’text’ }],
”buttonText”: ”Invia Ricerca” }}
Di seguito ´e mostrato il risultato della selezione dei soli campi CODICE, COGNOME e CAP:
Esempio di grafico: il SubReport
Questo esempio mostra il numero di abitanti per regione attraverso un grafico a torta ed il numero di abitanti per provincia con un secondo grafico che si ottiene andando a scegliere una delle regioni (cio´e una delle fette della torta). Le tabelle di riferimento sono la T REGIONE con campi T REGIONE CODICE,
T REGIONE DESCRIZIONE e la T PROVINCE con campi T PROVINCE CODICE, T PROVINCE DESCRIZIONE,
T PROVINCE ABITANTI e la Foreign Key T REGIONE CODICE. Per semplicit´a sono state rappresentate solo alcune regioni e solo alcune province per ogni regione.
Il codice Json per ottenere la torta che rappresenta il numero di abitanti per regione ´e il seguente:
{
”type”: ”chart”, ”chart”: {
”title”: {label:”Numero abitanti per regione”}, ”type” : ”Pie”,
”xaxis”:{”label”:”Regione”,field:”T REGIONE NOME”}, ”series”: [{”label”:”REG”,field:”AB”, dynamic:S}], ”subreport”: ”querystring”:”idObject=G PROVINCE”, ”breadcrumb”:”T REGIONE NOME”,
params”:[{ value:”T REGIONE CODICE”, name:”T REGIONE CODICE”}]
Figura 15: Abitanti per regione
8
Realizzazione del nuovo SDG
Il Sistema di Governo che era stato realizzato con il BMF 2.x, come detto nel capitoli precedenti, permette di accedere a dati di natura sia clinica che amministrativa degli ospedali di Pisa e Massa. Le
principali operazioni che vengono compiute su tali dati sono ricerca, filtraggio, inserimento, modifica e consultazione di grafici.
Ovviamente lavorando come amministratori del sistema si ha il
controllo totale su ogni singolo oggetto, ma in generale ciascun utente pu´o accedere solo ad una porzione dei dati in base ai propri diritti e la struttura dell’ applicazione stessa ´e in parte personalizzata in base agli utenti (ad esempio gli alberi sono diversi a seconda di chi accede al sistema).
Nel passaggio dal vecchio al nuovo SDG realizzato con il BMF 3.0 ´e stato fondamentale assicurarsi che i dati su cui si ´e lavorato non subissero alcun tipo di alterazione, che potrebbe ad esempio derivare da una modifica alle query. Si tratta inoltre di dati sensibili, cio´e strettamente personali ed il cui trattamento pu´o avvenire solo in seguito all’ autorizzazione dell’ interessato, quindi nel rispetto delle normative sulla privacy non sar´a possibile mostrarli e diffonderli in questo lavoro di tesi.
Nel prossimo capitolo ne verr´a data per´o una descrizione generale.
8.1 Struttura dell’ SDG
Le informazioni necessarie alla dirigenza di una struttura Ospedialiera per governarla ed effettuare analisi su di essa sono moltissime e di diverso tipo. Per questo, oltre a limitarsi a dire che i dati trattati sono di tipo clinico ed amministrativo, verranno di seguito presentati un po’ pi´u dettagliatamente i vari report messi a disposizione dall’ SDG e la sua struttura.
Dal men´u principale dell’ applicazione ´e possibile osservare che i report sono suddivisi tra Attivit´a Sanitaria, Controllo di Gestione e i Dizionari. Ad ognuno di questi elementi corrisponde una men´u folder nel men´u principale, nel quale inoltre sono presenti un pulsante per i link (per accedere rapidamente alla Clinica WEB, alla Home FGM ed a Google), un pulsante per accedere alla Top Ten dei reports pi´u usati ed infine tutti quelli utili al creatore dell’ applicazione per occuparsi della gestione del sito.
Figura 17: Men´u principale dell’ SDG
All’ interno della cartella Attivit´a Sanitaria sono racchiusi i Dati Archiviati, i Dati in linea ed i Reports&Indicatori.
I Dati Archiviati sono dati amministrativi con i quali si studiano le prestazioni effettuate e le attivit´a svolte dalle strutture in esame e dai quali si rivacano gli importi di tali attivit´a. All’ interno di questo gruppo di reports troviamo:
Confronta strutture Cofronta Periodi Ricerca per struttura Attivit´a
Proiezione Attivit´a Attrazione
I Dati in linea sono invece quei dati che non sono ancora stati archiviati e che vengono estratti dai Database ARCA, G2, LABPI e
LABMS. Si tratta di dati sia clinici che amministrativi riguardanti il Cup (Centro Unico di Prenotazione), gli Ambulatori, i Follow-Up i ricoveri, gli Esami di Laboratorio ed i Controlli effettuati. Scendendo pi´u nel dettaglio vi si trovano i seguenti report:
Lista Prenotati
Prenotati per mese PET SSN e LP Prenotati per mese
Posti liberi
Appuntamenti non erogati Appuntamenti Sospesi Struttura Agende Occupazione Agende Tempi d’ Attesa Simulati Tempi d’ Attesa Effettivi Rapporto Erogato/ Offerto Riepilogo Incassi LP
Documenti Annullati Fatture
Sessioni Casse
Modalit´a Pagamento Incassi Dettaglio Accessi
Prestazioni Erogate Erogato per Utente Erogato Day Service Elenco invio Referti TAC
Elenco invio Referti RM Elenco invio Referti MDN Elenco invio Referti PET Elenco invio Referti Holter Elenco invio Referti Lab
Elenco invio Referti Holter pressorio Elenco invio Referti Agoaspirato Ricerca Invio Referti
Richieste Cartelle Cliniche Follow-Up Ambulatori Follow-Up CUP
Utenti-Accessi-Prestazioni Ricoveri Aperti
Accettati nel periodo Ricoveri per utente Ricoveri per Nosologiico Lab FTGM
Lab Pisa con CUP Massa Lab esterni-PI
Lab FTGM Pisa
Lista prelievi per infermiere
Esami FTGM ambulatoriali di Pisa Esami esterni ambulatoriali di Pisa Lab FTGM Pisa (esami composti)
Lab esterni-MS Lab FTGM Massa
Lab FTGM Massa (esami composti) Lista di prelievi di LDL aferesi Lab LDL aferesi
Esami Lab Arca
Interventi Cardiochirurgici Prestazioni ARCA
Statistica Elettrofisiologica Ambulatorio c/o AOUP Interventistica Em&El Day Service
Esami Lab DRG
Tempi di attesa ricoveri Lista di attesa
Trend Temporale Liste d’ Attesa Report per Motivo Ricovero
Report per Provincia di provenienza Monitor Errori HL7
Episodi Utenti Dettaglio Anagrafica Controlli Anagrafiche Dimessi senza Cedolino Controlli Ricoveri
Controlli Prestazioni Impegnative Errate Impegnative Duplicate Sessioni Casse
Attivit´a per Operatore
All’ interno dei Reports&Indicatori si trovano per lo pi´u grafici ed indici con i quali vengono valutate la qualit´a e l’ efficienza delle Performance, vengono studiati gli andamenti temporali delle attivit´a svolte e vengono fatte analisi statisitiche di vario tipo. All’ interno di questo insieme di report si trovano:
Bersagli per anno B11- Peso Medio DRG B12- Mobilit´a
B17- Strategie attivit´a chirurgica C2a- Indice di performance Deg Med C4- Appropriatezza Chirurgica C5a- Qualit´a di Processo C14- Appropriatezza medica D18- Dimissioni volontarie Trend Ricoveri Storico Trend per Tipo Ricovero Trend Ricoveri Triennio
Trend Attrazione Ric. Triennio Ricoveri struttura per peso DRG Ricoveri per peso DRG
Ricoveri per struttura Ricoveri per sesso Mortalit´a per Struttura TMA Ricoveri
Ricoveri per fascia d’ et´a
Ricoveri per fascia d’ et´a e sesso Degenza media
Degenza media cfr Periodo Drg Chir LEA
Drg Medici LEA Distribuzione DRG Prestazioni SSN
Prestazioni per altre Aziende Trend Prest. Aziende Triennio Prestazioni per Struttura
Passando alla cartella Contollo di Gestione, all’ interno vi si trovano i reports relativi a costi e ricavi ed i principali indicatori di budget calcolati:
Ricavi&Costi Contabilit´a Analitica Ricavi&Costi Fatt Prod
Valore Produzione Sanitaria Consumi CDC
Tetti Attivit´a
Indicatori per DRG & Specialit´a Degenza pre-intervento
Degenza pre-chirurgica Degenza pre-procedura Trasferimenti tra Sedi
Editing Controllo di Gestione Costi Ricavi UOCG
Simulazione Costi&Ricavi Simulazione per DRG
Infine nei Dizionari, che possono essere sia Amministrativi che Sanitari si trovano elenchi di informazioni aggiuntive riguardanti le Aziende Ospedaliere ad utili al fine della loro gestione:
Aziende Sanitarie Presidi Ricoveri Reparti&Ambulatori Comuni Regioni Stati Esteri Tariffario DRG Diagnosi ICD-9-CM Interventi ICD-9-CM Tariffario specialistica Branche Esenzioni Specialit´a
8.2 Conversione degli oggetti
Il passaggio di tutti gli oggetti dell’ SDG dal BMF 2.x al 3.0 ha costituito un’ ampia parte di questo lavoro di tesi. Infatti, come si ´e potuto osservare dagli elenchi del precedente paragrafo, il numero di report ´e molto elevato (circa 140) ed inoltre ciascuno di essi ´e
costruito legando tra loro pi´u oggetti.
In fase di realizzazione del nuovo SDG ´e stata seguita una procedura di conversione di tali oggetti costituita da alcuni passi che si sono ripetuti ed applicati a ciascuno di essi.
Per ogni report da realizzare:
1. in primo luogo si sono individuati tutti gli oggetti che lo
costituiscono: c’ ´e sempre almeno un pulsante ed una tabella o un grafico, ma nella quasi totalit´a dei casi il report si compone anche di un filtro per l’ effettuazione di ricerche ed altri oggetti.
2. si ´e realizzato l’ oggetto pulsante che permette di accedere al report facendo il save as di uno gi´a esistente e cambiandone il nome (´e stato dato lo stesso che avevano nel vecchio SDG), il link ed il campo di configurazione Json. Tale campo, nel caso di questo tipo di oggetto, va a determinare il nome con il quale il pulsante sar´a visto nel men´u. Per quanto riguarda il link, esso determina quali oggetti si andaranno a visualizzare selezionando il pulsante, e nel nuovo BMF ha una forma del tipo #dispatcher/idObject= seguito dall’ elenco degli oggetti separati dal carattere &.
3. utilizzando la Navigazione sito si ´e associato il pulsante al men´u principale oppure ad una men´u folder secondaria mantenendo la stessa posizione assunta nel vecchio sistema.
4. si ´e realizzato l’ oggetto filtro facendo il save as di uno gi´a
esistente, assegnandogli lo stesso nome che aveva nel vecchio sistema e valorizzando in modo adeguato il campo Json. Qui vengono
determinati i campi su cui si effettua la ricerca: si settano la label e l’ id del campo, si determina se mantenere il parametro il sessione o meno ed infine si deve specificare il tipo del campo, tipicamente un testo, una data o un elenco a tendina (combo). In quest’ ultimo caso ´e stato creato anche l’ oggetto select che va a prelevare i valori da
inserire nella combo ed ´e stato passato come parametro di
configurazione. In caso di assenza di un filtro nel report questo punto ´e ovviamente stato saltato.
5. si ´e realizzato l’ oggetto tabella facendo il save as di una gi´a
esistente e assegnandogli il corretto nome, specificando il DB sul quale viene effettuata la query che preleva i dati e valorizzando i campi Query e Json. Per quanto riguarda la query ´e stata sempre riportata la medesima query per vista che caratterizzava l’ oggetto nel vecchio sistema. Con la configurazione Json sono state definite tutte le altre caratteristiche della tabella: nomi di ciascuna colonna, su quali campi effettuare l’ order by, su quali calcolare il totale o la percentuale. In alcuni casi ´e possibile che i valori di qualche campo siano cliccabili per accedere ad una tabella secondaria: questo viene realizzato associando un riferimento ipertestuale a quel campo all’ interno della query. Un riferimento ipertestuale ´e un link HTML che, in generale, permette di collegare una pagina web ad un’ altra oppure a un’ immagine, un documento o altri tipi di file andando a specificare all’ interno del link l’ indirizzo dell’ oggetto che si vuole raggiungere. Poich´e le nuove regole sulla composizione dei link descritte al punto 2 valgono anche per i riferimenti ipertestuali, questi si sono dovuti portare nella forma < ahref = ”#dispatcher/idObject = ...” >< /a >. Poi si ´e realizzata la tabella secondaria seguendo lo stesso procedimento appena
descritto.
6. in caso di presenza di un GroupButton nel report si ´e realizzato il corrispondente oggetto ancora una volta con la tecnica del save as e specificando il nome e le caratteristiche di ciascun pulsante facente parte del gruppo nel campo Json: la label ed il link. In genere i GroupButton sono inseriti nei report per poter accedere ad una tabella secondaria che fornisce informazioni di maggiore dettaglio oppure per poter effettuare una nuova ricerca.
7. in caso di presenza di albero nel report si ´e creato il corrispondente oggetto TREE specificandone il nome e la radice dell’ albero ed il tipo nel campo Json. Ad ogni nodo dell’ albero ´e in genere associato un link e quindi, come per i riferimenti ipertestuali, questi sono stati modificati e portati nella forma richiesta dal nuovo sistema. Ai link
degli alberi ´e possibile accedere dall’ apposito template Associa link a struttura.
8. in caso di presenza di un grafico nel report si ´e creato il
corrispondente oggetto CHART usando sempre la tecnica del save as e andando a modificare il nome, la query che genera il grafico e specificando nel campo di configurazione Json il tipo (in genere torta o istogramma), come costruire gli xasses e yasses e se si volesse o meno la legenda.
9. dopo aver finito la realizzazione di ciascun report si ´e verificato il loro corretto funzionamento dopo aver fatto il reload del sito per rendere effettive le modifiche.
Non ´e stato in realt´a necessario creare de novo tutti gli oggetti perch´e alcuni erano gi´a esistenti, ma mal configurati (cio´e seguendo le regole del vecchio sistema). In questi casi ´e stato necessario solo verificare che la query fosse corretta e modificare il campo Json direttamente sull’ oggetto esistente.
Di seguito sono mostrati alcuni esempi di report realizzati:
Figura 19: Report Confronti Attivit´a
Figura 21: Report Attrazione
Figura 23: Report Attrazione: dettaglio regione Toscana
Figura 25: Report Prestazioni Erogate
8.3 Alcuni problemi incontrati e loro risoluzione
Durante un lavoro di qesto tipo, nel quale ci sono numerose regole sintattiche da rispettare (soprattutto per la parte Json), ´e piuttosto facile commettere qualche errore di digitazione che porta
inevitabilmente ad una scorretta costruzione del report o lo rende non consultabile. Errori di questo tipo sono per´o facilmente identificabili consultando il Log File dell’ applicazione (file all’ interno del quale vengono registrate tutte le modifiche affettuate sui dati ed anche gli errori riscontrati dal sistema), e prima ancora ´e il sistema stesso che manda un messaggio riportando il codice ed il tipo dell’ errore. Inoltre esistono anche alcuni parser on-line che possono aiutare a scoprire se all’ interno del codice sono stati commessi errori di tipo sintattico (ad esempio parentesi non chiuse correttamente o mancanza di virgole separatrici dove dovrebbero esserci).
Un altro problema incontrato ha riguardato esclusivamente quei report i cui dati vengono estratti dai database LABPI, LABMS ed ASCOT: tali report non venivano visualizzati e consultando il Log File ci si ´e accorti che ci´o era dovuto alla mancanza delle datasources dei DB di riferimento che dovrebbero essere inserite nell’ apposito file di configurazione del sistema. Questo si ´e potuto facilmente risolvere andando appunto a registrare i DB nel file corretto.
Altri problemi sono stati un po’ pi´u ardui da risolvere e hanno richiesto pi´u tempo e l’ aiuto di un membro dello staff FTGM. Uno di questi ha riguardato quei casi in cui ai campi delle tabelle ´e associata la possibilit´a di effettuare l’ order by dei dati usando le apposite frecce. Per ottenere questa funzionalit´a si devono configurare i campi specificando la condizione ”OrderBy”:”S” per ciascuno di essi (come ´e possibile vedre ad esempio dalle figure n.23 o n.24). Pur avendo configurato tutti i campi in questo modo, solo in alcuni report veniva effettuato correttamente l’ ordinamento dei dati cliccando sulle frecce, mentre per molti altri l’ ordine rimaneva invariato. Inoltre ci´o che inizialmente non si riusciva a spiegare era il fatto che non veniva ricevuto alcun tipo di messaggio n´e dal Log File n´e dalla Console del Browser (un altro strumento utile per accorgersi di eventuali anomalie di funzionamento), come se la richiesta di ordinamento non venisse ”vista” dal sistema.
Era chiaro che non si trattava di un errore di configurazione e si ´e pensato che potesse essere dovuto ad un bug del sistema scatenato da una particolare casistica (combinazione di parametri) oppure ad una mal formazione delle query coinvolte. Tuttavia le query sono state lasciate invariate rispetto al vecchio SDG (nel quale gli oder by sono tutti perfettamente funzionanti), quindi questa seconda possibilit´a ´e stata scaratata. Con l’ aiuto di un membro dello staff FGTM si ´e poi scoperto che si trattava effettivamente di un bug del sistema e si ´e potuto risolvere correttamente.
Quando si effettua l’ ordinamento dei dati utilizzando le apposite frecce, quello che effettivamente succede ´e che viene invocato un url all’ interno del quale dovrebbero essere passati come oggetti da visualizzare gli stessi presenti nella pagina dalla quale si effettua l’ order by (l’ utente vuole agire solo sui dati, non cambiare il contenuto della pagina) ed un parametro che indica il tipo di ordinamento (crescente o decrescente). Un’ altra anomalia incontrata ha
