Tesi PACS

UNIVERSITÀ DEGLI STUDI DI PADOVA

Facoltà di Scienze MM. FF. NN.Corso di Laurea in Informatica

Implementazione di una versione demo diun PACS

Laureando

Stefano Tonello

Matricola 575381

Relatore

Prof. Tullio Vardanega

Anno Accademico 2010/2011

A mia nonna Alessandrina e alla mia famiglia

che mi hanno sempre sostenuto.

Sommario

Questa relazione si pone l’obiettivo di descrivere l’attività di stage svolta dal laureando

Stefano Tonello presso l’azienda Aqrate S.r.l. Il progetto proposto dall’azienda consiste

nella realizzazione di un PACS (Picture archiving and communication system) molto

basilare. Il documento è suddiviso in quattro parti principali:

Dominio applicativo: contiene informazioni riguardanti l’azienda ospitante ed in par-

ticolare il settore sul quale opera;

Strategia aziendale: fornisce una prospettiva di problema, attese ed obiettivi dal

punto di vista dell’azienda intorno allo stage;

Lo stage: espone il modo in cui è stato svolto lo stage;

Valutazione retrospettiva: racchiude le considerazioni finali.

All’interno del documento sono state adottate le seguenti convenzioni tipografiche:

• Riferimenti: i termini che fanno riferimento a pagine del documento sono seguiti

dal link della sezione in azzurro (3.4.1);

• Termine del glossario: per indicare che un termine è presente nel glossario viene

utilizzata la seguente nomenclatura: parola[g]. Qualora lo stesso termine compaia

più volte all’interno della stessa sezione, viene evidenziata la sua presenza nel

glossario solo la prima volta, facilitando così la lettura del documento. La stessa

cosa vale nel caso in cui la sua definizione sia chiara dal contesto.

• Termini in lingua straniera: viene utilizzato il carattere corsivo;

iii

Indice

Sommario iii

Indice iv

Elenco delle figure vii

Elenco delle tabelle ix

1 Dominio applicativo 1

1.1 Informazioni generali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Il contesto aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Tecnologie e strumenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1 Windows Azure Platform . . . . . . . . . . . . . . . . . . . . . . 3

1.3.2 .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.3 LINQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.4 WPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.5 JQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.6 SharePoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.7 Visual Studio 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.8 SQL Server 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Il sistema di offerta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.1 Prodotti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.2 Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4.3 Soluzioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5 Il processo di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

iv

INDICE v

2 Strategia aziendale 12

2.1 Introduzione ai PACS, Picture archiving and communication system . . 12

2.1.1 Immagini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.2 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.3 Funzionalità dell’archivio . . . . . . . . . . . . . . . . . . . . . . 15

2.1.4 Copia di riserva . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1.5 Integrazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Il problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Approccio al problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 L’obiettivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.6 I fattori di rischio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.7 Verifiche e revisioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.8 Utilizzo e sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.9 Piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Lo stage 27

3.1 La formazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.1 Standard DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.1 Requisiti Software . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.2 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.4 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.4.1 Componente Client . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.4.2 Componente server . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.4.3 Interfaccia grafica del server . . . . . . . . . . . . . . . . . . . . . 47

3.5 Verifica e validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.5.1 Metodi di verifica utilizzati . . . . . . . . . . . . . . . . . . . . . 50

3.5.2 Descrizione dei test e delle misurazioni effettuati . . . . . . . . . 52

4 Valutazione retrospettiva 54

INDICE vi

4.1 Analisi personale dell’attività di stage . . . . . . . . . . . . . . . . . . . 54

4.2 Conoscenze pregresse ed acquisite . . . . . . . . . . . . . . . . . . . . . . 55

4.3 Consuntivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4 L’esperienza in Aqrate S.r.l. . . . . . . . . . . . . . . . . . . . . . . . . 58

Glossario 59

Bibliografia 64

Elenco delle figure

1.1 Logo dell’azienda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Infrastruttura del framework .NET . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Aqrate Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Immagine di una tomografia visualizzata in un sistema PACS. . . . . . . . . 13

2.2 Architettura di un sistema PACS. . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Architettura di Aqrate Vector integrato con le funzionalità DICOM . . . . . 24

2.4 Diagramma di Gantt relativo al piano di lavoro a preventivo. . . . . . . . . 25

3.1 Schema semplificato delle relazioni tra le entità paziente, studio, serie ed

immagine nello standard DICOM. . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Schema semplificato della distribuzione gerarchica dell’informazione tra le

entità paziente, studio, serie ed immagine nello standard DICOM. . . . . . . 30

3.3 Schema semplificato delle sorgenti di informazione per le entità paziente,

studio, serie ed immagine nello standard DICOM. . . . . . . . . . . . . . . . 32

3.4 Diagramma UC1: Use case generale delle funzionalità a disposizione dell’Application

Entity chiamante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.5 Diagramma UC2: Use case generale delle funzionalità a disposizione dell’Application

Entity chiamato. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.6 Architettura della rete PACS: un PACS Server, e multipli PACS Clients

(PACS Workstations / DICOM Viewers) . . . . . . . . . . . . . . . . . . . 41

3.7 Richiesta di associazione DICOM . . . . . . . . . . . . . . . . . . . . . . . . 42

3.8 DC1 : Diagramma delle classi della componente client . . . . . . . . . . . . 44

3.9 File con i dati di configurazione. . . . . . . . . . . . . . . . . . . . . . . . . 45

vii

Elenco delle figure viii

3.10 DC2 : Diagramma delle classi della componente server . . . . . . . . . . . . 46

3.11 Screenshot[g] della prima finestra . . . . . . . . . . . . . . . . . . . . . . . . 47

3.12 Screenshot della finestra nella quale si configurano i parametri generali . . . 48

3.13 Screenshot della finestra nella quale si configurano i parametri di Abstract

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.14 Screenshot della finestra nella quale si configurano i parametri di Transfer

Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.1 Diagramma di Gantt relativo al piano di lavoro a consuntivo. . . . . . . . . 57

Elenco delle tabelle

2.1 Probabilità di rischio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2 Requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3 Requisiti di qualità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.4 Risultati delle misurazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

ix

Capitolo 1

Dominio applicativo

1.1 Informazioni generali

Denominazione dell’azienda: Aqrate S.r.l.

Indirizzo: via Roma 37/1

Città: Montebelluna

Provincia: Treviso

CAP: 31044

Telefono: 0423600005

Mail: [email protected]

Sito: www.aqrate.net

Figura 1.1: Logo dell’azienda.

1

CAPITOLO 1. DOMINIO APPLICATIVO 2

1.2 Il contesto aziendale

Aqrate S.r.l. nasce nel 2007 dall’incontro di professionalità che si integrano a vicenda

creando un team in grado di realizzare soluzioni software per le imprese.

L’azienda basa le proprie soluzioni sui prodotti della tecnologia MicrosoftTM in modo

da garantire minore tempo di sviluppo e maggiore stabilità della soluzione.

Grande importanza viene data alla capacità del personale di gestire al meglio progetti

e relazioni, sia nei confronti della clientela sia verso l’azienda stessa.

Rientra infatti nel modus operandi l’attenzione ed il rispetto nei confronti del cliente

e delle sue esigenze, in tal senso la posizione dell’azienda non è mai quella di semplice

fornitore ma di business partner.

Il livello di competenza offerto consente di poter curare un progetto dalla sua definizione

alla sua implementazione, garantendo il raggiungimento del risultato richiesto.

L’azienda fornisce la soluzione completa di documentazione e di codice sorgente; que-

st’ultimo è opportunamente commentato e consente al cliente di potersi svincolare in

qualsiasi momento.


1.3 Tecnologie e strumenti

Nelle prossime sottosezioni si passeranno in rassegna le principali tecnologie e gli stru-

menti che si utilizzano in azienda.

1.3.1 Windows Azure Platform

La piattaforma Windows Azure rappresenta il layer PaaS (Platform as a Service) al-

l’interno della strategia di Cloud Computing di Microsoft. Windows Azure Platform,

essendo una Platform as a Service rappresenta l’ambiente ideale per sviluppare, eseguire

e gestire le proprie applicazioni o servizi in the cloud indipendentemente dalla tecno-

logia e dai framework[g] di sviluppo. Su Windows Azure Platform è infatti possibile

sviluppare in .NET, JAVA, PHP, Ruby, e persino in C++. La piattaforma Windows

Azure è a sua volta composta da 3 elementi:

1. Windows Azure: il sistema operativo per il Cloud che permette alle applica-

zioni di girare e fornisce potenza computazionale, storage, hosting e funzioni di

management.

2. Microsoft SQL Azure: il database relazionale per il Cloud.

3. Windows Azure AppFabric: l’insieme di servizi di infrastruttura applicativa

per l’Identity Management e la connettività.

Quindi, con Windows Azure Platform, è possibile gestire cloud storage (relazionali e flat)

e sviluppare applicazioni nel cloud facilmente integrabili con altri servizi e/o applicazioni

sia on-premises che in the cloud.

1.3.2 .NET Framework

Il framework .NET include una vasta gamma di librerie e supporta diversi linguaggi

di programmazione, in modo da consentire l’interoperabilità tra linguaggi diversi(ogni

linguaggio può usare codice scritto in un altro linguaggio). I programmi scritti per il

framework .NET vengono eseguiti in un ambiente software conosciuto come Common

Language Runtime(CLR), una macchina virtuale per le applicazioni che fornisce impor-

tanti servizi quali la sicurezza, la gestione della memoria e la gestione delle eccezioni.


L’insieme delle librerie e il CLR insieme costituiscono il framework .NET. La Base Class

Library del framework .NET fornisce un set di funzionalità, per tutti i linguaggi, per

l’accesso ai dati, la connettività ai database, la crittografia, lo sviluppo di applicazioni

per il web, la comunicazione in rete. Questo permette agli sviluppatori di combinare il

proprio codice sorgente con il framework, in modo da ridurre la complessità nello scri-

vere il codice e in modo da assicurarne una maggiore portabilità. La figura 1.3 illustra

l’architettura del framework. In particolare si nota come il codice scritto in un qualsiasi

dei linguaggi supportati venga compilato con il compilatore adatto e trasformato in un

secondo tipo di codice, indipendente dalla piattaforma, detto Common Intermediate

Language (CIL). A questo punto, il CLR trasforma il CIL nel linguaggio macchina che

può essere eseguito nella piattaforma in cui risiede.

Figura 1.2: Infrastruttura del framework .NET


1.3.3 LINQ

LINQ è l’acronimo per Language Integrated Query ed è una tecnologia introdotta per

permettere la ricerca all’interno di qualunque struttura dati direttamente sfruttando

il linguaggio. Grazie a questa tecnologia, si possono scrivere query, in C# o VB, che

possono essere eseguite per ricercare elementi in una collezione di oggetti, nodi in una

struttura XML[g], o (ben più importante) in un database SQL. LINQ non è altro che

un’estensione del linguaggio che permette di eseguire query verso una determinata risor-

sa. La risorsa può essere un file XML, un database o una collection di classi e nonostante

questo, la sintassi LINQ rimane la stessa.

1.3.4 WPF

WPF, Windows Presentation Foundation, è una libreria di classi del Framework .NET

proprietarie Microsoft per lo sviluppo dell’interfaccia grafica delle applicazioni in am-

bienti Windows. L’innovazione principale di WPF è la rimozione di ogni legame con il

modello di sviluppo tradizionale di Windows, introdotto con la versione 1.0 del sistema

operativo. Tutti i controlli sono stati riscritti e lo stesso meccanismo basato su scambio

di messaggi, cuore del modello di programmazione di Windows, è stato abbandona-

to. WPF è basato su un sistema di grafica vettoriale che si appoggia alle DirectX[g]

per sfruttare l’accelerazione hardware delle moderne schede grafiche. WPF può essere

impiegato per realizzare applicativi eseguibili anche all’interno del browser Microsoft

Internet Explorer o di altri browser avanzati, purché sia presente il Framework. Il lin-

guaggio usato per la creazione di una interfaccia utente in WPF è l’XAML (eXtensible

Application Markup Language), basato su XML.

L’architettura di Windows Presentation Foundation si basa sia su codice gestito che

su codice nativo. Comunque, le API[g] pubbliche esposte sono disponibili soltanto come

codice gestito. Mentre la maggior parte di WPF è in codice gestito, il motore di com-

posizione che renderizza le applicazioni WPF è un componente nativo. Il suo nome è

Media Integration Layer (MIL) e risiede in milcore.dll. Esso si interfaccia direttamente

con DirectX e provvede il supporto di base per le superfici 2D e 3D, effettua la manipo-

lazione controllata nel tempo dei contenuti di una superficie con una vista per esporre

animazioni costruite ad alto livello, esegue la composizione degli elementi individuali


di una applicazione WPF nella scena finale 3D che rappresenta la UI dell’applicazione

e quindi si incarica di renderizzarla sullo schermo. I media codec sono anche imple-

mentati come codice non gestito, e sono forniti da windowscodecs.dll. Nella parte di

codice gestito abbiamo il Presentation Core (presentationcore.dll) che fornisce un wrap-

per per MIL e implementa il cuore dei servizi per WPF e il Presentation Framework

(presentationframework.dll) che implementa le novità incluse layouts, time-dependent,

story-board based animations e data binding.

1.3.5 JQuery

JQuery è una libreria di funzioni per le pagine web, codificata in javascript, che si propo-

ne come obiettivo quello di astrarre ad un livello più alto la programmazione lato client

del comportamento di ogni singola pagina HTML. Tramite l’uso della libreria JQuery

è possibile, con poche righe di codice, effettuare svariate operazioni, come ad esempio

ottenere l’altezza di un elemento, o farlo scomparire con effetto dissolvenza. Anche la

gestione degli eventi è completamente standardizzata e gestita automaticamente, as-

sieme alla loro propagazione; stessa cosa per quanto riguarda l’utilizzo di AJAX[g], in

quanto sono presenti alcune funzioni molto utili e veloci che si occupano di istanziare i

giusti oggetti ed effettuare la connessione e l’invio dei dati.

1.3.6 SharePoint

SharePoint è un programma lato server che permette la creazione di particolari siti web

principalmente ad uso aziendale (Intranet[g]) ma che possono anche essere messi in rete

e quindi essere disponibili e utilizzati come normali siti web. L’autenticazione viene

fatta inserendo un nome utente e password al momento del login. Questa procedura

viene agevolata dal single sign on che nell’ambito delle tecnologie Microsoft viene spesso

inserito al momento dell’accensione del proprio pc. Il sistema si preoccuperà pertanto

di autenticarvi automaticamente nei siti in cui si dispone delle credenziali di accesso.

L’importante valore aggiunto sta nel condividere informazioni e/o documenti in

diversi modi. È possibile creare liste, repository documentali, calendari sincronizzati con

outlook e molto altro ancora. SharePoint è completamente integrato con il pacchetto

Office e offre molte soluzioni come il versionamento dei documenti che essendo salvati su


server godono del vantaggio della collaborazione. Due utenti infatti, possono collegarsi

da due posti differenti e visionare o lavorare sullo stesso documento. Va fatta una

precisazione: un solo utente può modificare un certo documento mentre più persone

possono visionarlo in contemporanea. Questa operazione viene definita check-out e

check-in e serve ad impedire che si crei confusione su chi modifica cosa.

1.3.7 Visual Studio 2010

Visual Studio è un ambiente di sviluppo integrato (Integrated development environment

o IDE) sviluppato da Microsoft, che supporta attualmente diversi tipi di linguaggio, qua-

li C, C++, C#, F#, Visual Basic .Net e ASP .Net, e che permette la realizzazione di

applicazioni, siti web, applicazioni web e servizi web. É inoltre un RAD (Rapid Applica-

tion Development), ovvero una applicazione atta ad aumentare la produttività aiutando

il programmatore con mezzi come l’IntelliSense o un designer visuale delle forms. Visual

Studio è inoltre multipiattaforma: con esso è possibile realizzare programmi per server,

workstation, pocket PC, smartphone e, naturalmente, per i browser.

1.3.8 SQL Server 2008

Microsoft SQL Server è un DBMS[g] relazionale, meglio noto come Relational Database

Management System (RDBMS), prodotto da Microsoft. Microsoft SQL Server 2008 offre

una piattaforma dati affidabile, produttiva ed efficiente per eseguire le più esigenti appli-

cazioni mission-critical, abbattere tempi e costi di sviluppo e gestione delle applicazioni

e fornire informazioni traducibili in azione a tutti i livelli dell’organizzazione.


1.4 Il sistema di offerta

L’offerta di Aqrate alla clientela prevede:

• Prodotti;

• Servizi;

• Soluzioni.

Nelle seguenti sottosezioni vengono analizzate le proposte che l’azienda dedica al cliente.

1.4.1 Prodotti

Aqrate cerca di garantire software con le seguenti caratteristiche:

• Scalabilità, per permettere al crescere della richiesta di performance di essere

controbilanciato da una maggiore disponibilità del sistema;

• Modularità, per fare in modo che il software sia pluggabile;

• Innovazione.

1.4.1.1 Aqrate Vector

Aqrate Vector è un componente software che fa da ponte tra il protocollo medico HL7 e

il sistema di Conservazione Digitale. Il software riceve i documenti dai sistemi medicali

HL7 e li preparara per la Conservazione Digitale estraendone file(referti, radiografie)

e metadati(nome paziente, struttura medica, codice identificativo, data refertazione).

Esso è un servizio Windows, modulare, multithread ad alto parallelismo.


Figura 1.3: Aqrate Vector

Aqrate Vector è basato interamente su tecnologia Microsoft .NET Framework 4.0 ed

è stato sviluppato utilizzando Microsoft Visual Studio 2010. Esso può essere installato

su qualsiasi sistema operativo Microsoft ed è portabile su tecnologia Java - Db Oracle.

1.4.2 Servizi

L’azienda aiuta ed affianca il cliente nelle diverse fasi del processo di trasformazione

dell’idea in un servizio o un prodotto. Un’accurata pianificazione riduce i tempi di

sviluppo e i costi di gestione, comportando una maggiore soddisfazione.

Aqrate offre i seguenti servizi al cliente:

• Project Management ;

• Analisi e progettazione;

• Supporto tecnologico;

• Sviluppo di software verticale;

• Problem solving.


1.4.3 Soluzioni

L’azienda propone le seguenti soluzioni software:

Applicazioni aziendali: realizzazione di applicazioni che strutturano le informazioni

in una soluzione centralizzata, veloce ed affidabile. Esse sono in grado di interagire

con gli altri strumenti aziendali per massimizzare la collaborazione e l’efficienza.

Gestione della cooperazione aziendale: Aqrate ha esperienza nell’elaborazione di

soluzioni di Collaboration e WorkFlow. Gli strumenti di Collaboration consentono

ai dipendenti di aziende con diverse unità ed uffici, di condividere il proprio lavoro

in modo sicuro ed organizzato. Le soluzioni di tipoWorkFlow invece sono orientate

a quei processi aziendali che comportano una serie di passaggi e di interazioni tra

i vari uffici o reparti. L’azienda realizza per i propri clienti lo strumento per

automatizzare e rendere sicure queste procedure.

Gestione documentale avanzata: viene offerta una soluzione per strutturare l’ar-

chiviazione dei documenti, rendendo sicuri gli accessi alle varie aree documentali

e riducendo i tempi per la ricerca delle informazioni.

System Integration: soluzione per realizzare l’integrazione dei sistemi IT aziendali

in modo da rendere automatico l’allineamento delle informazioni ridondanti tra i

vari sistemi.

Soluzioni per Microsoft Office SharePoint Server: Aqrate sviluppa e fornisce con-

sulenza in ambito SharePoint. Le professionalità che fanno parte del team hanno

esperienza concreta nello sviluppo di soluzioni Microsoft SharePoint. L’azienda è

in grado così di sviluppare soluzioni ad hoc, integrandosi con gli altri applicativi

e server della famiglia Microsoft.


1.5 Il processo di sviluppo

L’approccio di Aqrate è quello di focalizzarsi sul business del cliente mediante un’espe-

rienza diretta in ambiente di produzione, più che un approccio teorico.

L’attitudine dell’azienda è propensa all’apprendimento della specifica realtà di business

e viene adottata una modalità lavorativa orientata all’integrazione totale con le esigenze

del committente.

Di norma Aqrate usufruisce del modello di ciclo di vita agile perché consente di rivedere

di continuo le specifiche e di cambiarle durante lo sviluppo mediante un forte scambio

di informazioni e di pareri. Questo modello tenta di ridurre il rischio di fallimento svi-

luppando il software in finestre di tempo limitate chiamate iterazioni che, in genere,

durano qualche settimana. Ogni iterazione è un piccolo progetto a sé stante e deve

contenere tutto ciò che è necessario per rilasciare un piccolo incremento nelle funzio-

nalità del software: pianificazione, analisi dei requisiti, progetto, implementazione, test

e documentazione. Anche se il risultato di ogni singola iterazione non ha sufficienti

funzionalità da essere considerato completo deve essere rilasciato e, nel susseguirsi delle

iterazioni, deve avvicinarsi sempre di più alle richieste.

Capitolo 2

Strategia aziendale

Il capitolo seguente vuole descrivere al lettore quali sono gli obiettivi da soddisfare

durante tutta l’attività di stage, quali sono le motivazioni che hanno spinto l’azienda

alla proposta del progetto, i vincoli da rispettare e l’approccio usato per la risoluzione

del problema. Inoltre viene esposta la pianificazione del lavoro settimanale.

2.1 Introduzione ai PACS, Picture archiving and

communication system

PACS è l’acronimo anglosassone di Picture archiving and communication system (Si-

stema di archiviazione e trasmissione di immagini) e consiste in un sistema hard-

ware e software dedicato all’archiviazione, trasmissione e visualizzazione delle immagini

diagnostiche digitali.

Un sistema PACS è normalmente composto da una parte di archiviazione, utilizzata

per gestire dati e immagini e una di visualizzazione, che presenta l’immagine diagnostica

su speciali monitor ad altissima risoluzione, sui quali è possibile effettuare la diagnosi.

I sistemi PACS più evoluti permettono anche l’elaborazione dell’immagine, come per

esempio le ricostruzioni 3D. Una parte fondamentale ma non visibile dall’utente finale

si occupa del colloquio con gli altri attori del flusso radiologico, utilizzando di solito

i relativi profili IHE (Integrating the Healthcare Enterprise) tramite lo standard HL7

(Health Level 7 ). In special modo, è fondamentale la sua integrazione con il sistema in-

12

CAPITOLO 2. STRATEGIA AZIENDALE 13

formatico radiologico o RIS (Radiology Information System), che rappresenta il software

gestionale della Radiologia.

Figura 2.1: Immagine di una tomografia visualizzata in un sistema PACS.

2.1.1 Immagini

Le immagini sono ricevute e trasmesse nel formato definito da DICOM (Digital Imaging

and Communications in Medicine), che permette di inglobare e trattare anche testo (per

esempio i referti) e documenti di vario genere, tra cui i PDF[g]; i visualizzatori collegati

sono in genere in grado di mostrare immagini e referti, ma anche di riconoscere i tipi di

immagine e comportarsi di conseguenza. I sistemi PACS, in origine creati per gestire

le immagini generate dalle TAC (Tomografia Assiale Computerizzata), al giorno d’og-

gi sono in grado di trattare tutte le immagini radiologiche digitali e, tramite speciali

digitalizzatori, anche quelle create da modalità analogiche. Da notare che le immagini

ricevute non devono essere modificate in alcun modo, per poter sempre risalire all’origi-

nale trasmesso dalla modalità; l’eventuale elaborazione viene registrata in aggiunta alle

altre immagini. Di solito è ammessa una compressione senza perdita di dati (lossless)

per diminuire lo spazio occupato su disco. Proprio per garantire che ogni immagine

immagazzinata nel PACS sia effettivamente quella generata dalla modalità durante l’e-


same, spesso il PACS spedisce tutti gli oggetti DICOM ad un sistema di archiviazione

legale.

2.1.2 Architettura

Recentemente, con l’evoluzione della tecnologia delle reti, sempre più sistemi PACS

stanno passando ad una architettura di tipo web, dove l’applicazione risiede su un ser-

ver, permettendo un semplice accesso alle immagini con il solo utilizzo di un browser

sul proprio computer, senza necessità di installazioni specifiche. Per la semplice distri-

buzione delle immagini (cioè per la loro consultazione, sia nei reparti che all’esterno

dell’ospedale) il computer può essere un normale terminale. Per la diagnosi la stazione

di lavoro deve avere:

• sufficiente RAM[g] per contenere tutte le immagini sotto esame;

• un’appropriata scheda grafica, in grado di pilotare i monitor diagnostici ad alta

risoluzione (anche fino a 5 megapixel, per gli esami mammografici);

• un processore potente, per la veloce manipolazione di immagini che possono

raggiungere i 20 megabyte l’una.

In origine, le immagini venivano archiviate immediatamente su memoria di massa locale

ad accesso veloce e lì tenute per un tempo variabile tra 3 e 6 mesi. In seguito politiche

automatiche del sistema le spostavano poi su DVD all’interno di un juke-box (gestore

di media ottici), da dove potevano essere richiamate in automatico in caso di necessità

senza intervento umano (near-line), ma con tempi di risposta notevolmente superiori. I

DVD venivano periodicamente tolti dal juke-box e, contrassegnati da un codice generato

dal sistema, immagazzinati in armadi ignifughi: in caso di necessità, gli esami potevano

essere immessi nuovamente nel sistema, ovviamente con intervento umano e tempi che

non potevano essere minori di qualche ora.

Con la diminuzione dei costi delle memorie di massa, è diventata prassi mantenere

tutte le immagini nella memoria ad accesso immediato cioè su hard disk; questo, as-

sieme alle crescenti velocità delle reti, permette un tempo di accesso alle informazioni

dell’ordine dei secondi per una singola immagine. Come affermato in precedenza, un


tipico sistema PACS è in grado di gestire solo oggetti DICOM; tali oggetti contengono

al loro interno, oltre all’immagine, anche i dati relativi al paziente e all’esame a cui si

riferiscono. Il sistema PACS registra questi dati quando riceve le immagini e li utilizza

quando gli viene richiesta una lista di esami o pazienti, invece di accedere ogni volta

agli oggetti DICOM; in questo modo, tutte le ricerche sono effettuate su un archivio

testuale, ricorrendo a quello DICOM solo quando è necessario visualizzare o comunque

spostare le immagini. L’architettura della parte hardware viene progettata ad hoc per

ogni situazione, in quanto può dipendere dal numero di ospedali coinvolti, dal loro carico

di lavoro e dalle politiche di backup necessarie per mantenere la continuità del servizio.

L’archivio DICOM on-line è di solito registrato su memorie di massa su sistemi SAN[g]

o NAS[g], spesso configurati in RAID[g] o con architettura ridondante. Ogni disco può

essere sostituito in caso di problemi senza interrompere il funzionamento del sistema.

Figura 2.2: Architettura di un sistema PACS.

2.1.3 Funzionalità dell’archivio

Le procedure con cui vengono ricevute e trasmesse le immagini sono definite dallo stan-

dard DICOM; in generale, il passaggio avviene sempre tra due AETitle (Application

Entity Title): tra la modalità diagnostica che genera le immagini e il PACS, tra il PACS

e un archivio remoto o una stampante. Un esempio tipico di utilizzo è la procedura di


Query/Retrieve, in cui un nodo DICOM remoto richiede una serie di informazioni, per

esempio la lista degli esami di un determinato paziente; vengono passati, tramite un’as-

sociazione DICOM, i dati da ricercare (in questo caso l’identificativo del paziente) ed i

campi che si vogliono avere come risultato (gli identificativi degli esami); il PACS filtra

i propri dati e risponde con la lista richiesta. Da tale lista, il richiedente può decidere

di voler vedere le immagini di un determinato esame tra quelli trovati: questa volta la

transazione conterrà l’identificativo dell’esame scelto, mentre le informazioni di ritorno

dovranno essere le immagini; il PACS riconosce il comando e metterà nella coda di spedi-

zione gli effettivi oggetti DICOM. Tutto questo avviene in modo trasparente all’utente: è

infatti compito dell’applicativo creare la corretta comunicazione DICOM, interpretando

le scelte che l’utente effettua sull’interfaccia grafica. Altre procedure importanti sono la

Store (ricevimento delle immagini provenienti da una modalità), l’autorouting (inoltro

automatico ad un altro nodo DICOM delle immagini ricevute), la print che permette

di stampare su una stampante DICOM l’immagine assieme alle eventuali annotazioni

aggiunte durante la refertazione.

2.1.4 Copia di riserva

La potenza del PACS risiede anche nella possibilità di analisi storiche sull’andamento

di una patologia, per cui è necessario assicurare che quanto archiviato sia sempre dispo-

nibile, anche in caso di problemi hardware o avvenimenti esterni. In più, oltre ai dati

personali dei pazienti, nel PACS sono mantenuti anche dati sensibili relativi allo stato di

salute: questi dati devono quindi essere protetti da perdite, o meglio in caso di errori o

di eventi distruttivi, deve essere possibile il loro recupero, oltre a garantire la continuità

dell’utilizzo. La legislazione italiana richiede che in caso di problemi l’archivio debba

essere recuperato entro un massimo di 7 giorni. Quindi, una parte importante di un

sistema PACS ha lo scopo di ridurre al minimo i rischi di perdita di dati; le politiche

per la sicurezza dei dati sono molteplici, ma l’elemento comune è rappresentato dall’ef-

fettuare una seconda copia di tutti i dati ricevuti: via rete ad un altro server, ad un

produttore di media ottici, su unità a nastro; è importante che il sistema di recupero

sia fisicamente in un’altra locazione, per esempio per non essere coinvolto nello stesso

incendio. Queste procedure sono indicate con il termine inglese disaster recovery.


2.1.5 Integrazioni

Il PACS deve essere integrato con tutti gli altri attori informatici, per poter trarre

il massimo vantaggio dall’informatizzazione. Per far questo utilizza sia lo standard

DICOM che il linguaggio HL7 come previsto da IHE. Nel normale flusso di lavoro della

Radiologia, le interazioni in cui è coinvolto il PACS sono (secondo il profilo Scheduled

Workflow - SWF di IHE):

Prenotazione: nel caso il sistema PACS non abbia una completa architettura web, il

RIS comunica al PACS via HL7 la lista degli esami previsti e nella notte precedente

il PACS spedisce alla stazione di visualizzazione gli esami precedenti del paziente

(prefetch), in modo che siano a disposizione del medico radiologo al momento

dell’esame. Per un sistema web nativo, questa fase non è necessaria, in quanto

tutti gli esami sono sempre disponibili via web;

Accettazione: riceve l’avviso dal RIS via HL7 che il paziente è giunto in Radiologia e

si predispone per ricevere le immagini, per esempio creando il paziente se non già

esistente nell’archivio (alcuni PACS non necessitano di questo passaggio, in quanto

possono creare il paziente all’arrivo delle immagini, utilizzando i dati all’interno

delle immagini stesse);

Esecuzione: la modalità diagnostica spedisce le immagini dell’esame al PACS; se sono

più di una, sono organizzate in serie. I dati del paziente e dell’esame da ese-

guire sono comunicati dal RIS alla modalità (DICOM Modality Worklist) prima

dell’esame;

Refertazione: il medico radiologo accede alla propria lista di lavoro dal RIS, che ri-

chiede al PACS di aprire le immagini necessarie sui monitor di refertazione; se

necessario, il medico può vedere immagini degli esami precedenti dello stesso pa-

ziente. Il referto viene scritto sul RIS, che si occupa di passarlo al PACS: questa

comunicazione può essere fatta tramite un file DICOM (SR - Structured Report),

oppure tramite un messaggio HL7. Il PACS può gestire sia il referto in formato

testo che documenti firmati digitalmente.


Esistono almeno due tipi di codici identificativi univoci che attraversano l’intero

flusso, riconosciuti anche dal PACS: l’identificazione del paziente e quella dell’episodio

(studio); i codici corrispondenti (PatientID e StudyID) vengono usati ogni volta che è

necessaria una comunicazione con un altro attore. Esistono poi altri messaggi utilizzati

dal PACS per comunicazioni al di fuori del flusso di lavoro, tra cui i più importanti

sono quelli relativi all’anagrafica del paziente (messaggi ADT), scambiati quando tali

dati vengono variati o creati. Un esempio importante (descritto nel profilo IHE Patient

Information Reconciliation - PIR) è l’aggiornamento di un paziente che all’arrivo in

ospedale non è in grado di comunicare le proprie generalità: l’esame verrà comunque

eseguito utilizzando un nome fittizio, che verrà corretto in seguito su un unico attore

e propagato a tutti gli altri, tra cui il PACS, che riceverà comunicazione tramite il

RIS. Secondo la visione IHE, il PACS non ha necessità di integrarsi direttamente con il

software di riferimento ospedaliero HIS, ma solamente attraverso il RIS.


2.2 Il problema

La necessità di avere un linguaggio digitale universale capace di trasmettere le informa-

zioni cliniche attraverso la rete ha portato ad un accordo tra NEMA (National Electric

Manufacturer Association) ed ACR (American College of Radiology). Il risultato più

importante è stato la creazione del protocollo standard DICOM (Digital Imaging and

Communications in Medicine), che descrive la comunicazione di immagini in un modo

standard riconosciuto a livello mondiale. Lo standard permette la formattazione e lo

scambio di immagini digitali ad alta risoluzione e di informazioni mediche in tempo reale

verso workstation, PACS e stampanti localizzate in aree diverse ma connesse fra loro

in rete. La possibilità di immagazzinare, rivedere e trasmettere le immagini cliniche ed

i relativi referti attraverso reti locali e geografiche in tempo reale crea percorsi innova-

tivi verso nuove frontiere diagnostiche. La semplicità di immagazzinamento e recupero

di singole immagini, loop, referti, sono alcune delle possibilità offerte dalla tecnologia

basata su piattaforma PC. Aqrate vuole espandere le funzionalità del proprio prodot-

to, AqrateVector (1.4.1.1), implementando un PACS completo che rispetti il protocollo

medicale DICOM.

2.3 Approccio al problema

Il primo approccio al problema è la presentazione dello stage nella quale l’azienda de-

finisce i requisiti macroscopici. La fruizione di tali informazioni, mi permette di con-

centrarmi nello studio delle tecnologie e degli strumenti da utilizzare. Il primo passo

è quello di studiare accuratamente lo standard DICOM, in particolare di comprendere

funzionamento, potenzialità ed utilizzo delle SOP Class. Lo studio è basato oltre che

sulla documentazione fornita dall’azienda, sui documenti messi a disposizione dal sito

dell’associazione NEMA. Questa prima attività è incentrata sullo standard in oggetto

e sulla comprensione dei requisiti da soddisfare. La comprensione del fine ultimo delle

funzionalità da sviluppare è importante per capire cosa fare e come attuarlo.


2.4 L’obiettivo

A fronte di quanto detto finora, lo scopo dello stage è quello di realizzare un modulo

caricabile dinamicamente da un application server proprietario di Aqrate, in modo da

realizzare un PACS (Picture archiving and communication system) molto basilare.

L’obiettivo dello stage è di implementare le seguenti SOP Class (3.1.1.5):

• Verification SOP Class;

• Storage SOP Class.

E cioè di fare in modo che l’applicativo sia in grado di:

• Rispondere al DICOM ping, cioè gestire la C-Echo (3.1.1.7);

• Memorizzare una IOD (Information Object Definition 3.1.1.5) di tipo CR (Com-

puted Radiology), cioè gestire la C-Store (3.1.1.7).

Ci si deve cimentare con:

• La comprensione dello standard DICOM;

• La scelta dell’architettura implementativa (vengono valutati due differenti approc-

ci);

• L’implementazione del modulo.

Per quanto riguarda il secondo punto, è fondamentale studiare i punti di forza degli

approcci proposti e fornire elementi tali da giustificare la scelta dell’architettura della

soluzione.

L’implementazione riguarda lo sviluppo di un componente senza alcuna interfaccia grafi-

ca, in grado di configurarsi dinamicamente per la ricezione e l’invio di messaggi DICOM

su socket TCP/IP in grado di gestire le operazioni di C-Store e C-Echo. Tale compo-

nente è la base per lo sviluppo futuro di un PACS completo che implementi quindi anche

altre operazioni utili, come C-Get e C-Find, e che possa integrare il prodotto Aqrate

Vector (1.4.1.1) con il protocollo DICOM.


2.5 Vincoli

Le direttive date dall’azienda allo stagista sono state le seguenti:

• Sviluppare un PACS Server e un PACS Client;

• Gestire la C-Echo e la C-Store;

• Utilizzo del framework[g]Microsoft R© .NET, del linguaggio di programmazione C#

e Visual Studio 2010 come ambiente di sviluppo integrato;

• Produzione di documentazione.

Tali direttive per essere soddisfatte richiedono una cospicua fase di studio delle nor-

mative, per apprendere i concetti che stanno alla base dello standard DICOM. Per

questo motivo Aqrate ha stabilito un’iniziale attività di formazione, come vincolo per

poter iniziare qualsiasi attività di sviluppo, con lo scopo di introdurre lo stagista al

mondo dei PACS ed alla struttura ed al funzionamento dello standard DICOM.

Un altro vincolo richiesto è che il software realizzato debba essere il più possibile por-

tabile e quindi compatibile in particolare con i sistemi operativi GNU/Linux, Mac OS

X e Windows.

Per lo sviluppo dei documenti si utilizza il programma Microsoft Office Word.

Tutto il codice sorgente che viene creato dal programmatore deve seguire le convenzioni

di codifica C#. Il codice sorgente che riguarda il progetto deve essere contenuto nella

directory del progetto, da cui possono eventualmente partire rami di sviluppo paralleli.

Non deve essere presente codice estraneo al progetto. Il codice deve essere accompagna-

to da commenti scritti in inglese o italiano rispettando le politiche di qualità imposte

tramite gli strumenti di validazione del codice. La qualità del codice, ed in particolare la

sua estensibilità, devono essere particolarmente curate per facilitare eventuali sviluppi

futuri da parte di altre persone. Ogni file di codice sorgente deve possedere un’intesta-

zione che abbia un registro delle modifiche contenente data della modifica nella forma

DD.MM.YYYY e autore della modifica.


2.6 I fattori di rischio

Questa sezione ha l’obiettivo di descrivere alcuni dei rischi che è possibile incontrare du-

rante la realizzazione del prodotto. Il rischio è definito come il valore atteso del danno

derivante dal verificarsi di una combinazione di condizioni incerte, è tale se comporta un

disagio, una sofferenza o una perdita, percepibile da determinati soggetti, conseguente

al verificarsi di situazioni che sono possibili ma non certe.

I rischi non incidono tutti nella stessa maniera, differiscono per probabilità e impatto.

Nella tabella 2.1 definiamo le probabilità di rischio.

Livello di probabilità CriterioBasso É molto probabile che non si verifichiMedio Uguale probabilità che si verifichi o menoAlto É altamente probabile che si verifichi

Tabella 2.1: Probabilità di rischio

Di seguito per ogni rischio identificato si cerca di delineare un’analisi generale e una

procedura di mitigazione.

Assenza per malattia

Analisi: per problemi di salute o lo stagista o il tutor aziendale, durante le fasi di

verifica, potrebbero assentarsi.

Probabilità: bassa.

Procedura di mitigazione: se l’assenza del componente si limita a qualche giorno,

ma a un periodo di tempo prolungato, si procede con la ripianificazione del piano di

lavoro.

Scarsa conoscenza delle tecnologie utilizzate

Analisi: alcune delle tecnologie che saranno impiegate durante lo sviluppo del progetto

sono a me sconosciute.

Probabilità: alta.

Procedura di mitigazione: studio della documentazione on-line, in particolare di

quella fornita dal tutor aziendale.


Variazione dei requisiti

Analisi: non sono ammesse radicali variazioni se non ad evidente miglioramento di

quanto pianificato.

Probabilità: media.

Procedura di mitigazione: se verranno comunicate variazioni dei requisiti, dovrò

prontamente apportare delle modifiche all’analisi dei requisiti e, di conseguenza, all’in-

tero progetto, in modo calcolare il prima possibile una nuova stima dei relativi costi e

ridurre il danno che può provocare questo evento.

Linguaggio di programmazione

Analisi: non si ritiene che l’uso del linguaggio di programmazione imposto dal com-

mittente possa comportare particolari problemi.

Probabilità: bassa.

Procedura di mitigazione: in caso di problemi con la sintassi o la semantica del

linguaggio usufruire della documentazione ufficiale che si trova nel sito di Microsoft.

2.7 Verifiche e revisioni

Le attività di verifica, proposte dal tutor aziendale, sono focalizzate sui concetti appresi

e sulla loro attuazione. La verifica delle conoscenze maturate è la metrica per vagliare

la possibilità di proseguire con le attività proposte o di stanziare nella fase di lavoro

in oggetto per rafforzare le stesse. Al termine di ogni attività di sviluppo è attuata

da parte del tutor aziendale una revisione formale interna. Le revisioni prendono in

oggetto i seguenti punti:

• documentazione prodotta in relazione allo sviluppo effettuato;

• verifica dello stato di avanzamento dello stage.


2.8 Utilizzo e sviluppi futuri

Il mio stage serve all’azienda per implementare un PACS basilare. Il prototipo da me

implementato è alla base dello sviluppo di un PACS completo che in futuro servirà al

prodotto Aqrate Vector (1.4.1.1) per integrare le più importanti funzionalità DICOM.

Il prodotto software, inoltre, verrà pubblicato nel sito aziendale con lo scopo di pubbli-

cizzarlo ed indirettamente di acquisire informazioni circa possibili clienti interessati al

futuro sviluppo di Aqrate Vector con lo standard DICOM.

Il prototipo verrà sicuramente migliorato ed espanso introducendo ulteriori servizi quali:

Storage commitment : utilizzato per confermare l’effettiva memorizzazione perma-

nente di un immagine su un dispositivo di memoria;

Query/Retrieve: consente ad una stazione di lavoro di trovare gli elenchi di immagini

o altri oggetti e poi recuperarli da un PACS;

Modality worklist : consente di ottenere i dettagli dei pazienti e la worklist degli

esami;

Printing : servizio utilizzato per inviare le immagini ad una stampante DICOM.

Nella figura seguente viene illustrata un’anticipazione dello sviluppo futuro dell’archi-

tettura DICOM del prodotto Aqrate Vector.

Figura 2.3: Architettura di Aqrate Vector integrato con le funzionalità DICOM


2.9 Piano di lavoro

Figura 2.4: Diagramma di Gantt relativo al piano di lavoro a preventivo.


Nella figura 2.4 viene illustrata la pianificazione delle attività stabilite ad inizio stage

con il tutor dell’azienda, al fine di organizzare nel modo migliore le fasi da svolgere.

Come riportato dal diagramma di Gantt, in relazione alle diverse funzionalità da svi-

luppare, l’attività di stage è scomposta in più fasi:

• La prima fase consiste nella formazione sulle tecnologie utilizzate all’interno del-

l’azienda, utili e necessarie per le fasi successive: studio dei concetti fondamentali,

del dominio e degli strumenti;

• Le fasi intermedie vertono, invece, nella vera e propria realizzazione e verifica delle

singole funzionalità: sviluppo, verifica e documentazione;

• L’ultima fase è dedicata ai test d’unità e alla correzione dei malfunzionamenti.

La fase iniziale, dedicata alla formazione e comprensione del dominio applicativo ed

aziendale, interessa non solo le tematiche affrontante durante lo stage, ma presenta una

panoramica generale dell’azienda e del mercato ICT.

Capitolo 3

Lo stage

Il seguente capitolo vuole descrivere quali sono state le attività svolte durante il periodo

di stage, attraverso le varie fasi affrontate, necessarie alla sua realizzazione, cercando

di entrare nel dettaglio di quelle più rilevanti. Il modello di ciclo di vita adottato per

lo sviluppo del progetto, e dei singoli moduli, è stato quello iterativo evolutivo. La

scelta, presa in accordo con l’azienda, è stata dettata dal fatto che l’azienda stessa non

aveva un’idea del tutto precisa e definitiva riguardo alla metodologia implementativa

di determinate funzionalità. Di conseguenza si è scelto un modello di ciclo di vita

che permettesse un certo grado di libertà nell’aggiunta incrementale di funzionalità nei

moduli stessi, non previste in partenza, ma emerse in fasi successive di realizzazione.

3.1 La formazione

Durante la prima settimana di stage ha avuto luogo la fase di apprendimento dei concetti

fondamentali dello standard DICOM, così come pianificato. L’azienda mi ha fornito di

tutti i mezzi necessari, quali documentazione e connessione ad Internet. La prima

fase della formazione è stata dedicata ad uno studio generale sull’argomento per avere

una visione completa ed esaustiva del dominio. Successivamente mi sono soffermato

sui concetti maggiormente correlati allo stage. Di seguito vengono descritti i concetti

appresi durante questa prima fase. La seguente documentazione è stata da me scritta e

fornita all’azienda per facilitare l’apprendimento dello standard DICOM.

27

CAPITOLO 3. LO STAGE 28

3.1.1 Standard DICOM

DICOM (Digital Imaging and Communications in Medicine) è uno standard orientato

alla comunicazione di immagini mediche in formato digitale. Diffuso soprattutto nei

dipartimenti di radiologia, è caratterizzato da una struttura aperta e da ampie pos-

sibilità di estensione ed applicazione per tutte le specialità che producono immagini

mediche: patologia, endoscopia, odontoiatria, oculistica e dermatologia. Negli anni ‘80,

con la crescente diffusione dei sistemi di acquisizione delle immagini mediche in formato

digitale (modalità) diventa indispensabile trovare soluzioni per semplificare la connes-

sione e l’interoperabilità, a vantaggio di utenti e produttori. DICOM è la risposta a

questa necessità. DICOM definisce l’interfaccia che rende possibile la connessione tra

sistemi diversi. Le funzionalità offerte includono: il trasferimento in rete di oggetti

ed immagini (invio, ricezione e ricerca); il trasferimento tramite file; l’integrazione con

altri sistemi (richiesta di un elenco di esami da completare, invio della notifica dell’e-

secuzione di un esame, impiego di documenti strutturati per la gestione congiunta di

dati, referti ed immagini). Lo standard è stato sviluppato congiuntamente da utenti e

produttori di dispositivi con l’obiettivo di rendere possibile la connessione tra sistemi

di produttori diversi. Possiede le componenti fondamentali per dialogare con i sistemi

informatizzati di gestione delle immagini (PACS, Picture Archiving and Communication

System), dell’attività ospedaliera (HIS, Hospital Information System) e, in particolare,

del dipartimento di radiologia (RIS, Radiology Information System).

3.1.1.1 Le caratteristiche generali

Le specifiche DICOM si sviluppano a partire da modelli che stabiliscono quali sono e

con quali relazioni interagiscono le entità reali, presenti nel contesto a cui lo standard è

applicato (pazienti, immagini, ecc.). Il vantaggio di questi modelli è quello di mostrare

chiaramente e congiuntamente le entità e le relazioni, non per descrivere il flusso dei dati,

ma per definire la struttura dell’informazione. I modelli sono generalmente rappresentati

con diagrammi del tipo schematizzato in figura 3.1, dove le frecce vengono utilizzate

per indicare la direzione di una relazione.

La documentazione dello standard è suddivisa in parti e ciascuna parte può com-

prendere degli allegati, dove sono riportate quelle sezioni che possono essere oggetto di


Figura 3.1: Schema semplificato delle relazioni tra le entità paziente, studio, serie edimmagine nello standard DICOM.

modifiche od estensioni. Lo standard è in continua evoluzione, per migliorare le fun-

zionalità indirizzate all’integrazione e per ampliare le possibilità di interfacciare sistemi

diversi da quelli tradizionalmente presenti in un reparto di radiologia.

3.1.1.2 La dichiarazione di conformità

La conformità allo standard DICOM dovrebbe assicurare la connettività tra due dispo-

sitivi, cioè la possibilità di scambiare in modo corretto messaggi in formato DICOM,

ma non implica l’interoperabilità a livello di applicazione, cioè la capacità di manipola-

re correttamente l’informazione. L’interoperabilità può richiedere specifiche aggiuntive

sulle applicazioni e sul flusso di dati. Lo standard DICOM impone di specificare in una

dichiarazione di conformità le informazioni necessarie per assicurare la connettività e

per poter verificare il livello di interoperabilità, senza dover fisicamente provare il si-

stema. Conseguentemente, per poter qualificare un’implementazione dello standard e

valutarne la compatibilità con altri sistemi, non è sufficiente la semplice conformità allo

standard, deve essere esaminato il contenuto della dichiarazione di conformità.


3.1.1.3 Il modello di informazione

In funzione della specialità clinica, possono variare la terminologia e le modalità ope-

rative utilizzate per l’acquisizione delle immagini, per l’esecuzione delle procedure e

per l’identificazione delle immagini. In un ambiente in cui l’informazione deve essere

condivisa, queste diversità devono essere in parte superate. L’informazione deve essere

manipolata in modo uniforme, indipendentemente dal particolare contesto in cui viene

generata. DICOM utilizza un proprio modello di informazione, sufficientemente flessi-

bile ed adattabile ad ambienti diversi. La struttura del modello è un insieme di entità

e relazioni tra entità, dove ciascuna entità caratterizza una specifica fase del processo

di produzione e manipolazione delle immagini. Le principali entità e relazioni presenti

nel modello DICOM possono essere descritte con riferimento all’attività di un tipico

dipartimento di radiologia. Come indicato nello schema semplificato di figura 3.1, le

immagini prodotte da ciascuna modalità vengono ordinate in una cartella paziente per

tipo di studio e per serie correlate da specifiche condizioni. Le principali entità sono il

paziente, lo studio, la serie e l’immagine. Le corrispondenti relazioni sono: il paziente è

oggetto di uno o più studi; ciascuno studio può contenere una o più serie; ciascuna serie

può contenere una o più immagini.

Figura 3.2: Schema semplificato della distribuzione gerarchica dell’informazione tra leentità paziente, studio, serie ed immagine nello standard DICOM.

Il modello DICOM distribuisce l’informazione gerarchicamente su quattro livelli fon-

damentali, come illustrato in Figura 3.2. Il livello più elevato è costituito dai dati iden-


tificativi del paziente sottoposto a studio. Lo studio raccoglie le informazioni relative

ad una richiesta di esami e costituisce il livello di riferimento per il sistema ammini-

strativo (dipartimentale o centrale). La serie definisce le caratteristiche e le modalità

operative dei sistemi utilizzati per effettuare l’esame. Il livello più basso è costituito

dai dati rappresentativi dell’immagine prodotta dal dispositivo di acquisizione. Le di-

verse entità sono strettamente collegate alle diverse fasi del processo di produzione di

un’immagine. Diversi sottosistemi generano in momenti diversi l’informazione associa-

ta a ciascuna entità, come illustrato schematicamente in figura 3.3. I dati del paziente

vengono normalmente forniti dal sistema amministrativo (centrale o dipartimentale) e

sono utilizzati dal sistema di acquisizione. I dati relativi allo studio provengono in parte

dal sistema amministrativo, che fornisce gli elementi per identificare e collegare parti

diverse di uno stesso studio, e in parte dal sistema di acquisizione. Le informazioni sulla

serie e sulle immagini sono completamente dipendenti dal sistema di acquisizione.

3.1.1.4 Le principali entità

L’entità paziente costituisce il punto di riferimento per tutta l’informazione prodotta

su un singolo paziente. A questa devono essere collegati tutti gli studi a cui il paziente

è stato sottoposto. La struttura dati del paziente contiene codici di identificazione ed

informazioni di tipo anagrafico. L’informazione viene generata e mantenuta dal sistema

amministrativo esterno al sistema di acquisizione. L’entità studio è il principale livello

di riferimento clinico ed amministrativo. Viene generata da una richiesta di esami. A

questa possono essere associate una o più procedure e ciascuna procedura può produrre

una singola immagine o una serie di immagini correlate. L’informazione viene prodot-

ta in parte dal sistema amministrativo, che deve garantire l’identificazione consistente

dello studio, e in parte dal sistema di acquisizione. La struttura dati dello studio con-

tiene codici di identificazione univoca (UID, Unique Identifier) ed informazioni relative

all’esame (data e ora di esecuzione, nome del medico richiedente, ecc.) e al paziente

(età, sesso, peso, occupazione, ecc.). L’entità serie è associata ad uno specifico sistema

di acquisizione e alle modalità operative di una particolare procedura. A questa pos-

sono essere associate una o più immagini. La relazione tra le immagini può essere di

tipo clinico (ad esempio immagini dello stesso organo visto da posizioni diverse) o fisico


(ad esempio una sequenza di immagini temporalmente o spazialmente correlate). In

DICOM, non esiste un insieme di regole che definisca, per ogni sistema di acquisizione,

il contenuto di una serie. Rientra nei compiti della dichiarazione di conformità speci-

ficare quali regole siano utilizzate da una particolare implementazione. L’informazione

viene generata esclusivamente dal sistema di acquisizione. La struttura dati della serie

contiene codici di identificazione univoca (UID) ed informazioni relative al dispositivo

utilizzato e alle modalità di acquisizione.

Figura 3.3: Schema semplificato delle sorgenti di informazione per le entità paziente,studio, serie ed immagine nello standard DICOM.

L’entità immagine contiene, in formato digitale e in funzione del dispositivo utilizza-

to, una singola immagine o una coppia di immagini (ad esempio per i sistemi biplanari)

o un insieme di immagini (ad esempio una sequenza di fotogrammi). Immagini mul-

tiple possono essere trattate come una singola immagine, quando la loro relazione è

molto semplice. L’informazione viene generata esclusivamente dal sistema di acquisizio-

ne. La struttura dati dell’immagine contiene codici di identificazione univoca (UID) ed

informazioni relative alle matrici di pixel (dimensioni, valori numerici, codifica, ecc.).

3.1.1.5 Le classi DICOM

Nel definire le procedure di gestione dell’informazione, lo standard DICOM segue un

approccio orientato agli oggetti, basato su classi ed istanze. Una classe contiene una

coppia di dichiarazioni relative ai dati e ai metodi utilizzabili per trattare una speci-

fica tipologia di oggetti. I dati codificano l’informazione. I metodi determinano quali

operazioni possono essere effettuate. La classe è un’entità astratta. Dichiara il formato

e la struttura dei dati (non il loro valore) e il tipo di operazioni ammesse. Un’istanza

rappresenta un particolare oggetto di una classe. Il valore dei suoi dati deve essere


compatibile col formato dichiarato nella classe di appartenenza. L’istanza può essere

manipolata solo con i metodi definiti nella classe di appartenenza. In DICOM l’in-

formazione viene scambiata mediante istanze a classi. La struttura delle classi viene

definita con una specifica terminologia. Le immagini vengono descritte da classi SOP

(Service Object Pair), che comprendono una definizione IOD (Information Object De-

finition), per la parte dati, e un gruppo di servizi, per la parte metodi. Le classi SOP

possono specificare estensioni o restrizioni dei dati presenti nella definizione IOD o dei

metodi disponibili nel gruppo di servizi. Specifici meccanismi di generazione dei codici

di identificazione univoca (UID) garantiscono l’univocità di un’istanza SOP e facilitano

la costruzione di relazioni certe tra le diverse istanze. La classe SOP costituisce l’uni-

tà funzionale elementare di DICOM. Ciascuna implementazione dichiara quali sono le

classi disponibili (conformi allo standard) e in quale modo sono supportate. Implemen-

tazioni diverse possono comunicare solamente utilizzando le parti funzionali comuni.

Chiarita l’unità funzionale fondamentale definita da DICOM (la SOP Class) vediamo

come avviene lo scambio di informazioni. Alla base del protocollo in esame esiste un

approccio Client/Server, nel senso che, ogni volta che due applicazioni decidono di con-

nettersi per scambiarsi informazioni, una delle due deve svolgere il ruolo di fornitore

del servizio (SCP: Service Class Provider) mentre l’altra quello di utente (SCU: Service

Class User). Ovviamente, per ciascuna combinazione di SOP Class e ruolo, lo standard

definisce un set di regole di base controllate in fase di pre-colloquio o negoziazione,

durante la quale si stabilisce se la comunicazione tra i due apparati è possibile oppure

no.

3.1.1.6 Le entità di informazione

La parte dati di una classe SOP è una definizione IOD. Le definizioni IOD specificano il

significato, gli obiettivi e la struttura dell’informazione rappresentata. L’informazione

viene suddivisa in entità di informazione. Ciascuna entità di informazione corrisponde

ad una particolare entità del modello di informazione DICOM. Un’entità di informazione

contiene un insieme di attributi, ciascuno dei quali descrive una porzione di informazione

elementare. Per esempio, gli attributi della definizione IOD del paziente comprendono

il nome, il cognome e il sesso. Attributi correlati sono raggruppati in moduli. Per


ciascun attributo viene specificato un codice di identificazione univoco, oltre ad un

nome e ad una breve descrizione del significato e dei possibili valori. Una definizione

IOD normalizzata ha una sola entità di informazione. Ad esempio, è normalizzata la

definizione IOD del paziente, che contiene solo dati relativi al paziente, principalmente

di tipo anagrafico. Una definizione IOD composita contiene più entità di informazione

tra loro correlate. Ad esempio, è composita le definizioni IOD di un’immagine, destinata

a rappresentare informazioni relative alle entità paziente, studio e serie, assieme ai dati

propri dell’immagine. Un’immagine DICOM è un’istanza ad una classe SOP. Un’istanza

composita contiene tutta l’informazione necessaria per il trattamento dell’immagine. La

parte dati è strutturata conformemente al modello di riferimento definito dallo standard

e contiene l’intera gerarchia di informazioni, dall’entità paziente all’entità immagine. In

questa modalità, parte dei dati vengono duplicati per tutte le istanze relative allo stesso

paziente e allo stesso studio. Un’istanza normalizzata contiene l’informazione relativa

all’entità immagine e solo i riferimenti per tutte le altre entità necessarie per ricostruire

l’informazione associata all’immagine. In questa modalità diminuisce la quantità di

dati da trasferire ed aumenta la complessità dei collegamenti tra le diverse istanze. Le

diverse istanze devono fornire dati consistenti per tutte le entità presenti ai diversi livelli.

Le informazioni relative allo studio e al paziente devono essere confrontabili per tutti i

dispositivi utilizzati e devono essere garantite da una fonte esterna comune. Ciascuna

implementazione dello standard deve inoltre definire una struttura uniforme per tutte

le serie e le immagini generate su uno stesso dispositivo. L’identificazione di ciascuna

entità (paziente escluso) viene ottenuta assegnando un codice identificativo univoco

(UID). I meccanismi di identificazione univoca del paziente devono essere garantiti da

un soggetto esterno.

3.1.1.7 Gli elementi di servizio

Il gruppo di servizi, o anche chiamato DIMSE service, si compone di elementi di servizio.

Gli elementi di servizio definiti in DICOM contengono specifiche che ne possono limitare

l’applicazione solo a definizioni IOD normalizzate o composite. Elementi di servizio

applicabili a definizioni IOD normalizzate sono utilizzati per:

• leggere o modificare il valore di uno o più attributi;


• creare o cancellare un’istanza;

• segnalare un evento;

• eseguire un’azione.

Elementi di servizio applicabili a definizioni IOD composite sono utilizzati per:

• memorizzare un’istanza in un’altra Application Entity, servizio chiamato C-Store;

• trovare o leggere tutte le istanze aventi attributi con prefissati valori, servizio

chiamato C-Find;

• verificare la comunicazione fra due AE, servizio chiamato C-Echo.

Esistono elementi di servizio specifici per ciascuna tipologia di classe DICOM. Ad

esempio, nel modello DICOM una richiesta di esami si compone di una o più richieste

di procedure, ciascuna delle quali viene eseguita in una o più fasi. Le liste di lavoro

DICOM includono tutte le fasi previste dalle procedure, suddivise per paziente. Gli

elementi di servizio DICOM, previsti per le classi relative alle liste di lavoro, includono:

La gestione delle liste di lavoro: permette ad una modalità di richiedere la lista di

lavoro corrente, di selezionare i pazienti e di programmare l’esecuzione di specifiche

fasi, previste dalle procedure richieste.

La notifica di esecuzione di una fase di una procedura: permette ad una moda-

lità di inviare al sistema informatizzato (HIS o RIS) le informazioni relativi all’e-

secuzione e ai risultati di una particolare fase, prevista dalla procedura richiesta.

3.1.1.8 La definizione delle immagini

Lo standard DICOM definisce più classi SOP di tipo immagine. Ciascuna classe utilizza

una specifica definizione IOD, applicabile ad un particolare dispositivo di acquisizione.

Tutte condividono un insieme minimo di informazioni che permette la visualizzazione

delle immagini in modo generico, indipendentemente dal tipo di classe. Le informazioni

di base, che devono essere presenti in un’istanza ad una classe SOP di tipo immagine,

sono: gli identificatori (UID) della classe, dello studio, della serie e dell’immagine (l’UID


dell’immagine coincide con l’UID dell’istanza); il tipo di dispositivo di acquisizione; le

informazioni sulla matrice di pixel dell’immagine. Altre informazioni utili per descrivere

il paziente, lo studio, la serie ed ulteriori particolari dell’immagine possono essere omessi.

Sono disponibili estensioni alla definizione IOD di immagine generica per quasi tutte le

principali modalità e, in particolare, per i seguenti sistemi:

Radiografia computerizzata: non sono richieste informazioni specifiche particolari;

Tomografia computerizzata: il posizionamento è importante per elaborare sequenze

di immagini e creare rappresentazioni tridimensionali;

Risonanza magnetica: oltre ad informazioni di posizione sono necessarie informazio-

ni sul protocollo di acquisizione;

Medicina nucleare: contiene informazioni dedicate sulle modalità di acquisizione e

sul formato dell’immagine;

Ultrasuoni: sono importanti i parametri di acquisizione, posizione e formato e le

informazioni sul colore;

Angiografia: sono importanti i parametri di acquisizione, posizione e formato e le

informazioni sull’immagine utilizzata come maschera per la sottrazione.

Ciascuna definizione IOD può utilizzare moduli comuni a tutte le definizioni IOD o

moduli specifici presenti in un solo tipo di definizione IOD.


3.2 Analisi dei requisiti

3.2.1 Requisiti Software

Si presenta ora la tabella dei requisiti, divisi per categoria e ordinati secondo tre livelli di

priorità dal più alto al più basso: obbligatorio (OB), desiderabile (DE), opzionale (OP).

Ad ogni requisito è assegnato un codice che lo identifica univocamente. I codici vengono

assegnati secondo la seguente convenzione: A.PR n dove A è una lettera che identifica

il tipo di requisito, PR identifica la priorità del requisito ed ad ognuno è assegnato un

numero n.

Codice DescrizioneF.OB 1 Sviluppare un PACS ServerF.OB 2 Sviluppare un PACS ClientF.OB 3 Rispondere al DICOM PING, cioè gestire la C-EchoF.OB 4 Memorizzare una IOD (Information Object Definition) di tipo CR

(Computed Radiology), cioè gestire la C-StoreF.DE 1 Possibilità di trasferire file DICOM contenenti immagini JPEG[g]F.DE 2 Possibilità di trasferire file DICOM contenenti immagini JPEG2000[g]F.DE 3 Creare un file di configurazione con cui l’utente possa settare i

parametri d’associazioneF.OP 1 Creare un’interfaccia grafica usando la libreria WPF per l’applicazione

lato server

Tabella 3.1: Requisiti funzionali

Codice DescrizioneV.OB 1 Utilizzo del linguaggio di programmazione C# e Visual Studio 2010

come ambiente di sviluppo integratoV.OB 2 Produzione di documentazione

Tabella 3.2: Requisiti di vincolo

Codice DescrizioneQ.OB 1 Effettuare test di unità per ogni funzionalità sviluppataQ.OB 2 Effettuare analisi statica del codiceQ.OB 3 Testare il PACS basilare sviluppato con i file DICOM rilasciati dal

sito ufficiale http://medical.nema.org

Tabella 3.3: Requisiti di qualità

http://medical.nema.org


3.2.2 Casi d’uso

Presentiamo di seguito alcuni casi d’uso della componente software realizzati. Vedremo

possibili usi generali e come le componenti interagiscono tra di loro.

Figura 3.4: Diagramma UC1: Use case generale delle funzionalità a disposizionedell’Application Entity chiamante.

Use case: UC1;

Sommario: Funzionalità a disposizione dell’Application Entity chiamante;

Attore: Application Entity Calling ;

Precondizioni: indirizzo IP, porta, Abstract Syntax e Transfer Syntax devono essere

configurate correttamente;

Descrizione: l’Application Entity chiamante dopo aver richiesto e in seguito stabilito

un’associazione può richiedere le operazioni di C-Echo o di C-Store. Al termine

richiede la chiusura dell’associazione.

Postcondizioni: l’operazione effettuata è andata a buon fine.


Figura 3.5: Diagramma UC2: Use case generale delle funzionalità a disposizionedell’Application Entity chiamato.

Use case: UC2;

Sommario: Funzionalità a disposizione dell’Application Entity chiamato;

Attore: Application Entity Called ;

Precondizioni: indirizzo IP, porta, Abstract Syntax e Transfer Syntax devono essere

configurate correttamente;

Descrizione: l’Application Entity chiamante dopo aver ricevuto e in seguito stabilito

un’associazione esegue le operazioni di C-Echo o di C-Store. Al termine chiude

l’associazione.

Postcondizioni: l’operazione effettuata è andata a buon fine.


3.3 Progettazione

Dopo aver studiato lo standard DICOM ed aver focalizzato i requisiti da adempiere, ho

dovuto progettare l’architettura delle componenti software. Una rete PACS è composta

da un server PACS centrale il quale possiede un database contenente immagini che più

client possono archiviare, recuperare e visualizzare. Il server e i client comunicano fra di

loro utilizzando il protocollo DICOM. Ogni computer in una rete PACS sono identificati

dal proprio indirizzo di rete (IP Address), dalla porta di comunicazione (porta TCP/IP)

e da un nome (Application Entity Title). Ogni computer è un DICOM Node nella

rete PACS. IP address, porta TCP/IP e Application Entity Title sono informazioni

obbligatorie per connettere ogni DICOM node nelle rete PACS. Per costruire la versione

demo di un PACS che ci interessa abbiamo bisogno di:

• Una componente software che rappresenti un PACS Server. Essa deve essere

capace di stabilire un’associazione con il client, di rispondere al ping di un client,

di salvare ed archiviare un file DICOM in un dispositivo di memoria persistente.

Concluse le operazioni richieste dal client deve rilasciare l’associazione così da

essere disponibile per un’altra operazione con un altro client.

• Una componente software che rappresenti un PACS Client. Essa richiede di sta-

bilire un’associazione con il server, in seguito può verificare se il server è dispo-

nibile in rete, può richiedere di archiviare un file DICOM e richiede di rilasciare

l’associazione una volta finita l’operazione.


Figura 3.6: Architettura della rete PACS: un PACS Server, e multipli PACS Clients(PACS Workstations / DICOM Viewers)

Per connettere client e server è fondamentale instaurare un’associazione DICOM. Lo

scopo di quest’ultima è di assicurare che due applicazioni DICOM siano compatibili e

trasferiscano dati in un formato ed in un ordine ben definito. Le regole delle associazioni

DICOM, costruite sopra l’architettura TCP/IP, rendono quest’ultima capace di trattare

gli oggetti e i comandi DICOM. La costituzione di un associazione DICOM è il processo

che avviene all’inizio di ogni transazione della rete DICOM, uno sorta di handshake.

Durante questo handshake due Application Entity DICOM si scambiano informazioni

circa le loro funzionalità e si accordano sui parametri di comunicazione che devono

essere utilizzati. La chiave di ogni associazione è il concetto di Presentation Context.

Quando un’Application Entity vuole inizializzare una transazione di rete essa comprime

tutte le informazioni di sé stessa in un messaggio di Presentation Context e lo manda

all’Application Entity ricevente. Un messaggio di Presentation Context è composto da:

Abstract Syntax : codifica le SOP Class supportate nella comunicazione fra Applica-

tion Entity ;


Transfer Syntax : rappresenta i formati di codificazione dei dati che sono supportati

nella comunicazione.

Quando un messaggio di Presentation Context è mandato all’Application Entity

ricevente, quest’ultima accetta o rifiuta l’associazione.

Figura 3.7: Richiesta di associazione DICOM

Al giorno d’oggi data la vasta scelta di progetti open source[g] disponibile nella

rete Internet è possibile costruire una rete PACS gratuitamente avendo solo come co-

sti le componenti hardware utilizzate. Con il consenso dal tutor aziendale, ho ana-

lizzato la gamma di librerie DICOM disponibili in Internet al fine di poter scegliere

quella maggiormente indicata ai nostri fini. Avendo come requisito obbligatorio di vin-

colo l’uso del framework .NET, sono state prese in considerazione librerie implemen-

tate con il linguaggio di programmazione C# escludendo quelle implementate utiliz-

zando come linguaggio Java, come ad esempio la libreria Java Dicom Toolkit (http:

//wiki.trispark.com/display/jdt/) o la libreria dcm4chee (http://sourceforge.

net/projects/dcm4che/). Sono state analizzate le librerie open-source Dicom# (http:

//sourceforge.net/projects/dicom-cs/) e ClearCanvas (http://www.clearcanvas.

ca/dnn/). Inizialmente, su consiglio del mio tutor aziendale, è stata presa in consi-

derazione anche Leadtools (http://www.leadtools.com), libreria shareware[g]. Senza

dubbio delle tre librerie quella architettata ed implementata nel modo migliore è Lead-

tools ma dopo aver contattato tramite e-mail l’azienda LEAD Technologies, Inc. è stata

rapidamente esclusa poiché il costo della licenza per il rilascio e per la necessaria ma-

nutenzione era spropositato. Dicom# e ClearCanvas sono state analizzate studiando il

http://wiki.trispark.com/display/jdt/


http://sourceforge.net/projects/dcm4che/


http://sourceforge.net/projects/dicom-cs/


http://www.clearcanvas.ca/dnn/

http://www.clearcanvas.ca/dnn/

http://www.leadtools.com


loro diagramma delle classi, le misurazioni sul loro codice e le funzionalità che mettevano

a disposizione. Seppur Dicom# abbia minore complessità ciclomatica[g]e minore grado

di accoppiamento[g] delle classi rispetto alla libreria ClearCanvas, ho scelto quest’ultima

per i seguenti motivi:

• oltre alle DIMSE C-Echo e C-Store, mette a disposizione i servizi di C-Find,

C-Move, C-Get;

• è in grado di integrare file DICOM contenenti dati compressi secondo gli algoritmi

JPEG, JPEG Lossless, JPEG Lossy e JPEG2000;

• dispone di una documentazione ben argomentata e di un forum di supporto ed

assistenza sempre celere e di grande aiuto.


3.4 Implementazione

Come precedentemente detto ho implementato il PACS basilare usufruendo della libre-

ria ClearCanvas, la quale definisce IOD e DIMSE dello standard DICOM.

Ho sviluppato la componente client, successivamente la componente server. Data la di-

sponibilità di tempo rispetto a quanto pianificato, anche se non era previsto, ho proposto

al tutor aziendale la creazione di un’interfaccia grafica per il server. Dopo la risposta

positiva del tutor ho implementato l’interfaccia usando la libreria grafica WPF. É risul-

tata molto interessante l’idea dell’interfaccia poiché dà la possibilità di pubblicare nel

sito dell’azienda un PACS Server demo, cominciando così a pubblicizzare il prodotto.

Nelle prossime sottosezioni verrà brevemente descritto ciò che è stato fatto.

3.4.1 Componente Client

Figura 3.8: DC1 : Diagramma delle classi della componente client


Per la componente client ho implementato la classe Client, la quale contiene tre

fondamentali metodi, oltre al costruttore. Nel costruttore creo un’istanza della classe

ClientHandler, la quale mi rappresenta un nuovo handler [g] che mi gestisce tutti gli

eventi associati al client. Con il metodo void init(...) creo e configuro i parametri

d’associazione. Imposto il nome dell’Application Entity Client e dell’Application Entity

Server, l’indirizzo IP e la porta in cui si metterà in ascolto il server. Inoltre setto la

struttura dati Presentation Context, la quale comprende sia l’Abstract Syntax che la

Transfer Syntax. I dati di configurazione li ricavo dal file di settings AqrateSettings.

Figura 3.9: File con i dati di configurazione.

Con il metodo void start() se i parametri d’associazione sono configurati corretta-

mente e se un PACS server è disponibile apro un nuovo socket [g] e cerco di connettere il

client aprendo quindi una nuova associazione. Dopo aver aperto una nuova associazione

con il server, l’handler del client può gestire i seguenti eventi:

• Dimse Timeout ;

• Errore di rete;

• Aborto dell’associazione da parte del server;

• Risposta di associazione avvenuta con successo;

• Risposta di associazione rifiutata;


• Risposta di rilascio dell’associazione;

• Risposta di operazione effettuata con successo da parte del server.

Con il metodo void stop() blocco l’associazione con il server e chiudo il socket del

client.

3.4.2 Componente server

Figura 3.10: DC2 : Diagramma delle classi della componente server

Per la componente server ho implementato la classe Server, la quale contiene tre

fondamentali metodi, oltre al costruttore. Nel costruttore creo un’istanza della classe

ServerHandler, la quale mi rappresenta un nuovo handler che mi gestisce tutti gli eventi

associati al server. Con il metodo void init(...) creo e configuro i parametri d’associa-

zione. Imposto il nome dell’Application Entity Client e dell’Application Entity Server,

l’indirizzo IP e la porta in cui si metterà in ascolto il server. Inoltre setto la struttura


dati Presentation Context, la quale comprende sia l’Abstract Syntax che la Transfer

Syntax. I dati di configurazione li ricavo dal file di settings AqrateSettings (vedi figura

3.9). Con il metodo void start() apro un nuovo socket e metto in ascolto il server per

qualsiasi richiesta del client. Dopo aver aperto una nuova associazione con il client,

l’handler del server può gestire i seguenti eventi:

• Dimse Timeout;

• Errore di rete;

• Aborto dell’associazione da parte del client;

• Richiesta di associazione;

• Richiesta di rilascio dell’associazione;

• Richiesta di effettuare una DIMSE.

Con il metodo void stop() blocco l’associazione con il client e chiudo il socket del

server.

3.4.3 Interfaccia grafica del server

Figura 3.11: Screenshot[g] della prima finestra


La prima finestra dell’interfaccia grafica della componente server è composta da

un’area di testo, nella quale vengono riportati gli eventi e le operazioni effettuate da

parte del server, da un bottone che premuto mette in ascolto o meno il socket del server

e da un altro bottone che serve per configurare tutti i parametri. Se si preme quest’ul-

timo appare la sottostante finestra.

Figura 3.12: Screenshot della finestra nella quale si configurano i parametri generali

In questa finestra si possono configurare il nome dell’Application Entity del server, il

numero della porta della rete TCP/IP, l’indirizzo IP e la cartella di destinazione per un

eventuale salvataggio di un file DICOM. Con il bottone Advanced si possono abilitare

o disabilitare i vari parametri di configurazione del Presentation Context.


Figura 3.13: Screenshot della finestra nella quale si configurano i parametri di AbstractSyntax

Figura 3.14: Screenshot della finestra nella quale si configurano i parametri di TransferSyntax


3.5 Verifica e validazione

3.5.1 Metodi di verifica utilizzati

3.5.1.1 Test

L’analisi dinamica è una forma di analisi che richiede l’esecuzione del codice e viene

utilizzata sia per la verifica che per la validazione del software. Questo tipo di analisi

viene effetuato tramite prove, dette test, su singole unità, su unità integrate tra loro o

sull’intero sistema. Durante l’attività di stage sono state effettuati due tipi di test:

Test di sistema: vengono applicati al sistema software completo e integrato. L’obiet-

tivo di un test di sistema è quello di verificare che il sistema aderisca a tutti i

requisiti specificati. Principalmente questo tipo di test sono test funzionali, ovve-

ro vengono controllate le differenze tra il sistema e i requisiti funzionali e i test

case vengono presi dai casi d’uso. Con i test di sistema si controllano quindi le

differenze tra i casi d’uso e il comportamento osservato;

Test di unità: vengono applicati ai singoli moduli o componenti software e mirano

a verificare la presenza di malfunzionamenti, errori e difetti. Il piano di test di

unità, ovvero la batteria dei test da eseguire, può essere pianificato solamente al

termine della progettazione di dettaglio del sistema. I test di unità che saranno

eseguiti mireranno ad avere sia copertura statement (eseguire almeno una volta

tutte le righe di comando del software) sia copertura branch (eseguire ogni ramo

della logica del flusso di controllo almeno una volta). I test di unità si dividono

in:

Test funzionali (Black Box): tecnica fondata sull’analisi dell’output generato

dal sistema in risposta a specifici input senza preoccuparsi del codice. Una

strategia per la definizione dei casi di test è basata sulla suddivisione degli

input in classi di equivalenza. Se l’input valido è un range si creano tre classi

di equivalenza corrispondenti ai valori sotto, sopra e dentro al range. Se

invece l’input valido è un insieme discreto di valori allora si creano due classi

di equivalenza corrispondenti ai valori dentro e fuori all’insieme. Si intende


che il comportamento del sistema sia equivalente per input appartenenti alla

stessa classe di equivalenza;

Test strutturali (White Box): tecnica fondata sulla individuazione di specifici

input definiti sulla conoscenza della struttura del software ed in particola-

re del codice ed analisi dell’output. Il criterio di copertura è che ciascuna

istruzione e ramo del flusso siano eseguiti almeno una volta.

3.5.1.2 Metriche

Una metrica è lo standard per la misura di alcune proprietà del software e viene ge-

neralmente utilizzata per stimare la qualità del software stesso. Le metriche prese in

considerazione durante l’attività di stage si dividono in metriche dimensionali e di com-

plessità.

Metriche dimensionali

Linee di codice sorgente: SLOC (Source Line of Code): misurazione della dimen-

sione del software. Tale metrica si basa sul numero di codice sorgente scritte.

Percentuale di commenti: percentuale delle linee di commento rispetto a tutte le li-

nee di codice. É usata per valutare la comprensibilità, il riuso e la manutenzione.

Il CP ideale è di circa il 30%.

Metriche di complessità

Complessità Ciclomatica: rappresenta il numero di test necessari per testare il co-

dice in modo completo. La complessità ciclomatica viene usata per valutare la

complessità di un algoritmo di un metodo e si basa sulla struttura del grafo che

lo rappresenta. In un grafo G fortemente connesso, il numero ciclomatico v(G)

è uguale al numero di percorsi linearmente indipendenti. Se sono presenti mol-

te espressioni booleane ci saranno tante scelte che generano percorsi multipli, ad


ognuno dei quali è associato un caso di test; minore è il valore della complessità

ciclomatica e minore è la difficoltà di esecuzione dei test.

3.5.2 Descrizione dei test e delle misurazioni effettuati

3.5.2.1 Test di unità

Ogni modulo, una volta ultimato, è stato mantenuto in Alpha-test per alcune ore. La

strategia si è rivelata molto utile, vista la natura del progetto: le sezioni da sviluppa-

re non prevedevano algoritmi complessi o interazioni molto fitte fra componenti. La

maggior parte del lavoro di test è consistita nel verificare che le funzionalità sviluppate

rispondessero correttamente con input volutamente errati. In sintesi, è stato necessario

verificare che il sistema di validazione dei dati funzionasse. La scelta è stata effettuata

dall’azienda, in quanto tale metodo viene utilizzato correntemente per tutte le altre

implementazioni che vengono effettuate in azienda.

3.5.2.2 Test di sistema

Vengono qui di seguito elencati i requisiti obbligatori, definiti nel documento Analisi dei

requisiti, che verranno testati tramite test di sistema. Per ognuno di tali requisiti verrà

data una descrizione di cosa dovrà fare il test e il grado del suo soddisfacimento.

Server

Descrizione: sviluppare un PACS server;

Soddisfacimento: totale.

Client

Descrizione: sviluppare un PACS client;


C-Echo

Descrizione: rispondere al DICOM PING, cioè gestire la C-Echo;



C-Store

Descrizione: Memorizzare una IOD (Information Object Definition) di tipo CR (Com-

puted Radiology), cioè gestire la C-Store;


3.5.2.3 Risultati delle misurazioni

Utilizzando la funzionalità Code Metrics di Visual Studio 2010 si sono potute calcolare

le seguenti misurazioni:

• numero di SLOC;

• percentuale di commenti;

• complessità ciclomatica.

Nella tabella 3.4 sono illustrati i risultati che si sono ottenuti per ogni componente

in merito alle due misurazioni prese in esame.

Componente SLOC CP CCCLIENT 91 27% 15SERVER 184 12% 25

INTERFACCIA GRAFICA 247 24% 89

Tabella 3.4: Risultati delle misurazioni

Capitolo 4

Valutazione retrospettiva

4.1 Analisi personale dell’attività di stage

Attraverso l’attività di stage ho potuto osservare come si differenzi il modus operandi

accademico da quello professionale; seppur nel settore informatico si avvicinino molto

di più rispetto ad altri ambiti, si nota un profondo distacco tra il mondo universitario

e il mondo del lavoro. All’interno dell’azienda è richiesto, oltre che la funzionalità e la

documentazione dell’applicativo, una presentazione che lo renda appetibile a possibili

utenti compratori mentre in ambito universitario la logica e il percorso concettuale che

portano alla creazione del prodotto sono fattore d’interesse primario.

A mio parere l’attività di stage resta un punto fondamentale del corso di laurea perchè

permette di ampliare le conoscenze teoriche e pratiche già acquisite e di entrare in con-

tatto con le dinamiche lavorative tese soprattutto alla soddisfazione del cliente finale.

Ho inoltre potuto notare che nel lavoro vengono richieste conoscenze specifiche ed ap-

profondite degli strumenti utilizzati.

Questo aspetto non viene affrontato nel percorso di studi universitari, a causa del poco

tempo a disposizione e per la continua evoluzione che caratterizza il mondo dell’informa-

tica. Nonostante ciò, penso che l’istruzione universitaria abbia un approccio proiettato

al futuro e come tale, il suo compito sia quello di fornire i concetti che stanno alla base

delle tecnologie più diffuse, senza focalizzarsi troppo su un caso specifico.

54

CAPITOLO 4. VALUTAZIONE RETROSPETTIVA 55

4.2 Conoscenze pregresse ed acquisite

La distanza tra le conoscenze da me possedute ad inizio stage e quelle richieste è risul-

tata ampia, ma questo era noto e previsto ben prima dell’avvio delle attività. Il tutor

aziendale che mi ha seguito conosce la realtà universitaria e sa quali sono le conoscen-

ze medie di uno studente del terzo anno del corso di informatica, quindi proprio per

questo è stata pianificata fin da subito un’attività di formazione, la quale è riuscita a

sopperire con successo alle mie lacune iniziali. Ritengo comunque che la presenza di

lacune nella formazione di uno studente universitario sia inevitabile poichè l’informati-

ca è una disciplina vasta, complessa e sempre in evoluzione; è normale che gran parte

della formazione di un informatico avvenga sul campo, mettendo in pratica quello che

ha imparato e scoprendo cose nuove.

Nell’ambito del progetto, di grande utilità sono state le competenze di Reti e Sicurez-

za e di Ingegneria del Software che ho acquisito durante gli studi. Grazie alle nozioni

apprese nel corso di Reti e Sicurezza, ho potuto ridurre la difficoltà nello studio dello

standard DICOM poiché le conoscenze in mio possesso mi hanno permesso di com-

prendere rapidamente i punti fondamentali. L’esame di Ingegneria del Software è stato

importantissimo, in quanto, pur essendo un corso di laurea, rispecchia al meglio le ca-

ratteristiche di un’attività di sviluppo software svolta all’interno di una realtà aziendale.

Il periodo impiegato per concludere il mio stage in Aqrate, si è rilevato al di sopra delle

aspettative per quanto riguarda le conoscenze apprese. Lo stage mi ha permesso di:

• esaminare il modo di lavorare all’interno di Aqrate;

• studiare lo standard DICOM su documenti ufficiali, aspetto da non sottovalutare

considerando la complessità con cui concetti semplici vengono esplicati;

• aumentare la mia formazione nelle tecnologie Microsoft;

• raffinare le conoscenze che avevo del linguaggio di programmazione C#;

• scegliere autonomamente gli aspetti più significativi da monitorare;

• implementare un’applicazione, valutando problematiche e punti di forza.


4.3 Consuntivo

Lo stage è terminato positivamente in quanto tutti gli obiettivi prefissati sono stati

raggiunti secondo i tempi e le modalità stabilite. Si può affermare ciò, constatando che:

• tutti i requisiti, obbligatori, desiderabili ed opzionali, sono stati sviluppati e

portati a termine;

• la scelta del ciclo di vita si è dimostrata adatta al tipo di progetto da realizzare;

• si dispone di una versione demo di un PACS;

• l’azienda, in particolare il tutor, si sono dimostrati molto soddisfatti.

L’attività di stage nel suo complesso è stata portata a termine nei tempi prestabiliti,

a fronte comunque di alcune discrepanze rispetto a quanto inizialmente perventivato. In

particolare le prime tre settimane di stage si sono svolte senza alcun tipo di problema,

grazie ad una attività in prevalenza dedicata allo studio del dominio applicativo e delle

tecnologie/strumenti da utilizzare. Dalla quarta settimana fino alla sesta settimana

era stato pianificato lo sviluppo delle classi C-Echo e C-Store ma grazie alla facilità

di comprensione della libreria ClearCanvas ne sono state utilizzate solo due. Il tempo

risparmiato della sesta settimana è stato riusato per implementare una componente

grafica, sviluppata tramite la libreria WPF, per il PACS Server. Le settimane successive

ciò che è stato svolto ha seguito le linee guida descritte nel piano di lavoro.


Figura 4.1: Diagramma di Gantt relativo al piano di lavoro a consuntivo.


4.4 L’esperienza in Aqrate S.r.l.

Trattandosi della mia prima esperienza lavorativa nel campo informatico, non ho ter-

mini di paragone per valutare Aqrate. Ciò nonostante, la mia permanenza all’interno

dell’azienda è da ritenersi molto positiva. É possibile sintetizzare tutto ciò che riguarda

il mio periodo di stage in Aqrate nei punti seguenti:

• mi è stata data la possibilità di valutare criticamente l’attuale situazione aziendale;

• mi è stata fatta una panoramica del mercato nel settore ICT;

• ho potuto capire quanto sia difficile creare e mantenere un rapporto proficuo e

duraturo con i clienti.

Grazie al mio tutor, Nicola Cinel, ho avuto fin da subito il suo appoggio, la sua dispo-

nibilità, la possibilità di organizzare il mio lavoro e di accedere a tutte le informazioni

necessarie per proseguire lo stage, che ha contribuito tantissimo per la realizzazione

del lavoro pianificato. Questo mi ha permesso di lavorare velocemente, riuscendo a

completare lo stage nei tempi previsti e in maniera totalmente positiva. Il progetto

in particolare mi ha permesso di scoprire e di utilizzare con successo tutta una serie

di tecnologie che non conoscevo, aumentando notevolmente la mia esperienza e il mio

bagaglio di conoscenza. Tutto questo è stato un banco di prova importante che mi ha

permesso di unire le mie capacità alle nozioni acquisite in questi anni di studio per la

risoluzione di un problema completamente nuovo. L’ambiente di lavoro in cui mi sono

trovato ha contribuito molto alla realizzazione di questo progetto. Oltre agli impiegati

del azienda, sempre amichevoli e disponibili per diversi confronti, ho potuto conoscere

altri stagisti con cui ho scambiato opinioni. L’esperienza è stata completamente posi-

tiva e mi ha permesso di crescere sia professionalmente che come persona, ed avere più

fiducia nelle proprie forze e capacità.

Glossario

A

Accoppiamento: proprietà esterna del software che indica quanto le componenti di-

pendono strettamente l’una dall’altra. Si punterà a ottenere un basso accop-

piamento poiché, in questo caso, eventuali modifiche a una componente avranno

poche ripercussioni sulle altre con cui è instaurata una relazione di dipendenza.

AJAX: è una tecnica di sviluppo per la realizzazione di applicazioni web interattive.

Lo sviluppo di applicazioni HTML con AJAX si basa su uno scambio di dati in

background fra web browser e server, che consente l’aggiornamento dinamico di

una pagina web senza esplicito ricaricamento da parte dell’utente.

API: è un’interfaccia che abilita e/o facilita l’iterazione tra software differenti allo

stesso modo in cui la user interface facilita la comunicazione tra umani e computer.

C

Complessità ciclomatica: è una metrica che serve per definire il numero di cammini

linearmente indipendenti di una sezione di codice sorgente.

D

DBMS: è un sistema software progettato per consentire la creazione e manipolazione

efficiente di database (ovvero di collezioni di dati strutturati) solitamente da parte

di più utenti.

59

GLOSSARIO 60

DirectX: è una collezione di API[g] per gestire attività legate alla multimedialità,

soprattutto game programming e video, sulle piattaforme Microsoft.

F

Framework: struttura di supporto su cui un software può essere organizzato e pro-

gettato. Generalmente presenta delle librerie utilizzabili in uno o più linguaggi di

programmazione assieme a degli strumenti per lo sviluppo del software.

H

Handler: è un gestore di eventi che cerca di intercettare gli eventi che possono accadere

su un determinato oggetto.

I

Intranet: è una rete locale (LAN), o un raggruppamento di reti locali, usata all’interno

di una organizzazione per facilitare la comunicazione e l’accesso all’informazione,

che può essere ad accesso ristretto.

J

JPEG: è l’acronimo di Joint Photographic Experts Group, un comitato ISO/CCITT

che ha definito il primo standard internazionale di compressione per immagini a

tono continuo, sia a livelli di grigio che a colori. È un formato aperto e ad imple-

mentazione gratuita. JPEG specifica solamente come una immagine può essere

trasformata in uno stream di byte, ma non come questo può essere incapsulato in

supporti di memorizzazione.

JPEG2000: è uno standard di compressione immagini basato sulla trasformazione wa-

velet discreta. Così come il celebre formato JPEG, anche JPEG 2000 è stato crea-

to dal Joint Photographic Experts Group, ed è definito dallo standard ISO/IEC

15444-1.

GLOSSARIO 61

N

NAS: è un dispositivo collegato ad una rete di computer la cui funzione è quella di

condividere tra gli utenti della rete una Area di storage(vedi SAN[g]).

O

Open source: indica software i cui autori (più precisamente i detentori dei diritti) ne

permettono, anzi ne favoriscono il libero studio e l’apporto di modifiche da parte

di altri programmatori indipendenti. Questo è realizzato mediante l’applicazione

di apposite licenze d’uso. La collaborazione di più parti permette al prodotto

finale di raggiungere una complessità maggiore di quanto potrebbe ottenere un

singolo gruppo di lavoro. L’open source ha tratto grande beneficio da Internet

perché esso permette a programmatori geograficamente distanti di coordinarsi e

lavorare allo stesso progetto.

P

PDF: formato di file basato su un linguaggio di descrizione di pagina sviluppato da

Adobe Systems nel 1993 per rappresentare documenti in modo indipendente dal-

l’hardware e dal software utilizzati per generarli o per visualizzarli. Un file

PDF può descrivere documenti che contengono testo e/o immagini in qualsiasi

risoluzione. È un formato aperto.

R

RAID: è un sistema informatico che usa un gruppo di dischi rigidi per condividere o

replicare le informazioni. I benefici del RAID sono di aumentare l’integrità dei

dati, la tolleranza ai guasti e le prestazioni, rispetto all’uso di un disco singolo.

RAM: è una tipologia di memoria informatica caratterizzata dal permettere l’accesso

diretto a qualunque indirizzo di memoria con lo stesso tempo di accesso.

GLOSSARIO 62

S

SAN: è una rete o parte di una rete ad alta velocità (generalmente Gigabit/sec) co-

stituita esclusivamente da dispositivi di memorizzazione di massa, in alcuni casi

anche di tipologie e tecnologie differenti. Il suo scopo è quello di rendere tali risorse

di immagazzinamento (storage) disponibili per qualsiasi computer (generalmente

application e DDBB server) connesso ad essa.

Screenshot: è il risultato della cattura istantanea di ciò che è visualizzato sul monitor

del computer.

Shareware: è una tipologia di licenza software molto popolare sin dai primi anni no-

vanta. Il software sotto tale licenza può essere liberamente ridistribuito, e può

essere utilizzato per un periodo di tempo di prova variabile. Scaduti questi termi-

ni, per continuare ad utilizzare il software è necessario registrarlo presso la casa

produttrice, pagandone l’importo. All’avvio dell’applicazione shareware general-

mente una finestra informa l’utente su come effettuare la registrazione e sulle

condizioni di utilizzo.

Socket: si indica un’astrazione software progettata per poter utilizzare delle API[g]

standard e condivise per la trasmissione e la ricezione di dati attraverso una rete

oppure come meccanismo di IPC. È il punto in cui il codice applicativo di un

processo accede al canale di comunicazione per mezzo di una porta, ottenendo

una comunicazione tra processi che lavorano su due macchine fisicamente separate.

Dal punto di vista di un programmatore un socket è un particolare oggetto sul

quale leggere e scrivere i dati da trasmettere o ricevere.

T

Thread: è un singolo flusso sequenziale di istruzioni all’interno di un programma.

GLOSSARIO 63

X

XML: è un linguaggio di marcatura che associa alcune proprietà dell’XML con le ca-

ratteristiche dell’HTML, un file XHTML è, sostanzialmente, una pagina HTML

scritta in conformità con lo standard XML. Il linguaggio prevede un uso più re-

strittivo dei tag HTML sia in termini di validità che in termini di sintassi per

descrivere solo la struttura logica della pagina, mentre il layout e la resa grafica

sono imposti dai fogli di stile a cascata (Cascading Style Sheets, CSS).

Bibliografia

Questi sono stati i miei riferimetni bibliografici:

[1] Aqrate S.r.l., sito web aziendale, http://www.aqrate.net/

[2] Sito ufficiale dello Standard DICOM, http://medical.nema.org

[3] Sito della libreria JDT, http://wiki.trispark.com/display/jdt/

[4] Sito della libreria dcm4che, http://sourceforge.net/projects/dcm4che/

[5] Sito della libreria Dicom#, http://sourceforge.net/projects/dicom-cs/

[6] Sito della libreria ClearCanvas, http://www.clearcanvas.ca/

[7] .NET Framework, http://en.wikipedia.org/wiki/.NET_Framework

[8] LINQ, http://msdn.microsoft.com/it-it/library/bb386976.aspx

[9] WPF, http://msdn.microsoft.com/en-us/library/ms754130.aspx

64

http://www.aqrate.net/

http://medical.nema.org




http://www.clearcanvas.ca/

http://en.wikipedia.org/wiki/.NET_Framework

http://msdn.microsoft.com/it-it/library/bb386976.aspx

http://msdn.microsoft.com/en-us/library/ms754130.aspx

Ringraziamenti

Ringrazio il prof. Tullio Vardanega per la disponibilità nel seguire lo sviluppo del pro-

getto di stage e per i consigli che mi hanno agevolato a scrivere il presente documento.

Ringrazio inoltre Mirco Girotto e Nicola Cinel, tutor aziendale, che hanno seguito co-

stantemente il mio lavoro e con i quali sono stato a stretto contatto durante lo stage.

Ringrazio infine tutti i dipendenti di Aqrate che hanno reso i miei due mesi in azienda

piacevoli e stimolanti.

65

Tesi PACS

Documents

Transcript of Tesi PACS