U
VERS
TÀ DEG
STUD
D
ADVA

Fa oltà diIngegneria

Corso di Laurea Magistrale in Ingegneria Informati a

Un framework per lo sviluppo di

sistemi informativi di diagnosti a in

ambiente IHE

Relatore: prof. FerrariCarlo

Correlatore: Dott. Ce hinDiego

Correlatore: Paolo Mos a

Laureando: PivaAlberto

Introduzione 1

I I due RIS esistenti 3

1 Sistemi informativi radiologi i 5

1.1 L'informati amedi a . . . 5

1.2 Imaging diagnosti o: Radiologia eMedi inaNu leare . . . 7

1.2.1 Radiologia . . . 7

1.2.2 Medi inaNu leare . . . 9

1.3 SistemiRISe PACS . . . 10

1.4 Organizzazionied enti . . . 12

1.4.1 RSNA . . . 12

1.4.2 IHE . . . 13

1.5 Standarde Linee guide . . . 14

1.5.1 HL7 . . . 14

1.5.2 DICOM . . . 16

1.5.3 Te hni al frameworkIHE . . . 17

1.6 Con lusioni . . . 20

2 I due sistemi MARiS eMN1 23 2.1 MARiSe MN1 . . . 23

2.1.1 EvoluzionediMARiS . . . 24

2.1.2 La bifor azione . . . 26

2.2.1 S heduled Workow . . . 28

2.2.2 PatientInformation Re on iliation . . . 30

2.2.3 Reporting Workow . . . 32

2.2.4 NM Image. . . 34

2.2.5 ITI-ATNA. . . 35

2.3 FunzionalitàdiMARiSeMN1 . . . 36

2.4 Caratteristi he diMARiSe MN1 . . . 37

2.4.1 La s eltaOpen Sour e . . . 38

2.4.2 Questioni legali . . . 38

2.4.3 Fattorisanitari- lini i . . . 41

2.4.4 Motivazioni ommer iali . . . 41

II Il nuovo framework 43 3 Analisi eprogettazione 45 3.1 L'analisi deisistemi. . . 45

3.1.1 Denizione delproblema . . . 46

3.1.2 Fattibilità . . . 47 3.1.3 Costi e bene i . . . 47 3.1.4 Dominio appli ativo . . . 47 3.1.5 Requisiti. . . 47 3.2 Le basi didati . . . 48 3.2.1 Motori dimemorizzazione . . . 48 3.2.2 Vin oli relazionali . . . 49 3.2.3 Attributi . . . 49

3.2.4 Struttura delletabellediautenti azione . . . 50

3.3 Il odi esorgente . . . 50

3.4 Con lusioni dell'analisi . . . 51

3.5 Valutazione diframework esistenti . . . 53

3.5.1 Zend Framwork . . . 54

3.5.2 Symfony . . . 55

3.6 Progettazione . . . 56 3.7 Con lusioni . . . 58 4 Implementazione 59 4.1 Database . . . 59 4.1.1 Integrazione e ottimizzazione . . . 59 4.2 L'ar hitetturasoftware . . . 60 4.2.1 Prototipo . . . 64 4.3 Componenti . . . 64 4.3.1 Core eAppli ation . . . 67 4.3.2 Registry . . . 67 4.3.3 Dispat her. . . 68 4.3.4 Controller . . . 68 4.3.5 A tionFinder . . . 71 4.3.6 ViewRenderData . . . 72 4.3.7 View . . . 72 4.3.8 Altro. . . 73 4.4 Flussodiese uzione . . . 73 4.5 Con lusioni . . . 75

5 Analisi del nuovo sistema 77 5.1 Materialie metodi . . . 77 5.1.1 Piattaforma . . . 77 5.1.2 Designpattern . . . 78 5.2 Collaudo . . . 80 5.3 Metri he di ollaudo . . . 81 5.3.1 Retro ompatibilità . . . 81 5.3.2 Prestazioni . . . 82

5.4 Strumentidi ollaudodelleprestazioni . . . 82

5.4.1 Modalitàdi ollaudo . . . 84

5.5 Risultati . . . 85

5.5.1 Retro ompatibilità . . . 85

6 Con lusioni 91 6.1 Considerazioni . . . 91 6.2 Sviluppi futuri . . . 92 6.3 L'esperienzapersonale . . . 93 A A ronimi 95 B Risultati ben hmark 99 B.1 MARiS . . . 99 B.1.1 Apa he JMeter . . . 99 B.1.2 Apa he Ben hmark . . . 100 B.2 MN1 . . . 101 B.2.1 Apa he JMeter . . . 101 B.2.2 Apa he Ben hmark . . . 101 B.3 Nuovo framework . . . 102 B.3.1 Apa he JMeter . . . 102 B.3.2 Apa he Ben hmark . . . 102 B.4 Zend . . . 103 B.4.1 Apa he JMeter . . . 103 B.4.2 Apa he Ben hmark . . . 103 B.5 Symfony . . . 104 B.5.1 Apa he JMeter . . . 104 B.5.2 Apa he Ben hmark . . . 104 B.6 CakePHP . . . 105 B.6.1 Apa he JMeter . . . 105 B.6.2 Apa he Ben hmark . . . 105

Elen o delle tabelle 106

Elen o delle gure 108

Bibliograa 110

L'informati aèentrataprepotentementenellaSanitàormaidapiùdi20anni,ma

l'informati anellaSanitànonèsempli ementeil omputerinmedi ina.

L'Infor-mati aMedi aèlas ienza hesio upadellagestioneinSanitàdell'informazione

e deiprogrammibasatisu al olatore

Questa s ienzaè ormaiparteintegrantedimolti pro essie pro edurean he

delledis ipline diRadiologia e Medi ina Nu leare, appartenenti aldominio più

generaledella diagnosti aperimmagini.

In parti olare, inquestebran he sonoda tempoaermatisistemi noti ome

RIS,ovveroRadiologyInformationSistem,SistemaInformativoRadiologi o. Un

RIS è un sistemainformati o usato in Radiologia per lagestione del usso dei

datiinerenti ipazienti trattati.

A partire da metà anni novanta, presso il Dipartimento di S ienze Medi o

Diagnosti hee terapiespe iali dell'UniversitàdiPadova,sezionidiRadiologiae

Medi ina Nu leare, sono stati sviluppati internamente sistemi informati i

ade-guatiarisponderealleesigenzespe i he interneerealizzatise ondostandarde

lineeguidainternazionali,noadottenereduesisteminoti omeMARiSeMN1,

quest'ultimo fruttodella s issionediMARiS, ormaiqual he anno fa.

Col tempo, la manutenzione e lo sviluppo dei due sistemi, simili ma non

ugualierealizzatise ondologi hedisempli itàeimmediatezzamanondirapida

ollaudabilità, èdiventatomeno sostenibile.

Inquestolavoroditesisonostatianalizzatiiduesistemiinformativiper

rea-lizzareunnuovoframework hefavorissel'integrazioneeriprogettazionegraduale

degli stessi.

dis i-organizzazioni inerentiagli standard internazionali usati inquestisistemi.

Nel apitolo 2 sono des ritti idue parti olari RIS in esame, la loro storia e

aratteristi he prin ipalie lemotivazionialla basedell'integrazione.

Nel apitolo3sonoanalizzatilebasididatieil odi esorgentedeidueRISin

esame, e valutati possibili framework esistenti per una loro eventuale adozione,

e lemotivazioni he hanno ondotto as artarli.

Nel apitolo4èillustratoilnuovoframeworkrealizzato,apartiredallafasedi

progettazione,passandoperlabasedidati,i omponentieilussodiese uzione.

Nel apitolo 5è esposta l'analisi delnuovo framework omparativamenteai

sistemi RISpre edentie anotiframeworkgiàdisponibili,illustrandostrumenti,

metodologiee te ni he usateperl'analisi.

Nel apitolonale sonotrattele on lusioni ir a ilpresentelavoroditesi,i

Sistemi informativi radiologi i

Introduzione

L'informati a è entrata prepotentemente nella Sanità ormai da più di 20

an-ni, e ha ormaiassunto un'indis ussa importanza strategi a. La progettazionee

implementazionedinuovipro essisanitari henon onsiderinolas ienza

dell'in-formazione omepropriaparte fondantenonha piùpossibilitàdirealizzazione.

Tuttavia l'informati a nella Sanità non è sempli ementeil omputer in

me-di ina, ma ra hiude una moltitudine di questioni e problemati he insite nel

parti olaredominio diappli azione,quello sanitarioappunto.

Questo apitolointrodu el'informati aneldominiomedi oingenerale,

quin-di entra nel dettaglio delle dis ipline di Radiologia e Medi ina Nu leare, degli

entiinternazionali edegli gli standard usati nelsettore.

1.1 L'informati a medi a

L'informati anellasanitàenellari er amedi a ostituis eunarivoluzione

epo- alerealizzatasinegliultimi20anni. InSanità,lete nologieinformati he,noa

po hiannifadestinatesoloall'automazionedeipro essiamministrativi,vengono

semprepiùutilizzate per:

ˆ migliorare l'assistenza aimalati roni i

ˆ fa ilitare laprevenzionedimalattie

ˆ aumentare l'e a ia e l'e ienza del lavoro quotidiano degli operatori

sanitari

Tutte questeattivitàsonolegateinmodo direttoalpro esso di ura, per iò

inSanitàl'informati astadiventandoan heunostrumento lini o,einMedi ina

si ostituis e anaturalestrumento diri er a.

Le esigenzedella Sanità generalesonomoltepli i:

ˆ ontrollarelaspesaattraverso larazionalizzazione deipro essi

ˆ gestire idatidello spe i o pazienteinmodorazionale

ˆ estrarre informazioni lini he dalle enormi moli didati disponibili sul

pa-ziente

ˆ forniresupporto allade isione medi a

Posto hel'informati aè unodeglistrumenti he late nologia orealla

pra-ti a medi a, dallato medi o hiopera a livello lini o nei sistemi sanitari deve

saper sfruttare in modo e ienteed e a e la te nologia, mentre hi propone

soluzionite nologi he deve avere onos enzasigni ativadial unedelle

proble-mati hedellaSanitàdallatote nologi o. Ne onsegue heladistanzafrasapere

te nologi o esaperemedi o deve essereridotta.

L'informati amedi aèlas ienza hesio upadellagestioneinSanità

dell'in-formazioneedeiprogrammibasatisu al olatore, ioèl'appli azionedeiprin ipi

della Teoria dell'Informazione alla onos enza medi a on l'obiettivo difornire

un supporto alla risoluzione delleproblemati he della S ienza Medi a attinenti

alla diagnosi, alla terapiaed alla prevenzione. Lo s opoultimo dell'informati a

medi a è ontribuire (direttamente o indirettamente) a migliorare lasalute del

paziente; essanon è sempli ementeil omputer inmedi ina.

ˆ sistemiperlagestione deidati lini i (in lude onservazione deidati

on-sistente, e ientee si ura)

ˆ sistemi di trasmissione/ omuni azione/esportazione di dati lini i basati

su metodologieinformati he etele omuni azioni

ˆ sistemidisupporto allade isione lini a

1.2 Imaging diagnosti o: Radiologia e Medi ina

Nu- leare

Radiologia e Medi ina nu leare sono due dis ipline medi he fa enti parte del

dominiopiùgeneraledelladiagnosti aperimmagini. Coniterminidiimagingo

imagingbiomedi oodiagnosti aperimmagini isiriferis ealgeneri opro esso

attraverso il quale è possibile esaminare un'area di un organismo non visibile

dall'esterno.

Le te ni he didiagnosti aperimmagini sononumerose, tra lealtresi

ri or-dano l'endos opia, l'e ograa, l'e odoppler, l'e ograa on mezzo di ontrasto,

la radiograa, laspettros opia, la tomograa omputerizzata, l'imaging a

riso-nanza magneti a, la uoros opia, l'angiograa, la mammograa, la tomograa

ad emissione di positroni la tomograa ad emissione di fotone singolo, non hé

levarie ombinazionitraqueste, omeRM-PET 1

,piuttosto hee o-TC 2

oaltro

an ora. Al une di queste te ni he onsentono sia di eettuare diagnosi, sia di

eettuare terapie.

1.2.1 Radiologia

La radiologia è la s ienza he si o upa della produzione di raggi X e del loro

utilizzo, diagnosti are e trattare le malattie attraverso l'utilizzodelle immagini

[g. 1.2℄ (vere, ri ostruite o virtuali) dell'interno del orpo umano. La bran a

della medi ina he sio upadellaproduzione e dellalettura diimmagini

radio-gra he è detta radiodiagnosti a. La bran a della medi ina he si o upadella

produzione diraggiX as opoterapeuti o èdetta radioterapia.

1

RisonanzaMagneti a-PositronEmissionTomography

Negli ultimi de enni, attraverso una sua bran a molto spe ialisti a, la

ra-diologiainterventisti a, essaprovvedealtrattamento diunospettro semprepiù

ampiodipatologievas olarienon. Laradiologiahasubitonegliultimi

inquan-ta anniuno sviluppo travolgenteinambitodiagnosti oe terapeuti o ed o upa

oggi un ruolo fondamentale ed impres indibile nella diagnosi e nel trattamento

della stragrandemaggioranzadellepatologie umane.

Figura1.2: Esempio diradiogrammadeltora e

1.2.2 Medi ina Nu leare

LaMedi inaNu leareèlaspe ialità heutilizzasorgentiradioattivenonsigillate

perladiagnosieiltrattamento dial unepatologie. Nellepro edurediMedi ina

Nu leare, radionu lidi 3

sono ombinati onaltrielementiperformare omposti

himi i, oppuresono ombinati on esistenti omposti farma euti i performare

radiofarma i 4

.

Questi radiofarma i possiedono tropismo elettivo, ovverouna volta

sommi-nistrati al paziente, sono in grado di fo alizzarsi su spe i i organi o re ettori

ellulari. Questa loro proprietà onsente alla medi ina nu leare di

visualizza-re l'estensione delpro esso diuna malattianel orpo, basandosi sulla funzione

ellularee siologiapiuttosto he sui ambiamentisi inell'anatomiadei

tessu-ti. Inal une malattie glistudi di medi ina nu leare sonoingrado anti ipare la

diagnosi rispettoad altritest diagnosti i.

La dis iplina onsente an he il trattamento ditessuti malati, basandosi sul

metabolismo o sul legame di un parti olare ligando 5

, similarmente ad altre

aree della farma ologia. In futuro, la medi ina nu leare potrà an he fornire

un nuovo impulso al settore noto ome medi ina mole olare. Sonde spe i he

potranno essere sviluppateperpermettere lavisualizzazione, aratterizzazione,

e laquanti azionedipro essi biologi ialivello ellulare esub ellulare.

1.3 Sistemi RIS e PACS

IlRadiologyInformationSystem(RIS),ovveroSistemaInformativoRadiologi o,

è un sistemainformati o usato in Radiologia perla gestione del usso dei dati

inerenti ipazienti trattati.

LefunzionalitàdelRISsonomoltepli i,mahannolos opodigestireil

pro es-sodirefertazione, ioèquellaseriediazioniodeventi heportanodall'appro io

del paziente on la struttura all'espletamento del referto, oggetto dell'indagine

radiologi a.

Il pro esso di integrazione informati a di un dipartimento di Radiologia

nell'ambito dell'azienda ospedaliera orbita intorno al RIS, dal momento he

tipi amenteèil riferimento peril dialogo on:

ˆ Sistemigestionali ospedalieri

4

Un qualsiasi medi inale he, quando è pronto per l'uso, in lude uno o più radionu lidi

in orporatias oposanitario

5

ˆ Sistemigestionaliregionali

ˆ Modalitàdiagnosti he

ˆ Workstation divisualizzazione

An hesenell'otti aaziendaleè lassi ato omeunadelletanteappli azioni

( lient-server) da reparto, il RIS per ragioni di ordine stori o legate al grande

numerodiprestazioni dagestire hauna lungastoria alle spalle,

In Radiologia quindi il ruolo di un RIS è entrale, un siatto sistema

per-mette di individuare e di eliminare olli di bottiglia all'interno del pro esso di

refertazione, onsentedirendi ontare orrettamentele attivitàeettuate, è

au-silio indispensabile alla diagnosi graziealla gestione delleCartelle Radiologi he

informatizzate.

In genearle un RIS è in grado di omuni are on altri sistemi informati i

ospedalieri:

ˆ omuni azioni Health Level 7 (HL7) on un sistema informativo

ospeda-liero,o on un Centro Uni o di Prenotazione o on un ar hivio di referti

aziendale

ˆ omuni azione on isistemiregionali 6

ˆ omuni azioniDigitalImagingandCommuni ationsinMedi ine(DICOM)

on lediagnosti heo on unPi tureAr hivingand Comuni ationSystem

(PACS)

ˆ integrazioni on visualizzatoriDICOM

Nel prosieguodel apitolo sonoapprofonditi glistandard HL7 e DICOM.

PACSèun SistemadiAr hiviazioneeTrasmissionediImmagini. UnPACS

onsisteinunsistemahardwareesoftwarededi atoall'ar hiviazione,

trasmissio-ne, visualizzazione e stampa delleimmagini diagnosti he digitali. Le immagini

diagnosti he digitali[g. 1.3℄ sono visualizzate su spe iali monitor ad altissima

risoluzione di lientDICOM.

Una parte fondamentale ma non visibile dall'utente nale si o upa

del-l'interfa iamento on gli altri attori del usso radiologi o. In spe ial modo,

è fondamentale la sua integrazione on il sistema informati o radiologi o, he

rappresenta ilsoftwaregestionaledella Radiologia.

Figura1.3: Immagine PETinun visualizzatoremedi ale

1.4 Organizzazioni ed enti

1.4.1 RSNA

Fondata nel 1915, la Radiologi al So iety of North Ameri a, o RSNA, è una

so ietà diappartenenza professionalenordameri ana impegnata afavorire

l'e - ellenza nella uradelpazienteattraverso l'istruzioneelari er a. Piùdi48.000

professionistidell'imagingmedi osonomembridiRSNA,traradiologi,on ologi

diradiazione, si imedi ie s ienziati alleati.

RSNAospitalapiùgranderiunioneannualediradiologiadelmondo,

pubbli- a duerivistealtamenterispettatedivalutazionetraparieoreborsediri er a

e formazione pergiovaniri er atori.

ziati del settore sanitario programmi edu ativie materiali di altissima qualità,

permigliorare ostantementeil ontenutoeilvalorediquesteattivitàedu ative.

LaSo ietàsiproponedipromuoverelari er aintuttigliaspettidella

radio-logiaedelles ienze orrelate,ivi ompreselari er a lini adibasenella

promo-zione diun'assistenza sanitariadiqualità. La So ietà si proponedipromuovere

una piùstretta omunionetratuttiiradiologi e unamaggiore ooperazione tra

radiologi e membri dialtrebran he della medi inae gli operatori sanitari.

Il su esso della So ietà nel raggiungimento dei suoi obiettivi nel ampo

dell'istruzione e della ri er a è dovuto all'alto livello di professionalità dei suoi

membri e gli altri olleghi he generosamente ondividono le loro onos enze

s ienti hee apa itàamministrative.

1.4.2 IHE

Integrating the Health are Enterprise (IHE) rappresenta un'iniziativa

interna-zionale di produttori ed utenti a supporto dello sviluppo dell'integrazione tra

sistemiinformativisanitari.

L'iniziativa IHE, nata negli Stati Uniti nel 1998 ad opera di Radiologi a

So iety of North Ameri a (RSNA) e Health are Information and Management

SystemsSo iety(HIMSS),siproponedidenireinmaniera hiara omegli

stan-dardesistenti(inparti olareDICOMeHL7)dovevanoessereutilizzatidaidiversi

sistemi informativi per realizzare un'integrazione traloro, partendo dall'analisi

delreale usso dilavoro lini o.

Nelle strutture sanitarie esistono numerosi sistemi informativi distinti, he

gestis onoidati anagra i, lini i ediagnosti i delpaziente. Questisistemi

ne- essitano di ondividere informazioni, tuttavia, pur utilizzando proto olli

stan-dard di omuni azione, spesso non sono in grado di s ambiarsi e ientemente

dati, in quanto gli standard stessi possono presentare onitti interpretativi e

una s eltadiopzionitroppo ampia.

IHE ha stabilito un forum, on omitati volontari di operatori dell'ambito

sanitario, esperti HIT e tutte le parti interessate in diverse lini he e domini

operativi,perraggiungereil onsensosusoluzionistandardriguardantigliaspetti

mentazionideiproliIHE,in lusiregolarieventiditest hiamatiConne tathon.

Dopo he un omitato ha determinato he un prolo ha superato un adeguato

numero ditest edè stato appli ato on su esso inunambientesanitarioreale,

viene in orporatonell'appropriato Te hni al Framework IHE. Il Te hni al F

ra-mework è quindi una risorsa uni a per lo sviluppo e l'utilizzo di sistemi HIT:

un insieme di soluzioni testate e basate su standard per far fronte alle

omu-ni esigenze di interoperabilità e supporto per l'utilizzo si uro degli Ele troni

Health are Re ord (EHR).

Gli a quirenti possono spe i are la ri hiesta di onformità on gli

appro-priati proli IHE ome requisito per una proposta di a quisto. I rivenditori

he hanno implementato on su esso i proli IHE nei loro prodotti, possono

pubbli areledi hiarazionidi onformità( hiamateIHEIntegrationStatements)

nell'IHE Produ tRegistry[1℄.

1.5 Standard e Linee guide

1.5.1 HL7

Per poter s ambiare informazioni tra omponenti diverse di un Sistema

Infor-mativoSanitario(SIS),otraappli atividiversi,otrasoftwarediversidi artella

lini a elettroni a, o tra strumentazione e al olatori, e quindi per favorire la

ollaborazione trasistemi,sideveutilizzare unlinguaggio standard.

Fondatanel1987, HL7 èun'organizzazionenon-prot, dedi ataa fornireun

quadro globalee dei relativistandard perlos ambio, l'integrazione,la

ondivi-sione e il re uperodelleinformazioni sanitarieelettroni he perilsupportodella

prati a lini ae lagestione,erogazionee valutazione deiservizisanitari.

Lo standard ISO/HL7 27931:2009 [2℄, in rapida diusione an he in Italia,

è on epito perlo s ambio di informazioni lini he tra i diversi possibili attori

di un SIS he usano piattaforme hardware e software diverse. HL7 non è un

linguaggio diprogrammazione, ma è un insiemediregole per la omuni azione

da appli azionead appli azione. Il numero7 siriferis einfattiproprioallivello

appli azione dello standardISOperiproto olli di omuni azione.

ˆ AdmsissionDimissionTransfer(ADT)

ˆ Finanziari

ˆ Reportdidati

ˆ A essoa ampi diun database

ˆ Controllo

ˆ Ordini

ˆ Appuntamenti

ˆ Referti

ˆ Esamidilaboratorio

Indipendentementedaltipodimessaggio, essoè untesto ASCIIstrutturato

nelmodo seguente[g. 1.4℄:

ˆ unmessaggio èsuddivisoinpiùsegmenti

ˆ unsegmentoè suddivisoinpiù ampi

ˆ un ampopuò esseresuddivisoinpiù omponenti

Ogni segmento ontieneinformazione orrelatadalpunto divistalogi o, on

una propria intestazione ditre lettere (adesempio inmessaggi di tipo ADT i

sonoisegmenti onintestazioneMSH,EVN,PID,...),edèdemar atodagli altri

segmentidal separatoreritorno a apo.

Cias unsegmentoè arti olatoinpiù ampi,demar atidaseparatoripipe(),

he ontengonoidativeriepropri(nomee ognomedelpaziente,datadinas ita,

nome e ognomedelmedi odiriferimento,...). I ampi possonoprevederedelle

sotto omponentitraloro diviseda deiseparatori(il simbolo).

1.5.2 DICOM

Le organizzazioni Ameri an College of Radiology (ACR) e National Ele tri al

Manufa turers Asso iation (NEMA) nel 1983 hanno formato un omitato per

sviluppare unostandard per:

ˆ promuovere la ondivisione di immagini digitali, indipendentemente dai

produttoridei dispositivi

ˆ fa ilitare lo sviluppo ed espansione di sistemi PACS he potessero an he

interfa iarsi on altrisistemi informativisanitari

ˆ permettere la reazione di basi di dati di informazioni diagnosti he he

potessero essere interrogate da un ampia varietà didispositivi distribuiti

geogra amente.

Lo standard ISO 12052:2006 DICOM è stato realizzato dal omitato per

fa ilitare l'interoperabilità tradispositivi medi alidiimaging,spe i ando:

ˆ un insieme di proto olli di omuni azione di rete he i dispositivi devono

implementareperessere onformiallo standard

ˆ la sintassi e la semanti a dei omandi e delle informazioni asso iate he

possono esseres ambiate on isuddetti proto ollidirete

ˆ un insieme di servizi di memorizzazione, di formati di le e strutture di

dire tory, he i dispositivi devono implementare per essere onformi allo

standard, perfa ilitare l'a essoalle immaginie relative informazioni

ˆ leinformazionidevonoesserefornitedaunsistema onformeallostandard

Lo standard DICOMnon spe i a: idettagli implementativi,altre

Lo standard risolve il problema di inters ambio di informazioni digitali tra

strumentimedi ali per immaginie altri sistemi,ma non onsidera

l'interopera-bilità on altri tipididispositivimedi ali.

1.5.3 Te hni al framework IHE

Il Te hni al Framework IHEdenis e lespe i heimplementazionidistandard

ben stabiliti per ottenere obiettivi di integrazione he promuovano

un'appro-priata ondivisione delle informazioni medi ali per un supporto ottimale della

salute delpaziente. Viene aggiornato ognianno, dopo un periodo di

valutazio-ne pubbli a, e mantenutoregolarmenteattraverso l'identi azione e orrezione

degli errori. L'attuale versione, rev. 10.0, spe i a le transazioni IHE denite

e implementate no a ottobre2010. L'ultima versione deldo umento è sempre

reperibile sulsito web diIHE[3℄.

Il Te hni al Framework IHE identi a un sottoinsiemedei omponenti

fun-zionali per le aziende sanitarie, hiamati Attori IHE, e spe i a le loro

intera-zioniinterminidiinsiemiditransazioni oordinatestandard. Attualmentesono

presentiiseguentiTe hni al Framework:

ˆ IHECardiology Te hni alFramework

ˆ IHEEyeCare Te hni al Framework

ˆ IHEIT Infrastru tureTe hni al Framework

ˆ IHELaboratory Te hni al Framework

ˆ IHEPatient Care CoordinationTe hni al Framework

ˆ IHERadiology Te hni al Framework

Il Te hni al Framework IHE identi a gli attori IHE solamente dal punto

di vista delle loro interazioni nell'azienda ospedaliera. Al momento denis e

transazionibasate suglistandard HL7 eDICOM.

IHEèquindiunframeworkimplementativo,nonunostandard,nonè

orret-to riferirsiaIHE ome aunostandard. Tuttavia la onformità di hiaratadaun

svilup-Integration Statement perdes rivere la onformità dei loro prodotti alle

spe i- he del Te hni al Framework IHE. Lo s opo dell'IHE Integration Statement

è quello di omuni are agli utenti i orrispondenti proli IHE he il prodotto

supporta.

Attori IHE

Gli Attori IHE e le transazioni des ritte nel Te hni al Framework IHE sono

astrazioni diun sistemainformativo sanitarioreale. Sebbeneal une delle

tran-sazioni vengano solitamente eseguite da ategorie di prodotti spe i i (per es.

HIS,Ele troni PatientRe ord(EPR),RIS,PACS,Clini alInformationSystem,

e .), il Te hni al Framework IHE evita intenzionalmentedi asso iare funzioni

o attori on tali ategorie diprodotti.

Per ogni attore il Te hni al Framework IHE denis e solo quelle funzioni

asso iate a sistemi informativi integrati. La denizione IHE di un attore non

deve quindiessereintesa ome una denizione ompleta delprodotto hepossa

implementarlo, né il framework stesso deve essere preso ome una guida he

des rival'ar hitetturadel sistemainformativo sanitario.

Laragionedietroladenizionedegliattoriedelletransazionièdiforniredelle

basiperdenireleinterazionitra omponentifunzionaliperisistemiinformativi

sanitari.

Proli di integrazione IHE

Ogni prolo di integrazione [g. 1.5℄ è la rappresentazione di una risorsa del

mondo reale,supportatada uninsiemediattori heinteragis onotramite

tran-sazioni.

Gliattorisonosistemio omponentidiunsistemainformativo he

produ o-no,gestis onooagis onosu ategoriediinformazioniri hiestedalleattività

ope-razionalidell'azienda. Letransazionisonointerazionitraattori hetrasferis ono

le informazioniri hiesteattraversomessaggibasatisu standard.

Iprolidi integrazione IHEorono un linguaggio omune he professionisti

nell'ambito sanitario e rivenditori possono utilizzare per omuni are irequisiti

ad uno spe i o insieme di attori, per ognuno dei quali vengono spe i ate le

transazioni ne essarieasupportaretali funzionalità.

Iprolidiintegrazione fornis onoun omodo mezzoperutentie rivenditori

direferenziareunsottoinsiemedifunzionalitàdes rittenelTe hni alFramework

IHE. Garantis ono a utenti e rivenditori un maggior dettaglio sulle

implemen-tazioni aderentiaIHE,senzadoverris rivereidettagli relativiagliattoriIHE e

relativetransazioni.

Iprolisi suddividonointre lassi:

ˆ prolidel ontenuto,o Content Proles

ˆ prolidel ussodilavoro, oWorkowProles

ˆ prolidell'infrastruttura,o Infrastru tureProles

I Content Prole si riferis ono alla gestione di un parti olare tipo di

onte-nuto: ome viene reato,immagazzinato, ri hiesto ere uperato.

I Workow Prole arontano la gestione dei pro essi dei ussi di lavoro, i

qualitipi amenteriguardanoworklisteilreporting/monitoraggiodeiprogressie

dei ompletamentedeiworkitem. Inquesto ontesto,unoopiùoggetti ontenuto

vengono reatiina ordo ailoroContent Prole.

GliInfrastru tureProlessio upanodellequestionigeneralidel

dipartimen-to, omeperesempiol'audittraildiradiologiaol'a essoalsistemainformativo

radiologi o.

IngeneraleiprolidiintegrazioneIHEnonoperanoindipendentemente.

Og-getti heservono omeinputdiunprolo,possonoalorovoltaessereilrisultato

di un altro prolo. In al uni asi questo tipo di dipendenze è strettamente

ne- essario per il orretto funzionamento del prolo. In generale omunque, ogni

prolohapo o valoreseadessononèasso iatounrelativoprolodi ontenuto.

1.6 Con lusioni

Al giorno d'oggi las ienza informati a è parte integrante dei pro essi sanitari,

sia ditipo amministrativo he ditipo sanitario. lete nologieinformati he sono

e-valoreelevatodegliinvestimentiinquestate nologia las iaintendere unelevato

grado di automazione dei pro essi di gestione e di erogazione dei servizi, ed è,

quindi,unindi atoreinizialedelgradodie ienzadelsistemasanitarionelsuo

omplesso. Lelineeguidaeglistandard presentati inquesto apitolo

rappresen-tato larispostapiù e a eperlamigliore interoperabilitàpossibile trasistemi

informativi, in parti olare radiologi i, all'avanguardia an he omparativamente

I due sistemi MARiS e MN1

Introduzione

Tutte leorganizzazionidiuna omplessitànonbanale hannovisto l'informati a

aermarsi omestrumentoprin ipeperunamodernagestionee ientedella

pro-pria ma hina di funzionamento. Le aziende ospedaliere rientrano pienamente

nella ategoria, ela entralità dell'e ienza operativa è an ora maggiore

onsi-derandoilruolo vitalenella ondizionequotidiana dimolti ittadini. An heper

ledis ipline diRadiologiae Medi inaNu learel'informatizzazione

dell'ammini-strazione è stata un'evoluzione quanto meno ne essaria, ed anzi la diagnosti a

per immagini patavina si è distinta per essere in prima linea per

l'informatiz-zazionedel proprioapparato. Questedue bran hesi aratterizzano perproprie

pe uliarità, he nel aso di Medi ina Nu leare sono onsiderate di ni hia già

nell'ambito dellasanità.

Vedremoinquesto apitolo lastoriadiMARiSe MN1 dalleorigini, fondate

sui Te hni al Framework IHE, no alle emerse esigenze di integrazione in un

uni osistemaAnalizzeremo leprin ipali aratteristi heel'adesioneaiTe hni al

Frameworkse ondo iproliimplementati.

2.1 MARiS e MN1

rare l'obsoleta gestione amministrativa arta ea di un repartoospedaliero. Per

de enni lagestione è stata implementate usando supporti non elettroni i:

l'a - ettazione in forma arta ea, la refertazione su nastro e la onservazione delle

immagini su pelli olalm.

Radiologia è stata pioniera della realizzazionedi una propria rete di

omu-ni azione lo aleLANperadattareilpro esso organizzativointernoalpassaggio

della refertazionedalsistemaanalogi oalastreaquellodigitalelmless onles

DICOM, una mole di dati molto elevata in un periodo in ui non esistevano

strumentitelemati ia nessunlivelloaziendale ospedaliero.

2.1.1 Evoluzione di MARiS

Il primopassoèstatol'adozionediunsistemaRIS ommer iale,maallanedel

1997 l'insoddisfazione perla s arsa rispondenza alle esigenze interne era ormai

non più tras urabile. La s elta fu quindi quella di reare un'unità Informati a

all'interno dell'allora Istituto di Radiologia sviluppando un software adeguato

alle esigenzeinterne. Il progettoaveval'obiettivo direalizzare unlaboratoriodi

softwareradiologi o disponibilea tuttisenzaal una limitazione.

Inquelmomentona queilprogettoESO:leridotterisorsee onomi hehanno

favoritol'adozionendall'iniziodistrumentiabasso osto. Ilprimopassoèstato

la reazionediun'appli azione lient-serverperl'inserimentodellarefertazionedi

esami,usandote nologieproprietarie. Nelfrattempoan hel'aziendaospedaliera

si dotòdi te nologieinformati he, on uiil sistema sviluppatointernamento a

Radiologia ha dovuto interagire.

L'arrivo di standard DICOM, HL7 e altri ha spinto an ora di più

l'a ele-ratore verso lagestione totalmente paperless. Un sistema PACS si aan ò per

ar hiviare e distribuire e immagini se ondo standard DICOM, usando Central

TestNode (CTN),un PACS realizzatodalRSNA. Inoltre,nel 2001nas eIHE,

all'iniziosolo perRadiologia, on tuttele suelineeguidaperfavorirel'adozione

distandard esistenti ondivisi.

La prima versione di ESO fu sviluppata on ar hitettura lient/server in

ambiente Mi rosoft (Windows 95 e Windows NT 4 Server) utilizzando Delphi

riti a. Ilpassoseguenteful'adozionedelserverdatabaseSQLServer,madopo

po hi mesi l'in remento ulteriore della dimensione del database mise in risi

an he questostrumento. Quindisi de iseil grande passo alsistemadigestione

dibasididatiOra le, heperòsidimostròs arsamente ompatibile onilsistema

operativo serverusatoWindows NT.

Subito dopo avereiniziatol'avviamento diESOfusubito avvertitala

ne es-sità di distribuire i dati radiologi i an he aireparti ri hiedenti, sia per snellire

le prati he di invio sia per rispondere all'esigenza dell'Azienda ospedaliera di

poter disporre deireferti radiologi i nel minortempo possibile. La ne essitàfu

soddisfattadaunnuovoprogetto,WebESO,un'appli azionewebsviluppata on

te nologiaMi rosoftA tiveServerPagessusistemaInternetInformationServer.

Perdurantiproblemialsistema lient-server,dovutian heaglistrumenti

pro-prietari usati, hanno imposto un ripensamento dello stesso, e sia per una

que-stionedi osti he diopportunitàdi ontrollosiègiuntil'adozionedite nologie

opensour e. Il primopassoè stato lari onversione dell'appli azionewebperla

distribuzione dellarefertazioneinte nologia PHP,quindil'adozionedelsistema

operativo server Linux, quindi l'adozione di software open lient-server per la

distribuzione evisualizzazione diimmagini DICOM.

La sperimentazione di Linux ha indotto a tentare la strada del sistema di

gestione di basi di dati open sour e, mettendo alla prova il sistema Interbase,

heperleesigenzeinternesièdimostratoequivalenteaOra le,quindiaMySQL,

notosistemaopensour e moltodiuso.

La nuova omponenteWeb si è dimostrata talmentemigliorativa della

las-si a lient-server da spingere alla totale onversione verso il nuovo ambiente,

reandoilprogettoMARiS,internamentenoto olnomediCrono; ometuttele

appli azioniweb,il ambiodiparadigmaha omportatonuoveproblemati hesia

positive he negative. Da questomomento inizia lamassi ia implementazione

diattorie transazioniprevistedallelineeguida IHE, omeADT,OrderFillere

altrean ora.

Usato presso la Sezione di Radiologia del Dipartimento di S ienze

Medi o-Diagnosti he e Terapie Spe iali dell'Università di Padova, il sistema MARiS si

seguendo le priorità interne, ad esempio non esiste una parte di gestione del

ti ketessendopresenteunaspe i apro eduranell'AziendaOspedaliera,mentre

è stata introdotta sialarefertazionevo ale sialarma digitale.

Collaborazioni stabili sono state instaurate ol Dipartimento

dell'Informa-zione dell'Università diPadova,per realizzare nuove funzionalitàgeneralmente

legateadaspettidiIHE,e onaziendeterzepersupportarel'adozionedelsistema

MARiSan he pressoaltrerealtàospedaliere e forniresupporto.

Figura2.1: Diagrammadell'evoluzionedei RISinterni

2.1.2 La bifor azione

La situazionepressolasezionediMedi inaNu leareeramoltodiversa: essendo

unsettoredini hiaperlegrandiaziendeprivatenon 'erainteresseasviluppare

te è la diversa gestione della alendarizzazione degli esami dovuta a una serie

di questioni sollevate dai radiofarma i, quali la preparazione anti ipata dei

ra-diofarma i, i tempi e modi di somministrazione, i tempi di de adimento, e la

disponibilità deiradiofarma i.

L'esigenzadiinformatizzarelasezionesife esemprepiùpressante,perquesto

perne essitàimmediate sirealizzò unsempli esistemadirefertazione

ar hivia-zionediimmagini, hiamatoPenelopoa ausadellanone essivarapiditàdi

svi-luppo. Conlanas itadiWebESOside isediintegrarePenelopo onquelsistema

informativo, al ontempo mutuando e adottando le linee guida IHE! (IHE!).

L'evoluzione di WebESO in MARiS è proseguita di parallelamente an he nel

sistemainformativorealizzatoperMedi inaNu leare.

Altre ne essitàsimili ma non uguali a quelle diun RIS, questioni di tempo

e opportunità, generarono las issione diMARiS per Medi inaNu leare, MN1,

il ui sviluppo è proseguito relativamentein parallelorispetto a quello del

pro-getto progenitore. Realizzato an he da appassionati programmatori ma di

for-mazionemedi a,ilper orsodisviluppoè statosempreimprontatoallamassima

sempli ità.

2.1.3 Riuni azione dei progetti

Dopo al uni anni in ui idue progetti MARiS e MN1 hanno per orso ammini

presso hé paralleli, oggisi è giuntiad un punto in uil'esistenzadi duesistemi

separati nonè piùfattibilene opportuna.

Grazie aduna ostante onfronto,ledierenze traMARiSeMN1sonostate

gestite perlimitare il tasso di diormità tra idue, ma oramaiil mantenimento

di due sistemi simili omporta uno sforzo non ongruo. Lo sviluppo parallelo

haprodotto odi esorgenteridondanteepronoalladupli azione,favoritean he

dall'appro iodisviluppo elementare.

Daqueste onsiderazionièemersalane essitàdiriportareledueappli azioni

adun'uni abase omune. Ilpro essodiriorganizzazionehalos opodiprodurre

2.2 Proli e attori di IHE implementati

Comevisto nel apitolo1,è moltoimportanteriferirsi edusare standard

ondi-visi,e inparti olarenell'informati asanitariadeisistemiinformativiradiologi i

esistono lineeguidauniformi dilivello internazionale.

MARiS e MN1 non fanno e ezione, implementando un sottoinsieme dei

prolidiintegrazioneIHE ([g. 1.5℄).

Inparti olare, iprin ipaliproliimplementatiodirettamente oinvolti sono:

ˆ S heduled Workow

ˆ PatientInformation Re on iliation

ˆ Reporting Workow

ˆ NM Image

ˆ Audit Trail and NodeAuthenti ation(ATNA)

ˆ Audit Trail

2.2.1 S heduled Workow

Il prolo diintegrazione S heduled Workow [g. 2.2℄ determina la ontinuità

e l'integrità delleinformazioni diimaging dipartimentali dibase. Esso spe i a

una serie ditransazioni he onsentono dimantenere la oerenza delle

informa-zionidipazienteeordine,oltreafornireipassiperlepro eduredis hedulazione

e a quisizionedelleimmagini. Inoltre questoprolo permette dideterminarese

immaginioaltrioggettidiprovaasso iati onunaparti olarepro edura

esegui-ta sonostato memorizzatie sonodisponibili per onsentire ipassaggisu essivi

del usso dilavoro, ome la refertazione. Può an he fornire oordinamento per

il ompletamento dell'elaborazione della pro edura, oltre a noti are l'Order

Pla erdieventualiappuntamenti.

Gliattoridiquestoprolo implementati inMARiS/MN1sono:

ˆ OrderPla er

ˆ PerformedPro edure StepManager

ˆ Image Managere ImageAr hive

L'attore ADT è responsabile perl'inserimento o l'aggiornamento delle

ana-gra he dei pazienti. In parti olare registra un nuovo paziente presso l'Order

Pla ere l'OrderFiller.

L'attoreOrderFillerèunsistemadipartimentale(peresempiorelativamente

a tuttalasezionediRadiologia) hefornis e funzionirelative allagestionedegli

ordini ri evuti da sistemi esterni o dipartimentali tramite opportune interfa e

utente.

L'attore Order Pla er è un sistema di livello aziendale ospedaliero he

ge-nera gli ordiniper vari dipartimenti e distribuis equesti ordinialdipartimento

orretto.

L'attorePerformedPro edure StepManagerèunsistema hesvolgeilruolo

di intermediario tragli attoriEviden eCreator, OrderFiller, ImageManager e

ReportManager.

Gli attoriImage Manager e Image Ar hive sono sistemi he fornis ono

fun-zionalità di memorizzazione e gestione relativamente a oggetti di prova. La

memorizzazione èfornita a lungoterminee inmodo si uro,fornendoalsistema

dis hedulazionedipartimentaleinformazioni suglioggettimemorizzati.

Questi attori non sono implementati direttamente dai progetti MARiS e

MN1, ma sono realizzati utilizzando il software open sour e d m4 he[4℄presso

Radiologia e ilsoftwareCTNpressoMedi inaNu leare 1

.

2.2.2 Patient Information Re on iliation

IlprolodiintegrazionePatientInformationRe on iliation(PIR)[g. 2.3℄

esten-de iproliS heduled Workowe Reporting Workow,orendo le modalitàper

ombinare leimmagini,ireportdiagnosti i ealtri oggettidiprovaa quisiti per

un paziente non identi ato o identi ato in modo errato on il fas i olo del

paziente.

Ad esempio, nel aso di un paziente traumatizzato questo prolo onsente

la ri on iliazionediimmagini a quisiteprimadella determinazionedell'identità

del paziente, an he senza previa registrazioneo on una registrazione generi a.

Queste informazioni potranno quindi essere asso iate orrettamente an he al

momentodell'inserimentodegliattoriADT,OrderPla ereOrderFiller. Inoltre

questoprolo onsenteagli attoriImageManagere ReportManagerdiri evere

messaggidiaggiornamento deidati deipazienti.

Questoprolo aggiungeil solo attoreReportManager.

L'attore Report Manager provvede alla gestione e alla memorizzazione a

breveterminedioggettiDICOMduranteilpro esso direfertazione,distribuis e

reporttestualiostrutturatiai entridimemorizzazione,gestis elalistadilavoro

e lostato della refertazionestessa.

2.2.3 Reporting Workow

IlproloReportingWorkow[g. 2.4℄èuna ontinuazionedelproloS heduled

Workow,erisolvelane essitàdiprogrammareeteneretra iadellostatodivari

in ari hi direfertazione. Questi in ludono le fasi di interpretazione, dettatura,

tras rizione, veri a, onfronto, revisione e odi a. Il sistema he gestis e la

pro edura rende disponibile lo stato attuale an he ad altri sistemi interessati.

L'output del prolo è ostituito da informazioni odi ate se ondo standard

DICOM. Idettagliperla reazione,memorizzazione,interrogazione, re uperoe

odi a sonodes rittinelprolo SimpleImage andNumeri Report(SINR).

Questoprolo aggiungegli attoriReportCreator e ReportReader.

L'attore Report Creator èun sistema he genera e trasmettebozze, e

fa ol-tativamenterevisionidenitive,direfertidiagnosti ipresentandoli omeoggetti

strutturati DICOM. Inoltre puòre uperarelalista dilavoroperlefasi di

refer-tazione dal Report Manager, fornendo noti he del ompletamento di ias una

fase, e permettendoil tra iamento dello statodiun referto.

L'attore Report Reader è parte di un sistema he può a edere ai referti

tramite interrogazioni via rete o tramite lettura di supporti inters ambiabili,

2.2.4 NM Image

Reporting Workow

IlproloNMImage[g. 2.5℄spe i a omeleimmaginidiMedi inaNu leare

sianomemorizzatedallestazionidiA quisizioneeCreazione,e omei

visualizza-tori diquesteimmaginidovrebberore uperarleeusarle. Denis ele apa itàdi

base heivisualizzatoridiimmaginidevonopossedere,manonspe i a

aratte-risti he più avanzate. Questo prolo può esserevalorizzato ombinandolo on i

prolidelussodilavoro, ome S heduled Workow,Post-Pro essingWorkow

e Reporting Workow, he risolvonoilproblemadi omeprogrammaree gestire

gli statidellefasi di reazionedegli oggettiNM Image.

Figura2.5: Diagramma proloNM Image

Questo prolo non è implementato direttamente da MARiS e MN1, ma lo

2.2.5 ITI-ATNA

LetransazioniIHEspesso ontengonoinformazioni hedevonoessereprotettein

onformità onle leggisullapriva ye lenormative vigentinellediverseregioni.

IHEin ludeal uniproliin entratisullasi urezzaelapriva y,mentrelamaggior

parte non spe i a al un tipo diprotezione, ma vanno raggruppatee integrate

adeguatamente onipre edenti.

Figura 2.6: Diagrammaprolo ATNA

Il prolodiintegrazioneITI-ATNA,ITInfrastru tureAuditTrailandNode

Authenti ation , stabilis e le misure di si urezza he, assieme alle pro edure e

politi hedisi urezza,garantis onola ondenzialitàdeidatisensibili,l'integrità

delle informazioni e la responsabilità utente. L'ambiente osì denito è detto

dominio di si urezza e può spaziare da un singolo dipartimento, no all'intera

azienda ospedaliera.

Il prolo Radiology AuditTrail èun opzione delprolo ITI-ATNA,ed èun

sistema per garantire la responsabilità dell'utente. L'Audit Trail deve

permet-tereaunu iale disi urezza,autorizzatoallaveri a delleattività, divalutare

la onformitàalle politi hedeldominiodisi urezza,individuareistanzedi

formazioni possono essere ri hieste dagli utenti o s ambiate tra sistemi. Ciò

in lude le informazioni esportate e importate da e verso ogni nodo si uro del

dominio disi urezza.

La responsabilità utenteè ulteriormenteassi uratada un deposito diAudit

Re ord entralizzato(CentralizedAuditRe ordRepository)altamentesi uro. Il

trasferimentodiunAuditRe ord,daunqualunqueattoreIHEall'AuditRe ord

Repository,ridu elepossibilitàdimanomissioneerendepiùsempli emonitorare

il dipartimento. Nodi dis onnessi dalla rete dovrebbero salvare i propri Audit

Re ord lo almente e trasferirli all'Audit Re ord Repository non appena viene

ripristinatala onnessioneal dominiodisi urezza.

L'Audit Trail and Node Authenti ation fornis e gli strumenti ne essari a

renderel'azienda onformeallenormedisi urezzaepriva y(HIPAA,European,

Japanese, e .),ma nonlarende automati amente onforme.

2.3 Funzionalità di MARiS e MN1

MARiSeMN1realizzanounamoltitudinedifunzionalità oerentementeaiproli

diintegrazione,lamaggiorparte sono omunia entrambe.

Imoduli prin ipalisono:

ˆ gestione dianagra hedeipazienti

ˆ gestione delle artelle lini he

ˆ larefertazione

ˆ l'agenda

ˆ gestione della listadilavoro

ˆ modulo diamministrazione

Ognimoduloèa essibileagliutenti heabbianoleautorizzazionine essarie.

Inparti olare, la omponentedigestione delleAnagra he deipazienti

on-sentel'inserimento,lavisualizzazione,lamodi adellestesse,oltre hel'unione

didue pazientiinun'uni aanagra a,perrealizzareil proloPIR [2.2.2℄.

Il modulo di Refertazione onsente l'inserimento di referti, la modi a, la

stampaelarmadigitaledelrefertostesso;ognifaseèopportunamentetra iata

e memorizzata,mantenendo lostori odel amminodirefertazione.

Il modulo diAgenda serve alla alendarizzazione degli esami; esso onsente

lavisualizzazioniesamiri hiestienon an oras hedulati, degliesamis hedulati,

la prenotazione di esami, la an ellazione di un esameri hiesto, sia s hedulato

he non,lavisualizzazione degli studi pre edentiperil paziente dell'esame

pro-grammato. PerMN1ilmodulo onsentel'inserimentodimoltepli istepperuna

singolapro edura,e di hiudere lafasediprenotazione.

Quindi,unavoltaprogrammatounesamelagestionedellostessoè

demanda-taallafunzionalitàdiWorklist,olistadilavoro. Esso onsentelavisualizzazione

degli esamiprenotati,assegnati edaeettuare inuna spe i asaladiagnosti a,

la modi a della pro edura, la visualizzazione dettagli dell'ordine, la

an el-lazione dell'ordine, la visualizzazione della artella del paziente, l'a ettazione

dellapro edurae l'eventualesegnalazionemanualedell'avvenutaese uzionePer

MN1 permette di gestire le iniezioni di radiofarma i, dalla visualizzazione alla

segnalazioneavvenutaese uzione.

Inne, ilmodulo diWorklist permette lastampadella lista dilavoroe delle

eti hetteadesive daappli are aido umenti arta ei

Ilmodulodiamministrazione,a essibilesolamenteagliutentiditipo

ammi-nistratore, onsentelagestione ditutte gli attori he devonoessere ongurati.

Quindi la gestione degli utenti e delle loro preferenze, dei gruppi di utenti, la

manutenzione dell'agenda per la reazione degli slot di prenotazione, delle

po-stazioni, dellestampanti, delle sale diagnosti he. Inoltre, inMN1 è presente la

gestionedeiradiofarma i,la ongurazionedeiparametripredenitidi

sommini-strazionedi ias unradiofarma oelavisualizzazionedegliordinidia quisizione

dinuovi radiofarma i.

2.4 Caratteristi he di MARiS e MN1

IprogettiallabasediMARiSeMN1ormaihannoallespallequal heannodivita.

Le trasformazioni inter orse neltempo, spe ialmenteperESO prima e MARiS

2.4.1 La s elta Open Sour e

La bennotalosoaopensour e,oa odi eaperto,nonèstataa oltandalla

nas itadelprimoprogettodisistemainformativo,tuttavia oltempo

opportuni-tàte nologi heede onomi hehannoraorzatol'adozionedistrumentiliberi he

in seguito hanno introdotto questa orrente dipensiero in MARiS. L'ambiente

sanitarioin uisièsviluppatoilpro esso ha ertamentefavorito l'apertura,per

fa ilitare ladiusione degli standarde lineeguidainternazionali.

Infatti nell'ambiente radiologi osono disponibili molti altri software, al uni

usati daMARiSeMN1, hetrailoro puntidiforzaannoveranoproprio

l'orien-tamento aperto. Tra gli altri ri ordiamo la ollezione d m4 he[4℄ e la famiglia

mirth[5℄, entrambiusati daisistemi MARiSeMN1

dm 4 he è un insieme di appli azioni open sour e basate su una robusta

implementazione dello standard DICOM a disposizione di aziende private e

ospedaliere perfavorirel'interoperabilitàdioggettiDICOM.

mirth inve e è una famiglia di strumenti, supportata da una vasta

omuni-tà, per realizzare la migliore soluzione possibile perlo s ambio di informazioni

basato su standard HL7 In parti olare, mirth Conne t permette di sviluppare,

ollaudare e rilas iare interfa edis ambiodati.

2.4.2 Questioni legali

Alle onsiderazioni viste nel paragrafo pre edente, se ne aggiungono altre più

squisitamentenormative. Le questioni fondamentali sonoessenzialmentelegate

ad aspetti dipriva y [6℄e del odi e dell'amminstrazionedigitale [7℄.

L'ambientesanitarioèsottopostoadiverseproblemati herelativealla

priva- y e alla si urezza deidati. In parti olare, l'avvento disistemi di ar hiviazione

elettroni i ha ri hiesto l'intervento di pre ise norme, in grado di dis iplinare

questi nuovimetodidigestionedeidatisensibili. Conlalegge196/2003,meglio

onos iuta omeCodi einmateriadiprotezionedeidatipersonali,oTesto

Codi e in materia di protezione dei dati personali

Il odi esi ompone ditre parti e treallegati, on disposizionigenerali relative

alle regole generali in materia di trattamenti dei dati personali, disposizioni

parti olariperspe i itrattamentioe ezionialleregolegenerali,edisposizioni

relative alla tuteladegliinteressatie alsistemasanzionatorio.

In parti olare, gli arti oli 34, omma 1, e 76, omma 1, pres rive le

moda-lità di trattamento dei dati personali on strumenti elettroni i; il onsentito è

onsentitosesono adottatemisuredi:

ˆ autenti azione informati a

ˆ pro eduredigestione delle redenzialidiautenti azione

ˆ utilizzazionediun sistemadiautorizzazione

ˆ aggiornamento periodi o dell'individuazione dell'ambito del trattamento

onsentito aisingoli in ari ati e addettialla gestione oalla manutenzione

degli strumenti elettroni i

ˆ protezionedegli strumentielettroni i edeidatirispettoatrattamenti

ille- itididati,ada essinon onsentitieadeterminatiprogrammiinformati i

ˆ adozione di pro edure per la ustodia di opie di si urezza, il ripristino

della disponibilitàdei datie deisistemi

ˆ tenutadiunaggiornato do umento programmati osullasi urezza

ˆ adozione di te ni he di ifratura o di odi i identi ativi perdeterminati

trattamenti di dati idonei a rivelare lo stato di salute o la vita sessuale

eettuatida organismisanitari

Inoltre, gli eser enti le professioni sanitarie e gli organismi sanitari

pub-bli i, an he nell'ambito di un'attività di rilevante interesse pubbli o, ai sensi

dell'arti olo 85,trattanoidatipersonali idonei arivelare lostato disalute:

ˆ onil onsensodell'interessatoean hesenzal'autorizzazione delGarante,

ˆ an hesenzail onsensodell'interessatoepreviaautorizzazionedelGarante,

selanalità di uialpunto pre edenteriguardaun terzoo la ollettività.

Insintesi,il odi e stabilis e he:

ˆ le redenzialidiautenti azione debbanobasarsi su:

password

token disi urezza,smart ardoanaloghi

aratteristi he biometri he

una ombinazione dellepre edenti

ˆ seè presenteuna passwordnelsistemadiautenti azione, an hein

ombi-nazione onaltrisistemidiautenti azione,questadeveessere ompostada

almenootto aratteri,(sepossibile)edeveesseremodi aognitremesiin

aso ditrattamento didatisensibili;

ˆ gli utentiinattivi daalmenosei mesidevonoessere blo ati

ˆ esistano degliadeguatisistemidipermessi, divisiper lassi diutentioper

singolo utente

Tutti questi requisiti possono essere soddisfatti e direttamente

ontrolla-ti da un sistema di ui sia disponibile l'intero odi e sorgente, he sia an he

modi abilealbisogno.

Codi e dell'amministrazione digitale

Il Codi edell'amministrazionedigitale olDe retoLegislativodel7marzo2005,

n. 82,alCaposlowroman apvistabilis eleModalità di sviluppo e a quisizione

di sistemi informati i nelle pubbli he amministrazioni. In parti olare l'arti olo

68, omma 1, elen a i parametri di omparazione tra soluzioni disponibili sul

mer ato,tra uian heprogrammiinformati iasorgenteaperto. Il omma2del

medesimo arti oloaerma he:

nell'a qui- he assi urino l'interoperabilitàe la ooperazione appli ativa,

se on-doquanto previsto dal de reto legislativo 28febbraio2005, n. 42, e

he onsentano la rappresentazione dei dati e do umenti in più

for-mati, di ui almenouno di tipo aperto, salvo he ri orrano pe uliari

ed e ezionaliesigenze. 

Di onseguenza soluzioni ome MARiS e MN1 a odi e aperto e realizzate

se ondo standard ondivisi nonpossono he ostituireun vantaggio pertutte le

amministrazioni sanitarie di Radiologia e Medi ina Nu leare al momento della

valutazionedinuovisistemi informati i.

2.4.3 Fattori sanitari- lini i

La pe uliarità forse più rilevante dei sistemi MARiS e MN1 è quella di

esse-re stati, e di essere an ora, sviluppati an o a an o on gure squisitamente

sanitarie, oltre he amministrative.

Ciò permettel'immediataedirettainterazione ongliutilizzatorinalidella

soluzione, on un dupli evantaggio:

ˆ ridurre notevolmente i tempi tra l'espressione di un nuovo requisito e la

soddisfazione dellostesso, periodonotoan he omelead time

ˆ evitare tutti i passaggi he, partendo dai reparti ospedalieri no agli

svi-luppatori nali, omportano perdite di informazioni e improprie

trasfor-mazionilessi ali

Inoltre, lapossibilitàdipersonalizzarealbisogno e ad ho la soluzione

on-sentelarealizzazionedispe i hefunzionalitàdedi ateas opidiri er amedi a;

un esempione è illavoroditesi [8℄,volto a lassi are automati amentereferti

radiologi ianalizzandounsetdirefertiinerentiallapatologiadellopneumotora e

ome supportoalla diagnosi.

2.4.4 Motivazioni ommer iali

ollaborazione on altrestruttureed entiuniversitari, tra uiilDipartimentodi

Ingegneria dell'Informazione,sanitari e privatidiPadova.

In parti olare, da tempo è stata instaurata una positiva ollaborazione on

un'azienda padovana [9℄ he fornis e servizi di supporto per un sistema

infor-mativo radiologi o basato su una s issione di MARiS. La realizzazione interna

di un sistema open sour e e ha per iò onsentito an he lo sviluppo di nuove

Analisi e progettazione

Introduzione

L'integrazionedel odi esorgentedidue appli azioniraramenteè banale,an he

quando esse siano frutto diprogetti simili. Dierenze funzionali,ar hitetturali,

an hestili diprogrammazionediversi impongonoun'a urataanalisivoltaa

de-terminarelabase omuneda uipartireperraggiungerelos opodiintegrazione.

La omplessità del software, uno sviluppo non sempreorgani o ed omogeneoe

l'ambienteoperativoospedalieronon onsentonodipro edereadunaimmediata

integrazione deidue sistemi.

Considerando la ne essità di pro edere all'uni azione per passi su essivi,

mantenendo quindi la ompleta ompatibilità trail nuovo odi e e il ve hio, e

rendereilpiùsempli epossibileallosviluppatorenale 1

l'usodelnuovosistema,

dopo l'analisi della stato pre edente è stata progettata una nuova ar hitettura

volta a ristrutturare il odi e sorgente, per favorire l'integrazione di MN1 on

MARiSsenza soluzionedi ontinuità.

3.1 L'analisi dei sistemi

Il i lodivitadiunsoftware onsistenelmodoin uiunametodologiadisviluppo

suddivide larealizzazionedel prodotto softwareinsotto attività oordinateper

1

ottenere ilprodotto stessoe lado umentazionead essoasso iata.

Le fasiprin ipaliprin ipali del i lodivitasonoleseguenti:

ˆ Analisi

ˆ Progettazione

ˆ Implementazione

ˆ Collaudo

ˆ Rilas io

Lafasedianalisihalos opogeneraledidistillare,spe i areedo umentare

le funzioni, he devono essere oerti da un sistema softwareo programma, per

risolvere un dato problema nel ontesto operativo. Le informazioni ra olte

nella fase di analisi rappresentano il punto di partenza per la progettazione di

un prodotto softwaree perl'intero pro esso della sua realizzazione, validazione

e manutenzione.

Questafaseè ingeneraleparti olarmente omplessa, ed èsuddivisa insotto

attività:

ˆ ladenizione delproblema he ilsistemada svilupparedeverisolvere

ˆ l'analisi di fattibilità, per apire se gli obbiettivi siano ragionevoli e

rag-giungibili

ˆ l'analisi dei osti e bene i, per valutare onvenienza e onomi a, osti

previsti ebene i

ˆ l'analisi deldominio in uiilsistemadovrà agire

ˆ l'analisi deirequisiti, hespe i a lefunzioni ri hiestealsistema

3.1.1 Denizione del problema

Los opoprin ipaledellariprogettazioneeproblemadarisolvereèl'integrazione

deiduesistemiRISesistenti. Unasempli eedirettaaggregazione eintegrazione

dovràsmussarnelela une,favorirnel'integrazione,aumentarelamanutenibilità,

ollaudabilitàed estensibilità.

3.1.2 Fattibilità

IduesistemiMARiSeMN1sonofruttodiunabifor azionedelmedesimo

proge-nitore. Neglilosviluppoèproseguitoinparallelo,mal'a ortezzadiminimizzare

il tassodi diormità onsentediprevedere he ilpro esso diriuni azione avrà

un'altaprobabilitàdisu esso.

3.1.3 Costi e bene i

I bene i della riuni azione sono hiari ed evidenti, il preponderante è il

mi-nore sforzo ne essario al mantenimento di due appli ativi simili ma separati.

Inoltre lariprogettazioneèvolta adaumentarelamanutenibilità, ollaudabilità

ed estensibilità,ridu endoasua voltalosforzo disviluppo.

Il osto prin ipaleè dovuto al tempo ne essario per apprendere e a quisire

padronanza onun nuovo modello disviluppo.

3.1.4 Dominio appli ativo

Questaanalisièpropedeuti aallariprogettazionedisistemiesistenti,perqualiil

dominioappli ativoèmoltosimile. Ildominiofondantenon ambia,la

riproget-tazionedeveottenereunprodottoingradodi oniugareiduedominipre edenti,

hesappia mantenere lepe uliaritàdi ias uno deidue.

3.1.5 Requisiti

I prin ipalerequisiti he la riuni azione e riprogettazionedovranno soddisfare

sonoiseguenti:

ˆ mantenimento dellefunzionalitàdientrambiisistemi esistenti

ˆ maggiore ompatibilitàpossibile onil odi esorgentelega y

ˆ in remento della ollaudabilitàdel odi e sorgente

ˆ urvadiapprendimento relativamenteripida

3.2 Le basi di dati

Lo s opodiquestafaseè studiareidue databaseesistentidiMARiSe MN1per

poterrealizzareunalorointegrazioneadabile: ilprimopassoèunama ro

ana-lisi on ettuale e logi a, quindil'individuazione di riti ità dinormalizzazione,

diridondanzae di onvenzionidisviluppo alivello ditabelle.

Poi hé, perpre isa s elta progettuale, neidue database sono assentivin oli

di hiaveesterna,lerelazionitraletabellesonostatededottedalleinterrogazioni

aldatabase realizzate dall'appli azione.

Sono stateindividuate leseguenti riti ità:

ˆ il motoredistorageMySQL usatoè MyISAM 2

ˆ per pre isa s elta progettuale non i sono vin oli referenziali di hiave

esterna

ˆ esistono al une tabelle on susso -old,oppure_old: questetabelle sono

obsolete

ˆ al une tabelle sonopresentiinMARiSe noninMN1, evi eversa

ˆ analogamente,moltepli iattributisonopresentiinMARiSe noninMN1,

e vi eversa,ohanno tipi diversi

3.2.1 Motori di memorizzazione

Il motore di storage MyISAM è velo e e par o di risorse omputazionali [10℄

ma, solo per itare le prin ipali de ienze, non è ompletamente onforme alle

spe i heACID 3

,nonsupportaletransazioni,gestis eillo kalivelloditabella

4

e in asodiguasto delserverpuòessere ne essariori ostruire letabelle.

2

MyIndexedSequentialA essMethod

3

Atomi ity,Consisten y,Isolation,eDurability.

Al ontrario il motore InnoDB è totalmente aderente alle spe i he ACID,

supporta le transazioni e il lo k è a livello di re ord, ma non supporta indi i

FULL TEXTeimpone limitazionisull'usodiattributiautoin rementanti.

Il maggiore limite attualedel motore InnoDB è la man anzadella apa ità

di ri er he FULL TEXT: ad oggi esistono alternative open sour e su ui fare

adamento, tuttavia l'implementazione di questa aratteristi a è prevista per

unadelleprossimereleasediMySQL.Adognimodo,almomentogliindi iFULL

TEXTnon sonousati nelleappli azionioggetto diquestaanalisi.

Dalla versione 5.5 di MySQL il motore dimemorizzazione predenito è

di-ventato InnoDB.Nel sito web di MySQL [11℄è possibile trovareuna

ompara-zione u iale tra i due motori: InnoDB si dimostra de isamentepiù s alabile,

ma soprattutto più ongurabile. È possibile modi are il livello di aderenza

alle spe i he ACID per ottenere gradi diversi di prestazione in lettura, pur

mantenendo untasso diprotezione deidatisuperiore aMyISAM.

3.2.2 Vin oli relazionali

Non essendo ivin oli di hiave esterna, forzatamentela gestionedi questotipo

di vin olo è demandata al livello appli azione, per iò tutte le relazioni tra le

tabellesonostatededottedall'appli azionestessaodadis ussione olgruppodi

sviluppo.

3.2.3 Attributi

Èstatoosservato heinomidirelazionieattributinonrispettanouna

onvenzio-ne pre isa: al uni sono inlingua italiana,altriininglese,le hiaviprimarienon

sonoomogeneeealtro an ora. Frequentementeinominonsonoparti olarmente

des rittivio indu ono ambiguità, oaddiritturasonofuorvianti.

Analisi di attributi

L'analisi dei tipi degli attributi ha rivelato una progettazione delle tabelle

im-perfetta. In parti olare, sonostate realizzatevalutazionisul tipo didatoperla

hiaveprimariadellatabella onilmaggiorenumerodire ord,latabella

re ord, sono generati anti ipatamente e periodi amente. Nel database di MN1

usato in produzione dal maggio 2008 ad oggi sono stati inseriti 313000 re ord

ir a.

Fino ad oggi e nel aso peggiore, sono inseriti re ord per 17 ore di turni

al giorno, per al più 6 stanze. In via autelativa, è stato onsiderato il aso

peggioredi 24 oreal giorno, per 8 stanze,ottenendo 281088re ord all'anno. Il

tipo di dato INT permette di memorizzare un valore massimo di 2147483647,

he diventa 4294967295 se senza segno; al tasso di riempimento ipotizzato per

esaurirelospazioperilvalore massimo onsegnosarebberone essari7639anni.

5

Tuttavia il tipo di dato usato per la hiave primaria di questa tabella è

BIGINT, heinMySQL o upa8byte,al ontrariodiINT heneo upa4[10,

pag. 716℄, on grande vantaggio dispazio eprestazioni degli indi i.

3.2.4 Struttura delle tabelle di autenti azione

Inoltre, la gestione delle redenziali e dei permessi utente è relativamente

ina-deguata dal punto di vista della base di dati. La modalità attuale omporta

l'aggiunta diun nuovoattributo alla tabella dei privilegi perogni nuova azione

di ui sidevono on edereiprivilegi.

Lamodi adella strutturadiunatabellaMySQL,perdipiùMyISAM,può

generaremoltiproblemi[10,pag. 2330℄poi hél'alterazioneavvienetramite

rea-zionediunanuovatabella onlanuovastruttura, opiadeidatidallapre edente,

eliminazione dellapre edentee ambio delnomedella nuova tabella.

3.3 Il odi e sorgente

Il ussodiese uzionedeidueappli ativiesaminatièsempli e: il i lodi

genera-zione dellepagineHTMLrestituite ai lient avvienesempreattraversoun'uni a

pagina prin ipale.

Si tratta del modello on interfa ia web a pagina singola, o Single Page

Interfa e [12℄. Opportuni ampi nas osti 6

determinanoqualialtresotto pagine

5

PerilrepartodiRadiologialestanzesono26,malasostanzanon ambia,inquesto aso

siimpiegherebbero2350anni

debbanoesserein luse, healorovoltaprevedono hetutteleazionidiri hiesta

all'appli azione riferis anodinuovoalla paginaprin ipale.

Il odi esorgente onsistedi ir a400letralePHP,leJavas ript 7

eledi

stileCSS 8

.Èstrutturatoinunagerar hiadidire tory[g. 3.1℄ hedenis edelle

sotto sezioni, ias una rappresentanteuna ma ro funzionalitàdell'appli azione;

sfortunatamente esistono moltepli ideroghe a questa logi a, frutto di soluzioni

rapide, e a i ma non e ienti, e he spesso da temporanee sono diventati

denitive. Inoltre non 'è al una separazione si a e logi a dei tre tradizionali

livellidiun'appli azione 9

atuttofavoredi odi eridondante,dupli atoedi ile

da testare.

L'ar hitetturapreesistentedelledueappli azionièsoloparzialmente

struttu-ratainmoduliindipendenti: sesottosistemi omequellodellevariegestioni(per

esempio lagestionedeipazientio dell'agenda)sonorelativamenteindipendenti,

non losonolagestionedel login,della ongurazionee della sessione.

3.4 Con lusioni dell'analisi

Il odi esorgenteha raggiunto unadimensionetale he,sviluppatose ondouna

logi a pro edurale a le singolo, esso non è più rapidamente manutenibile e

veri abile.

Il odi epro eduralerendesempli eaggiungerenuovefunzionisenza

modi- arelestrutture dati esistenti, marende ompli ato aggiungerenuovestrutture

datiper hé lefunzioni devono ambiare[13,pag. 97℄.

Inoltre [13,pag. 172℄, un sistema he non sia ollaudabile nonè veri abile;

unsistemaèveri abilesesipuòdeterminarefa ilmente heagis e omeprevisto

dalprogetto,e unsistema he nonsiaveri abilenondovrebbeessererilas iato

in produzione La ollaudabilità dei due sistemi esistenti è molto bassa, l'alto

a oppiamento rendedi ileintrodurre test e a i, ome loUnit Testing.

An he il tasso dimisurabilitàdeisistemi è basso: èdi ilemisuraree

otte-nererisultati omogenei daun ammino digestione della ri hiestae generazione

dell'output he nonè uniformerispettoa tutto lospazio delleri hieste.

7

Linguaggiodis riptinglato lient

8

Linguaggioperlaformattazionedido umenti

Vistalanotevole omplessitàdeldominioappli ativo,sonostate onsiderate

due possibilitàperl'integrazione del odi esorgente:

ˆ l'adozionediunframeworkesistente

ˆ progettazionee sviluppo diunnuovoframeworkpersonalizzato.

3.5 Valutazione di framework esistenti

Unframeworksoftwareèunastrutturadisupportosoftware hefornis e

funzio-nalitàgeneri he hepossonoesseremodi ateoesteseselettivamentedal odi e

parti olaredell'appli azionespe i a.

Un framework è una ollezione di librerie software he fornis e Appli ation

Programming Interfa e (API) ben denite, tuttavia è ben distinto da normali

libreriesoftware:

ˆ fausodelpattern inversione del ontrollo,inmododa ontrollareilusso

diese uzione

ˆ implementa un omportamento predenito diuna qual he utilità

ˆ è estensibileinal une sueparti perspe i he funzionalità

ˆ una partedel odi e nonpuò esseremodi ata.

Unframeworkneasestessononèassolutamentene essario,èsolounodegli

strumenti he è disponibile per aiutare a sviluppare meglio e più velo emente.

Esso fornis e la ertezza he si sta sviluppando un'appli azione he è in pieno

rispettodelleregoledibusiness, he èstrutturata, e hesiagestibilee

aggiorna-bile. Epiùvelo emente,per hé permetteagli sviluppatoridirisparmiaretempo

graziealriutilizzo dimoduli generi i,alne di on entrarsi sualtrearee.

A lungo termine un framework assi ura la longevità delle appli azioni. La

struttura imposta da un framework onsente a qualsiasi sviluppatore, an he se

non ha mai lavorato primasulla spe i a appli azione, di iniziarea sviluppare

inmodo rapidoe ordinato.

I riteri possibileperlavalutazione e selezionedi unframework appli ativo