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