GridPACS: una soluzione Grid ai sistemi PACS medici

Transcript

Università degli Studi di Napoli Federico II
Facoltà di Scienze MM.FF.NN.
Corso di Laurea in Informatica
Tesi Sperimentale di Laurea Triennale
GridPACS: una soluzione Grid ai
sistemi PACS medici
Relatori
Candidato
Prof. Guido Russo
Daniele Dell’Erba
Prof. Giovanni Mettivier
Matricola: 566/2748
Anno accademico 2009/2010
Daniele Dell’Erba 566/2748
Pagina 2
Indice generale
1.
2.
2.1
2.2
2.3
2.4
2.5
2.6
2.7
3.
3.1
3.2
3.3
3.4
4.
4.1
4.2
4.3
4.4
4.5
4.5
4.7
4.8
5.
5.1
5.2
5.3
5.4
6.
6.1
6.2
6.3
7.
7.1
7.2
7.3
8.
8.1
8.2
8.3
8.4
8.5
8.6
8.7
9.
9.1
9.2
Introduzione
Il formato DICOM
La nascita
La struttura
Il modello
La comunicazione
Le funzionalità
Le immagini
L’identificativo
PACS
Introduzione
Architettura
Problematiche
Prospettive
La Grid
Storia
Organizzazione
Sicurezza
Architettura
Middleware
Archivi
Immagazzinamento
Progetti Medici
AMGA
Panoramica
Affidabilità
Interfaccia
Sicurezza
GRID INFN
Architettura utilizzata
Protocolli
Struttura Progetto
GridPACS
Applicazione Web
Specifiche
Funzionamento
Guida d’uso
Tipologie utenti
Registrazione
Accesso al sistema
Invio di un file DICOM
Ricerca e download
Condivisione postazioni
Gestione errori
Sviluppi futuri
Sicurezza
Gestione Immagini
5
8
8
10
15
16
17
18
19
20
20
20
23
25
28
28
30
30
31
31
32
33
34
38
38
38
39
39
41
41
42
43
45
45
45
45
48
48
50
50
54
56
60
61
62
62
62
Pagina 3
9.3
9.4
9.5
9.6
9.7
10.
11.
11.1
11.2
12.
Client
Database
Accessibilità e Fault Tollerance
Funzionalità
Grid Storage e Computing
Conclusioni
Appendice
Installazione e Configurazione
Codice
Bibliografia
63
63
64
65
65
66
68
68
72
103
Pagina 4
1 Introduzione
Il mondo dell’Information Technology legato al “medical imaging” è cambiato
enormemente nell’ultima decade. Il passaggio dall’acquisizione di immagini
analogiche a digitali è in pieno svolgimento ed in tecniche come la CT e MRI è ormai
completo mentre la digital radiography (CR, DR) sta sempre più soppiantando, nelle
nuove installazioni ospedaliere, la radiografia film-schermo. Ciò sta comportando la
necessità della gestione e dell’archiviazione di questi dati. Un grande ospedale, con ad
es. 1500-2000 posti letto, produce dati di imaging medico che possono occupare 5-10
TB l’anno ed è stimato che con il sempre maggior uso di sistemi digitali questo valore
aumenterà fortemente. A questo si deve aggiungere la necessità di mantenere e rendere
accessibili i dati storici di archivio, in aggiunta a quelli correnti, sia per
l’interpretazione clinica sia per legge per almeno 5 anni ed in alcuni casi anche per 21
anni.
Per rispondere a questa esigenza sono nati i PACS (Picture Archiving and
Communication System). I sistemi PACS attualmente in commercio sono sistemi
informativi complessi che offrono, tramite una struttura hardware e software
opportunamente realizzata, la possibilità di molteplici funzioni in ambito ospedaliero,
riguardanti tutta la catena di trattamento delle immagini, partendo dalla loro
acquisizione nelle diverse diagnostiche (CT, NMR, PET/SPECT, US, etc.), passando
poi alla ricostruzione ed elaborazione, quindi alla visualizzazione e refertazione, ed
infine all’archiviazione e alla ricerca di dati clinici dei pazienti. Ma anche quest’ultimi
presentano problemi legati alla scarsa scalabilità ed inoltre essi sono legati al sito in
cui sono installati.
Questo comporta spesso l’inutile replicazione dei dati su diversi siti ed una
scarsa circolazione/visibilità delle informazioni.
La strategia che si sta affermando (ad es. in Gran Bretagna, e ora anche in
Pagina 5
alcune regioni italiane) è quella dell’impiego di archivi centrali/regionali che sono
usati come hub accessibili da facilities remote. Una possibile soluzione potrebbe essere
rappresentata dall’impiego della tecnologia GRID.
La tecnologia GRID, costituita da un livello intermedio (middleware) tra
l’applicazione software e l’hardware, ha la caratteristica di svincolare e rendere
completamente indipendenti il livello inferiore (l’hardware) da quello superiore
(l’applicativo). Ciò comporta che qualunque operazione (come ad esempio il backup o
l’aggiornamento degli archivi), o anche eventuali malfunzionamenti su uno dei due
livelli, non ricada sull’altro. L’innovazione GRID si basa su una diversa
organizzazione dell’hardware già esistente, che fornisce all’utente una grossa
potenzialità di calcolo e di storage, ma rimanendo allo stesso tempo semplice da
gestire.
L’implementazione di questa struttura permetterebbe la realizzazione di una
griglia tra diverse organizzazioni ospedaliere ed in particolare i vantaggi
dell’implementazione GRID come supporto di un PACS sono:
•
Integrare le funzionalità del PACS nella gestione degli archivi;
•
Condivisione di dati distribuiti (database di immagini, dati clinici dei
pazienti, dati amministrativi, etc);
•
in caso di rottura di una macchina è possibile l’accesso al sistema senza
interruzione di nessuna funzionalità;
•
accesso al PACS da tutte le workstations appartenenti alla griglia;
•
interventi di manutenzione senza interruzione dei servizi;
•
backup automatico;
•
struttura gerarchica per l’interrogazione di archivi di diversi PACS.
•
Ridondanza e disponibilità dei dati: copie multiple dei dati esistono tra
diversi nodi nella griglia, creando una ridondanza e utilizzazione in caso di
fallimento di un componente.
Pagina 6
La realizzazione di tale innovativa struttura GRID-PACS integrata pone diverse
problematiche di tipo tecnologico.
Il Gruppo di Fisica Medica del Dipartimento di Scienze Fisiche dell’Università
di Napoli Federico II e della Sezione INFN di Napoli è impegnato, anche con un
supporto della commissione GRID dell’INFN, nella realizzazione di una GRID di test
per valutare la fattibilità di una architettura di GRID storage. La GRID in fase di
realizzazione, inserita nella struttura GRID più generale dell’ INFN, prevede per il
momento la realizzazione di quattro nodi: la Sezione INFN di Napoli, l’Istituto di
Bioimmagini e Biostrutture del CNR di Napoli, l’azienda Ospedaliera Brotzu e la
Sezione INFN di Bologna che raccoglierà i dati dell’azienda ospedaliera S. Orsola
Malpighi di Bologna .
L’attività di GRID-PACS, prevista nell’attuale piano triennale all’interno delle
attività di trasferimento tecnologico, potrebbe proseguire su più vasta scala nell’ambito
di progetti di imaging all’interno di progetti regionali e/o nazionali.
Pagina 7
2 Il formato DICOM
Il formato DICOM (file *.dcm) è il formato standard dei file contenenti le
immagini digitali generate dai dispositivi medicali. Oltre alle immagini, in questa
tipologia di file vengono memorizzati anche dei metadati che contengono informazioni
sul paziente, sul tipo di studio e sulla procedura di cui è frutto l'immagine stessa.
2.1
La nascita
Negli anni '70 con la diffusione dei computer in ambito medico e con
l'introduzione della Computed Tomography, (CT) nasce il bisogno di gestire le
immagini mediche in formato digitale. Inizialmente questo compito fu affidato alle
aziende produttrici degli stessi dispositivi medicali, che provvedevano a creare dei
propri standard per la memorizzazione delle immagini e dei dati ad esse correlati,
stabilendo dei propri protocolli di comunicazione fra dispositivi, propri formati dei file
e politiche di gestione degli archivi.
Questo portò inevitabilmente ad una diffusa incompatibilità tra i diversi formati
dei file ed i sistemi di gestione, anche all'interno di uno stesso ospedale utilizzante
dispositivi medicali forniti da aziende differenti.
Al fine di ovviare a questo problema l’American College of Radiology (ACR)
(fig.2.1)[1] e la National Electrical Manifacturers Association (NEMA) (fig.2.2) [2]
formarono nel 1983 una commissione impegnata a promuovere la compatibilità dei
formati dei file riguardanti immagini mediche e dei dati ad esse collegate
indipendentemente dai dispositivi che generavano le immagini. Questo anche allo
scopo di facilitare lo sviluppo e l'espansione di sistemi Picture Archiving and
Communication System (PACS).
Pagina 8
Fig. 2.1: Logo American College of Radiology
Fig. 2.2: Logo National Electrical Manifacturers Association
Fig. 2.3: Logo Digital Imagind and Communications in medicine
Da questo sforzo nacque lo standard denominato Digital Imaging and
Communication in Medicine (DICOM) (Fig. 2.3) [3]. La prima versione di questo
standard non commerciale (DICOM 1.0) forniva le specifiche per la memorizzazione
delle immagini mediche, dei dati relativi al paziente e dello studio. La seconda
versione del 1988 (DICOM 2.0), fu arricchita da protocolli di rete per instaurare
connessioni di tipo punto a punto, con lo scopo di permettere ai dispositivi che
generano le immagini di trasmetterle ad altri apparecchi. Oggi il formato DICOM,
accettato a livello mondiale, subisce annualmente migliorie, pur mantenendo il
nominativo dell’ultima versione (DICOM 3.0 del 1993). Esso è riconosciuto e diffuso
in Giappone grazie alla Japan Industries Association of Radiological Systems (JIRA)
[4] ed in Europa tramite la European Commitlee for Standardization (CEN) [5].
Pagina 9
2.2
La struttura
Un file DICOM, come definito dallo standard DICOM 3.0, è formato da un
header in cui sono riportati i metadati secondo una scrittura codificata in formato
ASCII e dalle immagini a seconda del tipo di studio in formato jpeg. L’header di un
file DICOM è riconoscibile dalla scrittura dei caratteri “DICM” dal 128° byte fino al
131° byte. Dal 132° carattere comincia la codifica dei dati veri e propri. La codifica
utilizzata dai file DICOM è di tipo little endian, in base al quale un valore numerico è
interpretato da destra a sinistra ponendo quindi la parte più significativa a destra e la
meno significativa a sinistra ( l'opposto della normale lettura di un numero). I dati
contenuti sono organizzati in gruppi di dati chiamati DataSet (fig. 2.4), ogni elemento
dell'insieme è chiamato DataElement ed è identificato univocamente da un valore
chiamato tag disposto in ordine crescente all'interno dell'insieme.
DataSet
DataElem.
Tag
DataElem.
VR
VL
DataElem.
....
ValueField
Fig. 2.4: Rappresentazione di un elemento in un file DICOM
Pagina 10
Il tag è composto da due identificativi (es. 0008, 0122): uno per il gruppo (es.
anagrafica paziente) e uno specifico dell’elemento all’interno del gruppo (es. il nome
del paziente, data di nascita, …). Oltre al tag ogni DataElement è composto da un
campo denominato Value Rappresentation (VR) che indica il tipo di dato contenuto ed
è presente o meno in base alla sintassi di trasferimento (tab 2.1); dal value length (VL)
che indica la dimensione del DataElement e varia in base al tipo di dato indicato in
VR. Se il campo tipo (VR) indica “SQ” (sequece of items) o “UN” (unknown), il
campo VL contiene la stringa FFFFFFFFH che indica una lunghezza indefinita; infine
il campo value field (VF) che contiene i dati relativi a quell’elemento.
Pagina 11
Tab. 2.1 : Tabella dei tipi di VR
La sintassi di trasferimento è una regola del protocollo di rete che si applica
all’atto della trasmissione del file, definisce il tipo di codifica dei dati e la loro
organizzazione.
La grandezza dei campi di ogni DataElement è definita dal tipo di sintassi.
In particolare se la sintassi è di tipo explicit (fig 2.5) e il tipo indicato in VR è
OB, OW, OF, SQ, UT o UN, si hanno 4byte per il tag di cui 2byte per il gruppo e 2byte
l’elemento, 4byte per il VR di cui 2byte per il valore e 2byte fissi al valore 0000H,
Pagina 12
4byte per il VL, il VF è tanti byte quanti definiti dal VL. E’ possibile che VL sia
indefinito, cioè che contenga il valore FFFFFFFFH, in tal caso il VF ha grandezza
indefinita.
Fig. 2.5: DataElement con VR esplicito e implicito
Per tutti gli altri valori di VR con la sintassi explicit si hanno 4byte per il tag di
cui 2byte per il gruppo e 2byte l’elemento, 2 byte per il VR, 2byte per il VL, il value
field è tanti byte quanti definiti dal VL.
Infine se la sintassi è di tipo implicit si hanno 4byte per il tag di cui 2byte per il
gruppo e 2byte l’elemento, 4byte per il VL, il VF è tanti byte quanti definiti dal VL.
Anche in questo caso è possibile che VL sia indefinito e di conseguenza anche il VF.
Ogni file DICOM è relativo ad un unico paziente e ad un'unica tipologia di
studio/esame, ma può esser costituito da più immagini, come nel caso di studi TAC. I
file con più immagini hanno una struttura particolare caratterizzata dalla presenza di
Pagina 13
un elemento di tipo SQ al posto dell’elemento di tipo immagine. Questo campo può
contenere altri elementi al suo interno, separati fra loro da tag di delimitazione. Anche
in questo caso si possono avere diverse strutture in base al tipo implicito o esplicito. Se
il campo tipo è explicit (tab .2.2), la lunghezza è indefinita ed il campo dati contiene
una sequenza di oggetti ognuno dei quali ha come tag (FFFE,E000), seguito dalla
propria dimensione, in coda agli oggetti per delimitarne la fine viene inserito un
elemento di delimitazione vuoto, che ha tag (FFFE,E0DD) e lunghezza 00000000H.
Se il campo tipo è implicit si distingue il caso in cui l’elemento contenitore conosce la
grandezza degli elementi contenuti o meno. Se non la conosce (tab 2.3) ha come valore
lunghezza indefinito FFFFFFFH, il campo dati contiene la sequenza di oggetti, con tag
(FFFE,E000) seguito dalla dimensione dell'oggetto che può essere indefinita o meno,
nel primo caso dopo il contenuto dell'elemento viene inserito un tag di delimitazione
(FFFE,E00D) di lunghezza 00000000H con un altro elemento di delimitazione di fine
sequenza, nel secondo caso l'elemento ha una struttura normale. Quindi anche gli
elementi contenuti a loro volta possono avere una dimensione esplicita o meno. Nel
caso in cui il campo lunghezza dell’elemento contenitore è indicata (tab 2.4), così
come quella di tutti gli elementi contenuti, pertanto non c’è bisogno di avere un
elemento di fine sequenza.
Data
Element
Tag
(gggg,
eeee) with
VR of SQ
4
bytes
Value
Representation
SQ
2
bytes
0000H
Reserved
2
bytes
Data
Element
Length
Data Element Value
FFFF
FFFFH
un-defined
length
First Item
4
bytes
Second Item
Sequence
Delimitation Item
Item
Tag
Item
Length
Item
Value
Item
Tag
Item
Length
Item
Value
(FFFE,
E000)
98A5
2C68H
Data Set
(FFFE,
E000)
B321
762CH
Data Set
4
bytes
4
bytes
98A5
2C68H
bytes
4
bytes
4
bytes
B321
762CH
bytes
Seq.
Delim.
Tag
(FFFE,
E0DD)
Item
Length
4
bytes
4
bytes
0000
0000H
Tab. 2.2: Esempio di DataElement con VR esplicito impostato a Sequence of Items di grandezza indefinita, di
cui due con esplicita dimensione
Pagina 14
Data
Element
Tag
Data
Element
Length
Data Element Value
First Item
(gggg,
eeee) with
VR of SQ
4
bytes
Sequence
Delimitation
Item
Second Item
FFFF
FFFFH
un-defined
length
Item
Tag
Item
Length
Item
Value
Item
Tag
Item
Length
Item
Value
(FFFE,
E000
0000
17B6H
Data
Set
(FFFE,
E000)
FFFF
FFFFH
undefined
length
Data
Set
4
bytes
4
bytes
4
bytes
17B6H
bytes
4
bytes
4
bytes
undefined
length
Item
Delim.
Tag
(FFFE,
E00D)
Length
Item
Length
0000
0000H
Seq.
Delim.
Tag
(FFFE,
E0DD)
4
bytes
4
bytes
4
bytes
4
bytes
0000
0000H
Tab. 2.3: Esempio di DataElement con VR implicito impostato a Sequence of Items di grandezza indefinita, di
cui uno con esplicita dimensione, l’altro indefinita
Data
Element
Tag
Data
Element
Length
(gggg,
eeee) with
VR of SQ
00000F00
H
Data Element Value
First Item
Second Item
Third Item
Item Tag
Item
Length
Item
Value
Item Tag
Item
Length
Item
Value
Item Tag
Item
Length
(FFFE,
E000)
0000
04F8H
Data Set
(FFFE,
E000)
0000
04F8H
Data Set
(FFFE,
E000)
0000
04F8H
4
bytes
4
bytes
04F8H
bytes
4
bytes
4
bytes
04F8H
bytes
4
bytes
4
bytes
Item Value
Data Set
4
bytes
4
bytes
04F8H
bytes
Tab. 2.4: Esempio di DataElement con VR implicito impostato a Sequence of Items, di cui uno tre con esplicita
dimensione
2.3
Il modello
Come già è stato detto nel paragrafo precedente, all’interno dello standard
DICOM le informazioni hanno una struttura ben definita. Gli oggetti o Information
Object Definition (IOD) sono suddivisi in base all'attinenza (es. paziente, immagine,
studio, …), e sono organizzati come delle classi, cioè con definizioni di tipi di dati e
con attributi (fig 2.6). A ciascuno di questi oggetti sono associate delle operazioni dette
Dicom Message Service Element service group (DIMSE service group). Quindi ogni
oggetto in base al suo contenuto ed alla sua natura ha delle operazioni associate che si
Pagina 15
possono compiere. La coppia IOD-DIMSE service group è detta Service Object Pair
(SOP). La SOP è specifica per ogni IOD, cioè per il tipo di oggetto e l'insieme di tutte
le SOP di un oggetto forma una SOP class. Le SOP con compiti simili costituiscono le
service class. Poiché le SOP sono specifiche per gli IOD, differenti oggetti pur
richiedendo operazioni identiche, avranno due SOP differenti, che però faranno parte
della stessa service class.
2.4
La comunicazione
Nello standard DICOM sono fissati anche i protocolli per lo scambio di file
dicom tra due diverse strumentazioni o tra la strumentazione ed una postazione di
storage. Ogni elemento (apparato medicale, postazione di refertazione, storage
element,..) è identificato da un codice denominato DICOM Application Entity (AE).
Nella fase di trasmissione di un dato tra due AE si applica l'architettura client/server.
Dei due DICOM AE chi trasmette deve svolgere il ruolo di server utilizzando la
Service Class Provider (SCP), mentre chi riceve si comporta come un client ed utilizza
la Service Class User (SCU).
Il DICOM ha una serie di servizi primitivi con compiti di rete di request,
indication, response, confirmation, con funzionamento sincrono o asincrono. Le regole
di comunicazione sono analoghe a quelle utilizzate dai protocolli più diffusi.
Pagina 16
Service Classes
- Study Mgt
- Patient Image Mgt
- Results Mgt
- Storage
- Print
- Query/Retrieve
Information Objects
Normalized
- Patient
- Study
- Visit
Composite
- CT image
- MR image
- CR image
DICOM Message Service
(DIMSE)
Fig. 2.6: Relazioni del paradigma a oggetti nel formato DICOM
2.5
Le funzionalità
Sono le service class a definire cosa si può fare con lo standard DICOM. Le
principali sono: verification, storage, query/retriere, print.
La verification (conferma) si occupa di controllare il livello di comunicazione
tra peer DICOM AE che hanno stabilito un’associazione. Per effettuare una verifica,
un AE invia la primitiva di richiesta ECHO, aspettando la ECHO di risposta. E’ poi la
SCU a determinare se la verifica è completa.
La storage (memoria) permette ad un AE di inviare istanze di IOD tramite il
servizio DIMSE STORE. Affinché l’immagazzinamento sia completo il tipo di dato
trasferito deve essere supportato. Il dato deve esser salvato e deve essere accessibile.
Siccome i tipi di dati sono di diverso tipo la storage service class ha numerose SOP.
La query/retrieve consente a un AE di inviare una richiesta di dati o di
Pagina 17
recuperarne su richiesta. Utilizza query non complesse, poiché non necessita di un
meccanismo completo come quello di SQL. Ha opzioni come unique (valore univoco)
o required (valore obbligatorio) applicabili agli attributi. Le DIMSE utilizzate sono
GET, FIND e MOVE. Con la FIND, la SCU invia una richiesta relativa a qualche
attributo, la SCP invia una risposta per ogni occorrenza trovata, specificando se il
processo di ricerca è terminato o meno (pending status). La MOVE coopera con la
STORE per recuperare i dati. E’ possibile che i due servizi siano rappresentati da
applicazioni differenti o che risiedano su macchine diverse. Una MOVE può
comportare molteplici STORE e le STORE con il meccanismo del pending status
indicano alla MOVE che le ha generate se l’operazione è collettivamente conclusa o
meno. La GET ha lo stesso funzionamento della MOVE ma non può operare su sistemi
operativi diversi, può invocare operazioni di STORE su un solo computer.
La print management consente ad un dispositivo di inviare in stampa immagini
e i dati medici associati anche su più stampanti in serie. Nel processo di stampa si
recuperano tutte le informazioni relative alle immagini necessarie per riprodurle (e
quindi stamparle). Le immagini vengono messe in un pacchetto detto film session che
costituisce l’unità atomica per i processi di stampa. Sono possibili trasformazioni
spaziali e in scala di grigi da applicare alle immagini (modalità LUT, VOI-LUT,
inversione polarità, presentazione LUT).
2.6
Le immagini
Lo standard DICOM supporta vari livelli di compressione delle immagini JPEG
(LS, 2000) oltre a supportare formati video come MPEG2 memorizzati tramite frame
(MP@ML, MP@HL). Ciò significa che è in grado di immagazzinare video e immagini
dei formati corrispondenti. Esistono numerosi software, che senza estrarre i metadati
contenuti nei DICOM, sono capaci di estrarne le immagini in quanto esse sono
puramente incapsulate all'interno del file rispettando la codifica originale. Ovviamente
Pagina 18
nessuno di questi programmi può dire cosa le immagini rappresentano o a chi si
riferiscono, non potendo leggere i metadati associati ad esse.
2.7
L’identificativo
Il formato DICOM garantisce l'univocità dei file. In base alla normativa ISO
9834-3 ogni file ha un identificativo detto UID composto da due parti, la prima è
legata all'ente che genera il file mentre la seconda funge da suffisso incrementale
all'interno dell'ente stesso per contraddistinguere file immessi dalla stessa
organizzazione. Ogni ente è registrato presso l’ISO e pertanto ha assegnato un
identificativo univoco.
Pagina 19
3 PACS
3.1
Introduzione
L’introduzione delle tecnologie digitali comporta numerosi vantaggi rispetto ai
metodi tradizionali come l’uso di carta stampata e di pellicole fotografiche nelle
operazioni tipiche di un reparto medico ed in particolare di radiologia. Esempi sono la
facilità di analisi e di manipolazione delle immagini digitali ai fini diagnostici, la
riduzione dei costi e dei tempi delle operazioni, la facilità di trasporto e comunicazione
dei dati.
Un reparto di radiologia digitalizzato è costituito da due componenti: un sistema
informatico (Radiology Information System, RIS) e un sistema di gestione di immagini
digitali. Il RIS, che opera nell’ambito del reparto, è un sotto sistema del Hospital
Information System (HIS) che gestisce tutti i dati relativi ad un paziente nell’intero
ospedale. Il secondo sistema è detto Picture Archiving and Communication System
(PACS) e gestisce l’acquisizione, l’archiviazione, la trasmissione, l’elaborazione e la
visualizzazione delle immagini mediche.
3.2
Architettura
Il PACS nel più semplice dei casi può essere composto da un dispositivo di
digitalizzazione immagini, una workstation di visualizzazione e un piccolo database di
archivio.
Nei casi più complessi, le fonti di dati possono essere moltissime: tutti gli
apparecchi di radiografia, mammografia, tomografia (CT); di medicina nucleare
(PET); di ultrasuoni (US), di risonanze magnetiche (RM) (fig 3.1). Inoltre, le
apparecchiature di tipo tomografico generano, sequenze di immagini che possono
essere virtualmente sovrapposte per fornire immagini 3D del paziente. Inoltre
Pagina 20
immagazzinare un’immagine è di per sé inutile, è necessario sapere cosa
quell’immagine rappresenta, come è stata prodotta e a quale soggetto si riferisce.
Questi metadati di un immagine medica sono contenuti con l’immagine stessa
all’interno di un file di formato DICOM.
Scanner
TIFF,BMP,..
Modality
Acquisizione
Capture
Scanning
Image Server
Stampanti
Query
Consultazione
Visualizzazione
Stampa
Fig. 3.1: Esempio di architettura in un sistema PACS
Gli utenti di un sistema PACS possono essere principalmente di due tipi, i
radiologi (refertazione) ed i medici (consultazione).
In fase di visualizzazione per le diagnosi i radiologi utilizzano delle workstation
ad alte prestazioni grafiche per supportare elevate risoluzioni, con molta memoria per
poter analizzare più immagini contemporaneamente e con un’adeguata potenza di
calcolo per elaborare le ricostruzioni 3D. I medici invece possono accedere
Pagina 21
direttamente all’archivio dal proprio computer personale tramite delle workstation
server se connessi al sistema PACS, altrimenti tramite un interfaccia web accessibile
con connessioni SSL o VPN. Programmi come K-PACS simulano l’archivio PACS sul
pc del medico, scaricando localmente le immagini di interesse e offrendo strumenti di
analisi e di misurazione per lo studio dei dati (fig 3.2).
Fig. 3.2: Esempio schermata K-PACS
Per i costi di esercizio, la gestione delle immagini mediche tramite l’ausilio di
un sistema PACS è più economico dell’usuale gestione cartacea e su pellicola. Come
costo di avvio, di finanziamento iniziale, è economicamente conveniente se il numero
di casi per anno supera i 50000, dovendo ammortizzare le spese di acquisto delle
macchine. Le operazioni di diagnosi, analisi e trasporto dei dati risultano accelerate, il
sistema è robusto e i medici lo accettano integrandolo nelle loro attività giornaliere.
Pagina 22
3.3
Problematiche
Malgrado tante qualità ci sono delle complicazioni che rendono il
funzionamento dei PACS “delicato” e ultimamente sempre più faticoso con previsioni
future di stallo. I grandi ospedali generano una quantità immensa di dati (fig 3.3-3.4),
basti pensare che una singola immagine può richiedere 20Mb e che gli apparati
tomografici generano sequenze di immagini. I flussi di dati sono quindi notevoli e solo
grazie ad architetture studiate e con adeguati cablaggi è possibile trasmettere i dati
senza latenza. Ma arrivati a destinazione, negli archivi, si crea un problema di spazio.
Attualmente la stima è di 6mesi di permanenza dei dati nell’archivio PACS di un
ospedale, dopo questo tempo i dati devono essere trasferiti per liberare spazio per
permettere l’archiviazione di nuovi dati. Le tecniche di backup consistono nel
salvataggio dei dati su supporti definitivi come nastri o dvd, automatizzati da strumenti
come i jubox. L’operazione è molto lenta, salvare un dato costa un terzo del tempo
necessario per la sua acquisizione, cioè per salvare 3 mesi di archivio ci vuole un
mese. Stesso procedimento, ma nel verso contrario si ha nel caso di recupero dei dati.
Inoltre i dati gestiti dai PACS non sono informazioni qualunque, ma rientrano in una
categoria particolare di informazioni, che per la loro natura devono essere protetti da
accessi non autorizzati, in quanto contengono dati sensibili e devono risultare sempre
reperibili entro un tempo limitato e non possono esser persi. Per tale motivo si deve
quindi avere a disposizione un copia di emergenza di tutte le informazioni. Queste
criticità comportano vincoli stetti, come l’accesso ai dati possibile sono internamente
all’ospedale o se esternamente tramite connessioni sicure come SSL o VPN. Per
risolvere i problemi di spazio e di tempo del recupero e del salvataggio dei dati,
ultimamente si adotta la tecnica dello “spinning”, cioè copia dei dati non su nastri o
dvd, ma su dischi tramite NAS, SAN o DAS, cioè direct o network storage. Si crea una
connessione performante fra l’archivio PACS interno all’ospedale e una farm di
archiviazione gestita con tecniche di memorizzazione come RAID1 per garantire
l’integrità dei dati in casi di rotture e la non interruzione del flusso in fase di
Pagina 23
sostituzione di dischi rotti.
Fig. 3.3: Crescita degli studi CT e delle immagini per studio
Fig. 3.4: Crescita degli studi CT e delle immagini per studio
Studi effettuati dalla University of Maryland presso la Mayo Clinic
Pagina 24
3.4
Prospettive
Tuttavia le evoluzioni che gli ospedali stanno intraprendendo sono inadeguate
agli sviluppi tecnologici offerti dalle innovazioni attuali. Le preoccupazioni sulle
capacità evolutive dei PACS si basano sul fatto che il mercato è estremamente ristretto,
essendo chiuso ai produttori dei dispositivi medici che generano le immagini e che per
primi hanno presentato soluzioni alla gestione dei dati che i loro stessi dispositivi
generavano. L’ utilizzo di massa delle tomografie e delle risonanze magnetiche
potrebbe estendersi alle ricostruzione a fascio di cono, alle immagini spettrali,
l’utilizzo di tali innovazioni verrebbe compromesso dai limiti dei PACS.
Fig.3.5: Diagramma di flusso dei dati in un sistema PACS
Pagina 25
Per dare un futuro a questi sistemi di archiviazione e trasferimento di immagini
sono state ipotizzate delle innovazioni.
Nel 1965 il cofondatore della Intel, Moore, formulò una previsione della durata
di 10 anni sull’incremento della potenza dei computer e sulla capienza della memoria
secondaria, dopo 40anni la previsione continua a coincidere con lo sviluppo dei
computer che per il 2012 dovrebbero raggiungere i 40 GHz di potenza e 3TB di
memoria secondaria. Purtroppo nonostante la previsione ottimistica, l’incremento
misurato di dati immessi nei PACS che è proporzionale sia al numero di studi che alla
dimensione delle immagini prodotte dagli studi è superiore alla crescita di Moore sui
dischi, quindi non solo sarà necessario sostituite dischi con altri più capienti, ma se ne
dovranno aggiungere ulteriori se ci si baserà sui dischi come unità di archiviazione.
Un’alternativa potrebbero essere le memorie solid-state drive (SSD), unità a stato
solido, memorie non volatili che risolverebbero praticamente tutti i problemi che
hanno attualmente le farm di dischi. Consumano meno, scaldano meno, sono più
affidabili, non hanno vincoli di dimensioni, hanno tempi di lettura e scrittura inferiori
non avendo parti meccaniche in movimento e si sta investendo molto su questa
tecnologia. Per ora rimane una speranza in quanto ancora non si è raggiunti la stessa
capacità di capienza dei dischi, ma soprattutto il costo è proibitivo, anche se con una
radicale diffusione potrebbe calare rapidamente.
Altra prospettiva è quella di sfruttare il mercato delle aziende che offrono farm
di blade server per risolvere i problemi di spazio che nascono dalla necessità di avere
molte workstation e molte unità di archivio in un ospedale, esternalizzando i problemi
di ingombro, prestazioni, tolleranza ai guasti meccanici e potenza di calcolo, che
verrebbero demandate al gestore della farm. Le comunicazioni server-server sono
istantanee, gli spazi occupati ridotti del 90%, la frequenza di manutenzioni dovute a
guasti meccanici come ventole, alimentatori o parti mobili dei dischi minima, grazie
all’architettura dei server blade.
Un ulteriore sviluppo sarebbe utile alle applicazioni client, oggi appesantite dai
conflitti che si creano con lo stato software costituito dai sistemi operativi, un
Pagina 26
approccio basato sul web e quindi sugli ambienti standard dei browser contribuirebbe a
creare un client “thinner”, se affiancato da tecniche come AJAX che gli
permetterebbero di non perdere prestazioni e funzionalità.
Infine l’architettura che è attualmente indefinita dovrebbe esser formalmente
riorganizzata su un modello Model View Controller (MVC), con un livello di
visualizzazione per l’utente, un livello logico con regole, protocolli e flussi, infine un
livello dati.
Un ultima soluzione è quella di avere una memoria distribuita, poiché risulta
ingestibile localmente, sia per la mancanza di competenze nell’ente ospedaliero, che
per l’entità della struttura necessaria. Gli approcci possibili sono due, la cloud e la grid
computing orientate allo storage, cioè all’immagazzinamento.
La prima, agli evidenti pregi associa il difetto della sicurezza e dell’affidabilità,
irrisolvibili e basate puramente sulla fiducia dell’azienda che offre il servizio, la
seconda invece, più trasparente, è l’alternativa investigata in questa tesi.
Pagina 27
4 La Grid
Per griglia di calcolatori o grid si intende un’organizzazione basata su
connessioni di rete che collega computer geograficamente sparsi e potenzialmente
eterogenei per condividere le proprie risorse. L’utilità è quella di utilizzare tutte le
risorse disponibili quando necessario. I processori passano la quasi totalità del loro
tempo in uno stato di inattività o di basso carico di lavoro. In una griglia ogni membro
o nodo che ne fa parte cede la parte di tempo libero che ha a chi ne ha bisogno. Così
un calcolo lungo che su un solo computer richiederebbe molto tempo e non
premetterebbe di fare altre operazioni, può esser risolto rapidamente distribuendolo su
più calcolatori che nel frattempo fanno meno operazioni di quante potrebbero farne e
che quindi stanno sprecando risorse. Per questo le griglie sono un esempio di calcolo
distribuito, che a differenza di quello parallelo ha come priorità non la prestazione, ma
l’utilizzo di tutte le risorse e la minimizzazione gli sprechi. La tecnologia GRID
dovendo rispondere alla richiesta di avere una grande capienza, senza il diretto
interesse di gestire i siti di memorizzazione, alla necessità che i dati siano protetti sia
sui dischi che nella fase di trasporto, alla garanzia che in caso di incidenti sia sempre
reperibile una copia dei dati, è una candidata ideale alla soluzione del problema della
gestione dei PACS.
4.1
Storia
Condor è considerato il precursore della GRID, un progetto elaborato
dall’Università del Wisconsin nel 1988 con lo scopo di fornire una grande potenza di
calcolo per periodi prolungati. Si parla di High Throughtput Computing (HTC) poiché
ciò che si deve elaborare è una grande quantità di dati indipendenti. A differenza
dell’High Performance Computing, (HPC) che ha come unità di misura le operazioni
floating point per secondo, e per la quale sono necessari supercomputer e ambienti di
Pagina 28
lavoro in parallelo al fine di avere risposte immediate, l’HTC ha come unità di misura
le operazioni floating point per mese. L’idea è di usare le macchine quando sono
inattive, senza rallentare le operazioni del proprietario, con un’architettura formata da
nodi di assegnazione delle risorse e nodi contenenti le parti dei “job”.
Il passaggio alla GRID avviene applicando le tecnologie che già da tempo si
adottavano con i cluster e le workstation in ambito di calcolo parallelo, ad un insieme,
una griglia, di “risorse” non specificatamente dedite alle operazioni della GRID.
In Europa l’European Grid Initiative (EGI) è un’iniziativa volta a coordinare le
iniziative nazionali dei paesi europei (NationalGI) per rendere possibile lo svolgimento
di progetti comunitari. Dal 2006 si succedono vari progetti evolutivi come i tre
Enabling Grids for E-sciencE (EGEE), l’EGI design study e l’attuale Integrated
Sustainable Pan-European Infrastructure for Researchers in Europe (EGI-InSPIRE)
iniziato il primo maggio 2010. L’Italian Grid Infrastructure (IGI) è la parte dell’EGI
italiana, vi fanno parte numerose organizzazioni di ricerca come il CNR, l’ENEA, il
GARR, l’INAF, l’INFN e molte altre.
I progetti mondiali più noti sono il Wordlwide LHC Computing Grid (WLCG),
una griglia di calcolatori sparsa su 34 paesi per raccogliere ed elaborare i dati generati
dagli esperimenti del Large Hadron Collider (LHC). Il più popolare progetto è il
Search for Extraterrestrial Intelligence (SETI@HOME) che ha trovato come
infrastruttura di supporto il web e i normali utenti, collegandoli ad una GRID dinamica
tramite un programma, con il compito di cercare segni di vita extraterrestre
analizzando le onde radio provenienti dallo spazio. La maggior parte dei progetti
umanitari sono sviluppati dalla World Community Grid, anch’esso basato non su centri
di calcolo ma sulle risorse di normali utenti, ha raggiunto numerosi traguardi in merito
a studi sul cancro, sul genoma, sull’AIDS, sulla distrofia muscolare, oltre che sulla
ricerca di materiali per produrre energia pulita. Il programma più diffuso per la
realizzazione dell’architettura GRID è il Berkley Open Infrastructure for Network
Computing (BOINC) impiegato sia nei progetti umanitari che per il SETI. In Europa è
diffuso il Lightweight Middleware fog Grid Computing (gLite) sviluppato nell’ambito
Pagina 29
delle iniziative EGEE.
4.2
Organizzazione
All’interno della griglia i PC sono organizzati in Virtual Organizzation (VO) a
seconda dei compiti a cui sono dedicati. Gli utenti una volta registrati sulla griglia
dall’ente che la gestisce e che ne assicura il funzionamento può richiedere l’accesso ad
una o più VO. L’accesso alla VO viene gestito dal manager della VO stessa. Solo dopo
il consenso del VO manager l’utente può accedere alle risorse che appartengono alla
VO e solo a quelle. Le VO sono la rappresentazione virtuale di insiemi di utenti che
condividono le risorse, come i gruppi di lavoro per progetti di ricerca. All’interno di
una VO si possono definire permessi sia collettivi che individuali per avere una
granularità dei ruoli.
4.3
Sicurezza
L’autenticazione avviene tramite certificati X.509, file generati da una
Certification Authority (CA), contenenti le credenziali dell’utente. I certificati sono
criptati, non si possono modificare e per leggerli bisogna avere una password detta
chiave in possesso del proprietario del certificato. Essi sono il mezzo più sicuro di
autenticazione e costituiscono una carta d’identità digitale. E’ importante però che i
certificati non vengano diffusi liberamente sulla rete, per evitare che nel caso in cui
estranei vengano in possesso della chiave dell’utente e possano autenticarsi al suo
posto. Per far si che il certificato resti sempre nelle mani del proprietario si utilizzano i
proxy, delle credenziali create localmente e temporaneamente, inviate al posto del
certificato, che permettono a processi esterni di autenticarsi a nome di un utente.
Pagina 30
4.4
Architettura
I componenti di una griglia sono, l’User Interface (UI), e cioè il punto di
accesso per gli utenti alla griglia, il Resource Broker (RB), che gestisce le risorse
assegnando i lavori. Il Job Submission Service (JSS), il sistema di sottomissione dei
lavori, l’Information Index (II), utile per selezionare le risorse, il Logging and
Bookkeeping services (LB), che contiene le informazioni sui lavori sottomessi dagli
utenti, ed infine i calcolatori che si differenziano in Computer Elements e Storage
Elements (CE e SE), i primi svolgono i lavori o job mentre i secondi contengono i dati
sui quali si opera.
4.5
Middleware
Siccome la caratteristica delle griglie è quella di collegare risorse eterogenee, è
necessario garantire la compatibilità della griglia con i vari sistemi. Il middleware è
uno strato software che si interpone fra l’hardware e la griglia, la sua architettura è a
clessidra (fig 4.1), cioè un modello a strati con al centro i servizi base e ai due lati la
griglia e i servizi di alto livello. L’architettura dei protocolli è a 5 livelli, il primo detto
fabric, interfaccia le risorse locali con la griglia, il connectivitiy fornisce i protocolli di
comunicazione e autenticazione, il resource ha i protocolli per ottenere informazioni
sulla configurazione e sullo stato di una risorsa e per negoziarne l’utilizzo, il collective
gestisce un insieme di risorse come le VO, l’application comprende tutte le
applicazioni dell’utente che possono interagire con la griglia.
Pagina 31
Fig. 4.1: Architettura middleware
4.5
Archivi
Il grid computing è adottato soprattutto per fini di calcolo, con problematiche
legate alla gestione delle code di job, alla loro assegnazione, alla suddivisione dei
grossi calcoli. La griglia di GridPACS per come è attualmente implementata è di
immagazzinamento, con problematiche differenti. Le tecnologie oggi usate per
l’immagazzinamento dei dati senza grid più diffuse sono la Direct e Network
Attacched Storage (DAS e NAS) e la Storage Area Network (SAN). La DAS richiede
una connessione diretta, non di rete, fra il server che richiede l’accesso ai dati e i dischi
stessi, la NAS utilizza macchine di archiviazione con il minimo indispensabile per
collegarsi alla rete attraverso la quale possono accedere tutti gli altri computer, la SAN
è formata da un insieme di macchine di archiviazione connesse con uno switch che con
collegamenti ad alte prestazioni gestisce le richieste ai dischi. Il NAS rispetto al DAS è
un’evoluzione, ma a differenza del SAN non è scalabile, poiché ha un limite di
capienza, che nel SAN è quasi illimitata. Tuttavia la NAS è molto più economica e
facile da applicare. In ambito GRID il NAS non è adottabile, poiché un SE ha bisogno
di avere lo strato software intermedio, laddove possibile un SE di una griglia ha una
struttura SAN.
Pagina 32
4.7
Immagazzinamento
Per inviare un dato sulla griglia si deve aver accesso ad una UI, anche tramite il
web. Bisogna esser registrati presso una VO della griglia ed avere un certificato
firmato da un CA. L’UI per motivi di prestazioni è bene che sia connesso ad alta
velocità con l’utente che vi si collega, poiché sulle reti normali l’upload di file grandi
risulta costoso, potrebbe ad esempio trovarsi all’interno della LAN dell’utente. Una
volta connessi alla griglia si invia il file che viene trasferito su un SE, si registra la
presenza del nuovo file sul catalogo della griglia (Logical Filename Catalogue, LFC) e
viene creata una replica su un altro SE, per motivi di ridondanza dei dati. A questa
struttura di griglia manca un componente di comodità, un database che tenga traccia
dettagliatamente delle informazioni immesse. Il catalogo LFC infatti si occupa di
ricordare dove i file sono stati inviati, tramite l’associazione logical filename - guid,
ma non cosa essi contengano. Per far ciò, in GridPacs, è stato utilizzato un database
specifico per cooperare con le griglie, l’ARDA Metadata Catalogue Project (AMGA,
dove ARDA significa A Realization of Distribuited Analysis) [6].
Pagina 33
Fig. 4.2: Struttura Progetto
4.8
Progetti Medici
Numerosi progetti si affiancano all’iniziativa GridPACS, ponendo soluzioni
simili ai problemi comuni. I fattori comuni sono il problema dello spazio, dovuto alla
non scalabilità dei sistemi PACS e la ricerca di soluzioni economiche.
Il Mobius Project [9], del Dipartimento di Informatica Biomedica
dell’Università dell’Ohio (USA) ha collegato tramite una griglia diverse istituzioni e
permette di incrociarne i dati, di potervi accedere con il minimo costo e di eseguire
query distribuite. Il progetto si basa sulla fornitura di servizi come mako, un servizio di
data storage e retrival.
Pagina 34
Il Data Grid for large scale medical image archive and analysis [10], elaborato
dal Dipartimento di Radiologia e Ingegneria Biomedica dell’Università della
California del Sud (USA), applica la tecnologia data grid per risolvere i problemi dei
sistemi di storage esistenti in ambito medico, con un sistema su larga scala di
immagazzinamento a basso costo di backup e recupero dati ottenuto collegando i SAN
dei vari enti alla griglia. L’analisi delle immagini viene effettuata dividendo le
immagini in piccole porzioni da analizzare individualmente da nodi diversi, evitando
la necessità di avere un nodo con elevate prestazioni di calcolo.
Un progetto del Dipartimento di Matematica e Informatica dell’Università di
Cagliari mira ad utilizzare un SRB per la realizzazione di una griglia per dati medici
[11]. L’SRB è lo Storage Resorce Broker, un componente grid che viene fatto
interagire con le funzionalità DICOM tramite un’interfaccia scritta in C++. Grazie a
questo driver SRB/DICOM è possibile l’invio di dati anonimizzati dal PACS alla grid
e quindi l’accesso alle immagini dei PACS tramite griglia.
Un progetto che si basa sullo stesso middleware di GridPACS è MEDICUS[12],
sviluppato dal Dipartimento di Radiologia, dall’Children Hospital di Los Angeles,
dalla scuola di medicina Keck, dal Dipartimento di Ingegneria Biomedica e dalla
Scuola di Ingegneria Viterbi e dal Dipartimento di Chirurgia dell’Università della
California del Sud, con l’Istituto di Radiologia e Calcolo dell’Università di Chicago, il
Centro Nazionale per le Tecnologie Grid Argonne, la divisione sistemi avanzati e
l’Istituto di Scienze dell’Informazione. MEDICUS utilizza il Globus toolkit come
middleware di accesso ai servizi grid che interfaccia a tutte le tipologie di utenti
(sistemi PACS, medici, radiologi, dispositivi di acquisizione, ecc) tramite un servizio
denominato DICOM Grid Interface Service (DGIS). Il compito del DGIS è di tradurre
le operazioni grid/DICOM, occupandosi dei protocolli, di consultare i cataloghi grid,
di trasferire i file avendo a disposizione una cache. La sperimentazione effettuata con i
dati di un gruppo di oncologia infantile e di una fondazione per la cura del
neuroblastoma ha mostrato che le specifiche grid sono ben mascherate dall’interfaccia
e gli utenti coinvolti non hanno dovuto modificare le usuali procedure di flusso dei dati
Pagina 35
nell’ambiente DICOM. Il DGIS è multithread ed ottimizza le operazioni,
comprimendo le serie immesse nella griglia, inoltre utilizza come identificativo non il
GUID ma l’identificativo unico relativo ad uno studio o una serie nativo del formato
DICOM. La sicurezza è stata organizzata su tre livelli, il primo basato sull’identity
provider(IdP) per l’autenticazione, il secondo relativo all’impiego dei certificati X.509
necessari per accedere alla GRID, l’ultimo riferito ai dati che vengono anonimizzati,
conservando i metadati originali su un database del DGIS.
Una soluzione proveniente da privati è quella della Bycast Inc. oggi acquisita
dalla NetApp [13]. All’interno degli ospedali si inseriscono i nodi di una griglia che
interagiscono tramite un software di interfaccia ai PACS locali. L’obiettivo è di
minimizzare i punti di fallimento abbandonando l’approccio centralizzato dei PACS e
distribuendo i servizi di immagazzinamento e trasmissione dei dati su nodi distanti ma
costituenti una singola entità, una griglia.
Il progetto della Bycast ha già trovato uno sviluppo, fornendo le basi per
GMAS[14] sviluppato dalla IBM che si basa sul software di StorageGRID del progetto
della Bycast. GMAS è stato sviluppato in due versioni, per singoli ospedali e per più
ospedali, dando la possibilità di adottare la soluzione grid anche a enti non federati.
Oltre allo storage di dati multimediali è possibile immagazzinate qualsiasi dato
medico, cartelle cliniche, appunti dei medici, video, audio, immagini, email, ecc.
Altri progetti si concentrano sul problema delle risorse di calcolo, come il
MedIGrid [15], elaborato dall’Università di Genova con l’INFM di Genova, l’Istituto
di Calcolo e Reti ad Alte Prestazioni CNR di Napoli, il Dipartimento di Fisiopatologia
Clinica dell’Università di Firenze e il Dipartimento di Matematica e Applicazioni
dell’Università degli Studi di Napoli Federico II. Il progetto ha prodotto un prototipo
di infrastruttura grid per applicare le tecniche di ricostruzione tomografica su griglia. Il
problema è la grande quantità di dati prodotti dalle analisi che necessitano di essere
elaborati per essere visualizzati e immagazzinati.
Il Medgrid project [16] è un progetto svolto dal centro di ricerca grid
dell’Istituto Nazionale della Scienza e delle Tecnologie Industriali Avanzate di
Pagina 36
Tsukuba City (Giappone) e dal Dipartimento di Tecnologia Gerontologica del Centro
Nazionale per la Gerontologia e Geriatria di Ohbu (Giappone). Collegando tre siti nel
Giappone, Filippine e Taiwan ha creato una federazione di risorse in una VO con lo
scopo di avere una capacità di calcolo e di memoria collettiva superiore a quella
individuale.
Pagina 37
5 AMGA
5.1
Panoramica
AMGA è un database che permette di memorizzare i metadati associati ai file
che si immettono su una griglia, associando il loro identificativo univoco sulla GRID
(GUID) a vari dati di interesse. In questo modo per reperire un dato generico, invece di
dover sapere a priori il GUID del dato, è possibile effettuare ricerche in base ai
parametri dei valori presenti in AMGA e trovare anche più di un file sulla griglia di
interesse.
Essendo un programma che lavora in stretta collaborazione con le griglie,
anch’esso viene inserito in un nodo e nella stessa VO degli SE, diventando un
componente del meccanismo di invio e ricezione dei dati. Per accedervi è necessario
avere un proxy valido, precisamente lo stesso necessario per autenticarsi sulla griglia,
che una volta creato all’accesso sulla griglia, agendo da sessione rende trasparente la
successiva connessione al database AMGA.
Fig. 5.1: Logo ARDA Metadata Catalogue Project
5.2
Affidabilità
Le griglie sono molto grandi e quindi contengono molti file, per questo AMGA
Pagina 38
è stato sviluppato con l’intento di gestire una grande quantità di dati. Le comunità
nelle quali è stato impiegato per sviluppo e testing sono l’High Energy Physics (HEP)
e la Biomed. La prima ha fornito feedback sulla robustezza, utilizzando AMGA per
memorizzare centinaia di milioni di dati con letture variabili, la seconda invece ne ha
impiegati i vincoli, memorizzando informazioni mediche sensibili, come dati
anagrafici associati a malattie, monitorando gli accessi con una Access Control List
(ACL).
5.3
Interfaccia
In AMGA è’ possibile definire query SQL-like comprendenti stringhe e funzioni
matematiche, per garantire la compatibilità sono presenti i tipi di dati più comuni
come: float, integer, string e timestamp.
AMGA è un front-end di un database relazionale che può essere MySQL,
Oracle, SQLite, PostgreSQL. Il paradigma di modellazione delle tabelle è somigliante
alla gerarchia di un file system, la gestione risulta più familiare agli utenti ed è più
semplice effettuare query su sottoalberi di dati o replicarne rami.
5.4
Sicurezza
Trovandosi all’interno della griglia vi può accedere solo chi fa parte della stessa
VO e le comunicazioni sono criptate dal protocollo SSL. Tuttavia nel database
vengono immagazzinate le informazioni più sensibili in chiaro. Nei file DICOM senza
un PACS non sono immediatamente leggibili i dati, inoltre è possibile che categorie di
utenti si debbano interessare solo ad alcuni aspetti dei pazienti. C’è la possibilità di
definire permessi aggiuntivi tramite le ACL restringendo l’accesso per tabella o per
tupla, cioè singola riga di valori presente in una tabella, ma con prevedibili costi di
prestazione. Per quanto riguarda le repliche, i database si trovano in relazione di
Pagina 39
master-slave fra loro, il master copia parzialmente o totalmente i dati aggiornando lo
slave con degli update. Il database slave può esser consultato localmente per avere
maggiore rapidità. Questo approccio è stato preferito in quanto efficace nel caso di
produzione geograficamente fissa dei dati, nel caso di GridPACS proveniente dagli
ospedali.
Pagina 40
6 GRID INFN
6.1
Architettura utilizzata
La griglia INFN utilizza come middleware gLite [7]. Rispetto all’architettura a
clessidra [fig. 4.1]
si concentra sugli strati collective, resouce e connectivity. Il
modello si basa su due servizi, i core ed i collective [fig. 6.1].
I servizi core sono locali e permettono di condividere le risorse di calcolo o di
storage, i collective sono servizi centralizzati che lavorano al di sopra delle risorse
locali, e costituiscono l’infrastruttura.
L’unità fondamentale è il grid element (GE), un host che fornisce i servizi, siano
essi core o collective, fornisce i metodi per accedere ai servizi e può interagire sia con
altri GE che direttamente con gli utenti.
I GE possono essere computing element (CE) fornitori di servizi di calcolo,
storage element (SE) fornitori di servizi di storage, worker node (WN) macchine di
calcolo, o site BD (SBDII) contenenti le informazioni sulle risorse locali. I GE sono
organizzati in siti, in ogni sito è presente almeno un CE, un SE, un SBDII e più WN. I
siti forniscono i servizi core come l’invio di un job, la visualizzazione dello stato di un
job, la cancellazione di un job o il recupero del suo output, l’interfaccia per la gestione
dello storage.
I servizi collective che interagiscono con i siti sono il Virtual Organization
Membership Server (VOMS) responsabile dell’accesso di un utente alla propria VO, il
Workload Management System (WMS) che ha lo schedule dei job su tutti i siti e
consulta il top db (BDII) che contiene tutte le informazioni distribuite sui SDBII, ed il
Logical Filename Catalogue (LFC), un file system virtuale che mappa i nomi logici sui
file fisici distribuiti negli SE.
Pagina 41
Fig. 6.1: Struttura GRID gLite
6.2
Protocolli
Al livello connectivity degli strati di protocolli, il Globus toolkit, dal quale
deriva gLite, utilizza i protocolli Grid Security Infrastructure (GSI) per le fasi di
autenticazione, autorizzazione, comunicazione e protezione. Al livello resource i
protocolli standard utilizzati sono: il Grid Resource Information Protocol (GRIP) per
ottenete informazioni sulla configurazione e sullo stato di una risorsa, il Grid Resource
Registration Protocol (GRRP) per registrare le risorse, il Grid Resource Access
Management (GRAM) per l’allocazione delle risorse di calcolo e per il controllo dei
calcoli sulle risorse, il Grid File Transfert Protocol (GridFTP) basato sull’FTP per
l’accesso ai dati, il Ligthweight Directory Access Protocol (LDAP) per l’accesso alle
directory. Al livello collective usa il Meta Directory Service (MDS) per la gestione di
Pagina 42
collezioni di risorse.
Fig. 6.2: Logo Lightweight Middleware for Grid Computing
6.3
Struttura Progetto
Nella Griglia INFN è stata creata un VO chiamata pacs.infn.it [8] con un SE a
nome dell’INFN di Napoli nel centro di calcolo della sede Monte Sant’Angelo del
Dipartimento di Scienze Fisiche dell’Università “Federico II” di Napoli. E’ previsto
l’inserimento delle UI nelle LAN degli enti partecipanti al progetto: Sezione INFN di
Napoli, CNR Policlinico di Napoli, ospedale Sant’Orsola Malpighi di Bologna,
ospedale Brotzu di Cagliari. Attualmente è funzionante solo quella della Sezione INFN
di Napoli ed è in fase di installazione quella del CNR. Le UI non sono accessibili
dall’esterno delle LAN e costituiscono l’unico canale di comunicazione fra la griglia e
gli enti. Questo per garantire un ulteriore livello si sicurezza oltre all’utilizzo dei
certificati e delle connessioni SSL.
La fase attuale del progetto è di BETA-test, in quanto i dati immessi sono
sanitizzati e servono a dimostrare la possibilità di effettuare ricerche incrociate sui dati
provenienti da enti geograficamente distanti.
Successivamente con l’introduzione di livelli di accesso diversificati in base al
ruolo medico o ad altre caratteristiche si potrà passare all’immissione dei dati reali.
Pagina 43
Fig. 6.3: Infrastruttura delle connessioni di rete
Pagina 44
7 GridPACS
7.1
Applicazione Web
Il risultato dell’utilizzo di queste tecnologie ha portato alla realizzazione di
un’applicazione web presente sulle User Interfaces della VO pacs.infn.it che consente
agli utenti l’accesso al database. Le funzionalità dell’applicazione sono di inserimento,
ricerca e recupero dei file DICOM, con l’ausilio dei certificati X.509 per la fase di
autenticazione, del database AMGA per le ricerche basate sui metadati, di varie
funzioni fornite dalle librerie openssl, lcg e gLite/bin utilizzate tramite il linguaggio di
scripting PHP. L’applicazione è pensata per mascherare agli utenti tutte le operazioni
tecniche e per rendere il suo funzionamento semplice e intuitivo. Le procedure
normalmente manuali e svolte da linea di comando sono state automatizzate e tradotte
in un’interfaccia grafica.
7.2
Specifiche
Il sistema operativo presente sulle UI è redhat scientific linux CERN 4 dotato
del middleware gLite. Come web server è stato utilizzato apache2 con il modulo PHP
modificato per interpretare le pagine .php come script Common Gateway Interface
(CGI). Tutti gli utenti della VO GridPacs devono essere registrati come utenti di
sistema ed inseriti in un apposito gruppo. L’applicazione web delle UI è montata in
locale ed è accessibile solo dalla LAN nella quale è inserita.
7.3
Funzionamento
Il medico, l’utente a cui è destinato l’uso di GridPACS, ha due credenziali,
Pagina 45
quella fornitagli dalla CA che ha creato il certificato X.509 ed una credenziale richiesta
all’amministratore locale della UI per poter accedere al portale [fig. 7.1].
Se l’utente è al primo accesso al sistema, l’UI rileva l’assenza del certificato e
chiede all’utente di inviargli il file .pk12 corrispondente al certificato fornitogli dal CA
con la chiave di crittografia. Localmente l’UI elabora il file certificato separandone la
componente chiave dalla parte dati. I risultanti file, due *.pem, vengono salvati nella
cartella privata dell’utente del sistema corrispondente all’utente che si è autenticato sul
portale. Il certificato .pk12 dopo l’elaborazione viene eliminato.
Se non è il primo accesso al sistema i file .pem sono già presenti sulla UI e
viene chiesta la chiave all’utente per generare il proxy e inoltrarlo al fine di accedere ai
servizi della griglia. Una volta generato il proxy ha una durata di 24 ore. La homepage
di GridPACS offre la possibilità di inviare file DICOM per memorizzarli, di effettuare
ricerche in base a qualunque metadato riguardante il paziente o il tipo di analisi
relativa alle immagini presenti nel file DICOM, infine di poter scaricare file presenti
sulla griglia.
Pagina 46
Fig. 7.1: Diagramma di flusso dell’accesso al sistema
L'inserimento prevede l'upload del file DICOM, i metadati vengono estratti ed
inseriti in AMGA, mentre il file è inviato sulla griglia. La ricerca ha per possibili
attributi di ricerca il nome del paziente, l'età del paziente, la data in cui ha eseguito
l'esame, l'ente esecutore dell'esame, il tipo di esame, la parte del corpo analizzata o
l'identificativo del paziente. L'esito della ricerca permette di scaricare il file DICOM
desiderato tramite una tabella.
Pagina 47
8 Guida d’uso
8.1
Tipologie utenti
Nell’ambito del progetto GridPACS ci sono 4 tipologie di utenti che
interagiscono fra loro. Il CA è una figura a livello nazionale, ad esso compete
concedere l’utilizzo dell’infrastruttura GRID INFN utilizzata dal progetto, le richieste
devono essere inviate dal diretto interessato (il medico). L’amministratore della VO è a
capo del progetto, è il responsabile delle risorse affidate alla VO, ha il compito di
autorizzare chi partecipa al progetto. Il sistemista della UI, è una figura locale ad ogni
ente che partecipa, ha il compito di configurare la UI, di effettuare la manutenzione, di
garantirne il funzionamento e di permetterne l’accesso agi utenti che ne hanno diritto.
Gli utenti (i medici) sono gli utilizzatori, ad essi è pensato GridPACS, sono gli unici
utenti che possono avere accesso ai dati presenti sulla griglia.
La struttura dell’applicazione web è mostrata in figura 8.1, le pagine sono
spiegate in dettaglio nel paragrafo successivo.
Pagina 48
Fig. 8.1: Sitemap di GridPACS
Pagina 49
8.2
Registrazione
Per avere accesso al sistema l’utente ha bisogno di due credenziali. La prima è
quella della griglia, che deve richiedere al CA , nel caso di GridPACS è l’INFN [17]. Il
CA con una procedura fornisce all’utente un certificato che attesta la sua identità
“digitale”. La griglia è organizzata in sottoinsiemi di risorse appartenenti alle VO (la
VO del progetto è pacs.infn.it) ed è necessario richiedere all’amministratore della VO
l’accesso alle risorse. Dal portale IGI [18] si inoltra la richiesta per entrare a far parte
della VO; ottenuto l’accesso si conclude la prima fase di registrazione.
La seconda credenziale che l’utente necessita è quella per accedere alla UI di
competenza, si deve rivolgere al sistemista responsabile della UI presente nella LAN
dell’ente dal quale l’utente dipende. L’amministratore della UI ha il compito di creare
un account di sistema per l’utente che intende registrarsi e di inserire una copia
dell’applicazione web nella cartella privata public_html. Dopo queste procedure
l’utente può accedere a GridPACS.
8.3
Accesso al sistema
La prima pagina (fig 8.2) è un semplice portale di benvenuto già protetto dalla
connessione https e raggiungibile da tutti senza autenticazione. Il link “Avvia
Sessione” conduce al portale di accesso, nel passaggio sono richiesti i dati relativi
all’account che l’utente ha sul sistema. Una volta autenticato ogni operazione che
l’utente svolgerà sarà a suo nome e reperibile dai log del sistema.
Pagina 50
Fig. 8.2: Portale benvenuto index.html
Qualora fosse il primo accesso sarà necessario l’invio del certificato ricevuto
dal CA e della chiave per separare la componente dati dalla parte di crittografia (fig 8.3
– fig 8.4) la pagina invio.php è referenziata dal collegamento “Invio Certificato” della
pagina index.php.
Pagina 51
Fig. 8.3: Portale accesso index.php
Fig. 8.4: invio certificato invio.php
Pagina 52
Ai successivi accessi verrà richiesta solo la chiave per generare il proxy e
autenticarsi sulla griglia (fig 8.5 – fig 8.6) in questo caso la pagina index.php sarà
diversa, il link “Accesso Grid” conduce alla pagina accesso.php.
Fig. 8.5: Portale accesso index.php
Pagina 53
Fig. 8.6: accesso alla griglia accesso.php
8.4
Invio di un file DICOM
La home (fig 8.7) è la pagina dalla quale si possono effettuare le operazioni,
all’atto della creazione del proxy viene mostrata la scadenza del proxy, fino ad allora
l’utente può accedere al sistema senza alcuna procedura di autenticazione, finchè non
effettua il logout che provvede alla rimozione del proxy (collegamento “Uscita”). Il
link “Invio File” conduce alla pagina upform.php che contiene un semplice campo di
input file. L’operazione di invio del file può durare qualche secondo in base alla
dimensione del file e alla velocità di upload dell’utente. Quando il file arriva all’UI se
ne verifica il formato e viene inviato alla grid, come feedback dell’avvenuta
immissione è mostrato il GUID del file e in una tabella il riepilogo del contenuto del
Pagina 54
file (fig 8.8).
Fig. 8.7: Home sistema home.php
Pagina 55
Fig. 8.8: Conferma invio di un file upload.php
8.5
Ricerca e download
Il link della home “Ricerca File” collega alla pagina cercaform.php che
permette di effettuare ricerche in base ai seguenti parametri: nome del paziente, età del
paziente, data in cui ha eseguito l'esame, ente esecutore dell'esame, tipo di esame,
parte del corpo analizzata o identificativo del paziente (fig 8.9). Non è necessario
compilare tutti i campi, è invece possibile lasciarli tutti vuoti.
Pagina 56
Fig. 8.9: tabella ricerca file cercaform.php
Il bottone “ricerca” porta alla pagina cerca.php che in formato tabellare mostra
le righe relative ai file cercati, specificando se si tratta di un singolo file (es.
radiografia) o di una serie (es. risonanze) con il campo “serie”. Per ogni riga è
possibile richiedere di scaricare il file (fig 8.10). Alla richiesta di scaricare un file la UI
preleva il file dalla griglia e lo predispone per il download nella pagina download.php
(fig 8.11). Prima di avviare lo scaricamento è offerta la possibilità di visualizzare
un’anteprima dell’immagine contenuta nel file in una nuova finestra (fig 8.12)
cliccando sul link “Visualizza Anteprima”.
Pagina 57
Fig. 8.10: tabella risultato query ricerca cerca.php
Pagina 58
Fig. 8.11 pagina di scaricamento con anteprima download.php
Fig. 8.12 anteprima immagine contenuta nel file
Pagina 59
8.6
Condivisione postazioni
La durata standard di un proxy è di 24 ore, durante questo periodo l’utente non
ha più la necessità di autenticarsi e l’accesso al sistema dal portale di benvenuto è
immediato. E’ possibile tuttavia che la postazione utililizzata dall’utente non sia
dedicata ad esso ma in comune con altri, in tal caso per evitare che altri utenti possano
effettuare operazioni a nome dell’utente precedente è indispensabile che chi utilizza il
sistema al termine del proprio lavoro effettui il logout (fig 8.13), tale operazione
rimuove il proxy, ma per una completa protezione, è necessario chiudere manualmente
il browser o riavviarlo.
Fig. 8.13: uscita dal sistema logout.php
Pagina 60
8.7
Gestione errori
Sono molte le operazioni critiche effettuale dal sistema, critiche perché l’esito
non dipende solo dalle risorse locali della UI ma anche dallo stato di altre macchine.
L’utente può trovarsi in una situazione di errore nelle fasi di invio dei certificati o dei
file DICOM. In entrambi i casi deve essere sicuro che il formato del file sia corretto.
Per il certificato avviene un’interazione fra l’UI e il nodo della griglia contenente la
lista degli utenti con certificati autorizzati ad accedere. Per il file DICOM le operazioni
sono due, l’invio del file ad un SE e l’immissione dei metadati nel server AMGA, in
particolare la seconda operazione rileva la correttezza dei metadati, come la presenza
di caratteri non numerici nei campi età o data.
Pagina 61
9 Sviluppi futuri
Questo progetto pone le basi per un’infrastruttura che si può espandere e
migliorare arricchendosi di nuove funzionalità per raggiungere l’obbiettivo di
sostituire i sistemi di archiviazione PACS. Di seguito vengono proposte diverse
possibili vie di sviluppo.
9.1
Sicurezza
L’adozione dell’architettura GRID-LAN con connessioni protette da certificati
(https) è un livello ottimale di sicurezza dei messaggi. I dati invece possono esser
maggiormente protetti tramite una dissociazione dati-metadati all’atto dell’immissione
sulla griglia, i file DICOM potrebbero essere privati dei metadati tramite una
cancellazione completa, rimarrebbero solo le immagini. I metadati invece seguirebbero
il loro attuale percorso verso il database AMGA, dove grazie al GUID possono essere
associati alle immagini presenti nei file. Questo meccanismo già adottato da alcuni
progetti paralleli a GridPACS previene danni derivati da accessi non autorizzati ai file
presenti sulla griglia.
9.2
Gestione Immagini
Lo scopo finale del progetto è quello di sostituire i PACS. Ciò significa fornire
all’utente non solo la possibilità di consultare le immagini relative a tutte le analisi di
un paziente, ma anche di mettergli a disposizione una serie di strumenti di analisi e
studio delle immagini. Le tecnologie per il web permettono di simulare un ambiante
desktop da browser tramite l’utilizzo di codice javascript o di tecniche ajax. Con una
buona programmazione lato client l’utente potrebbe scaricare i file ed aprirli
Pagina 62
all’interno della sua sessione web virtuale automaticamente, avendo un resoconto
completo dei metadati, la possibilità di visualizzare le serie di immagini complete, la
disponibilità di strumenti come lo zoom o il righello per le misurazioni e naturalmente
la possibilità si salvare il proprio lavoro.
9.3
Client
La UI ricopre il ruolo di server. Attualmente tutte le fasi di calcolo sono a suo
carico, ma a fronte di un previsto uso intenso della UI da parte di molti client
all’interno della sua LAN è bene pensare ad alleggerirla. Il client che ora è thin può
compiere alcune operazione che non è essenziale vengano svolte dalla UI, come ad
esempio la generazione del proxy, si può implementare una porzione di
programmazione lato client che si occupi di manipolare localmente il certificato .pk12
creando i file .pem. Va tenuto conto che queste operazioni richiedono la libreria
openssl.
9.4
Database
Il database è essenziale che venga sottoposto ad un attento studio basato sulla
tipologia di query effettuate e sulle caratteristiche dei dati immessi. L’entità dati oggi
presente è una sola grande tabella, ma non è pensabile di utilizzarla a pieno regime. E’
noto che molti pazienti effettuano numerose analisi, con la struttura attuale si avrebbe
un notevole spreco di memoria dovuto alle repliche dei valori relativi ad un paziente su
diversi esami. Inoltre non sono presenti indici, è necessario uno studio per la scelta
della tipologia di indici e dei campi sui quali sarebbero più utili, tenendo conto che le
operazioni a breve termine sono di solo inserimento.
Conoscendo la mole di dati che AMGA si troverà a gestire, la latenza dovuta
alle interazioni con i database può facilmente diventare l’aspetto più importante sul
Pagina 63
quale lavorare, bisognerebbe organizzare l’architettura dei vari server AMGA che
hanno un funzionamento di tipo master/slave, indicizzare i campi più utilizzati nelle
query, suddividere la tabella dei metadati per attinenza di paziente, studio e analisi e
infine considerata la possibilità di generare repliche di sottoalberi per garantire una
tolleranza agli incidenti.
Come miglioramento immediato andrebbe ampliata la rosa di possibili query,
passando dall’attuale ricerca per valore esatto alla ricerca per intervallo e per ricerche
parziali con l’aggiunta di simboli speciali di query (+, *, …).
9.5
Accessibilità e Fault Tollerance
Con l’adozioni di meccanismi di sicurezza come la generazione del proxy
localmente e non più da parte della UI, si può spostare il progetto da un livello locale
ad un livello globale, rendendo le UI non più parte di LAN isolate ma portali web di
accesso. Un ente attualmente per avere una tolleranza a guasti e imprevisti deve avere
a disposizione due UI locali che gli consentano l’accesso ininterrotto al database
GRID, con un funzionamento parallelo o seriale. Se le UI non venissero più gestite
localmente, ma rese accessibili via WAN e non più LAN, la tolleranza sarebbe totale,
dipendendo dal numero complessivo di UI. Il costo di questa scelta è di avere basse
prestazioni di velocità di connessione fra l’utente e la UI nel caso dell’assenza di UI
geograficamente vicine o ben connesse con l’ente o di rottura della UI vicina.
Problemi risolvibili installando le UI presso gli enti con un organizzazione simile a
quella adottata attualmente, ma con l’enorme vantaggio di offrire la possibilità agli
utenti di accedere al sistema ovunque e non più solo al’interno dell’ente.
Similmente anche gli SE possono moltiplicarsi per aumentare le prestazioni
grazie alle repliche, che permettono di evitare di interrogare e richiedere file
memorizzati su SE poco accessibili copiandone porzioni di dati su altri SE distribuiti.
Un ulteriore possibilità offerta dall’adozione dell’acceso WAN del sistema è di
Pagina 64
fornire un servizio anche ai pazienti, permettendogli tramite opportuni strumenti di
autenticazione come la tessera sanitaria o le penne USB di accedere ai propri dati
personali.
9.6
Funzionalità
La grande disponibilità di dati medici su un unico database permette di
effettuare alcuni studi normalmente non possibili o difficoltosi. Le analisi di tipo
statistico sarebbero molto facilitate. Esempi di query possono rilevare la
concentrazione geografica di patologie sul territorio, evidenziarne l’incidenza in
particolari comuni o province. E’ possibile calcolare medie sul numero di esami per
paziente, per anno o per regione, calcolandone i costi o gli esiti ai fini di prevenzione.
Le possibilità offerte sono tantissime, la collezione di dati immagazzinati diventerebbe
una ricchezza per la sanità, sebbene fortemente limitata dall’adesione degli enti al
sistema, poiché molte analisi statistiche verrebbero falsate da un inadeguato insieme di
dati, perché mal distribuito o perché parziale.
9.7
Grid Storage e Computing
L’infrastruttura utilizzata da GridPACS è di data grid, cioè finalizzata
all’immagazzinamento dei dati, ma il passo per arrivare alla grid computing è breve.
Con l’accorpamento di nodi di calcolo nella VO del progetto si avrebbero a
disposizione anche delle risorse di calcolo. Una prospettiva interessante sarebbe di
sollevare gli enti ospedalieri non solo dalla parte di storage, di memorizzazione e
mantenimento dei dati, ma anche della parte di calcolo, per le trasformazioni che molte
analisi richiedono sulle immagini prodotte e che superate una soglia di analisi
effettuate diventano eccessivamente onerose per la disponibilità di calcolo che gli enti
hanno normalmente a disposizione.
Pagina 65
10 Conclusioni
Il progetto GridPACS ha portato alla creazione di un database di immagini
mediche su GRID, alla possibilità di effettuare ricerche su tale database e di accedevi
da remoto. GridPACS è nato come uno studio di fattibilità, dal desiderio di permettere
a utenti estranei alla realtà GRID di averne accesso senza venire a contatto con le
macchinose operazioni del contesto. Semplificare l’accesso alla GRID nascondendo le
istruzioni da linea di comando sarebbe potuto costare un sacrificio della sicurezza
legata al tipo di interazioni che si possono compiere con la griglia, cioè dell’impiego
dei certificati digitali.
Grazie all’impiego di alcune tecniche di programmazione lato server e di
configurazione del server stesso si è riusciti a garantire un’ottima sicurezza di esercizio
nonostante la più assoluta facilità d’uso del sistema. Il risultato è un portale basato
completamente sulla grafica che automatizza tutti i comandi e la presenza di log grazie
ai quali è sempre possibile stabilire chi ha fatto cosa e quando lo ha fatto.
Un'altra sfida è stata quella di rendere i dati inviati sulla griglia non “passivi”,
ma consultabili. I database GRID non permettono l’identificazione dei dati in base al
contenuto, ma solo tramite un codice, il GUID. Con l’impiego del database AMGA si
ha la possibilità di conoscere tutti i dettagli dei dati presenti sulla griglia prima di
scaricarli. Con un database convenzionale è facile ottenere un risultato simile, ma
AMGA è integrato nella griglia, questo significa avere interazioni sicure perché
protette dai certificati, ridondanza dei dati tramite le repliche e una gerarchia di server
AMGA master/slave sulla griglia per l’organizzazione dei dati.
Il progetto dopo fasi throw away ha raggiunto un livello di alta usabilità e
scalabilità che sono principali requisiti dai quali si è partiti, ma resta pur sempre vicino
ad uno studio di fattibilità, per assicurare l’efficienza e l’assoluta affidabilità che il
settore cui è destinato l’uso richiede, ha bisogno di intraprendere ulteriori fasi di
Pagina 66
sviluppo.
Pagina 67
11 Appendice
11.1 Installazione e Configurazione
Per poter utilizzare il sistema GridPACS è necessario disporre di una UI con
sistema operativo redhat scientific linux cern 4 e globus toolkit.
Di seguito sono indicate le istruzioni di installazione e configurazione per
l’utilizzo del sistema. Tutte le istruzioni devono essere eseguite da shell con privilegi
di amministrazione.
Il primo componente necessario è un web server come apache, aprire una
console shell e con un utente di amministrazione digitare i comandi indicati dal
seguente formato:
Comando da digitare all’interno della console
Descrizione dell’operazione svolta dal comando digitato
Yum install httpd
installazione server web apache
La creazione delle path private è una procedura che dovrà essere eseguita ogni volta
che un nuovo utente verrà amesso nella VO.
mkdir /var/www/wpacs
creazione path sistema
mkdir /home/utente1/public_html/DICOM
mkdir /home/utente1/public_html/cert
creazione path private
Pagina 68
Per proteggere la comunicazione utente-UI è necessario creare un certificato del server
da fornire agli utenti quanto contattano la UI. La libreria openssl è compresa nel
globus toolkit.
openssl genrsa –des3 –out wpacs.key 512
openssl req –mew –key wpacs.key –out wpacs.csr
openssl ca –in wpacs.csr –out wpacs.crt
creazione di un certificate self-signed per la connessione https fra l’utente e la UI
Bisogna abilitare il server alla ricezione di connessioni https modificando i file di
configurazione
/etc/httpd/conf.d/ssl.conf
all’interno del file modificare i valori indicati
SSLEngine on
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/wpacs.key
SSLCertificateFile /etc/httpd/conf/ssl.crt/wpacs.crt
In seguito si spostano i certificati creati con le funzioni openssl nelle directory indicate
nel file ssl.conf
Il PHP per poter eseguire le istruzioni normalmente svolte da linea di comando con
provilegi dell’utente autenticato ha bisogno di essere eseguito come script cgi
gedit /etc/httpd/conf.d/php.conf
all’interno del file modificare i valori indicati
ScriptAlias /php-cgi /usr/bin/php
Action php-cgi /php-cgi
AddHandler php-cgi .php
Pagina 69
DirectoryIndex index.php
Il modulo php automaticamente installato nel server web apache, viene disabilitato,
l’esecuzione degli script php avviene con il meccanismo CGI
Il modulo AuthPAM necessario per l’autenticazione potrebbe non esser presente di
default sulla UI, se assente dopo averlo scaricato si crea il file nel path indicato
/etc/httpd/conf.d/auth_pam.conf
Il suo contenuto deve essere
LoadModule auth_pam_module modules/mod_auth_pam.so
LoadModule auth_sys_group_module
modules/mod_auth_sys_group.so
Si crea il file di protezione del web path che richiede obbligatoriamente di autenticarsi
come utenti di sistema
Gedit /ar/www/wpacs/.htaccess
Nel file si inseriscono le seguenti righe
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule .* [E=http_AUTHORIZATION:%{HTTP:authorization},L]
</IfModule>
AuthPAM_Enabled on
AuthType Basic
AuthName “Accesso riservato ai membridel gruppo WPACS”
Require group wpacs
Creazione file .htaccess per la restrizione all’accesso al sistema tramite autenticazione
Pagina 70
degli utenti del sistema operativo appartenenti al gruppo indicato
È necessario creare un gruppo riservato agli utenti della VO sul sistema, la procedura
di creazione e aggiunta del singolo utente al gruppo va ripetuta per ogni nuovo utente.
Groupadd wpacs
Creazione gruppo utenti autorizzati all’utilizzo del sistema
Usermod –G wpacs utente1
Esempio di inserimento utente autorizzato
Infine bisogna indicare al server web che le pagine contenenti codice php vanno
gestite come script
gedit /etc/httpd/conf.d
all’interno del file modificare i valori indicati nella sezione public_html
#
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
ExecCGI
<Limit GET POST OPTIONS>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS>
Order allow,deny
Allow from all
</LimitExcept>
</Directory>
Pagina 71
<Directory /home>
AddHandler cgi-script .php .php3 .php4 .php5 .phtml
</Directory>
Utilizzo di suexec per consentire l’esecuzione di comandi non come utente apache ma
come utente che si autentica sul .htaccess
Le pagine dell’applicazione GridPACS vengono posizionate in due path, il primo
pubblico e comune a tutti gli utenti in /var/www/ e var/www/wpacs/, il secondo
privato nella cartella dell’utente /home/utente1/public_html/.
Le pagine pubbliche sono gli indici index di accesso al sistema, nelle pagine private si
articola l’applicazione web vera e propria.
I permessi delle pagine web devono essere chmod 755 di proprietà dell’utente e del
suo gruppo, chgrp utente1, chown utente1. Le pagine in quanto script CGI hanno nella
prima riga il magic number #! indicante l’interprete cui passare lo script, nel caso di
GridPACS /usr/bin/php.
Una volta trasferite le pagine nelle loro sedi e aver riavviato il server apache il sistema
è funzionante, tutti gli errori saranno riportati nei log, così come gli accessi di suexec,
utili a tracciare ogni comando eseguito o pagina visitata.
11.2 Codice
Index.php
#!/usr/bin/php
<?
Pagina 72
if(isset($_SERVER['REDIRECT_HTTP_AUTHORIZATION'])) {
$auth_params = explode(":" ,
base64_decode(substr($_SERVER['REDIRECT_HTTP_AUTHORIZATION'],
6)));
$_SERVER['PHP_AUTH_USER'] = $auth_params[0];
unset($auth_params[0]);
$_SERVER['PHP_AUTH_PW'] = implode('',$auth_params);
}
// open user/pass prompt
echo "<p>Benvenuto: </p>".$_SERVER['PHP_AUTH_USER'];
echo "<br>";
system("id");
echo "<br>";
$ind="/home/".$_SERVER['PHP_AUTH_USER']."/public_html/cert/use
rcert.pem";
if (!file_exists($ind))
{
echo "Primo accesso <br>";
echo "<a
href=\"https://gridpacs2.na.infn.it/~".$_SERVER['PHP_AUTH_USER
']."/invio.php\">Invio Certificato</a>";
}
else
{
echo "<br>";
echo "<a
href=\"https://gridpacs2.na.infn.it/~".$_SERVER['PHP_AUTH_USER
Pagina 73
']."/accesso.php\">Accesso Grid</a>";
}
?>
Invio.php
#!/usr/bin/php
<?
session_start();
if (!isset($_SESSION['nomeutente']))
$_SESSION['nomeutente']=$_REQUEST['User'];
?>
<html>
<head>
<title>Invio Certificato</title>
<style type="text/css">
body {
text-align: center;
}
</style>
</head>
<body>
<img src="banner.jpg" width="900" height="250"/>
<p>Utente: <?php echo $_SESSION['nomeutente']; ?> </p>
<form enctype="multipart/form-data" name="invio certificato"
method="post" action="inviato.php">
<input type="hidden" value="1" name="up">
Pagina 74
<p><label for="certificato">Certificato: </label>
<input type="file" name="certificato"/></p>
<p><label for="chiave">Chiave Certificato (passphrase):
</label>
<input name="chiave" type="password" size="30" /></p>
<input type="submit" value="invio" />
</form>
</body>
</html>
Inviato.php
#!/usr/bin/php
<?
session_start();
?>
<html>
<head>
<title> Portale Griglia </title>
body {
text-align: center;
}
</style>
</head>
<body>
<?
Pagina 75
if($_REQUEST['up']!=0)
{
if($_FILES['certificato']['error'] != UPLOAD_ERR_OK)
{
print("fallimento upload");
echo "<a
href=\"https://gridpacs2.na.infn.it/~".$_SESSION['nomeutente']
."/invio.php\">Ripetere Invio</a>";
exit;
}
else
{
if(preg_match('/Firefox/i',$_SERVER['HTTP_USER_AGENT']))
{
if
($_FILES['certificato']['type']!="application/octet-stream")
{
print("tipo file errato firefox ".$_FILES['certificato']['type']);
echo "<a
exit;
}
}
elseif ($_FILES['certificato']['type']!="application/xpkcs12")
{
print("tipo file errato altri -
Pagina 76
".$_FILES['certificato']['type']);
echo "<a
exit;
}
copy($_FILES['certificato']['tmp_name'],"cert/".$_FILES['certi
ficato']['name']);
unlink($_FILES['certificato']['tmp_name']);
print("tipo file "
.$_FILES['certificato']['type']. "<br>");
print("nome file "
.$_FILES['certificato']['name']. "<br>");
$filename = $_FILES['certificato']['name'];
$pp = $_REQUEST['chiave'];
$cmd1 = "openssl pkcs12 -nocerts -in
cert/".$_FILES['certificato']['name']." -out cert/userkey.pem
-passin pass:".$pp." -passout pass:".$pp;
$output=system($cmd1);
$cmd2 = "openssl pkcs12 -clcerts -nokeys -in
cert/".$_FILES['certificato']['name']." -out cert/usercert.pem
-passin pass:".$pp;
$cmd3="chmod 0400 cert/userkey.pem";
$cmd4="chmod 0600 cert/usercert.pem";
Pagina 77
$ind="/home/".$_SESSION['nomeutente']."/public_html/cert/userc
ert.pem";
$ind1="/home/".$_SESSION['nomeutente']."/public_html/cert/user
key.pem";
if (filesize($ind)>0)
{
if (filesize($ind)>0)
{
print("Invio file avvenuto con successo.");
echo "<br>";
echo "<a
."/accesso.php\">Accesso Griglia</a>";
$cmd="rm cert/".$_FILES['certificato']['name'];
$out=system($cmd);
}
else
{
print("errore passphrase");
$cmd="rm ".$ind;
$out=system($cmd);
$cmd="rm ".$ind1;
$out=system($cmd);
$cmd="rm ".$_FILES['certificato']['name'];
$out=system($cmd);
echo "<a
Pagina 78
}
}
else
{
print("errore passphrase");
$cmd="rm ".$ind;
$out=system($cmd);
$cmd="rm ".$ind1;
$out=system($cmd);
$cmd="rm cert/".$_FILES['certificato']['name'];
$out=system($cmd);
echo "<a
}
}
}
?>
</body>
</html>
Accesso.php
#!/usr/bin/php
<?
session_start();
?>
<html>
<head>
Pagina 79
<title>Accesso Grid</title>
body {
text-align: center;
}
</style>
</head>
<body>
<form name="chiave certificato" method="post"
action="home.php">
<p><label for="chiave">Chiave Certificato </label>
<input id="key" name="chiave" type="password" size="30"/></p>
<input type="submit" value="Accesso">
</form>
</body>
</html>
Home.php
#!/usr/bin/php
<?
session_start();
?>
<html>
<head>
<title>Portale Griglia</title>
Pagina 80
body {
text-align: center;
}
</style>
</head>
<body>
<?
$cmd='/opt/glite/bin/voms-proxy-info -timeleft';
$output=exec($cmd);
if (!($output))
{
$pp = $_REQUEST['chiave'];
$cmd = "echo ".$pp." | /opt/glite/bin/voms-proxy-init
-voms pacs.infn.it -key cert/userkey.pem -cert
cert/usercert.pem --debug -pwstdin";
$proxy=exec($cmd);
$cmd='/opt/glite/bin/voms-proxy-info -timeleft';
$output=exec($cmd);
if (!($output))
{
echo "<p>Errore autenticazione \n";
echo "<a
."/accesso.php\">Ripetere Accesso</a></p>";
exit();
}
else echo "<p>ValiditÃ
proxy: <br>".$proxy."</p>";
}
Pagina 81
echo "<p>Utente: ".$_SESSION['nomeutente']."</p>";
echo "<p>Utente certificato:\n";
$cmd="/opt/glite/bin/voms-proxy-info -issuer | awk '{print
$3,$4}'";
echo exec($cmd);
echo "</p>"
echo "<a
."/upform.php\">Invio File</a>";
echo "<br>";
echo "<a
."/cercaform.php\">Ricerca File</a>";
echo "<br>";
echo "<a
."/testins.php\">temp verifica invio</a>";
echo "<br>";
echo "<a
."/logout.php\">Uscita</a>";
?>
</body>
</html>
Cercaform.php
#!/usr/bin/php
<?
Pagina 82
session_start();
?>
<html>
<head>
<title>Ricerca File</title>
body {
text-align: center;
}
</style>
</head>
<body>
<? echo "<p>Utente ".$_SESSION['nomeutente']."</p>"; ?>
<form id="ric" action="cerca.php" method="post">
<table align="center">
<tr>
<th><label for="nome">Nome Paziente</label></th>
<td><input id="nome" name="nome" type="text"
/></td>
</tr>
<tr>
<th><label for="eta">EtÃ
Paziente</label></th>
<td><input id="eta" name="eta" type="text" /></td>
</tr>
<tr>
<th><label for="data1">Data Esame (AAAA-MM-GG)</label></th>
<td><input id="data1" name="data1" type="text" /></td>
</tr>
<tr>
Pagina 83
<th><label for="ente">Istituzione Esame</label></th>
<td><input id="istituto" name="ente" type="text"
/></td>
</tr>
<tr>
<th><label for="studio">Tipo Esame</label></th>
<td><input id="esame" name="studio" type="text"
/></td>
</tr>
<tr>
<th><label for="parte_corpo">Parte Anatomica</label></th>
<td><input id="parte" name="parte_corpo" type="text"
/></td>
</tr>
<tr>
<th><label for="id_paz">Identificativo Paziente</label></th>
<td><input id="id_paz" name="id_paz" type="text"
/></td>
</tr>
</table>
<input id="invio" name="invio" type="submit" value="ricerca"
/>
</form>
<br>
<?
echo "<a
."/home.php\">Home</a>";
?>
</body>
</html>
Pagina 84
Cerca.php
#!/usr/bin/php
<?
session_start();
?>
<html>
<head>
<title> Ricerca File </title>
body {
text-align: center;
}
</style>
</head>
<body>
<?
echo "<p id=\"attesa\">Attendere ...</p>";
require_once('DB.php');
$dati =array();
$indice_val=
array("nome","eta","data1","ente","studio","parte_corpo","id_p
az");
$indice_att=
array("nome","eta","data","istituzione","studio","parte_corpo"
,"id_paziente","guid","serie");
foreach($indice_val as $elem)
Pagina 85
{
if($_POST[$elem] != "") $dati[$elem]=$_POST[$elem];
}
$cmd="export HOME=/home/mettivier; /opt/glite/bin/mdcli
\"selectattr dbgrid:nome dbgrid:eta dbgrid:data
dbgrid:istituzione dbgrid:studio dbgrid:parte_corpo
dbgrid:id_paziente dbgrid:guid dbgrid:serie";
if (count($dati) != 0)
{
$cmd=$cmd." '";
foreach($dati as $ind => $val)
{
$cmd=$cmd."like(".$ind.",\\\"".$val."\\\") and ";
}
$cmd=substr($cmd,0,strlen($cmd)-4); //cancellazione ultimo
and
$cmd=$cmd."'\"";
}
else $cmd=$cmd." ''\"";
$output= shell_exec($cmd);
//print($output);
?>
<br>
<table border=1 align="center">
<tr>
<?
for ($i=0; $i<count($indice_att); $i++) echo
"<th>".$indice_att[$i]."</th>";
echo "<th>Scarica File</th>";
Pagina 86
echo "</tr>";
$riga = explode("\n", $output);
$numr= floor(count($riga)/9)+1;
$k=0;
for($j=1; $j<$numr; $j++)
{
echo "<tr>";
for ($i=0; $i<count($indice_att); $i++) echo
"<td>".$riga[$i+$k]."</td>";
echo "<td><a href=\"download.php?cod=".$riga[$i+$k2]."&s=".$riga[$i+$k-1]."\">Scarica</a></td>";
echo "</tr>";
$k=$k+$i;
}
echo "<table><br>";
if(0)
{
$cmd="export HOME=/home/mettivier;
/opt/glite/bin/mdcli selectattr dbgrid:nome
'eta=".$_REQUEST['eta']."'";
echo'<br>';
$output= shell_exec($cmd);
print($output);
echo'<br>';
}
echo'<br>';
echo "<a
Pagina 87
?>
<script type="text/javascript">
document.getElementById("attesa").innerHTML="Ricerca
completata";
</script>
</body>
</html>
Dowload.php
#!/usr/bin/php
<?
session_start();
?>
<html>
<head>
<title> Caricamento File </title>
body {
text-align: center;
}
</style>
</head>
<body>
<?
Pagina 88
if(isset($_REQUEST['cod']))
{
$cmd="export LFC_HOST=lfcserver.cnaf.infn.it; export
LCG_GFAL_INFOSYS=gridit-bdii-01.cnaf.infn.it:2170;
/opt/lcg/bin/lcg-cp guid:".$_REQUEST['cod']."
file:///home/".$_SESSION['nomeutente']."/public_html/tempdicom
file";
$out=system($cmd);
if ($out != "")
{
?>
document.getElementById("attesa").innerHTML="si Ã¨
verificato un errore GRID";
</script>
<?
echo "<a
exit();
}
else
{
?>
document.getElementById("attesa").innerHTML="file
pronto";
</script>
Pagina 89
<?
}
echo "serie ".$_REQUEST['s']." ";
if ($_REQUEST['s'])
{
system("mv tempdicomfile tempdicomfile.zip");
$zip = zip_open("tempdicomfile.zip");
while ($zip_entry = zip_read($zip))
{
$num_file=$num_file+1;
}
$estratto=$num_file/2;
$c=0;
zip_close($zip);
$zip = zip_open("tempdicomfile.zip");
do{
$c=$c+1;
$zip_entry = zip_read($zip);
}while ($c<=$estratto);
$file = basename(zip_entry_name($zip_entry));
$fp = fopen(basename($file), "w+");
if (zip_entry_open($zip, $zip_entry, "r"))
{
$buf = zip_entry_read($zip_entry,
zip_entry_filesize($zip_entry));
zip_entry_close($zip_entry);
}
fwrite($fp, $buf);
Pagina 90
fclose($fp);
echo "The file ".$file." was extracted";
zip_close($zip);
system("convert ".$file." anteprima.jpg");
?>
<a href="anteprima.jpg" target="_blank">Visualizza
anteprima</a>
<br>
<?
echo "<form action=".$file." method=\"post\">";
?>
<input id="invio" name="down" type="submit"
value="Avvia download" />
</form>
<?
}
else
{
system("mv tempdicomfile tempdicomfile.dcm");
system("convert tempdicomfile.dcm anteprima.jpg");
?>
<a href="anteprima.jpg" target="_blank">Visualizza
anteprima</a>
<br>
<form action="tempdicomfile.dcm" method="post">
<input id="invio" name="down" type="submit"
value="Avvia download" />
</form>
<?
Pagina 91
}
}
else
{
echo "<p>Errore parametri ricerca</p>";
echo "<a
."/cercaform.php\">Ripetere Ricerca</a></p>";
exit();
}
echo "<a
."/home.php\">Home</a></p>";
?>
</body>
</html>
Upform.php
#!/usr/bin/php
<?
session_start();
?>
<html>
<head>
<title>Invio File</title>
Pagina 92
body {
text-align: center;
}
</style>
</head>
<body>
<? echo "<p>Utente ".$_SESSION['nomeutente']."</p>"; ?>
<form enctype="multipart/form-data" name="invio file"
method="post" action="upload.php">
<input type="hidden" value="1" name="up">
<p>
<label for="file">File Archivio DICOM </label>
<input id="dcm" name="file" type="file"/>
</p>
<input type="submit" value="invio" />
</form>
<?
echo "<a
?>
</body>
</html>
Upload.php
#!/usr/bin/php
Pagina 93
<?
session_start();
?>
<html>
<head>
<title> Caricamento File </title>
body {
text-align: center;
}
</style>
<body>
<?
require_once('File/DICOM.php');
require_once('PEAR.php');
if (!extension_loaded('zip')) {
dl('zip.so');
}
if($_REQUEST['up']!=0)
{
if($_FILES['file']['error'] != UPLOAD_ERR_OK)
{
print("fallimento upload");
echo "<br>";
echo "<a
."/upform.php\">Inviare nuovo file</a>";
Pagina 94
}
else
{
if(preg_match('/Firefox/i',$_SERVER['HTTP_USER_AGENT']))
{
if($_FILES['file']['type']!="application/zip" &&
$_FILES['file']['type']!="image/x-dcm")
{
print("tipo file errato ".$_FILES['file']['type']." tipi ammessi application/zip o
image/x-dcm firefox");
echo "<a
."/upform.php\">Invio nuovo file</a>";
exit;
}
}
elseif(0)//$_FILES['file']['type']!="application/octetstream")
{
print("tipo file errato ".$_FILES['file']['type']." invece di application/octet-stream
non firefox");
echo "<a
exit;
}
echo "tipo file
- ".$_FILES['file']['type'];
Pagina 95
copy($_FILES['file']['tmp_name'],$_FILES['file']['name']);
unlink($_FILES['file']['tmp_name']);
//print("tipo file " .$_FILES['file']['type']. "<br>");
//print("nome file " .$_FILES['file']['name']. "<br>");
$filename = $_FILES['file']['name'];
$serie=0;
if ($_FILES['file']['type']=="application/zip")
{
$num_file=0;
$estratto=0;
$zip = zip_open($filename);
while ($zip_entry = zip_read($zip))
{
$num_file=$num_file+1;
}
$estratto=$num_file/2;
$c=0;
zip_close($zip);
$zip = zip_open($filename);
do{
$c=$c+1;
$zip_entry = zip_read($zip);
}while ($c<=$estratto);
$file = basename(zip_entry_name($zip_entry));
$fp = fopen(basename($file), "w+");
if (zip_entry_open($zip, $zip_entry, "r"))
{
Pagina 96
$buf = zip_entry_read($zip_entry,
zip_entry_filesize($zip_entry));
zip_entry_close($zip_entry);
}
fwrite($fp, $buf);
fclose($fp);
echo "The file ".$file." was extracted";
zip_close($zip);
$serie=1;
}
else $file=$filename;
$dicom= new File_DICOM();
$out=$dicom->parse($file);
if (PEAR::isError($out))
{
print("l'archivio contiene file di tipo errato");
$cmd="rm ".$file;
$out=system($cmd);
$cmd="rm ".$filename;
$out=system($cmd);
echo "<a
exit;
}
else
{
echo "<table border=1 align=\"center\"><tr>";
echo "<td>Metadati File inviato</td></tr><tr>";
Pagina 97
echo "<td>Nome paziente</td>";
echo "<td>Eta paziente</td>";
echo "<td>Study Date</td>";
echo "<td>Institution</td>";
echo "<td>Study description</td>";
echo "<td>Anatomic Structure</td>";
echo "<td>PatientID</td>";
echo "</tr><tr>";
echo "<td>".$dicom->getValue('PatientName')."</td>";
echo "<td>".$dicom->getValue('PatientAge')."</td>";
echo "<td>".$dicom->getValue('StudyDate')."</td>";
echo "<td>".$dicom->getValue('InstitutionName')."</td>";
echo "<td>".$dicom->getValue('StudyDescription')."</td>";
echo "<td>".$dicom->getValue('AnatomicStructure')."</td>";
echo "<td>".$dicom->getValue('PatientID')."</td>";
echo "</table></tr>";
}
echo "<br>";
//file con nome ID paziente
/opt/lcg/bin/lcg-cr --vo pacs.infn.it -d gridpacs.na.infn.it l lfn:/grid/pacs.infn.it/nuovofile
file:///home/".$_SESSION['nomeutente']."/public_html/".$filena
me;
$guid=system($cmd);
if ($guid == "")
{
Pagina 98
?>
verificato un errore GRID ripetere invio";
</script>
<?
$out=system($cmd);
if ($serie)
{
$cmd="rm ".$file;
$out=system($cmd);
}
echo "<a
exit();
}
$GUID=substr($guid,5,40);
/opt/lcg/bin/lfc-rename /grid/pacs.infn.it/nuovofile
/grid/pacs.infn.it/".$GUID;
$out=system($cmd);
$cmd="export HOME=/home/mettivier; /opt/glite/bin/mdcli
\"INSERT INTO dbgrid VALUES ('".$GUID."','".$dicom>getValue('PatientName')."','".$dicom>getValue('PatientAge')."','".$dicom>getValue('StudyDate')."','".$dicom-
Pagina 99
>getValue('InstitutionName')."','".$dicom>getValue('StudyDescription')."','".$dicom>getValue('AnatomicStructure')."','".$dicom>getValue('PatientID')."','".$GUID."','".$serie."')\"";
$amga=system($cmd);
if ($amga == "")
{
?>
verificato un errore AMGA ripetere invio";
</script>
<?
/opt/lcg/bin/lcg-del -a --vo pacs.infn.it
lfn:///grid/pacs.infn.it/".$GUID;
$out=system($cmd);
echo "<a
exit();
}
$out=system($cmd);
$cmd="rm ".$file;
$out=system($cmd);
}
echo "<br>";
Pagina 100
echo "<a
}
?>
document.getElementById("attesa").innerHTML="Inserimento
effettuato";
</script>
</body>
</html>
Upload.php
#!/usr/bin/php
<?
session_start();
$cmd="/opt/glite/bin/voms-proxy-destroy";
echo exec($cmd);
session_destroy();
?>
<html>
<head>
<title>Uscita</title>
body {
text-align: center;
}
</style>
Pagina 101
</head>
<body>
<br>
<p> Proxy rimosso </p>
<p> Per terminare la sessione Ã¨ necessario chiudere il
browser </p>
<?
echo "<a href=\"https://gridpacs2.na.infn.it\">Indice</a>";
?>
</body>
</html>
Pagina 102
Bibliografia
[1] http://www.acr.org/
[2] http://www.nema.org/
[3] http://medical.nema.org/
[4] http://www.jira-net.or.jp/e/index.htm
[5] http://www.cen.eu/cen/pages/default.aspx
[6] http://amga.web.cern.ch/amga/
[7] http://glite.cern.ch/
[8] https://igi.cnaf.infn.it/grid_operations/users/getting_started/VO
[9] S. Hastings, S. Langella, S. Oster, J. Saltz “The Mobius Project, distribuited data
management and integration” http://projectmobius.osu.edu/
[10] H.K. Huang, A. Zhang, B. Liu, Z. Zhou, J. Documet, N. King, L.W.C. Chan “Datagrid
for large scale medical image archive and analysis” Proceedings of the 13th annual American
Computing Machine conference on Multimedia nov. 2005, 1005-1013
http://www.ipilab.org/Research/DataGrid/p1005-huang.pdf
[11] L. Leoni, S. Manca, A. Giachetti, G. Zanetti ”A virtual data grid architecture for
medical data using SRB” EuroPACS-MIR 2004, 475-478
[12] S. G. Erberich, J. C. Silverstein, A. Chervenak, R. Schuler, M. D. Nelson, C. Kesselman
Globus MEDICUS federation of DICOM medical imaging devices into healthcare grids
[13] http://www.netapp.com/us/products/storage-software/storagegrid/
[14] http://gridatasia.ercim.eu/images/seoul/pdf/ibm-03.pdf
[15] P. Bonetto, G. Oliva, A.R. Formiconi “A Medical imaging environment based on a grid
computing infrastructure”
[16] E. Bagarinao, T. Nakai, Y. Tanaka “Medgrid project, using grid technology for
brain studies” Philippine Information Technology Journal - Volume1 Number1 of February
2008, 3-7
[17] http://security.fi.infn.it/CA/
[18] https://igi.cnaf.infn.it/grid_operations/users/getting_started/VO
Capitolo 2
Emanuele Neri, Paolo Marcheschi, Davide Caramella “Produrre ed elaborare immagini
diagnostiche” Springer 2008
Documentazione ufficiale DICOM – Nema
Materiale corso metodologie per l’analisi dell’immagine – Giovanni Mettivier
W.R. Riddle D.R. Pickens “Extracting data from a DICOM file” Medical Physics vol.32 N.6
June 2005, 1537-1541
Capitolo 3
H.K. Huangs “Pacs: basic principles and applications”Wiley ????
Paul G. Nagy “The future of pacs” Medical Physics vol.34 N.7 July 2007, 2676-2682
Capitolo 4
Materiale corso griglie computazionali – Silvio Pardi
Capitolo 5
B. Koblitz, N. Santos, V. Pose “The amga metadata service” Journal of Grid Computing, vol.6
Pagina 103
N.1 Springer 2007, 61-76
Pagina 104

GridPACS: una soluzione Grid ai sistemi PACS medici

Transcript

Documenti analoghi

scheda immagini

antipasti . apetizers . entrada . entremes . hors d`œuvre

l`uomo del destino

I miei poeti tradotti su "Avvenire"

Ingli curri - Daniele Trambusti

invito7aprile

"LA MUSICA NEL CUORE)" (August Rush)

Frescobaldi Castello di Nipozzano Riserva Chianti Rùfina

biblionewsletter settembre 2016