PIATTAFORMA TECNOLOGICA ED APPLICATIVA EPHIS E-HEALTH PORTAL HOSPITAL INFORMATION SYSTEM

Transcript

1 PIATTAFORMA TECNOLOGICA ED APPLICATIVA EPHIS E-HEALTH PORTAL HOSPITAL INFORMATION SYSTEM

2 Smmari Premessa... 5 Caratteristiche Tecniche della Piattafrma Applicativa... 7 Requisiti di sistema Architettura applicativa della piattafrma Design Pattern Mtre di templating Base dati Accessi e Sicurezza Theming Mtre API Middleware integrazine MiddleWare: Scenari di riferiment MiddleWare: Prtclli di cmunicazine MiddleWare: Sicurezza MiddleWare: Tracciament delle perazini effettuate MiddleWare: architettura applicativa MiddleWare: flussi di integrazine EPHIS Sistema Infrmativ Ospedalier EPHIS: l scenari e gli biettivi EPHIS: le caratteristiche ed i punti di frza EPHIS: funzinalità e mduli applicativi... 40

3 Prcessi Implementati EPHIS: cartelle cliniche specialistiche... 45

4 Indice delle immagini Figura 1 - Schema architetturale piattafrma Figura 2 - Schema flussi integrazini Figura 3 - Schema architetturale middleware d'integrazine Figura 4 - Funzinalità Middleware Figura 5 - Integrazine dei servizi spedalieri Figura 6 - EPHIS: gli attri Figura 7 - EPHIS: macr-funzini... 39

5 Premessa La piattafrma tecnlgica ed applicativa per la sanità elettrnica rappresenta il cntenitre, il veicl e l strument per la gestine ed il trattament di tutti i dati anagrafici e clinici dei pazienti nelle differenti strutture sanitarie, che sian spedaliere, territriali dmiciliari, e secnd i differenti prcessi lavrativi in esse espletati. La piattafrma è un insieme di funzinalità e mduli applicativi fra di esse strettamente legate in percrsi lgici che rappresentan le attività lavrative qutidiane del persnale scisanitari, pnend al centr sempre la salvaguardia della salute del paziente, centralizzand e rendend dispnibili sempre ed vunque tutte le infrmazini ad ess inerenti ed ttimizzand le attività e le risrse sia ecnmiche che umane. La piattafrma nasce e cresce in una frte e cntinua sinergia, qutidiana, dentr gni turn lavrativ, cn il persnale sci-sanitari che ha partecipat prattivamente e cn un cntribut di analisi dei prcessi e funzinale indispensabile. Un tale apprcci prgettuale ha cnsentit e cnsente di avere un sistema applicativ cmplet, vist da mlte e differenti prspettive lavrative, e sprattutt nn calat dall alt su realtà scnsciute ma intrinsecamente cinvlt nella gestine e rappresentazine dei prcessi lavrativi. Tutt ciò prta ad avere nn sl un prdtt, specializzat e custmizzat, ma sprattutt una sluzine infrmatic-rganizzativa cmpleta ed integrata. La base tecnlgica centrale su cui pggia la piattafrma, e di cui è parte integrante ed attiva, è un framewrk applicativ che rappresenta il mtre intelligente di tutti i prcessi presenti nelle varie applicazini che ne derivan. La natura cmpletamente Open Surce del framewrk cnsente alla piattafrma per la sanità elettrnica di essere integrata ed integrabile cn gni tip di applicativ estern ad essa, si pensi ai servizi strasversali presenti nelle strutture spedaliere (labratri clinici, radidiagnstici, etc.) e/ ad applicazini specifiche per patlgie. 5

6 Infatti tra le principali caratteristiche del framewrk applicativ è cmpres l utilizz di layer che asslve al cmpit di middleware di integrazine; di fatt funzinand da interprete da e vers gni tip di infrmazine garantisce l acquisizine di gni infrmazine che riguardi il paziente e nel cntemp il dialg cntinu tra le mlteplici realtà applicative presenti all intern di strutture sanitarie cmplesse, senza mdificare le mdalità lavrative di gni attre. 1. EPHIS Sistema Infrmativ Ospedalier 2. MiddleWare di Integrazine 6

7 Caratteristiche Tecniche della Piattafrma Applicativa La piattafrma applicativa integrata per la gestine di prcessi e dati in sanità presente le seguenti caratteristiche principali: 1. WEB BASED nativa 2. OPEN SOURCE (sia a livell di cdice sia a livell di base dati) 3. MODULARE e SCALABILE 4. Architettura CLOUD Cmputing Le caratteristiche tecniche e tecnlgiche della piattafrma, ltre a presentare tutti i vantaggi del mnd WEB, la raggiungibilità e fruibilità dei servizi real time vunque, e nel cntemp quelli del mnd del sftware OPEN, nessun cst di licenza e cdice cmpletamente apert, presentan ntevli vantaggi nell infrastruttura necessaria al su funzinament, infrastruttura asslutamente snella e di facile manutenzine. La piattafrma tecnlgica ed applicativa per la sanità elettrnica è stata prgettata e sviluppata implementand un infrastruttura a sistemi di CLOUD Cmputing, quest per cgliere un'pprtunità, che nn riguarda sltant la capacità di ffrire servizi in un mercat differente, ma anche quella, più nbile, di cntribuire all svilupp del Paese realizzand, nel prpri ambit ed insieme alla pubblica amministrazine di riferiment, un md di gvernare apert, trasparente e cllabrativ. Il CLOUD cmputing è un strument fndamentale per ttenere quest risultat. Una piattafrma applicativa CLOUD nativa cnsente di ttenere ntevli vantaggi sia in termini ecnmici che di utilizz delle risrse: avend maggiri pprtunità di diffuephisne dei prpri servizi nel mercat di riferiment mdificand ed ampliand l'fferta delle sluzini per un numer maggire di clientela 7

8 evlvend vers un nuv md di pensare e prprre servizi alla PA e quindi al cittadin aumentand la prpria cmpetitività andand incntr alle nuve esigenze della pubblica amministrazine relative al risparmi e al miglir utilizz delle risrse già acquisite Di fatt si punta ad aumentare il fattre di risparmi da parte di chi acquista i servizi, risparmi dat dall'adzine di tecnlgie clud, in quant esse abbattn i csti fissi per l'acquisizine di strumenti infrmatici (hardware e sftware), cme anche i csti di manutenzine e di aggirnament, permettend di cnvgliare la spesa sltant sull'tteniment del servizi desiderat e di farl in maniera flessibile e sl quand ce n'è bisgn, in base alle reali esigenze di apprvviginament. In quest md, la PA ptrà dedicarsi a fare la PA senza dversi rientare fra le cmplessità dell svilupp tecnlgic. In quest md ptrann veder frma servizi più avanzati a benefici di cittadini, pazienti, turisti, scule, imprese, assciazini, cmunità. In quest md le piccle e medie imprese ptrann rimanere sul mercat, diventand parte attiva nell'ergazine di servizi al cittadin. Altra caratteristica fndamentale della piattafrma è la sua architettura MODULARE. È pssibile decidere quali servizi ccrrn per i prpri prcessi lavrativi e acquistare sl quelli strettamente necessari, cnfigurand i mduli applicativi pprtuni. In questa maniera si ttiene una ntevle ttimizzazine delle risrse sia ecnmiche che infrastrutturali, e nn si appesantiscn i prcessi lavrativi in att. La base cmune all implementazine di tutti i prcessi sanitari rappresentati si fnda su un CORE centrale (framewrk applicativ) che garantisce mlteplici servizi trasversali all'inter sistema: l'autenticazine degli utenti e relative autrizzazini la sicurezza e crittgrafia dei dati e dei canali di trasmisephisne la gestine delle sesephisni di cnnesephisne la gestine del mtre di templating la gestine dei cntrller dei prcessi la gestine dei servizi di theming relativi all interfaccia 8

9 la gestine della persistenza delle transazini e dei dati la interperabilità ed integrabilità cn altre piattafrme applicative In aggiunta ai mduli centrali del sistema sn stati prgettati e sviluppati una serie di mduli e funzinalità specifiche sulla base delle esigenze emerse dall'analisi funzinale e dati eseguita direttamente n site cn il persnale sanitari ed amministrativ cinvlt nel prcess di prgettazine. La prgettazine e svilupp di mduli specialistici ha cnsentit di ttenere un insieme cmplet di funzinalità per la gestine a 360 di strutture sanitarie cmplesse. A livell applicativ ed architetturale la piattafrma tecnlgica ed applicativa per la sanità elettrnica è cmpsta da una serie di layers nativamente integrati fra lr gnun dei quali asslve a differenti cmpiti, ma tutti cn un unic scp finale: quell di mettere al centr dei prcessi e relative infrmazini la tutela della salute del paziente. La piattafrma è stata studiata e prgettata guardand alle nuve esigenze che stann emergend nel mnd della sanità: maggire efficienza ed efficacia nell ergazine dei servizi, il tutt cn mdalità e strumenti estremamente sicuri, rispettsi della privacy del paziente e tali da ridurre ntevlmente il rischi clinic. In tale direzine la prgettazine della piattafrma ha pst particlare interesse ed imprtanza sulla svilupp di mduli applicativi che asslvesser al cmpit di rendere la trattazine dei dati, il lr trasferiment, la lr gestine nnché fruizine altamente sicuri. L biettiv che ci si è pst è quell di garantire che la piattafrma applicativa risultasse un strument sicur ed utilizzabile nel rispett dei principi guida che la Carta dei diritti del malat sancisce cme imprescindibili. Si deve garantire al paziente: 1. il Diritt alla Sicurezza 2. il Diritt alla Prtezine 3. il Diritt alla Qualità 9

10 Di fatt sn valri e principi che fndan le lr radice su di una frte intercnnesephisne fra lr e reciprcità di azine: la sicurezza del paziente si prpne in primis di evitare, cntrllare e ridurre gli eventi avversi i danni cnnessi all assistenza la sicurezza deriva dall interazine di tutte le cmpnenti del sistema e cnsiste nell evitare gli errri i casi prevenibili la sicurezza delle cure è crrelata alla qualità delle cure e ne rappresenta un fndamentale sttinsieme (US Natinal Patient Safety Fundatin) In materia di Risk Management, cmplessa ed in cntinua evluzine, garantire livelli di sicurezza, prtezine e qualità richiede una grande sfrz prgettuale ed una grande capacità rganizzativa. Caratteristiche peculiari che sn riscntrabili nella piattafrma applicativa che presenta un sistema cmplet ed alta affidabilità per la garanzia e gestine della sicurezza secnd le seguenti mdalità e linee guida: segretezza e cnfidenzialità: i dati devn pter essere cnsultati e/ mdificati sltant da parte di chi sia debitamente autrizzat; integrità ed autenticità: i dati nn devn pter essere maniplati dlsamente d accidentalmente e la lr prvenienza deve essere verificabile; accessibilità: i dati devn essere sempre dispnibili eventualmente anche attravers il lr immediat ripristin I mduli applicativi sviluppati per la gestine della sicurezza riguardan in particlare i seguenti punti: crittgrafia dei dati autenticazine degli utenti e relative autrizzazini autrizzazine all'us degli ggetti del database amministrazine e l'aggirnament delle plicies 10

11 auditing strategie di backup e di ripristin dei dati Il mdul di autenticazine ed autrizzazine degli utenti rispetta le principali e più sicure regle di sicurezza cn l scp di diminuire sensibilmente i rischi di intercettament e riutilizz della passwrd: Temp di durata delle credenziali minim Cmplessità della passwrd elevata Algritm di creazine delle passwrd casuale e randmic Meccanismi di lck dell accunt Determinazine del cicl di vita dell accunt Livell di facilità di rintracciament delle passwrd secnd dizinari dati metdi di attacc a frza bruta Crittgrafia passwrd La sicurezza dell'intera infrastruttura applicativa inltre viene implementata anche attravers il mdul dedicat alla gestine della crittgrafia. Quest mdul, trasversale a tutt il sistema, cnsente ai dati in transit di essere autmaticamente crittgrafati e decrittgrafati a secnda delle funzinalità attive. Tale prcess è cmpletamente trasparente all'utente che, se autenticat, vedrà sempre i dati in chiar. I dati sn crittgrafati successivamente cn due diversi algritmi a 256 bit scelti tra quelli ggi cnsiderati sicuri dalle agenzie di intelligence dei paesi più industrializzati. Una cnseguenza mlt imprtante dell'adzine di quest mdul è la ttale inutilità dei dati qualra il server fsse sttratt da malintenzinati: senza le chiavi di access il temp stimat per una frzatura (sia criptanalitica che brute frce) è stimabile in centinaia di anni anche cn l'utilizz dei più ptenti sistemi di calcl ggi dispnibili. 11

12 La piattafrma, inltre, implementa un mdul dedicat alla gestine dei LOG del sistema. Un sistema dettagliat e suddivis in maniera precisa e puntuale che cnsente di sapere sempre ed in gni circstanza chi ha fatt csa quand e in che mdalità. Il sistema per la gestine dei LOG registra gni azine (clic) che viene effettuata dall utente all intern della piattafrma, cnsentend di ricstruire sempre la stria ttale dell infrmazine. In questa direzine la piattafrma tecnlgica ed applicativa per la sanità elettrnica eleva ntevlmente i livelli di sicurezza nella gestine dei prcessi, tracciand tutt, identificand in maniera univca sia il paziente che l utente utilizzatre, prteggend le infrmazini da rischi di intruephisne ed acquisizine nn autrizzati. L schema lgic della piattafrma applicativa prevede i seguenti livelli applicativi (visualizzazine TOP-DOWN): Applicazini specifiche (EPHIS-SIT) Framewrk Applicativ Middleware di integrazine Base dati 12

13 Figura 1 - Schema architetturale piattafrma 13

14 Requisiti di sistema Il sistema ha i seguenti requisiti base: REQUISITI DELLA PIATTAFORMA APPLICATIVA Unix PIATTAFORMA OPERATIVA - OS Windws MacOS SERVER WEB Apache2 IIS PHP5 LINGUAGGIO DI PROGRAMMAZIONE EstenEPHISni di base: XML, SOAP Ajax/jQuery DATABASE MySQL v.5.x 14

15 Architettura applicativa della piattafrma Design Pattern Il prdtt è realizzat utilizzand il linguaggi di scripting PHP5. Si basa su un framewrk che utilizza i più diffusi design pattern, in particlare l'mvc (mdelview-cntrller), dve i flussi di infrmazine sn gestiti da differenti ggetti: il mdel gestisce l'interazine cn il database e le altre srgenti di input/utput dei dati (XML, HTTP), il view gestisce l'utput, attravers un sistema di templating che può basarsi direttamente su PHP, ppure su altri linguaggi descrittivi della pagina (XML, XSLT), accmpagnati da un sistema di caching per velcizzare l'utput. Gerarchicamente l'applicazine cnsiste di mduli. Ogni mdul altr nn è se nn una cllezine di elementi che abbian caratteristiche cmuni. Dat che la suddiviephisne dell'applicazine in mduli è puramente rganizzativa e funzinale, si può avere un'applicazine cmpsta di un unic mdul. Ogni mdul cntiene al su intern pagine, blcchi, templates, scripts. Le pages (pagine) sn dei cntenitri di blcchi. Vengn definite insieme alla lr struttura (utilizzand di default il grid system frnit da twitter btstrap) in dcumenti XML creati all'up. Cme dett, una pagina può cntenere da 1 a n blcchi. I blcks (blcchi) sn definiti all'intern dell'appsita cartella. Ogni cartella cl blcc cntiene le views (viste) del blcc stess, i cntrllers e gli scripts assciati (pzinali). Un blcc può avere più viste (ad esempi un blcc clienti può avere una vista grid, per visualizzarne l'elenc, ed una edit, per mdificare le infrmazini); nel cas nn sia pssibile utilizzare ggetti standard per le viste, se ne pssn creare di custm, definend, in quest cas, in un'appsita sezine dell'applicazine le infrmazini di cui ha bisgn l'ggett per funzinare. Cmunque queste infrmazini verrann definite nei settings XML del blcc. Il cntrller si ccupa dell'interazine tra mdel e view. Un design pattern, anch'ess tra i più diffusi, il singletn, gestisce la registrazine delle infrmazini tempranee (sesephisni, variabili glbali), in md da garantire la sicurezza del sistema e da evitare svrappsizini e duplicazini delle infrmazini stesse durante l'esecuzine dell'applicazine. L'applicazine è mdulare, basata su un cre predefinit e su mduli aggiuntivi. Partend quindi da una base cndivisa, ad esempi, sulle varie views, è semplice realizzare views pers- 15

16 nalizzate aggiungere cmprtamenti custm al cre system, mdul per mdul. Ogni mdul, pertant, a secnda delle funzinalità richieste, può ereditare le caratteristiche del cre ed implementare i prpri cmprtamenti, secnd la prassi di svilupp rmai cnslidata della prgrammazine ad ggetti. Il sistema al fine di velcizzare le perazini e garantire una visualizzazine grafica adeguata agli standard Web 3.0, fa larg us di librerie JavaScript, in particlare jquery, che permette anche un efficace gestine delle richieste Ajax (HTTP request), le quali garantiscn l'interazine in md da evitare, ad gni necessità di i/, il caricament dell'intera applicazine. L'utilizz della tecnlgia Ajax/jQuery permette, inltre, di applicare al prdtt sistemi di validazine dei dati misti (su client e su server), che impediscn l'inseriment nel database di infrmazini nn crrette mal frmattate, garantend in tal md l'integrità dei dati. Un sistema di cancellazine dei dati a cascata, infine, garantisce l'integrità referenziale delle infrmazini cntenute nel database. Per la gestine dei settings, sia dell intera piattafrma sia del singl blcc pagina, è stat utilizzat gli standard del linguaggi XML al fine di garantire la maggir cmpatibilità e diffue- PHISne pssibile cn altre piattafrme applicative e cn le diverse tecnlgie presenti nel mnd della sanità, cme apparati elettrmedicale e/ applicazini verticali e specifiche. A tal prpsit è' stat creat un parser XML specializzat, per pter gestire tags ed attributi in un frmat che permetta di trasfrmarne crrettamente i cntenuti in array PHP. Per quant riguarda la gestine di tutte le viste che la piattafrma è in grad di elabra e presentare è stat prgettat ed implementat un view manager. L'perazine è timecnsuming. E' stat creat un sistema più razinale di gestine dei settings prvenienti dai vari dcumenti XML. Il view manager si cmprta semplicemente da dispatcher, e chiama le varie classi specifiche dell'ggett. Tutte le funzinalità di gestine del view manager sn pertant state affidate ai manager dei singli ggetti. 16

17 Mtre di templating Per la gestine del mtre di templating si è scelt Twig, prdtt da SenEPHISLabs, vver dalla stessa firm che ha creat Symfny. Prdtt rbust, affidabile e cn una quantità ntevle di pzini, ltre ad una facilità d'us che in definitiva è un dei parametri principali nella scelta di un template engine. Nnstante si sia scelt Twig cme template engine di base, la piattafrma applicativa può accettare anche altri template engines, a secnda dell'pprtunità. All'intern della cartella render, per gni template engine è presente una classe (Template) che si ccupa da cnnettre tra il framewrk e il mtre. Riprducend la classe in un altr mtre, si può utilizzarl in applicazini custm. Ovviamente, in quel cas, ccrrerà ridefinire i nuvi templates per adattarli alla nuva sintassi. La piattafrma può sstituire il template standard per applicativi specifici e verticali secnd le seguenti linee: Attravers il tema. I templates (sia quelli generali, tip page blck, che quelli di view, tip edit grid) vengn ridefiniti all'intern del tema, rispettand le cnvenzini (classi e id framewrk-related). Attravers l'applicazine. Un blcc può avere: un template specializzat (cme nella verephisne attuale), ma anche un'implementazine specializzata dei templates standard (tip edit grid). Anche una singla pagina può avere un'implementazine specializzata del page template. In quest cas devn essere rispettate le cnvenzini del framewrk e quelle del tema (css). Base dati La piattafmra pssiede un su ORM, basat sul PDO di PHP. Di cnseguenza è in grad di gestire database di vari tip, nn esclusivamente MySQL, ma qualunque database che sia ricnsciut da PHP e per il quale sian dispnibili i cnnettri. Nell'eventualità di database nn gestibile direttamente da PHP, sarà cmunque pssibile cllegarsi al database tramite ODBC. E stat scelt l utilizz di MySql per implementare la base dati della piattafrma applicativa sanitaria. Scelta effettuata in linea cn in principi adttati nella prgettazine e svilupp dell intera piattafrma rispettand i canni delle tecnlgie pen surce e le esigenze legate 17

18 alla rappresentazine di prcessi riguardanti mli di dati elevate e di particlare sensibilità e delicatezza. Tale scelta, però, nn preclude alcun tip di utilizz ed implementazine di differenti basi dati anche in maniera cntempranea; un dei punti più imprtanti, infatti, a cui si è prestata particlare attenzine nell svilupp della piattafrma è l'access alle fnti esterne di infrmazini, in entrata ed in uscita, sian essi files di test che xml ppure recrds di database. Nnstante MySQL sia universalmente ricnsciut cme il database più diffus al mnd, si sn cmunque ridisegnate le rutines di access alle fnti esterne, in md da pter gestire: fnti differenti database differenti L strument per la gestine dei dati e della base relativa prgettat e sviluppat è un Database Manager all intern del quale è stata realizzata la gestine del design pattern DAL (Database Astractin Layer), per permettere l'astrazine dei metdi del Database Manager dal tip di database. Sn dispnibili drivers per: CUBRID (PDO) MS SQL Server (PDO) Firebird/Interbase (PDO) IBM (PDO) Infrmix (PDO) MySQL (PDO) MS SQL Server (PDO) Oracle (PDO) ODBC and DB2 (PDO) PstgreSQL (PDO) SQLite (PDO) 4D (PDO) 18

19 Accessi e Sicurezza Il sistema è ad access riservat, cn autenticazine dell'utente (lgin/passwrd), accmpagnat da meccanismi di sicurezza e criptazine che evitin attacchi ed intruephisni esterne, ltre a meccanismi di sicurezza aggiuntivi (scadenza della passwrd, numer massim di tentativi di access, frmattazine della passwrd, etc.). Il sistema di sicurezza e gestine utenti, infine, permette la creazine di ruli e privilegi d'access persnalizzati, in md che gni utente, a secnd dei privilegi cncessigli dell'amministratre di sistema, pssa accedere in lettura, scrittura ( nn pssa accedere per niente) a qualsiasi mdul dell'applicazine. Per quant riguarda la gestine della sicurezza sn stati implementati le seguenti funzinalità: Mdifica l'attuale ricrda passwrd al lgin (utilizz ckies) Integrazini lgin: Captcha Integrazini lgin: Disattivazine accunt dp n tentativi falliti Integrazini lgin: Scadenza passwrd Passwrd criptate cn MD5 Prfil utente: Passwrd strength Inltre sn stati sviluppate integrazini e metdi specifici per cnsentire l utilizz delle seguenti tecnlgie/piattafrme: CAS LDAP Sistemi di autenticazine FORTE Theming E' stat realizzat un sistema di temi, a partire dal tema di default, per permettere, tramite pprtune mdifiche al CSS (e ad eventuali mdifiche nei templates di default) l switch da un tema all'altr, cn una semplice mdifica alla cnfig.xml. La creazine di temi custm è stata facilitata dall'utilizz di un framewrk tra i più diffusi, se nn il più diffus al mnd, vver btstrap, creat dagli autri di Twitter. 19

20 Il vantaggi di btstrap è quell di riunire, in un unic dcument CSS tutti i tags necessari per la visualizzazine degli elementi grafici e dei campi. Btstrap cntiene inltre gli script per la gestine di tutti gli elementi di input delle infrmazini e dell'interattività cn l'utente. E' cmpletamente integrat cn jquery (set di rutines javascript del quale il framewrk attuale fa larg us, e che è a sua vlta il framewrk js più diffus al mnd). La piattafrma applicativa, cmunque, pur basandsi su btstrap, ne frnisce una verephisne mdificata, per gestire al megli le sue funzinalità. In tal md nn sl l sviluppatre può creare in md semplice ed intuitiv i prpri temi custm, ma può attingere cn un ridtt impegn extra alla sterminata libreria di temi che utilizzan btstrap cme base. Di seguit le mdalità cnfigurabili ed utilizzabili nella piattafrma: Tema di default Css di default Temi applicazine Frmati Mbile cmpliance - HTML5 cmpliants e multibrwser Mtre API E stat implementat un mtre API (server e client), cn le classi necessarie al fine di permettere ad utenti esterni di accedere alle funzinalità della piattafrma. E' stat creat un sistema di chiavi (keys) che pssn essere messe a dispsizine (e ritirate all'ccrrenza) degli utenti, e di tagging; il risultat è frnit all'utenza stt frma di dcumenti files XML, custmizzabili attravers chiavi di ricerca al database: SOAP XML-RPC RESTful 20

21 Middleware integrazine MiddleWare: Scenari di riferiment Nel camp dell'infrmatica sanitaria diventa sempre più centrale nella prgettazine e realizzazine di sluzini riferirsi a degli standard per facilitare l'interperabilità tra sistemi sanitari infrmatici diversi. L'biettiv di questa viephisne è quell di svinclarsi da legami trpp stringenti a sistemi prprietari chiavi in man e mnblcc e agevlare l scambi di dati e infrmazini sanitarie tra sistemi, applicativi e apparati diversi e frniti da partner cmmerciali distinti. Ecc quindi l'ambit in cui si deve muvere un prgett di integrazine di sistemi e applicativi di una struttura sanitaria spedaliera. I servizi e i cmpnenti di un sistema spedalier pssn essere: ADT Sistema Accettazine DimisEPHISne Trasferiment CUP Sistema Unic di Prentazine MPI ANAGRAFICA CENTRALE PAZIENTI PS SISTEMA DI PRONTO SOCCORSO HIS SISTEMA INFORMATIVO OSPEDALIERO EMR dati sanitari del paziente LIS sistemi dei labratri RIS e PACS sistemi radilgici AMBULATORI SPECIALISTICI PIATTAFORMA AMMINISTRATIVA Il prblema dell'interperabilità tra le applicazini infrmatiche sanitarie nasce dal fatt che spess alcune delle sluzini tecnlgiche già presenti ed utilizzate nn è cnfrme agli standard di integrazine descritti in precedenza. In questa situazine due sn le pssibili strade da percrrere per ttenere l'biettiv di integrare tutte le cmpnenti del sistema spedalier: richiedere a tutti i frnitri di applicativi infrmatici presenti nella struttura spedaliera di adeguarsi agli standard di interperabilità. Sarebbe la strada per ttenere l'integra- 21

22 zine più mgenea dei sistemi ma cmprta prblemi tecnici e cntrattuali: tecnici perchè gli applicativi più bsleti pssn essere anche impssibilitati ad ffrire la vere- PHISne standard cmpliant perlmen a farl in tempi medi-brevi; cntrattuali perchè i frnitri richiederann l'acquist di licenze aggiuntive e delle girnate di lavr necessarie per cmpletare l'adeguament. Creare un strat intermedi (MIDDLEWARE) in grad di far dialgare le applicazini e i servizi infrmatici cmpnenti il sistema spedalier cmprese quelle nn standard cmpliant attravers la creazine di cnnettri ad hc per gnun dei servizi. In figura l schema descrittiv di questa sluzine, che evidenzia cme è il MIDDLEWARE che si ccupa di cnsegnare e ricevere messaggi da tutti i diversi cmpnenti del sistema. Figura 2 - Schema flussi integrazini Questa secnda sluzine è la scelta che è stata presa ed implementata nella piattafrma tecnlgica applicativa per la sanità elettrnica ciè è stat creat un layer intermedi di integrazine in grad di far dialgare i nuvi servizi che si vann ad implementare cn i diversi pezzi già installati del sistema infrmativ. 22

23 MiddleWare: Prtclli di cmunicazine Si è fatt in md di garantire il maggire spettr pssibile di cnnettri in md da pter integrare ptenzialmente anche sistemi bsleti legacy. E' imprtante distinguere tra la srgente, le fnti da cui il MIDDLEWARE deve estrarre interpretare i dati, e la destinazine che invece rappresenta il sistema in cui il MIDDLEWARE va a scrivere i dati. Elenchiam i principali cnnettri che la piattafrma deve essere in grad di integrare Srgente cdifiche accettate: xml, hl7, dicm, csv cnnettri utilizzabili: tcp listener, database (attravers bdc/jbdc), web service listener (sap, xmlrpc, rest), lettre e parser di file di scambi, http listener, hl7 listener, DI- COM listener. pssibilità di creazine di API dedicate prtclli di cnnesephisne: TCP/IP, FTP/SFTP, SMB, cnnessi ad API dedicate Destinazine cdifiche accettate: le stesse viste per la srgente cnnettri utilizzabili: tcp, database writer(attravers bdc/jbdc), web service sender (sap, xmlrpc, rest), cstruttre di file neutri di scambi, http sender, hl7 sender, DI- COM sender, pssibilità di creazine di API dedicate prtclli di cnnesephisne: gli stessi visti per la srgente MiddleWare: Sicurezza Il sistema MIDDLEWARE stess e i canali di cmunicazine da e vers di ess diventan un nd critic della rete riguard alla prtezine dei dati trattate e la relativa tutela cnfrme alla nrmativa su privacy e sicurezza. Avend scelt una piattafrma Web Oriented queste sn le misure tecnlgiche vinclanti che la piattafrma di integrazine deve supprtare: 23

24 Https Cifratura file system dei device cntenenti dati sensibili Sistema di autenticazine frte cn crittgrafia frte sul canale di autenticazine MiddleWare: Tracciament delle perazini effettuate E' fndamentale che sia cmpletamente tracciabile tutt il percrs di cmunicazine tra srgente e destinazine che prta l'infrmazine da un'applicazine del sistema ad un'altra distinta e tecnlgicamente nn mgenea alla prima. La piattafrma di integrazine ptrebbe, ad esempi, recuperare un file in frmat.csv di un refert prdtt da un sistema legacy, prprietari ed esprla tramite cnnesephisne diretta HL7 ad un sistema spedalier Standard Cmpliant. In quest prcess i passaggi e le trasfrmazini che l'infrmazine attraversa sn innumerevli e cmplessi. E' allra determinante per il mnitraggi del crrett andament dei prcessi di integrazine che vengan tracciati ed archiviati i seguenti lg: Lg del bus: testimnia il crrett funzinament del MIDDLEWARE durante il prcess se si sn verificati errri interni, errri di sistema altri eventi blccanti Lg srgente: server a dcumentare la crretta entrata dell'infrmazine nel sistema MIDDLEWARE attravers i relativi cnnettri e prtclli utilizzati Lg destinazine: dcumenta la crretta uscita dell'infrmazine dal sistema MIDDLEWARE e la scrittura della stessa nel sistema destinazine 24

25 Scrittura file di lg specifici di prcess: può essere necessari creare dei lg specifici dedicati al particlare prcess implementat e che vadan a mnitrare elementi particlarmente dedicati della transazine. Tutt quant espress in precedenza viene evidenziat dall schema in figura dve in alt abbiam il client di cnnesephisne WEB per l'amministratre del sistema, a sinistra i sistemi SORGENTE, a destra i sistemi DESTINAZIONE, in bass il REPOSITORY di interscambi dei dati e al centr il MOTORE del sistema. Figura 3 - Schema architetturale middleware d'integrazine 25

26 MiddleWare: architettura applicativa Il middleware di integrazine è di fatt un cllettre sftware che cnsente la gestine delle intercnnesephisni per l incapsulament e la trasmisephisne dei dati fra i vari attri che partecipan ai prcessi sanitari in mdalità perative cmplete e sicure: web client (standard serve sl java virtual machine e su qualunque sistema perativ) https per la cnnesephisne (sicurezza e cifratura dei dati) pssibilità di gestine pluriutente e prfili separati cnslle in temp reale di mnitraggi dei prcessi sistema di alerting in cas di malfunzinamenti lg cmpleti di gni prcess e gni azine del sistema interfaccia di srgente cn ptenzialità di integrazine multiprcess e multiprtcll: cdifiche accettate: xml, hl7, dicm, csv, ecc.; cnnettri utilizzabili: tcp listener, database (attravers bdc/jbdc), web service listener (sap, xmlrpc, rest), lettre e parser di file di scambi, http listener, HL7 listener, DICOM listener. pssibilità di creazine di API dedicate; prtclli di cnnesephisne: TCP/IP, FTP/SFTP, SMB, cnnessi ad API dedicate; cstruzine di integrazini dedicate cn sistemi legacy usand i linguaggi di prgrammazine del sistema; cnnettri tra sistema middleware e SOURCE sicuri e cifrati; interfaccia destinazine cn ptenzialità di integrazine multiprcess e multiprtcll: cdifiche accettate: xml, hl7, dicm, csv, ecc.; cnnettri utilizzabili: tcp, database writer (attravers bdc/jbdc), web service sender (sap, xmlrpc, rest), cstruttre di file neutri di scambi, http sender, HL7 sender, DICOM sender, pssibilità di creazine di API dedicate; prtclli di cnnesephisne: TCP/IP, FTP/SFTP, SMB, cnnessi ad API dedicate; cstruzine di integrazini dedicate cn sistemi legacy usand i linguaggi di prgrammazine del sistema; cnnettri tra sistema middleware e DESTINATION sicuri e cifrati. mtre intern di trasfrmazine/integrazine Java sistema di auditing di gni prcess 26