UNIVERSITA‟ DEGLI STUDI DI TRIESTE

Facoltà di Ingegneria
Corso di laurea triennale in Ingegneria Informatica

PROVA FINALE IN BASI DI DATI

PORTING EVOLUTIVO DI UN DATABASE

DI DATI CLINICI DI CARDIOCHIRURGIA
DALL’AMBIENTE FILEMAKER PRO
ALL’AMBIENTE ORACLE 9i

Relatore: Laureando:
prof. Fermeglia Maurizio Fabbro Christian
Correlatore:
ing. Zabucchi Stefano

Anno Accademico 2009 / 2010

2
 Sommario

1 INTRODUZIONE ............................................................................................ 4
2 IL CONTESTO OSPEDALIERO ........................................................................ 6
2.1 IL DIPARTIMENTO CARDIOVASCOLARE ...................................................................................................................6
2.2 PERCORSO DI CURA DI UN PAZIENTE IN OSPEDALE .................................................................................................7
2.2.1 Percorso diagnostico - terapeutico in cardiologia e cardiochirurgia .................................................7
2.2.2 Flusso di lavoro ospedaliero in cardiologia e cardiochirurgia ............................................................9
3 ANALISI ...................................................................................................... 11
3.1 SITUAZIONE ATTUALE ........................................................................................................................................ 11
3.2 IL SISTEMA INFORMATIVO IN USO IN CARDIOCHIRURGIA....................................................................................... 14
3.2.1 Base dati del sistema informativo di cardiochirurgia ....................................................................... 15
3.3 IL SISTEMA INFORMATIVO MEDARCHIVER........................................................................................................... 17
3.3.1 Caratteristiche generali del sistema informativo MEDarchiver ....................................................... 18
3.3.2 Architettura di MEDarchiver ............................................................................................................... 19
3.3.3 Funzionamento del nucleo di MEDarchiver ....................................................................................... 19
3.3.4 Il nucleo della base dati di MEDarchiver ........................................................................................... 21
3.3.5 Funzionamento di MEDarchiver per cardiochirurgia: discussione del caso CCH ........................... 23
4 PROGETTAZIONE E REALIZZAZIONE .......................................................... 26
4.1 CONFIGURAZIONE DELLA SCHEDA SPECIALE “DISCUSSIONE DEL CASO CCH” .......................................................... 26
4.2 SVILUPPO PROCEDURE AD HOC PER L‟EUROSCORE............................................................................................ 29
4.3 MIGRAZIONE DEI DATI ...................................................................................................................................... 32
4.3.1 Esportazione dati da FileMaker Pro a file .csv .................................................................................. 32
4.3.2 Importazione dati in Oracle tramite tabelle esterne ........................................................................ 34
4.3.3 Importazione dati in MEDarchiver ..................................................................................................... 37
4.3.3.1 Importazione pazienti .............................................................................................................................................. 37
4.3.3.2 Importazione dati pre-operatori ............................................................................................................................ 41

5 CONCLUSIONE ............................................................................................ 44
6 BIBLIOGRAFIA ........................................................................................... 45

3
1 Introduzione

In questa tesi si vuole descrivere il procedimento di porting evolutivo di un database di dati clinici
cardiochirurgici dall‟ambiente FileMaker Pro all‟ambiente Oracle 9i progettato e realizzato presso
l‟azienda Generation Byte s.r.l. di Trieste che opera nel settore delle tecnologie telematiche
multimediali e realizza progetti e sistemi informativi integrati in ambito clinico.
L‟obiettivo del progetto è quello di avere un database migrato e ristrutturato su Oracle con lo
scopo di non perdere i dati clinici del vecchio sistema informativo realizzato in ambiente FileMaker
Pro.
Il progetto nasce dall‟esigenza di informatizzare il reparto di cardiochirurgia compatibilmente con il
sistema informativo ospedaliero usato attualmente dall‟ospedale per permettere la comunicazione
e l‟interoperabilità tra i reparti dell‟azienda ospedaliera.
Le tecnologie software utilizzate per la realizzazione del progetto sono FileMaker Pro versione 10 e
Oracle 9i.
Le fasi principali che sono state affrontante durante lo svolgimento del progetto sono state:
o analisi del sistema informativo esistente in cardiochirurgia e ricostruzione dello schema
logico della base dati
o analisi e ricostruzione dello schema logico della base dati di MEDarchiver già esistente per il
reparto di cardiochirurgia
o configurazione delle maschere di input/output di MEDarchiver per adattare il sistema alla
realtà clinica di cardiochirurgia
o progettazione e implementazione di procedure ad hoc per il calcolo dell‟ euroscore
o progettazione e implementazione di procedure per la migrazione dei dati
o esecuzione delle procedure implementate in ambiente di test
o esecuzione delle procedure in ambiente di produzione

La tesi è organizzata secondo tre capitoli, che ripercorrono l‟iter di svolgimento di lavoro.

Nel capitolo 2 è descritta la realtà ospedaliera del dipartimento cardiovascolare; viene esposto e
schematizzato il percorso diagnostico e terapeutico del paziente nei reparti di cardiochirurgia e
cardiologia.

Nel capitolo 3 viene presentata la situazione attuale del reparto di cardiochirurgia e vengono
delineati gli obiettivi da raggiungere.

4
Nel capitolo 4 è descritta la fase di progettazione e implementazione delle procedure per il calcolo
dell‟euroscore, delle procedure riguardanti la migrazione dei dati clinici e della configurazione delle
maschere del nuovo sistema informativo.

5
2 Il contesto ospedaliero

2.1 Il dipartimento cardiovascolare

Il Dipartimento Cardiovascolare si compone di un insieme di Unità Operative affini e

complementari, che operano sinergicamente nel campo della prevenzione e della terapia delle
malattie cardiovascolari.
Il dipartimento è, infatti, in grado di offrire una valutazione diagnostica completa ed un adeguato
trattamento, medico o chirurgico, di malattie cardiovascolari dell'adulto.
Il Dipartimento Cardiovascolare è composto dalle seguenti unità e sotto-unità:

Dipartimento cardio -
vascolare

U.O. U.O. Chirurgia

U.O. Cardiologia
Cardiochirurgia vascolare

Chirurgia
Chirurgia di
Ricovero diurno vascolare
urgenza
d’urgenza

Chirurgia
Analisi e gestione
Elettrofisiologia vascolare
dei percorsi clinici
interventistica

Emodinamica e
cardiologia
interventistica

Diagnostica non
invasiva
cardiovascolare

Unità terapia
intensiva

Figura 1: Organigramma Dipartimento cardiovascolare.

In modo particolare, l‟unità operativa d‟interesse a questa tesi è quella di cardiochirurgia. E‟ un

reparto ben distinto del Dipartimento cardiovascolare, che si occupa d‟interventi chirurgici al cuore
con l‟importante funzione di ristabilire la circolazione coronarica, consentendo il corretto
funzionamento del cuore, mediante tecniche di ricostruzione (angioplastica) con l‟inserzione di
tratti di vaso naturale o artificiale, con la tecnica del “by-pass” e con svariate procedure vascolari.

6
2.2 Percorso di cura di un paziente in ospedale

Il generico percorso di cura di un paziente in ospedale (dal ricovero alla dimissione) è strutturato
in diversi stadi, riassumibili come segue:

Inquadramento Trattamento
Ingresso del paziente Monitoraggio Uscita dal percorso
diagnostico terapeutico

Figura 2: Percorso del paziente in ospedale.

Il paziente nel momento in cui entra in ospedale è visitato dal medico specialista per un
inquadramento diagnostico (valutazione e stadiazione). Appena individuata la diagnosi passa alla
fase di trattamento terapeutico con lo scopo di riportare uno stato patologico ad uno stato sano
(trattamento). Poi è sottoposto ad una fase di monitoraggio (valutazione post-trattamento) prima
di uscire dal processo di cura.

2.2.1 Percorso diagnostico - terapeutico in cardiologia e

cardiochirurgia

In questo paragrafo viene descritto il percorso diagnostico – terapeutico del paziente nei reparti di
cardiologia e cardiochirurgia.
Il flusso operativo inizia quando al paziente vengono riscontrate anomalie del normale
funzionamento del cuore. Il paziente entra in reparto di cardiologia e si sottopone ad esami di
accertamento quali l‟elettrocardiogramma, l‟ecocardiogramma, test da sforzo e altri esami. In base
ai risultati degli esami viene decisa la tipologia d‟intervento migliore per il paziente, tra le quali una
terapia medica farmacologia, una terapia cardiologia interventistica oppure un intervento
chirurgico al cuore. In quest‟ ultimo caso inizia per il paziente un iter che, attraverso una serie di
visite ed accertamenti, lo porterà all‟intervento cardiochirurgico. Il paziente viene ricoverato in
reparto di cardiochirurgia in attesa di entrare in sala operatoria per l‟intervento. Percorrerà una
fase pre-operatoria in cui verranno eseguiti esami specifici, una fase operatoria in cui verrà
eseguito l‟intervento e una fase post-operatoria in cui vengono monitorate le condizioni cliniche del
paziente. Nel momento in cui le condizioni cliniche di monitoraggio sono stabili, il paziente entra
nella fase di degenza post – operatoria e successivamente viene trasferito nuovamente al reparto
di cardiologia per iniziare la riabilitazione post – operatoria.
Finita la fase di riabilitazione il paziente viene dimesso. Il medico compila la scheda di dimissione
(SDO – Scheda Dimissione Ospedaliera) inserendo informazioni sugli aspetti clinici del ricovero

7
(diagnosi, sintomi rilevati, interventi chirurgici, procedure diagnostiche terapeutiche, impianto di
protesi, ecc.) e informazioni sugli aspetti organizzativi del ricovero (unità operativa d‟ammissione e
dimissione, eventuali trasferimenti interni, ecc.).
Infine il paziente entra nella fase di follow – up in cui sono programmati gli esami di controllo
futuri, estesi nel tempo.

Si riporta di seguito un diagramma di flusso relativo al percorso appena descritto.

CARDIOLOGIA CARDIOCHIRURGIA

Ingresso paziente

Esami di
accertamento

Teraia medica Tipologia Intervento

Fase pre - op
(farmaci) intervento chirurgico al cuore

Terapia
cardiologica Fase intra - op
interventistica

Condizioni Cronico Fase post - op

cliniche

Guarito

Degenza post -op

SDO Fase riabilitativa Stabili Condizioni Instabili

cardiologica cliniche

Uscita paziente

Follow - up

Figura 3: Percorso diagnostico - terapeutico

8
Come si nota in Figura 3 il percorso di cura del paziente in cardiochirurgia ha inizio quando, in
cardiologia, viene deciso che la tipologia d‟intervento necessaria è l‟intervento chirurgico al cuore.
Da questo momento il paziente viene sottoposto all‟intervento e rimane in reparto fin quando le
sue condizioni cliniche non si stabilizzano. Dopodichè ritorna al reparto di cardiologia per la
riabilitazione chirurgica.

2.2.2 Flusso di lavoro ospedaliero in cardiologia e cardiochirurgia

L‟azienda ospedaliera è divisa principalmente in tre aree di lavoro ben distinte che collaborano:
l‟area amministrativa, l‟area clinica e l‟area locale o area di isola funzionale.

L‟area amministrativa ha il compito d‟identificare il paziente all‟ingresso, di contabilizzare la

degenza (permanenza e cure ricevute dal paziente), di accettare il paziente e di dimetterlo.

L‟area clinica ha il compito di gestire il processo di cura del paziente come ad esempio la
programmazione dei letti, la pianificazione degli esami da eseguire, la prescrizione dei farmaci da
assumere e la decisione della terapia migliore.

L‟area denominata “isola funzionale” non è altro che un reparto dell‟azienda ospedaliera (come ad
esempio cardiologia, cardiochirurgia, pediatria, ecc.) che autonomamente provvede all‟esecuzione
degli esami archiviando i risultati che potranno essere consultati da chi d‟interesse.

In Figura 4 si può osservare la interoperabilità tra le aree appena descritte. L‟area clinica è
evidenziata di azzurro e si riferisce al reparto di cardiologia, l‟area di “isola funzionale” è
evidenziata in rosso e si riferisce al reparto di cardiochirurgia mentre l‟area amministrativa è
evidenziata in blu e interessa più aspetti dell‟azienda ospedaliera.

9
 Richiesta di
Specialista ricovero in Lista d’attesa
Programmazione del Cardiologia
ricovero
cardiologia
Ammissione
clinica

Valutazione
Pronto
gravità Ammissione Diario clinico
soccorso
paziente

Apertura della
cartella clinica Programmazione
letti
Dimissione Grave?

Richiesta di
ricovero in
cardiologia

Scheduler
sale Management Pianificatore Management
operatorie farmaci infermieri degli ordini
Cardiochirurgia

Pre - OP Prescrizione Ordine di

riempimento

Amministrazione
Intra - OP dei farmaci

Scheduler degli
Post - OP esemi

Ammissione
No
Si Dimissione
Relazione Report lista di Esecuzione Lista di
Fine
dell’esame lavoro esame lavoro

Figura 4: Flusso di lavoro ospedaliero

10
3 Analisi

In questa prima parte del documento è presentata una descrizione della situazione attuale in cui si
trova la realtà del reparto di cardiochirurgia e vengono delineati gli obiettivi da raggiungere. Inoltre
vengono analizzate le due basi dati esistenti, l‟una di FileMaker Pro e l‟atra relativa a MEDarchiver,
per ricavare la struttura delle tabelle necessaria per eseguire una migrazione ad hoc.
A supporto delle tematiche affrontate sono stati opportunamente inseriti alcuni diagrammi UML.

3.1 Situazione attuale

Il sistema informativo ospedaliero (SIO) dedicato alla gestione dell‟area sanitaria di Presidi
ospedalieri è un sistema integrato modulare. Al fine di massimizzare l‟interoperabilità tra i reparti
dell‟ospedale, il SIO è visto come una piattaforma orizzontale in cui si innescano moduli verticali.
La piattaforma orizzontale contiene una sezione di anagrafica, una sezione di ADT
(Admission/Dimission/Transfer), un modulo di Order Entry e una sezione di Repository dove
vengono trattati i dati comuni a tutti i reparti.
Invece i moduli verticali, diversi per ogni reparto (cardiologia, radiologia, ortopedia, ecc.), sono
configurati per la realtà clinica d‟interesse e non hanno dati in comune.

La situazione attuale in cardiochirurgia prevede un‟informatizzazione ad isola (Figura 5), cioè il

reparto è informatizzato con un proprio sistema informativo realizzato con FileMaker Pro, che lo
rende isolato dal resto della realtà ospedaliera e in particolare dal reparto di cardiologia. Possiede,
quindi, un proprio database di dati anagrafici e un proprio database di dati clinici. Inoltre non
supporta i protocolli HL7 e DICOM fondamentali per l‟interoperabilità tra i reparti.

11
 Chirurgia generale
Cardiologia

Radiologia

Ortopedia
Medicina

Cardiochirurgia
……...

SIO Sistema Informativo Ospedaliero

Figura 5: Informatizzazione ad isola.

Lo scambio d‟informazioni, di dati e documenti informatici è molto importante e del tutto

necessaria per:
o creare un fascicolo sanitario elettronico del paziente
o condividere le informazioni cliniche tra medici appartenenti a strutture sanitarie diverse
o evitare spostamenti non necessari di pazienti tra strutture diverse
o rendere più rapide e tempestive le decisioni cliniche
o rendere possibile l‟accesso da parte del paziente ai propri dati sanitari
o analizzare l‟efficacia delle cure
o fini statistici

Pertanto l‟obiettivo da raggiungere è quello di creare un modulo verticale per cardiochirurgia

(Figura 6), integrandolo nel sistema informativo ospedaliero in modo da permettere la
comunicazione con i vari reparti, in particolare con cardiologia, senza perdere i vecchi dati
memorizzati. Essendo il reparto di cardiologia attualmente informatizzato con MEDarchiver
(paragrafo 3.3) si rende necessaria la migrazione dei dati in un database gestito dal RDBMS
Oracle.

12
 Chirurgia generale
Cardiochirurgia
Cardiologia

Radiologia

Ortopedia
Medicina
……...

SIO Sistema Informativo Ospedaliero

Figura 6: Integrazione del modulo verticale di CCH

Inoltre FileMaker Pro non risulta più essere idoneo a gestire la grossa mole di dati presenti,
soprattutto per quanto riguarda l‟elaborazione statistica.
Per questo sorge la necessità di utilizzare un sistema adeguato a gestire i dati in maniera
efficiente, robusta e affidabile come MEDarchiver.

Il sistema informativo attualmente usato in cardiochirurgia contiene al suo interno due funzioni
molto importanti e molto usate che sono l‟euroscore additivo e logistico.
L‟EUROSCORE, il cui acronimo significa EUROpean System of Cardiac Operative Risk Evaluation, è
un metodo per calcolare la mortalità operatoria per i pazienti che devono subire un intervento
chirurgico al cuore. Si basa su di un certo numero di fattori di rischio ai quali sono stati assegnati
dei pesi. Se il fattore di rischio è presente nel paziente allora il peso associato partecipa alla
sommatoria per calcolare l‟euroscore additivo, altrimenti non viene coinvolto. Tale metodo è molto
utilizzato proprio per la sua semplicità di calcolo, tuttavia, per i pazienti ad altissimo rischio di
mortalità, il semplice modello additivo può in alcuni casi sottovalutare il rischio. Viene perciò usata
la funzione di euroscore logistico, che produce una predizione molto più accurata del rischio e si
basa su un calcolo aritmetico molto complesso.
Si rende necessaria, quindi, una progettazione e un‟implementazione ad hoc di queste due
importanti funzioni.

In definitiva, dopo queste considerazioni, gli obiettivi da raggiungere sono:

o Avere un database migrato e ristrutturato su Oracle.
o Implementare soluzioni specifiche per il modulo verticale di cardiochirurgia cioè configurare
il nuovo sistema informativo in modo che rispetti la logica operativa del reparto.
o Implementare le funzioni di calcolo dell‟EUROSCORE nel nuovo sistema informativo.

13
3.2 Il sistema informativo in uso in cardiochirurgia

Il reparto di cardiochirurgia utilizza un sistema informativo realizzato con FileMaker Pro. È un

sistema di archiviazione dati dedicato esclusivamente alla memorizzazione di informazioni cliniche
relative agli interventi cardiochirurgici. Le informazioni al suo interno sono relative ai dati anagrafici
del paziente, ai dati della lista d‟attesa, ai dati pre-operatori, ai dati intra-operatori (dati
dell‟intervento) e ai dati post – operatori.

Nella Tabella 1 vengono elencate le operazioni eseguite dagli utenti, con indicazione del soggetto
che utilizza il caso d‟uso.

Operazione
1 Inserimento nuovo paziente
2 Inserimento dati pre – operatori
3 Inserimento lista di attesa
4 Inserimento dati intra – operatori
5 Inserimento periodo post – operatorio
6 Cerca paziente
7 Visualizza dati anagrafici
8 Visualizza dati lista di attesa
9 Visualizza dati pre – operatori
10 Visualizza dati intra – operatori
11 Visualizza dati clinici riassunti del paziente
12 Visualizza dati post - operatori
Tabella 1: Elenco delle operazioni svolte dagli utenti
Soggetto
Cardiochirurgo
Cardiochirurgo
Cardiochirurgo
Cardiochirurgo
Cardiochirurgo
Cardiochirurgo – Medico – Infermiere
Cardiochirurgo – Medico – Infermiere
Cardiochirurgo – Medico – Infermiere
Cardiochirurgo – Medico – Infermiere
Cardiochirurgo – Medico – Infermiere
Cardiochirurgo – Medico – Infermiere
Cardiochirurgo – Medico – Infermiere

Durante l‟analisi delle operazioni si sono individuati due tipi di utenti (attori):
o Il cardiochirurgo, che è sia utilizzatore che destinatario del sistema in quanto ha i permessi
di inserimento e di visualizzazione dei dati.
o Il personale medico – infermieristico, che è destinatario del sistema nel senso che è fruitore
dell‟informazione inserita. Rientrano in questa categoria anche i medici appartenenti ad altri
reparti diversi da cardiochirurgia.

Nella figura seguente viene rappresentato il diagramma di casi d‟uso che descrive il funzionamento
del sistema con notazione UML:

14
 Sistema informativo FileMaker Pro CCH
Calcolo euroscore Vis. dati intra -
op
*
<<Include>>
<<Include>>

Inserimento dati
pre - op
Vis. dati intra -
* <<Include>> op
* *
*
Inserimento nuovo <<extend>> Creazione nuova * *
<<Include>> *
paziente cartella clinica <<Include>>
Inserimento lista
* di attesa
*
* * * Destinatario
Visualizza lista *
di attesa
<<Include>>
Cardiochirurgo
<<extend>> <<Include>>
Visualizza Trova paziente
Inserimento dati
cartella clinica
* intra - op
<<Include>> <<Include>>

*
Visualizza
<<Include>> anagrafica
Cardiochirurgo Medico- Infermieristico
* *

Inserimento
periodo post - op Visualizza <<Include>>
Vis. dati pre - op
euroscore

Figura 7: Use Case Diagram del sistema informativo in FileMaker Pro.

3.2.1 Base dati del sistema informativo di cardiochirurgia

Nel paragrafo precedente (paragrafo 3.2) sono state trovate ed elencate le operazioni principali
eseguite dagli utenti del sistema informativo.

Non essendo presente la funzionalità di visualizzazione dello schema relazionale del database
(come avviene, ad esempio, in Access) si è proceduto in un‟ottica di “Reverse Engineering” per
ricavarlo. È stato studiato e analizzato attentamente il sistema informativo dal punto di vista
dell‟interfaccia grafica per poi ricavare il diagramma delle classi necessario a delineare la struttura
della base dati.

Sono state raggruppate le operazioni secondo la logica dei dati trattati. Così facendo si sono potute
ricavare delle classi di appartenenza come elencate in Tabella 2:

15
 Operazione Classe
Inserimento nuovo paziente Anagrafica
Visualizza dati anagrafici paziente
Inserimento lista di attesa Dati lista di attesa
Visualizza lista di attesa
Inserimento dati pre – operatori Dati pre-operatori
Visualizza dati pre - operatori
Inserimento dati intra – operatori Dati intra – operatori
Visualizza dati intra - operatori
Inserimento dati post – operatori Dati post - operatori
Visualizza dati post - operatori
Tabella 2: Elenco delle classi

Le cinque classi individuate possiedono ognuna una propria interfaccia grafica di input dove poter
inserire i relativi dati. Queste maschere di input sono state realizzate e adattate direttamente sulle
tabelle, come la logica di sviluppo prevede per FileMaker Pro, dove non esiste una separazione
della visualizzazione dei dati dalla loro elaborazione e manipolazione.
Essendo presenti cinque maschere di input e sapendo che ognuna corrisponde ad una sola tabella
è stata raggiunta la considerazione che la base dati possiede cinque tabelle. Pertanto il diagramma
delle classi in notazione UML sarà composto da cinque oggetti come si vede in Figura 8.

Il passo successivo è stato quello di ricavare la struttura delle tabelle. Per fare questo si è
proceduto cambiando il modo di visualizzazione della maschera, passando dalla visualizzazione
grafica a quella tabellare. Si è proseguito utilizzando questa tecnica per tutte le maschere di
interesse. Questo metodo, benché l‟unico, risulta essere molto lento ma necessario per avere una
visione sulla struttura di tutte le tabelle.
E‟ stata fatta poi l‟analisi della struttura dei campi e successivamente sono stati ricercati gli attributi
candidati a chiavi primarie e a chiavi esterne per ricostruire le “pseudo relazioni” tra le tabelle e
quindi le relazioni tra le classi del diagramma.

Viene riportato di seguito il diagramma delle classi che rappresenta con UML lo schema logico del
database del sistema informativo (Figura 8).

16
 Lista di attesa
Dati pre - op
-Dati lista di attesa
-Dati preoperazioni
+Inserimento() 1..*
1..* +Inserimento()
+Visualizza()
1..1 +Visualizza()

Anagrafica
-Dati anagrafici
1..1
+Inserimento dati()
+Visualizza dati()

1..1 1..1
Dati intra - op
Dati post - op
-Dati intervento
-Dati postoperatori 1..*
+Inserimento()
+Inserimento() 1..*
+Visualizza()
+Visualizza()

Figura 8: Diagramma delle classi del database di CCH

Nel capitolo successivo verrà analizzato il sistema informativo MEDarchiver e la sua base dati, per
poter successivamente progettare la logica di importazione dati.

3.3 Il sistema informativo MEDarchiver

MEDarchiver è un sistema informativo clinico di gestione integrato per cartelle cliniche multimediali
corredate da dati, tracciati ed immagini in grado di adattarsi a tutte le problematiche della realtà
clinica odierna.
Si basa sulla definizione di una piattaforma configurabile, comprensiva di servizi HIS, PACS, RIS,
CIS e dei sottosistemi verticali qualsiasi per specialità clinica, in grado di adeguarsi a strutture
sanitarie complesse ed articolate.
Consente di organizzare e informatizzare la totalità delle attività cliniche e amministrative dei
servizi a livello dell‟intera struttura sanitaria. I flussi di informazione gestiti comprendono i dati
clinici, i dati amministrativi e anche le interazioni tra strutture diverse, arrivando fino alla gestione
delle interazioni con i Medici di Medicina Generale.

17
 Applicazioni cliniche Applicazioni amministrative
Cardiologia sistema di informazione

Gestione lista di attesa del paziente

Cartella clinica generale paziente

Controllo clinico della qualiltà

Indice master del paziente
Gestione stanze e letti

Amministrazione ADT
Gestione degli ordini
Nurse management

Gestione ECG ………………. ……………….

Piattaforma integrata MEDarchiver ORACLE

Integration Services

HIS PACS RIS CIS

Patient Master Picture Archiving and
Index Hospital Information Radiology Clinical Integration
Comunication
System Information System System
System

Figura 9: MEDarchiver platform.

A titolo di esempio vengono citate alcune caratteristiche insite nella piattaforma MEDarchiver :
o configurabilità degli eventi che compongono la cartella clinica del paziente
o configurabilità dei percorsi clinici
o configurabilità di protocolli terapeutici ed assistenziali
o utilizzo di codifiche (cataloghi per diagnosi, procedure, etc…)
o configurabilità della modulistica interna e della documentazione per il paziente
o configurabilità di agende, liste di lavoro, liste di refertazione e liste di attesa

3.3.1 Caratteristiche generali del sistema informativo MEDarchiver

Basandosi sull‟integrazione delle piattaforme tecnologiche MEDarchiver e Oracle, il sistema è

costituito da una gamma di moduli informatici totalmente integrati tra loro che si completano a
vicenda.
Le caratteristiche salienti del sistema informativo sanitario possono essere riassunte nei seguenti
punti chiave :
o è un sistema aperto, in grado di fornire informazioni ad altri sistemi, riducendo il grado di
ridondanza dei dati gestiti
o è in grado di garantire la tracciabilità di tutte le operazioni effettuate, dei documenti gestiti,
dei farmaci e dei materiali usati

18
 o è un sistema in cui l‟accesso all‟informazione avviene in tempo reale
o è un sistema flessibile e scalabile
o è un sistema modulare in grado di essere personalizzato a seconda delle richieste
specifiche degli utilizzatori
o è un sistema capace di raccogliere dati clinici ed amministrativi, di archiviare e visualizzare
allegati multimediali, di supportare l‟attività medico-infermieristica attraverso la
riproduzione di protocolli di cura e di assistere gli utilizzatori in ogni loro attività
o è uno strumento di comunicazione in grado di gestire lo scambio di informazioni inter- ed
intra-reparto (messaggistica interna e richieste ad unità esterne)
o è uno strumento di analisi statistica per il controllo della qualità e della quantità delle
attività svolte, per la valutazione dei costi e dei risultati ottenuti
o consente di gestire tutte le informazioni relative ai dati sensibili dei pazienti in piena
sicurezza

3.3.2 Architettura di MEDarchiver

L‟interfaccia degli applicativi basati su piattaforma MEDarchiver è tipicamente client/server.

L‟interfaccia client/server comunica direttamente con il database Oracle senza necessità di
installare sulle stazioni client alcun software di supporto per il protocollo Oracle Net80 in quanto il
supporto al protocollo è nativo e compreso nell‟eseguibile MEDarchiver.

La gestione delle configurazioni delle postazioni è centralizzata e viene gestita tramite

un‟opportuna interfaccia. Quando l‟utente effettua il login su MEDarchiver, l‟applicazione individua
autonomamente il suo profilo configurato, che contiene informazioni di primaria importanza come
le impostazioni di base (permessi ecc.) e le funzionalità previste per la postazione (refertazione,
accettazione, ecc.).

Anche l‟aggiornamento dell‟applicativo è completamente automatico : la presenza di una nuova

versione dell‟eseguibile determina l‟automatica sostituzione della precedente versione con la nuova
release disponibile. In tutti i casi, il processo di aggiornamento viene svolto dal „lato‟ server è
infatti quest‟ ultimo che invia gli aggiornamenti disponibili, quindi non c‟è bisogno di manutenzione
software per le postazioni client.

3.3.3 Funzionamento del nucleo di MEDarchiver

19
Il sistema informativo MEDarchiver, indipendentemente dalla realtà clinica considerata, possiede
una logica operativa standard, adeguabile a tutti i moduli verticali dei reparti dell‟azienda
ospedaliera.

Le operazioni principali vengono elencate di seguito in Tabella 3 con indicazione degli utenti che le
eseguono:

Operazione Soggetto Descrizione

Creazione nuovo paziente
Creazione nuovo evento
Inserimento dati dell‟evento
Visualizza dati anagrafici
Visualizza lista di eventi
Visualizza dati evento
Tabella 3: Lista delle operazioni generali di MEDarchiver
Personale amministrativo Vengono inseriti i dati
anagrafici del paziente
Medico specialista Per evento si intende la
fase di cura in cui è arrivato
il paziente (per es. la fase
pre intervento equivale
all‟evento “Discussione del
caso”)
Medico specialista Vengono inseriti i dati clinici
relativi all‟evento scelto
Personale medico Vengono visualizzati i dati
infermieristico e medico anagrafici del paziente
specialista
Personale medico Viene visualizzata una lista
infermieristico e medico degli eventi associati al
specialista paziente
Personale medico Vengono visualizzati i dati
infermieristico e medico relativi ad un evento
specialista

Durante l‟analisi delle operazioni si sono individuati tre tipologie di utenti (attori):
o Il personale amministrativo di cui fanno parte i dipendenti che lavorano nell‟area
amministrativa dell‟azienda ospedaliera e danno inizio alla transizione ADT
(Admission/Dimission/Transfer) del paziente.
o Il medico specialista, l‟utilizzatore del sistema informativo, costituisce una categoria in cui
rientrano tutti i medici che lavorano in un reparto specifico, per esempio il cardiologo o il
cardiochirurgo.
o Personale medico – infermieristico di cui fanno parte tutti i medici e tutti gli infermieri di
tutti i reparti dell‟azienda.

20
Nella Figura 10 viene rappresentato il diagramma di casi d‟uso che descrive il funzionamento del
nucleo di MEDarchiver con notazione UML:

Sistema nucleo MEDarchiver

Creazione nuovo
* paziente <<extend>>
*
* *
Creazione cartella *
clinica
Pers. amministrativo
Visualizza dati
<<extend>> <<extend>> anagrafici Utente
*

Creazione nuovo Visualizza

evento cartella clinica
* <<extend>>
*
Visualizza lista
degli eventi
* <<include>>
*
<<include>>

Inserimento dati * Medico specialista Pers. medico inferm.

Medico specialista evento Visualizza dati
*
evento

Figura 10: Use case del funzionamento generale MEDarchiver

3.3.4 Il nucleo della base dati di MEDarchiver

Nel paragrafo precedente sono state individuate le operazioni principali nell‟utilizzo del nucleo del
sistema informativo MEDarchiver.
La base dati in cui vengono memorizzati i dati relativi ai pazienti e agli eventi ad esso associati è
una base dati completamente relazionale e normalizzata, gestita dal RDBMS Oracle.

In particolare, il nucleo del sistema, ha il seguente schema logico:

21
 PAZIENTI EVENTI TIPI_EVENTI
PK ID PK ID PK ID

NOME FK1 ID_PAZIENTE NOME

COGNOME FK2 ID_TIPO FK1 ID_SCHEDA
.... ... ...

ID_SCHEDA = XXX
DETTAGLI_EVENTI_XXX
SCHEDE_SPECIALI
PK ID
PK ID
DATA
NOTE NOME
..... VERSIONE
FILE_ID_NEW
...

Figura 11: Schema logico del nucleo di MEDarchiver

Nella Tabella 4 vengono elencate le entità che costituiscono il nucleo del database, con la relativa
descrizione dei campi più importanti e una breve spiegazione del contenuto di ciascuna tabella:

TABELLA CAMPI CARATTERIZZANTI DESCRIZIONE

PAZIENTI
TIPI_EVENTI ID_SCHEDA : campo numerico
contenente l‟identificatore univoco
della scheda speciale associata
all‟evento.
EVENTI ID_PAZIENTE: chiave esterna che
identifica il paziente.
ID_TIPO: chiave esterna che
identifica l‟evento.
SCHEDE_SPECIALI VERSIONE: campo contenente la
versione della DLL.
FILE_ID_NEW: campo contenente
l‟identificativo della libreria DLL
presente nel disco fisso.
DETTAGLI_EVENTI_XXX
Tabella 4: Elenco delle tabelle del nucleo di MEDarchiver
Contiene informazioni riguardanti
l‟anagrafica del paziente.
Contiene informazioni sui tipi di
evento che si possono scegliere.
La combinazione delle due chiavi
esterne genera l‟evento.
Una scheda speciale è la
maschera di input/output (libreria
DLL) associata ad un evento
specifico. Ogni evento possiede
una sua DLL configurata
appositamente per l‟evento scelto.
Contiene informazioni riguardanti i
dettagli dell‟evento specifico.
XXX è un valore che specifica il
numero della scheda speciale in
quanto ogni evento possiede
propri dettagli eventi diversi dagli
altri.

22
Di seguito vengono elencate alcune operazioni individuate nel caso d‟uso di Figura 10 per
descriverne le modalità di memorizzazione dei dati nel database:
o Creazione nuovo paziente: vengono inseriti i dati anagrafici nella tabella PAZIENTI
o Creazione nuovo evento: viene selezionato un evento tra i tanti nella tabella TIPI_EVENTI e
il suo identificativo univoco viene scritto nella tabella EVENTI assieme all‟identificativo del
paziente. Inoltre viene identificata la scheda speciale che a livello di front end permette di
identificare quale DLL chiamare per la visualizzazione dei dati e a livello di database
permette di identificare la tabella corretta di DETTAGLI_EVENTI.
o Inserimento dati evento: i dati relativi all‟evento selezionato vengono inseriti nella tabella
DETTAGLI_EVENTI_XXX.

3.3.5 Funzionamento di MEDarchiver per cardiochirurgia:

discussione del caso CCH

In questo paragrafo viene analizzato il funzionamento del sistema MEDarchiver dell‟evento

“Discussione del caso CCH” corrispondente, nel sistema informativo realizzato in File Maker Pro,
alla fase d‟inserimento dei dati pre-operatori.

Le operazioni principali individuate vengono elencate in Tabella 5 con i relativi utenti che le
eseguono:

Operazione Soggetto
Creazione nuovo paziente Area amministrativa
Creazione nuovo evento Cardiochirurgo
Ricerca paziente Utenti
Visualizza lista degli eventi Utenti
Visualizza i dettagli dell‟evento Utenti
Modifica dati anagrafici del paziente Area amministrativa / cardiochirurgo
Modifica dettagli eventi del paziente Cardiochirurgo
Tabella 5: Elenco delle operazioni dell'evento "Discussione del caso CCH"

Durante l‟analisi delle operazioni sono stati individuati tre tipi di utenti (attori):
o L‟area amministrativa, che ha il compito di creare il paziente (se non esiste) oppure
modificarne i dati anagrafici.

23
 o Il cardiochirurgo che è sia utilizzatore che destinatario del sistema in quanto possiede i
permessi di inserimento che di visualizzazione.
o Gli utenti, di cui fanno parte tutto il personale medico infermieristico, tutti i reparti (in
particolar modo quello di cardiologia) e il cardiochirurgo.

Nella Figura 12 è rappresentato il diagramma dei casi d‟uso riguardante la situazione appena
descritta.

Sistema di Discussione del caso CCH

*
Visualizza dati <<extend>> Ricerca paziente
anagrafici
Creazione/modifica
nuovo paziente

nd>>
*

te
*

<<ex
Visualizza lista *
sintesi eventi *
Esame obiettivo *
Creazione/modifica
evento
Utenti

<<
<<
ex

inc
* ten
>

Area amministrativa
d>

d>

lud
>
n
te
<<include>>

e>
ex

>
<<

Anamnesi prossima <<ex

ten d>>
* >>
tend
* <<ex *
* nd>> Visaulizza
te
* Inserimento <<ex dettagli eventi
<<extend>>
dettagli eventi Dati generali
>
d>
<<ex
te ten
nd>> ex
<<
Cardiochirurgo Programma Pers. medico inferm. Reparti Cardiochirurgo
>
d>

<< terapeutico
n

ex
te

ten
ex

d>
<<

>

Calcolo euroscore

Figura 12: Caso d'uso del sistema dell'evento Discussione del caso CCH

Si può notare che l‟operazione di inserimento dei dettagli evento, come per la corrispondente
visualizzazione, si estende all‟inserimento dell‟esame obiettivo, dell‟anamnesi prossima, dei dati
generali, del programma terapeutico e al calcolo dell‟euroscore. Tutte queste operazioni si
riferiscono all‟evento “Discussione del caso CCH”.

24
 PAZIENTI EVENTI TIPI_EVENTI SCHEDE_SPECIALI
PK ID PK ID PK ID PK ID

NOME FK1 ID_PAZIENTE NOME NOME

COGNOME FK2 ID_TIPO FK1 ID_SCHEDA VERSIONE
DATA FILE_ID_NEW

NUCLEO

DETTAGLI_EVENTI_1880 DETT_1880_LK DETT_1880_LK_CAT

PK,FK1 ID PK ID PK ID

FK2 ID_MOTIVO_RICOVERO NOME NOME

FK1 GRUPPO

DETT_1880_VALUTAZIONE_CAT
PK,FK2,FK3 ID_SCHEDA
DETT_1880_LK_CAT_ESAME
PK,FK1 ID_PADRE
DETT_1880_LK_CAT_PAGINE PK ID
NOTE
PK ID NOME VALORE1
LK_VAL1 VALORE2
NOME LK_VAL2 VALORE3
LK_VAL3 NOTE_BREV
CK_MOTIVI ID
FK1 ID_PAGINA

DETT_1880_LK_ESAME DETT_1880_VALUTAZIONE

PK ID PK ID_SCHEDA
PK,FK1 ID_VOCE
FK1 ID_PADRE PK ID
NOME
REAL_DIM NOTE
ID_PADRE

Figura 13: Schema logico Discussione del caso MEDarchiver CCH.

Il database in cui i dati vengono memorizzati è descritta in Figura 13 in cui si notano le tabelle che
rispecchiano lo schema logico del nucleo, come descritto in Figura 11, e le tabelle interessate
all‟evento “Discussione del caso CCH” identificato dal numero 1880.

25
4 Progettazione e realizzazione

In questo capitolo viene presentata la fase di configurazione della scheda speciale di “Discussione
del caso CCH” del modulo verticale del reparto di cardiochirurgia, la fase di sviluppo delle
procedure per il calcolo dell‟EUROSCORE e la fase di progettazione e realizzazione delle funzioni
che servono per l‟importazione dei dati pre – operatori.

4.1 Configurazione della scheda speciale “Discussione del

caso CCH”

MEDarchiver permette, da interfaccia grafica, di personalizzare e configurare le schede speciali in

modo di adeguare il sistema alle esigenze del cliente. Una scheda speciale è una maschera di
input/output dell‟evento considerato, progettata assieme all‟utente finale e realizzata secondo le
sue specifiche esigenze.
La possibilità di personalizzazione delle schede evento che costituiscono la cartella clinica del
paziente è molto ampia: ogni evento può essere personalizzato tramite codifiche specifiche,
modificabili e aggiornabili in qualsiasi momento. Automaticamente le tabelle del database vengono
modificate e al loro interno vengono inserite le codifiche specificate nelle schede.
In particolare, in questo caso, sono state configurate le schede speciali e sono stati aggiunti i
campi destinati a contenere i dati che dovranno essere migrati da FileMaker Pro.
Questa fase è stata necessaria in quanto le schede speciali per gestire il reparto di cardiochirurgia
non erano ancora state configurate ad hoc per la realtà clinica di interesse.
La configurazione è avvenuta selezionando la voce „Codifiche scheda specialistica‟ dal menù
„Gestione‟ presente nella finestra eventi di un paziente.

Figura 14: Codifica scheda specialistica

26
Si apre una finestra in cui è possibile impostare le codifiche di interesse (Figura 15).
Selezionando la voce „Discussione del caso CCH‟ è stato possibile inserire i dettagli delle pagine di
Programma terapeutico, Esame obiettivo, Anamnesi prossima e Dati generali tramite l‟utilizzo dei
bottoni presenti nella maschera.
Operando in tal modo è stata configurata la scheda mantenendo la struttura verticalizzata e
rispettando i requisiti.

Figura 15: Impostazioni scheda specialistica.

Successivamente è stato testato il suo funzionamento e il suo aspetto grafico, provando ad

associare ad un paziente di test l‟evento appena creato di Discussione del caso. (Figura 16).

27
 Figura 16: Discussione del caso CCH.

L‟immagine soprastante riguarda una vista della sezione „Anamnesi prossima‟ interna all‟evento
„Discussione del caso‟ associato al paziente Prova2. Sono elencati, nella sezione Anamnesi, tutti i
valori che il cardiochirurgo inserisce durante il percorso di cura del paziente.

Il procedimento di configurazione adottato per l‟evento “Discussione del caso CCH” è stato
utilizzato anche per la codifica delle altre schede speciali degli eventi “Lista di attesa”, “Dati
dell‟intervento” e di “Degenza post-operatoria”. Non sono state descritte le rispettive procedure di
configurazione perché identiche a quella appena descritta.

28
4.2 Sviluppo procedure ad hoc per l’EUROSCORE

Come descritto nell‟ introduzione di questo documento, il sistema informativo realizzato in

FileMaker Pro comprende due funzioni per il calcolo dell‟EUROSCORE (additivo e logistico), due
indici che servono per valutare il rischio operatorio del singolo paziente in base alla sua patologia.

La fase di progettazione delle due funzioni si è sviluppata su diversi punti.

In principio è stata portata avanti l‟analisi delle procedure implementate in FileMaker Pro per
individuare i fattori di rischio utilizzati (con i relativi pesi numerici) e per capire il modo in cui questi
intervengono nel calcolo dei due tipi di euroscore.
Successivamente le due funzioni sono state eseguite utilizzando parametri di prova per confrontare
i risultati ottenuti con quelli forniti da un programma certificato, a parità di input. Proprio in questa
fase si è verificata una discrepanza nei risultati forniti dalla funzione di euroscore logistico a causa
di un peso errato associato ad un fattore di rischio che successivamente è stato corretto.
Individuati i fattori che intervengono nel calcolo è stato necessario poi ricercarli nelle tabelle del
database di MEDarchiver al fine di individuare le tabelle interessate.
Le tabelle e i campi che vengono interrogati durante il calcolo sono riassunti in Figura 17:

PAZIENTI DETT_1880_VALUTAZIONE_CAT DETT_1880_VALUTAZIONE

PK ID PK ID_SCHEDA PK ID_SCHEDA
PK ID_PADRE PK ID_VOCE
SESSO
DATA_NASCITA VALORE1 NOTE
VALORE2 ID_PADRE
VALORE3
NOTE_BREV

Figura 17: Tabelle interrogate per l’EUROSCORE.

Il passo conclusivo è stato quello di implementare con PL/SQL le due procedure ad hoc il cui
funzionamento viene descritto nella Figura 18.

29
 ID_PAZIENTE ID_EVENTO SCELTA

Elaborazione valori
di input

Scelta = 1 Scelta = 0
Database CCH
Corpo della Corpo della
Funzione Funzione
EUROSCORE EUROSCORE
logistico additivo Table1 Table2
FIELDS FIELDS

Interrogazione Table3
Base di dati
FIELDS

Calcolo

Funzione EURSCORE

EUROSCORE

Figura 18: Schema di funzionamento della funzione.

Come si può notare dalla figura 18 alla procedura sono passati in input tre parametri:
o ID_PAZIENTE: identifica univocamente il paziente di cui si vuole calcolare l‟indice.
o ID_EVENTO: identifica univocamente l‟evento associato esclusivamente a quel paziente.
o SCELTA: contiene il valore della scelta per l‟euroscore additivo e per l‟euroscore logistico.
I parametri sono elaborati e in base al valore di SCELTA si attiva la parte del calcolo dell‟euroscore
additivo o dell‟euroscore logistico. Vengono estratti i dati necessari dal database, vengono elaborati
e in output viene fornito il calcolo desiderato.

Segue un esempio d‟interrogazione con un fattore di rischio utilizzato per il calcolo

dell‟EUROSCORE.

--3 CRITERIO PRIORITA'

l_step := '[SELECT CRITERIO PRIORITA]';
BEGIN
SELECT VALORE1, VALORE2, VALORE3 INTO l_v1, l_v2, l_v3
FROM DETT_1880_VALUTAZIONE_CAT
WHERE ID_SCHEDA = p_ID_scheda AND ID_PADRE = 664;
CASE
WHEN l_v1 = 'S' THEN
l_criterio_priorita := 'Elettivo';
WHEN l_v2 = 'S' THEN
l_criterio_priorita := 'Urgenza';
WHEN l_v3 = 'S' THEN
l_criterio_priorita := 'Emergenza';

30
 END CASE;
l_v1 := NULL;
l_v2 := NULL;
l_v3 := NULL;
EXCEPTION
WHEN NO_DATA_FOUND THEN
l_criterio_priorita := NULL;
END;

In quest‟esempio viene interrogata la tabella DETT_1880_VALUTAZIONE_CAT, vengono estratti i

dati che servono e vengono copiati in variabili. I valori estratti vengono confrontati con le
condizioni interne al CASE da cui, in output, uscirà la stringa desiderata.
Se i valori estratti dalla tabella non soddisfano nessuna condizione del CASE, la procedura fornisce
in output un valore NULL.

La variabile che esce (l_criterio_priorita) è poi impegnata nel processo di calcolo dell‟EUROSCORE
come si vede nell‟esempio sottostante:

l_step := '[CRITERIO PRIORITA]';

l_euroscore_add := l_euroscore_add +
CASE
WHEN l_criterio_priorita like '%Emergenza%' THEN 2
ELSE 0
END;

Quando viene soddisfatta una condizione nel CASE, viene fornito in output un numero che va a
incrementare il valore dell‟EUROSCORE.

Tale funzione è stata testata e poi inserita nelle schede speciali dell‟evento „Discussione del caso
CCH‟ dei pazienti interessati.
La funzione è richiamata da un bottone „calcola‟, come si vede in Figura 19, e fornisce in output il
valore calcolato dei due euroscore.

Figura 19: Calcolo euroscore.

Nel campo note di destra, non editabile, vi è un resoconto dei parametri utilizzati nel calcolo con i
rispettivi valori.

31
4.3 Migrazione dei dati

Prima di esportare i dati dal vecchio sistema informativo a MEDarchiver è stato necessario fare
alcune considerazioni sul formato d‟esportazione da utilizzare e quali metodi d‟importazione
adottare in Oracle.
Una possibile strada da seguire è quella di esportare i dati in file csv, creare manualmente le
tabelle di destinazione e implementare le procedure di lettura del file e scrittura in tabella. Il
vantaggio nel seguire questa strada risiede nella possibilità di progettare manualmente le tabelle e
le procedure d‟importazione. D‟altra parte, scegliendo questa soluzione i tempi di sviluppo si
sarebbero dilungati notevolmente a causa dell‟implementazione manuale delle procedure che
prevedevano di creare le tabelle di destinazione, leggere e separare i dati nei file csv e scriverli
nelle tabelle appena create.
La seconda strada, che è stata effettivamente percorsa, invece prevede di esportare i dati in file
csv per poi importarli in „tabelle esterne‟. Il vantaggio di usare questo strumento risiede nella
completa automazione nel creare le tabelle esterne (paragrafo 4.3.2) e nell‟importare i dati al loro
interno, e nel guadagno di tempo di progettazione e importazione.
Avendo poi a disposizione i dati in Oracle sono state implementante le procedure in PL/SQL per
importarli nella base dati di MEDarchiver.

4.3.1 Esportazione dati da FileMaker Pro a file .csv

Per l‟esportazione dei dati nei file di testo csv è stato necessario in un primo momento specificare il
formato di file in cui i dati dovevano essere scritti, come visualizzato nella Figura 20.

32
 Figura 20: Selezione del formato del file d’esportazione.

È stato necessario poi scegliere la tabella di cui si voleva esportare i dati e selezionare i campi
d‟interesse come viene descritto in Figura 21.

Figura 21: Ordine dei campi per l'esportazione.

Il metodo appena descritto è stato applicato a tutte le tabelle del database. Alla fine di tale
operazione sono stati creati diversi file csv, uno per tabella, in cui i dati sono memorizzati come
visualizzato in Figura 22.

33
 Figura 22: Formato csv.

4.3.2 Importazione dati in Oracle tramite tabelle esterne

Un server Oracle è rappresentato fondamentalmente da due strutture, il database e l'istanza. Con

il termine database si indicano i file fisici in cui sono memorizzati i dati, mentre per istanza
s‟intende l'insieme delle aree di memoria e dei processi di background necessari ad accedere ai
dati, ovvero al database. L'architettura del server è complessa: ogni area di memoria nell'istanza
contiene dati che non sono contenuti in altre e i processi di background hanno compiti ben precisi,
tutti diversi fra loro. Ogni database deve obbligatoriamente fare riferimento almeno ad un'istanza
anche se possibile avere più di un'istanza per database.
Ciascun database consiste di strutture logiche di memorizzazione, per immagazzinare e gestire i
dati, (tabelle, indici, etc.) e di strutture fisiche di memorizzazione che contengono le strutture
logiche. I servizi offerti dalle strutture logiche del server sono indipendenti dalle strutture fisiche
che le contengono. Questo perché le strutture logiche possano essere progettate nello stesso
modo indipendentemente dall'hardware e dal sistema operativo impiegati. Quindi sia che abbiamo
un'installazione di server Oracle su sistema operativo Microsoft, Linux o Solaris non troveremmo
alcuna differenza nella progettazione delle strutture logiche di memorizzazione.

Una „tabella esterna‟ è una tabella definita nel database ma i cui dati sono conservati in un file
ASCII posto fuori dal database. La tabella esterna può essere letta esattamente come ogni tabella
relazionale ma non può essere modificata. La logica di funzionamento è semplice. Nella definizione
della tabella s‟includono le informazioni su come leggere il file che contiene i dati. Quando si

34
esegue un‟istruzione SQL che coinvolge la tabella esterna viene eseguito al volo un import dei dati
in memoria. I dati memorizzati vengono utilizzati come se fossero provenienti da una tabella
memorizzata.

Una tabella esterna si crea con l‟istruzione CREATE TABLE. La clausola da utilizzare per indicare
che i dati della tabella risiedono esternamente al database è ORGANIZATION EXTERNAL.
All‟interno di questa clausola bisogna indicare il tipo di dati esterni che si utilizzano (TYPE), la
directory dove si trovano i dati esterni (DEFAULT DIRECTORY), i parametri con cui è possibile
accedere ai dati (ACCESS PARAMETERS) e la posizione fisica dei dati (LOCATION).
I dati da leggere come tabella esterna possono essere conservati in un data source di qualunque
tipo. In pratica, per leggere i dati dal data source esterno, e modellarli in formato relazionale, il
database ha bisogno di un driver adatto al data source utilizzato. La parola chiave TYPE permette
di selezionare il driver da utilizzare. Oracle mette a disposizione un solo driver, l‟ ORACLE LOADER,
che consente di leggere i dati immagazzinati in un file ASCII.
Nella DEFAULT DIRECTORY si deve specificare un identificatore di directory definito in Oracle.
Mediante la clausola ACCESS PARAMETERS si specifica la struttura del file ASCII che contiene i
dati: ad esempio si specifica se i record sono a lunghezza fissa, se sono terminati con un certo
carattere, i tipi ed i formati dei singoli campi e il nome del file di Log.

La sintassi per definire una tabella esterna è la seguente :

create table nome_tabella_ext (

lista dei campi della tabella esterna
)
ORGANIZATION EXTERNAL
(
type oracle_loader
default directory nome_directory_file_csv
access parameters (
records delimited by newline
logfile file_cch_log:'nome_file_log.log'
fields terminated by ','
)
location ('csv_nome_file.csv')
);

Alla fine dell‟esecuzione di questo script sono state ottenute le tabelle esterne identiche alle tabelle
presenti in FileMaker Pro e con gli stessi dati in esse contenuti.

Per il motivo già detto in precedenza (le tabelle esterne possono essere solo lette), prima di
affrontare l‟importazione dati vera e propria, è stato necessario pulire i campi all‟interno di esse e

35
riscriverli in maniera corretta. Prima di ripulire i dati si è proceduto alla consolidazione delle tabelle
esterne tramite una istruzione SQL che ha permesso di creare una tabella vera e propria con la
stessa struttura di quella esterna. Le tabelle così consolidate hanno il vantaggio che possono
essere lette ma anche modificate.
L‟istruzione SQL per tale scopo è la seguente:

create table nome_tabella as select * from nome_tabella_ext

L‟ultimo passo è stato quello di pulire i dati scritti in tabella dagli apici (Esempio: “Prova2”) per
avere il dato originale. Anche in questo caso sono state implementate delle righe di codice in SQL
che hanno permesso di togliere dal dato gli apici ereditati dal file csv.

select 'update nome_tabella set' testo from dual union all

select 'nome_tabella.' || column_name ||
'= upper(trim(replace(nome_tabella.' || column_name || ', ''"'', '''))),'
testo from all_tab_columns
where table_name= 'nome_tabella';

Questa query interroga la tabella all_tab_columns che è una tabella di sistema: ciascun record al
suo interno descrive le colonne di tutte le tabelle del database accessibili dallo user corrente. La
query fornisce in output il seguente risultato:

update nome_tabella set

nome_tabella.campo1 = upper(trim(replace(nome_tabella.campo1, '"', ''))),
nome_tabella.campo2 = upper(trim(replace(nome_tabella.campo2, '"', ''))),
………..

Eseguendo questo script la tabella interessata viene aggiornata, ciascun dato al suo interno viene
spogliato dagli apici (funzione TRIM) e sovrascritto dal nuovo valore (REPLACE).

In questo modo è stato creato un database in Oracle che è identico, per quanto riguarda a
struttura e contenuto di dati, a quello di partenza progettato in FileMaker Pro.
A questo punto è possibile, quindi, utilizzare gli strumenti forniti da Oracle per portare a termine la
migrazione dei dati, visto che non serve più interfacciarsi a FileMaker Pro.

36
4.3.3 Importazione dati in MEDarchiver

Dopo la creazione delle tabelle identiche a quelle del sistema di partenza, si è finalmente pronti per
l‟importazione vera e propria.
In questo paragrafo vengono documentate solo due funzioni d‟importazione, quella per i dati
anagrafici del paziente e quella per i dati preoperatori, in quanto le altre procedure implementate
sono simili anche se coinvolgono dati diversi.
Per importare i dati in MEDarchiver sono state implementate delle funzioni sulla base dello schema
relazionale analizzato nel capitolo 3.3.5.
Le funzioni che sono state sviluppate sono le seguenti:
o Importazione pazienti.
o Importazione dati preoperatori.
o Importazione lista di attesa.
o Importazione dati operatori.
o Importazione dati postoperatori.
Per ciascuna funzione è stato necessario, in base allo schema logico già analizzato, trovare le
tabelle e i campi coinvolti per l‟importazione.

4.3.3.1 Importazione pazienti

Prima di iniziare a implementare la procedura di importazione è stato necessario fare alcune

considerazioni sulle tabelle interessate e sulla struttura dei dati memorizzati.
In un primo momento le tabelle individuate sono state la tabella Pazienti e la tabella Anagrafica.
Tramite un attenta analisi dei campi delle due tabelle si è notato che, alcuni di loro, non avevano
la stessa informazione memorizzata. I campi in questione sono appartenenti alla tabella Pazienti e
si riferiscono al comune, alla provincia e alla nazione. Al loro interno è memorizzato il valore della
chiave associata e non il valore del dato vero e proprio come nella tabella Anagrafica. Questo
significa che ci sono altre tre tabelle da considerare: le tabelle LK_COMUNI, LK_PROVINCE e
LK_NAZIONI come rappresentato in Figura 23.

37
 LK_COMUNI PAZIENTI LK_PROVINCE
ANAGRAFICA PK ID PK ID PK ID
PK IDAF
NOME NOME NOME
COGNOME COGNOME
NOME SESSO
DATA_NASCITA LK_NAZIONI DATA_NASCITA
...... .....
PK ID FK1 ID_COMUNE
FK3 ID_PROVINCIA
FMP NOME FK2 ID_NAZIONE

MEDarchiver
Figura 23: Tabelle interessate nell'importazione dati anagrafici

Si rende necessaria, quindi, l‟implementazione di altre tre funzioni che, dato in input il nome
cercato, fornisce in output l‟identificativo ad esso associato per poi poterlo scrivere nella tabella
Pazienti.
E‟ stato pensato di sviluppare un package che raccoglie tutte le funzioni da sviluppare in un unico
pacchetto come descritto dallo script seguente:

CREATE OR REPLACE PACKAGE PKG_IMPORTA_PAZIENTI AS

PROCEDURE IMPORTA_PAZIENTI;
FUNCTION TROVA_COMUNE (DESCRIZIONE IN VARCHAR2) RETURN VARCHAR2;
FUNCTION TROVA_NAZIONE (DESCRIZIONE IN VARCHAR2)RETURN VARCHAR2;
FUNCTION TROVA_PROVINCIA (DESCRIZIONE IN VARCHAR2)RETURN VARCHAR2;
FUNCTION TROVA_STATO_CIVILE (DESCRIZIONE IN VARCHAR2)RETURN VARCHAR2;
END PKG_IMPORTA_PAZIENTI;

Il package è costituito da una stored procedure chiamata IMPORTA_PAZIENTI che è la procedura

d‟importazione vera e propria, e da quattro funzioni TROVA_COMUNE, TROVA_NAZIONE,
TROVA_PROVINCIA e TROVA_STATO_CIVILE che ricevono in input il parametro DESCRIZIONE,
ricercano nelle rispettive tabelle l‟identificativo associato al parametro di input e forniscono in
output il valore cercato.
Di seguito viene inserito lo script della funzione TROVA_PROVINCIA come esempio
d‟implementazione:

FUNCTION TROVA_PROVINCIA (DESCRIZIONE IN VARCHAR2) RETURN VARCHAR2 IS

k_procedure_name CONSTANT varchar2(100) := '[Trova_provincia]';
l_id_provincia VARCHAR2(5);
l_step varchar2(400);
l_error varchar2 (400);
BEGIN
l_step := '[Cerca provincia]';
l_id_provincia := '000';
SELECT ID INTO l_id_provincia FROM LK_PROVINCE
WHERE DESCRIZIONE = SIGLA;
RETURN l_id_provincia;

38
EXCEPTION
WHEN NO_DATA_FOUND THEN
RETURN l_id_provincia;
WHEN TOO_MANY_ROWS THEN
l_error := substr(SQLERRM,1,4000);
RAISE_APPLICATION_ERROR(-20100, k_procedure_name ||l_step || l_error);
WHEN OTHERS THEN
l_error := substr(SQLERRM,1,4000);
RAISE_APPLICATION_ERROR(-20100, k_procedure_name ||l_step || l_error);
END TROVA_PROVINCIA;

La stessa logica di funzionamento è stata adottata per le altre funzioni di ricerca.

Nella Figura 24 viene schematizzato il funzionamento del package IMPORTA_PAZIENTI:

Inizio

Tabelle identiche in
Estrazione dati da Oracle
importare

Esiste Controllo
Anagrafica
codice fiscale
Fields

Non esiste

Controllo nome,
Esiste cognome, sesso,
data_nascita

Non esiste

Ricerca in Tabelle del database

LK_COMUNI,
LK_PROVINCE, MEDarchiver
LK_NAZIONI

LK_PROVINCE
Inserimento dati
FIELDS

Pazienti LK_NAZIONI

NO
FIELDS FIELDS
Ultimo record
LK_COMUNI

SI FIELDS

Esci

Package Importa_Pazienti

Figura 24: Diagramma di flusso del package Importa_Pazienti

Come si può notare dalla Figura 24 la procedura inizia con l‟estrazione dei dati necessari (ovvero i
dati da importare) dalle tabelle identiche a quelle di FileMaker Pro tramite cursore, la cui
definizione avviene nel modo seguente:

39
CURSOR c_anagrafica IS
SELECT a.IDAF, a.COGNOME, a.NOME, b.GENERE, a.NAZIONEDINASCITA, b.STATOCIVILE,
b.CODICE_FISCALE, a.DATADINASCITA, a.PROVINCIA_1, a.NATOA, b.PROVINCIA_2,
b.LOCALITA, b.N_CIVICO, b.RESIDENZA_VIA_PIAZZA, b.CAPPAZ,
b.N_TESSERA_SANITARIA, a.COMPILATORE, a.DATAINSERIMENTO, b.ULSS
FROM ANAG_FOND_EXT a, ANAG_SUCC_EXT b
WHERE a.IDAF = b.CTV_IDANAGFOND;

PL/SQL offre un meccanismo per processare i risultati delle query in un modo “orientato alle
tuple”, il che vuol dire, una tupla alla volta. A questo scopo vengono utilizzati i cursori. Un cursore
è fondamentalmente un puntatore al risultato di una query ed è impiegato per leggere i valori degli
attributi delle tuple selezionate, inserendoli in variabili. Un cursore è tipicamente usato in
combinazione con un costrutto loop tale che ogni tupla letta dal cursore può essere processata
individualmente.

La stored procedure continua poi con una fase di controllo dell‟esistenza del paziente prima tramite
codice fiscale successivamente controllando il nome, cognome, data di nascita e sesso del
paziente. Lo script che segue è l‟esempio di controllo dell‟esistenza di un paziente prendendo come
riferimento il codice fiscale.

BEGIN
l_step := '[Controllo codice fiscale]';
SELECT ID INTO l_id_paziente FROM PAZIENTI
WHERE l_anagrafica.CODICE_FISCALE = CODICE_FISCALE;
EXCEPTION
WHEN NO_DATA_FOUND THEN
l_id_paziente := -1;
WHEN TOO_MANY_ROWS THEN
l_id_paziente := -1;
WHEN OTHERS THEN
l_id_paziente := -1;
l_error := substr(SQLERRM, 1, 400);
RAISE_APPLICATION_ERROR(-20100, k_procedure_name || l_step || l_error);
END;

Successivamente vengono cercate le chiavi associate ai parametri di ricerca come già descritto in
precedenza e, se il paziente non esiste, vengono inseriti i dati anagrafici relativi nella tabella
Pazienti. Il procedimento si ferma solo quando non ci sono più tuple da leggere nel cursore.

40
4.3.3.2 Importazione dati pre-operatori

Come per l‟implementazione della funzione IMPORTA_PAZIENTI anche in questo caso si è iniziato
con alcune considerazioni a riguardo delle tabelle interessate e sulla struttura dei dati al loro
interno.
Le tabelle che entrano in gioco sono rispettivamente, nel database di partenza LISTA_ATTESA e
DATI_PREOPERATORI e nel database di MEDarchiver DETT_1880_VALUTAZIONE_CAT e
DETT_1880_VALUTAZIONE come si vede in Figura 25.

LISTA_ATTESA DETT_1880_VALUTAZIONE_CAT1
PK ID PK ID_SCHEDA
PK ID_PADRE
CTV_PATOLOGIA
ANAMNESI NOTE
CRITERIO_PRIORITA VALORE1
DATA VALORE2
FK1 CTV_IDANAGFOND VALORE3
...... NOTE_BREV
ID

DATI_PREOPERATORI
PK ID DETT_1880_VALUTAZIONE1

EUROSCORE_ADD PK ID_SCHEDA
EUROSCORE_LOG PK ID_VOCE
ALTEZZA_CM PK ID
PESO_KG
PRESSIONI NOTE
..... ID_PADRE
FK1 CTV_IDANAGFOND

Oracle
FMP

Figura 25: Flusso di migrazione dati preoperatori.

Individuate le tabelle, il passo successivo è stato quello di capire quali campi erano interessati per
la fase d‟importazione e in che modo i dati dovevano essere scritti nelle nuove tabelle. È stato
necessario, quindi, capire la struttura dei dati dei due database.
Alla fine è stata sviluppata la procedura d‟importazione il cui funzionamento è descritto nella Figura
26.

41
 Inizio

Estrazione ID
pazienti importati
MEDarchiver - Oracle

Estrazione dati Table1 Table2

preoperatori e dati
in lista attesa FIELDS FIELDS

Table3

Inserimento FIELDS
evento

Inserimento dati Tabelle esterne Oracle

preoperatori

Table1 Table2
NO
Ultimo record
FIELDS FIELDS

SI
Table3

Esci FIELDS

Procedure Importa_Datipreoperatori

Figura 26: Diagramma di flusso della stored procedure IMPORTA_DATIPREOP.

Come descritto in Figura 26 la procedura inizia con l‟estrazione dalla tabella Pazienti
dell‟identificativo univoco associato al paziente importato. Nella tabella Pazienti è presente un
campo denominato ALTRO_CODICE che contiene il valore del vecchio ID del paziente, quello cioè
di FileMaker Pro.
Grazie all‟ ID è possibile estrarre i dati che interessano dalle tabelle esterne, associare a quel
paziente l‟evento corretto e inserire i dati estratti fino a che non ci sono più pazienti.

Per capire il principio in cui i dati sono memorizzati nelle tabelle di MEDarchiver, viene proposto di
seguito un esempio.

Nella fase d‟estrazione dati preoperatori, per esempio, in tabella DATI_PREOPERATORI è presente
una colonna denominata FUNZIONE_VSx il cui campo contiene il valore „scadente‟.

Instabilità_emodinamica Obesità Funzione_VS

….. …… scadente

La tabella in MEDarchiver che contiene quest‟informazione è la DETT_1880_LK_CAT_ESAME in cui

il dato è memorizzato come segue:

42
 ID NOME LK_VAL1 LK_VAL2 LK_VAL3
915 Funzione VSx Scadente Media Buona

Lo script della funzione seguente permette di inserire nella tabella di MEDarchiver il valore
corretto.

--Funzione vs
CASE
WHEN l_funzioneVS LIKE '%SCADEN%' THEN
INSERT INTO DETT_1880_VALUTAZIONE_CAT (ID_SCHEDA, ID_PADRE, VAL, VALORE1)
VALUES (l_id_evento, 915, 'S', 'S');
WHEN l_funzioneVS LIKE '%MEDIA%' THEN
INSERT INTO DETT_1880_VALUTAZIONE_CAT (ID_SCHEDA, ID_PADRE, VAL, VALORE2)
VALUES (l_id_evento, 915, 'S', 'S');
WHEN l_funzioneVS LIKE '%BUONA%' THEN
INSERT INTO DETT_1880_VALUTAZIONE_CAT (ID_SCHEDA, ID_PADRE, VAL, VALORE3)
VALUES (l_id_evento, 915, 'S', 'S');
END CASE;

Dopo l‟esecuzione di tale funzione viene inserito nella tabella DETT_1880_VALUTAZIONE_CAT il

seguente record:

ID_SCHEDA ID_PADRE VALORE1 VALORE2 VALORE3

….. 915 S

La logica di inserimento appena descritta è adottata per tutti i dati che vengono trattati nella fase
di importazione, non solo per i dati preoperatori.

Per quanto riguarda le funzioni di importazione dei dati operatori e post operatori valgono le
medesime considerazioni fatte in questo capitolo. Le due funzioni sono simili nel funzionamento
alla procedura IMPORTA_DATIPREOPERATORI, solo che intervengono valori diversi.
Si è quindi ritenuto superfluo descrivere in questa tesi anche tali funzioni.

43
5 Conclusione

In questo elaborato sono state descritte le fasi di analisi, progettazione e implementazione per un
progetto di porting evolutivo di dati clinici dall‟ambiente FileMaker Pro all‟ambiente Oracle.
Per raggiungere tale obiettivo sono state svolte altre fasi, oltre al porting vero e proprio, quali
l‟implementazione di funzioni ad hoc per il calcolo dei due EUROSCORE, additivo e logistico (i due
indici che servono per valutare il rischio operatorio dei pazienti) e la configurazione delle maschere
di input/output del nuovo sistema informativo.
Tutte le stored procedure, le function e i package sono stati implementati in linguaggio PL/SQL di
Oracle.
Le cinque procedure d‟importazione riguardanti i dati anagrafici dei pazienti, i dati delle lista
d‟attesa, i dati pre operatori, i dati operatori e i dati post operatori, sono state prima eseguite in
ambiente di test per rilevare eventuali mal funzionamenti e poi sono state eseguite in ambiente di
produzione con lo scopo di creare l‟archivio storico dei dati clinici dei pazienti.
Le due procedure riguardanti il calcolo dell‟EUROSCORE additivo e logistico, sono state testate
confrontando i valori di output prodotti con quelli del vecchio sistema informativo. Attualmente
sono utilizzate dai cardiochirurghi nella maschera di input/output riguardanti i dati pre operatori.
Le cinque maschere configurate sono state controllate e testate sotto l‟aspetto grafico e funzionale
e attualmente sono state inserite nel sistema informativo di produzione nel reparto di
cardiochirurgia.

44
6 Bibliografia

Oracle architettura:
o http://database.html.it/guide/lezione/3075/l-architettura-di-oracle/

Oracle Documentation:
o http://www.oracle.com/technology/software/index.html

Oracle – PL/SQL Topics:

o http://www.techonthenet.com/oracle/index.php

FileMaker Pro Documentation:

o http://www.filemaker.com/

Guida all‟UML:
o http://programmazione.html.it/guide/leggi/41/guida-uml/

Euroscore additivo ed euroscore logistico:

o http://www.euroscore.org/

45