PROGETTAZIONE E SVILUPPO DI UN SOFTWARE PER LA TRACCIATURA E MONITORAGGIO DEI DATI SENSIBILI CON CARTELLE CLINICHE ELETTRONICHE

UNIVERSITÁ DI PISA

FACOLTA’ DI INGEGNERIA

Corso di Laurea Magistrale in Ingegneria Biomedica

PROGETTAZIONE E SVILUPPO DI UN SOFTWARE

PER LA TRACCIATURA E MONITORAGGIO DEI

DATI SENSIBILI CON CARTELLE CLINICHE

ELETTRONICHE

Relatore: Candidato:

Prof. Maurizio Mangione Daniele Pau

Desidero ringraziare il Professor Mangione, relatore, per l’aiuto, la disponibilità e gli incoraggiamenti durante questi mesi di lavoro, inoltre un ringraziamento va anche al settore tecnico informatico della FTGM, in particolare a Donatella Danti che è sempre stata disponibile per rispondere alle mie domande e perplessità nonostante i suoi innumerevoli impegni.

Vorrei inoltre ringraziare le persone a me più care: i miei amici, la mia famiglia e infine la mia fidanzata, a cui questo lavoro è dedicato.

i SOMMARIO

Introduzione ... 1

CAPITOLO 1 - Contesto di lavoro ... 6

1.1 - FTGM ... 6

1.2 - GDPR ... 8

1.2.1 - Portabilità dei dati ... 9

1.2.2 - Data Protection Officer ... 9

1.2.3 - Limiti del regolamento ... 10

1.2.4 - GDPR in ambito sanitario ... 10

CAPITOLO 2 - Sistemi di CCE ... 12

2.1 - Benefici per il paziente ... 12

2.2 - Fascicolo sanitario elettronico ... 13

2.3 - Dossier sanitario ... 14

2.4 - Linee guida in materia di dossier sanitario... 15

2.4.1 - INFORMATIVA E CONSENSO ... 15

2.4.2 - SISTEMI INFORMATIVI ... 17

2.4.3 - DIRITTI DELL’INTERESSATO ... 17

2.4.4 - ACCESSO AL DOSSIER ... 19

2.4.5 - SICUREZZA DEI DATI ... 19

2.4.6 - SISTEMA DI AUDIT... 20

2.4.7 - DATA BREACH e DPO ... 21

2.5 - Conclusioni ... 21

CAPITOLO 3 - Biomedical Framework ... 23

3.1 - Applicazioni web dinamiche e pattern MVC ... 23

3.2 - Single Page Application ... 25

3.3 - Architettura a 3 livelli ... 26

3.3.1 - Il Database ... 26

3.3.2 - Server Side ... 27

3.3.3 - Web Server e Application Server ... 28

ii 3.4 - Gli oggetti BMF ... 29 3.4.1 - Report ... 30 3.4.2 - Filtro ... 31 3.4.3 - Template e helpers ... 32 3.4.4 - Personalizzazione ... 33 3.5 - Conclusioni ... 34 CAPITOLO 4 - Il Progetto ... 35 4.1 - Analisi funzionale ... 35

4.1.1 - Chi avrà accesso alla webapp ... 37

4.2 - Architettura del Database ... 38

4.2.1 - Vecchia Architettura e differenze con la nuova ... 40

4.3 - Ambienti di sviluppo ... 41

4.3.1 - La macchina virtuale ... 42

4.3.2 - Ambiente di stage ... 42

4.3.3 - Ambiente di produzione ... 45

4.4 - Struttura della webapp ... 45

4.4.1 - Accesso e funzionalità della webapp ... 45

4.5 - Ricerca Paziente... 47

4.5.1 - Filtro per Encounter ... 49

4.5.2 - Filtro per Azioni ... 54

4.5.3 - Considerazioni ... 56

4.6 - Ricerca Operatore Sanitario ... 56

4.6.1 - Filtro per Sessione... 57

4.6.2 - Filtro per Altre Azioni ... 61

4.6.3 - Considerazioni ... 63

4.7 - Stampa Pdf Paziente ... 63

4.8 - Conclusioni ... 68

CAPITOLO 5 - Personalizzazioni ... 69

5.1 - Personalizzazione JavaScript: filtroAudit ... 71

5.1.1 - sessionStorage ... 71

5.1.2 - Radio Button ... 75

iii

5.2 - Personalizzazione JavaScript: datiAudit ... 79

5.2.1 - Salvataggio dei parametri ... 80

5.2.2 - Salvataggio dei sottotitoli ... 83

5.2.3 - InfoBox ... 85

5.3 - Personalizzazione JavaScript: datiAuditPdf ... 87

5.3.1 - Sezione 1: Dati anagrafici del paziente ... 89

5.3.2 - Sezione 2: Lista operatori acceduti alla CCE ... 90

5.3.3 - Sezione 3: Dettaglio accessi alla CCE per operatore ... 91

5.3.4 - Sezione 4: Dettaglio azioni compiute sulla CCE per operatore ... 92

5.3.5 - Funzione pdf ... 94

5.4 - Migrazione dei dati di Audit ... 97

5.4.1 - Lo script: INSERT INTO SELECT ... 98

5.4.2 - Trigger: TR_APPLICATION ... 99 5.4.3 - Trigger: TR_PATIENT ... 101 5.4.4 - Procedure: INSERT_INTO_OTHER_ACTION ... 102 5.5 - Conclusioni ... 104 Conclusioni ... 105 Appendice A ... 109 Bibliografia e Sitografia ... 130

1

Introduzione

L’istituzione di un mercato interno dell’Unione europea (Ue) nella prima metà degli anni 90 ha portato ad un’integrazione economica e sociale tali da generare un considerevole aumento dei flussi di dati personali tra attori pubblici e privati, comprese persone fisiche, associazioni e imprese, inoltre la rapida evoluzione tecnologica e la globalizzazione hanno significativamente aumentato la portata della condivisione e della raccolta di dati personali, consentendo tanto alle imprese private quanto alle autorità pubbliche di utilizzare dati personali nello svolgimento delle loro attività come mai in precedenza, favorendo la libera circolazione dei dati stessi che ormai, sempre più spesso, le persone rendono disponibili al pubblico su scala mondiale, trasformando l’economia e le relazioni sociali così come le conosciamo oggi. Si comprende immediatamente perché tale evoluzione richieda un quadro solido e coerente in materia di protezione dei dati personali, che sia affiancato da efficaci misure di attuazione che garantiscano un elevato livello di protezione e tutela dei diritti e delle libertà fondamentali e il rispetto della dignità nel trattamento dei dati personali, necessari alla creazione di un clima di fiducia che possa favorire lo sviluppo dell'economia digitale.

Quello della protezione dei dati personali è un tema molto attuale, nonostante i moderni sistemi di sicurezza e di criptazione dei dati informatici infatti anche grosse multinazionali si sono imbattute negli ultimi anni in problemi di data breach che hanno comportato la violazione dei dati di milioni di utenti, arrivando ad esporre nominativi, indirizzi email, password e talvolta contenuti privati di varia natura.

Per citarne alcuni, tra i più famosi per portata mediatica c’è il recentissimo “scandalo Facebook” che parrebbe aver consentivo l’accesso ai dati di oltre 87 milioni di utenti alla società Cambridge Analytica ingaggiata nella campagna elettorale di Donald Trump, il Mega-breach di Yahoo che ha compromesso le informazioni di oltre tre miliardi di utenti, o ancora il data-breach del noto sito di e-commerce eBay in cui gli hackers hanno utilizzato le credenziali di tre impiegati dell’azienda per accedere per ben 229 giorni ai dati di oltre 145 milioni di utenti.

2

In generale le violazioni sono all’ordine del giorno e avvengono in tutto il mondo tuttavia alcune più di altre espongono a rischi maggiori di danneggiamento le compagnie e soprattutto le persone fisiche i cui dati sono stati violati, la violazione dei dati personali può infatti provocare danni fisici, materiali o immateriali alle persone, come ad esempio la perdita del controllo dei dati personali che le riguardano o la limitazione dei loro diritti, il furto o l’usurpazione d’identità, perdite finanziarie, la perdita di riservatezza dei dati personali protetti da segreto professionale o qualsiasi altro danno economico o sociale significativo alla persona interessata.

Non sono da trascurare inoltre gli illeciti legati alla parziale se non totale assenza di disposizioni interne alle aziende atti a tutelare i dati personali dei clienti, a cui i dipendenti possono talvolta accedere liberamente, non curanti della riservatezza dei dati personali protetti ad esempio da segreto professionale utilizzandoli illecitamente per fini economici o addirittura per ledere la reputazione della persona interessata.

Per queste e per altre ragioni il 14 aprile 2016 è stato approvato dal Parlamento Europeo il regolamento Europeo in materia di protezione dei dati personali (2016/679), pubblicato sulla gazzetta ufficiale Europea del 4 maggio 2016 ed entrato in vigore il 25 maggio 2016 ma trovando un’effettiva applicazione solo in data 25 maggio 2018 in modo da fornire alle imprese e le pubbliche amministrazioni due anni di tempo per organizzarsi e adeguarsi alla normativa.

Tale normativa meglio nota come “Regolamento generale sulla protezione dei dati” (General Data Protection Regulation) o GDPR è stata istituita in sintesi per introdurre delle regole più chiare su informativa e consenso, per definire i limiti al trattamento automatizzato dei dati personali, per stabilire dei criteri rigorosi per il trasferimento degli stessi tra gli stati membri e al di fuori dell’Ue e per fissare delle norme severe per i casi di violazione dei dati (data breach). Quanto detto finora ci permette di definire meglio il quadro in cui si inserisce questo lavoro di tesi, il cui obbiettivo è quello di sviluppare un software capace di coadiuvare il lavoro svolto dal sistema di audit sviluppato dall’ente sanitario FTGM, sistema finalizzato alla protezione dei dati personali dei pazienti presi in cura presso l’ente ospedaliero, tali dati rientrano nella categoria dei cosiddetti “dati sensibili” ovvero di quei dati attinenti alla salute fisica o mentale che in generale rivelano informazioni relative allo stato di salute del paziente.

3

Questi dati sono manipolati all’interno di un sistema di cartelle cliniche elettroniche (CCE) che ne aumenta la portabilità e migliora l’efficienza del processo diagnostico e di cura dello stesso grazie alla condivisione logica delle informazioni sulla salute del paziente tra gli operatori sanitari, garantendo la sicurezza dei dati personali in accordo con le regole definite dal GDPR senza esporli a rischi di accessi illeciti e data breach.

Obbiettivi della tesi

L’ente pubblico presso la quale ho svolto il lavoro di tesi è la Fondazione Toscana Gabriele Monasterio (FTGM), ente specialistico del Servizio Sanitario Regionale della Toscana.

Si è rivolta l’attenzione su quelle tematiche riguardanti la protezione delle persone fisiche con riguardo al trattamento dei dati sensibili dei pazienti presi in cura presso la Fondazione. Nello specifico l’obbiettivo è quello di sviluppare e implementare un software per il tracciamento e il monitoraggio dei dati sensibili nelle cartelle cliniche elettroniche (CCE), in modo da predisporre il personale competente alla verifica del corretto trattamento dei dati clinici del paziente. In particolare ho implementato un applicativo web dinamico, sviluppato tramite l’ausilio dell’ultima release del Biomedical Framework (BMF3.x) messo a disposizione dal settore informatico della FTGM, capace di rispondere alla domanda “chi ha fatto cosa, su quale paziente, quando e da quale postazione”, tale strumento permette di ricostruire la storia degli accessi alle cartelle cliniche elettroniche dei pazienti da parte dei professionisti sanitari operanti presso la Fondazione.

L’applicazione è stata sviluppata dunque per poter avere un controllo totale sul trattamento dei dati sensibili presenti nelle cartelle cliniche, per visualizzare chi vi accede e quali azioni compie, permette inoltre di monitorare l’attività lavorativa del personale sanitario visualizzando tutti i login ai sistemi della Fondazione e tutte le azioni che questi compiono durante le sessioni di lavoro.

Il software così implementato mette a disposizione dell’utente due tipologie di filtri di ricerca che si differenziano per il soggetto a cui è riferita la ricerca, in uno il soggetto è il paziente e permette di accedere all’intera lista degli operatori sanitari che sono acceduti alla sua CCE dal momento dell’istituzione della stessa in poi fornendo tutti i dettagli delle azioni che sono state

4

compiute dagli stessi operatori, il secondo, invece, inverte i ruoli e permette di ricercare uno specifico operatore sanitario di cui si vuole monitorare l’attività, visualizzando i login agli applicativi (Cartella Clinica e Infermieristica) e gli accessi alle cartelle cliniche dei pazienti fornendo anche qui la possibilità di indagare il dettaglio delle azioni che sono state effettuate. Inoltre è stata predisposta la funzionalità di stampa del pdf che permette, dato un certo paziente, di generare un documento pdf contenente la lista intera degli operatori acceduti alla sua CCE con il dettaglio delle azioni che sono state effettuate, in linea con il dovere del titolare del trattamento dei dati clinici, la FTGM in questo caso, di fornire all’individuo richiedente la lista completa con i dettagli degli accessi alla sua cartella elettronica.

Struttura della tesi

Nel primo capitolo presento in breve l’ente pubblico FTGM presso cui ho lavorato al progetto di cui tratta questa tesi, successivamente introduco il tema della protezione dei dati personali e della relativa normativa Ue 2016/679 GDPR, dandone dapprima una visione globale e successivamente inquadrandola in un ambito più specifico ossia quello sanitario introducendo i sistemi di cartella clinica elettronica.

Nel secondo capitolo tratto nella prima parte i suddetti Sistemi di Cartella Clinica Elettronica presentandone due esempi, il fascicolo sanitario elettronico (fse) ed il dossier sanitario, analizzandone i punti in comune ed esaltando le differenze, soffermandomi poi su quest’ultimo nella seconda parte del capitolo e approfondendo le “Linee guida in materia di dossier sanitario” redatte dall’Autorità Garante per la protezione dei dati personali (GPDP). Nel terzo capitolo introduco lo strumento di lavoro, il framework BMF3.x, con cui ho realizzato l’applicativo web, o webapp, presentandone le potenzialità e le funzionalità in generale.

Nel quarto capitolo presento il progetto di tesi e analizzo dapprima le specifiche minime che l’applicativo web deve avere per soddisfare le disposizioni normative, sulla cui base vado a sviluppare un modello, successivamente spiego come effettivamente ho implementato tale modello e lo analizzo in maniera dettagliata, mi avvalgo di immagini con cui spiego passo per passo le funzionalità messe a disposizione dell’utente che gli permettono di interfacciarsi in

5

maniera dinamica con la base di dati attraverso delle maschere apposite, mentre nel quinto capitolo mi soffermo sulle personalizzazioni lato client che ho implementato per realizzare la webapp così come è stata presentata, alcune di carattere estetico mentre altre funzionali, servendomi oltre che delle immagini anche di spezzoni di codice per poter spiegare al meglio l’implementazione.

6

CAPITOLO 1 - Contesto di lavoro

In questo primo capitolo viene presentato l’ente pubblico specialistico Fondazione Toscana Gabriele Monasterio (FTGM) presso cui ho svolto questo lavoro di tesi e vengono introdotte le tematiche principali che definiscono il quadro generare in cui si inserisce il progetto, queste vanno a toccare il tema attuale sulla protezione delle persone con riguardo al trattamento e alla libera circolazione dei dati personali soggetti alla normativa Europea 2016/679 GDPR del 2016 che ha trovato la sua effettiva applicazione nel maggio del 2018, focalizzando in particolare l’attenzione sui dati sensibili in ambito sanitario.

1.1 - FTGM

La Fondazione Toscana Gabriele Monasterio è un ente pubblico specialistico del Servizio Sanitario Regionale della Toscana ai sensi della Legge n. 85/2009 e opera quale Presidio di Alta Specialità in ambito cardiovascolare e pneumologico.

Essa è costituita dal Consiglio Nazionale delle Ricerche e dalla Regione Toscana per la gestione e lo sviluppo delle attività sanitarie specialistiche e di ricerca di interesse del SSR toscano, già svolte dall’Istituto di Fisiologia Clinica CNR.

Due sono le sedi delle attività della Fondazione, uno a Massa all’Ospedale del Cuore “G. Pasquinucci” ed uno a Pisa nello stabilimento ospedaliero presso l’Area della Ricerca CNR ed in particolare quest’ultima è stata la sede del presente lavoro di tesi.

La Fondazione costituisce un centro di alta specialità per la cura delle patologie cardiopolmonari, comprese le patologie rare di interesse specifico, quali ad esempio le cardiopatie congenite, le dislipidemie ereditarie, l'emocromatosi, l'ipertensione polmonare e l'amiloidosi; inoltre grazie alla completa informatizzazione delle attività cliniche e di gestione ed alla disponibilità delle tecnologie più avanzate per la diagnostica funzionale, d’immagine e

7

di laboratorio il paziente viene posto al centro di un sistema multidisciplinare che offre percorsi preventivi, diagnostico-terapeutici e riabilitativi appropriati e all’avanguardia.

Ogni articolazione operativa, dipartimento ed unità operativa, oltre a svolgere le attività sanitarie specialistiche si occupa al contempo di attività di ricerca ad esse correlate in collaborazione con Istituti del Consiglio Nazionale delle Ricerche - primo tra tutti l'Istituto di Fisiologia Clinica - e con altri Istituti del CNR, con le Università toscane, la Scuola Superiore Sant'Anna e la Scuola Normale Superiore, importanti anche le collaborazioni con l'Industria, traendo così dall’esperienza dell’attività clinica spunti per l’investigazione di ricerca e al contempo dai risultati della ricerca e dell’innovazione suggerimenti per il miglioramento della pratica clinica.

Anche la ricerca ha un approccio fortemente multidisciplinare grazie al quale tramite un lavoro che riunisce componenti di medicina molecolare, bioingegneria ed informatica si riescono così a sviluppare tecnologie innovative in ambito sanitario.

Proprio il settore informatico si è reso protagonista nella realizzazione di un “paperless hospital”, ossia di una struttura interamente virtuale organizzata per gestire le attività cliniche e i flussi sanitari in maniera automatizzata e in linea con gli sviluppi tecnologici informatici moderni.

La digitalizzazione oltre che migliorare l’efficienza e l’efficacia del servizio ha reso possibile lo sviluppo di ulteriori servizi a beneficio del paziente uno su tutti la possibilità di redare dei dossier digitali con lo scopo di raccogliere le informazioni e i documenti clinici rilasciati dalla struttura e dai medici del Servizio sanitario operanti presso la FTGM in formato digitale. Tale dossier sanitario diviene dunque, insieme al Fascicolo sanitario elettronico (Fse), uno strumento attraverso il quale sono rese accessibili informazioni inerenti lo stato di salute dell’individuo, relative ad eventi clinici presenti e trascorsi (es. referti di laboratorio, documentazione relativa a ricoveri, accessi al pronto soccorso), volte a documentare la storia clinica del paziente. Con la differenza che i documenti e le informazioni sanitarie accessibili tramite tale strumento sono state generate da un solo titolare del trattamento, e non da più strutture sanitarie in qualità di autonomi titolari, come avviene proprio per il Fse.

8

Ciò stante, molte delle misure individuate a tutela della protezione dei dati in occasione dell’esame dei testi normativi relativi all’istituzione del Fse devono trovare applicazione anche con riferimento ai trattamenti effettuati mediante il suddetto dossier sanitario.

Per tali ragioni sono state delineate dall’Autorità Garante per la Protezione dei Dati Personali (GPDP) specifiche garanzie, responsabilità e diritti relativi alla condivisione da parte di tutti i professionisti sanitari operanti presso il medesimo titolare delle informazioni sanitarie che ricostruiscono la storia clinica di un individuo. In tal senso, sono state adottate le “Linee guida in tema di Fascicolo sanitario elettronico (Fse) e di dossier sanitario” (provv. del 16 luglio 2009).

1.2 - GDPR

Il Regolamento Ue 2016/679, noto come “Regolamento generale sulla protezione dei dati” (General Data Protection Regulation) o più semplicemente GDRP, è un regolamento dell’Unione Europea approvato il 14 aprile 2016 dal Parlamento Europeo ed entrato in vigore a partire dal 25 maggio dello stesso anno in materia di protezione dei dati personali, valevole sia per le pubbliche amministrazioni che per le imprese, e direttamente applicabile in tutti gli Stati membri dell’Ue. Il regolamento nasce dall’esigenza di fornire una certezza giuridica, un’armonizzazione ed una maggiore semplicità delle norme riguardanti il trasferimento di dati personali definendo i limiti al trattamento automatizzato e introducendo regole più chiare su informativa e consenso. Il testo affronta anche il tema dell'esportazione di dati personali al di fuori dell'Ue e obbliga tutti i titolari del trattamento dei dati (anche con sede legale fuori dall'Ue) che trattano dati di residenti nell'Unione europea ad osservare ed adempiere agli obblighi previsti.

Nonostante il regolamento sia entrato in vigore il 25 maggio 2016 ha trovato applicazione in Italia e nel resto degli Stati membri a partire dal 25 maggio 2018. Le imprese pubbliche e private hanno pertanto avuto due anni per organizzarsi e adeguarsi alle nuove regole, un tempo congruo ma non troppo ampio.

Con la sua entrata in vigore, il GDPR ha sostituito i contenuti della precedente direttiva Europea sulla protezione dei dati (Direttiva 95/46/EC) e, in Italia, ha abrogato le norme del “Codice in materia di protezione dei dati personali” (dlgs.n. 196/2003) con esso incompatibili.

9

Dev’essere garantita la sicurezza dei dati raccolti dal titolare del trattamento e dal responsabile del trattamento chiamati a mettere in atto misure tecniche e organizzative idonee per garantire un livello di sicurezza adeguato al rischio. A garanzia dell’interessato inoltre il Regolamento Ue 2016/679 regolamenta anche il caso di trasferimento dei dati personali verso un paese terzo o un'organizzazione internazionale.

Il titolare del trattamento dei dati ha l'obbligo legale di rendere note le fughe di dati all'autorità nazionale, in Italia all’Autorità Garante della Protezione dei Dati Personali (GPDP), e di comunicarle entro 72 ore da quando ne è venuto a conoscenza così come avrà l’obbligo di comunicare senza ritardo all’interessato le operazioni di trattamento illecito sui dati dello stesso.

1.2.1 - Portabilità dei dati

Nell’Articolo 18 del testo si delineano le linee guida in merito al diritto di portabilità dei dati. Una persona deve essere in grado di trasferire i propri dati personali da un sistema di elaborazione elettronico a un altro senza che il controllore dei dati possa impedirlo, e inoltre i dati devono essere forniti dal controllore in un formato strutturato e di uso comune. 1.2.2 - Data Protection Officer

Qualora l’elaborazione sia effettuata da un’autorità pubblica o qualora, in ambito privato, l’elaborazione sia effettata da un controllore le cui attività principali consistono di operazioni di elaborazione che richiedono un monitoraggio regolare e sistematico dei soggetti dei dati, si rende indispensabile l’individuazione di un responsabile per la protezione dei dati - Data Protection Officer o DPO - esperta di legislazione e pratiche relative alla protezione dei dati che debba assistere colui che li controlla o li gestisca al fine di verificare l’osservanza interna al regolamento. Considerati lo scopo e la natura della nomina, sono in gioco una miriade di questioni legate alla governance e a fattori umani che le organizzazioni e le aziende dovranno affrontare. Chi detiene l'incarico dovrà creare un proprio team di supporto e sarà anche responsabile del proprio sviluppo professionale continuativo, dal momento che dovrà essere indipendente.

10 1.2.3 - Limiti del regolamento

L'insieme unico di regole e la rimozione di requisiti amministrativi si era supposto, in prima istanza, avrebbe portato ad un risparmio economico, tuttavia i critici hanno sollevato diverse obiezioni in merito:

 Il GDPR è stato sviluppato con un'attenzione particolare per i social network e i

provider di servizi cloud, ma non ha preso in sufficiente considerazione i requisiti per il trattamento dei dati dei dipendenti.

 La richiesta di avere un funzionario per la protezione dei dati è stata criticata da alcune

nazioni per l’elevato carico amministrativo.

 La portabilità dei dati non è vista come un aspetto fondamentale per la protezione dei

dati, ma più come un requisito funzionale per i social network e i provider di servizi cloud.

 Il nuovo regolamento è in conflitto con altre leggi, regolamentazioni e prassi non

europee (ad esempio la sorveglianza da parte dei governi). Le imprese in tali paesi non andrebbero più considerate accettabili per la gestione dei dati personali nell'Ue.

 L'implementazione del GDPR europeo ha richiesto un sostanziale cambiamento nelle

pratiche commerciali per quelle imprese che non avevano implementato un livello confrontabile di privacy prima che il regolamento entrasse in vigore (soprattutto le imprese extraeuropee che trattano dati personali europei).

1.2.4 - GDPR in ambito sanitario

Anche i dati amministrativi e clinico-sanitari dei pazienti in ambito sanitario non fanno eccezione e il titolare del trattamento dei dati, sia esso ente pubblico che privato, deve garantire la tutela ed il corretto trattamento dei dati sensibili dell’individuo preso in cura presso lo stesso, il tutto in conformità al Regolamento Ue 2016/679 e, in Italia, in adempimento delle linee guida presenti nel “Codice in materia di protezione dei dati personali” (dlgs.n. 196/2003).

Più complessa diviene la questione in materia di protezione dei dati personali quando i dati relativi alla salute del paziente vengono gestiti tramite l’ausilio di Cartelle Cliniche Elettroniche (CCE).

11

Come indicato nel “Documento di lavoro sul trattamento dei dati personali relativi alla salute contenuti nelle cartelle cliniche elettroniche (CCE)” del 15 febbraio 2007, i sistemi di CCE possono assicurare maggiore qualità e sicurezza dell'informazione medica di quanto consentano le forme tradizionali di documentazione. Tuttavia, parlando della tutela dei dati, va sottolineato che i sistemi di CCE danno la possibilità non solo di trattare una quantità maggiore di informazioni di natura personale, ma anche di rendere i dati del paziente più facilmente disponibili ad una cerchia di destinatari più ampia di prima.

Tutti i dati contenuti nella documentazione medica, nelle cartelle cliniche elettroniche e nei relativi sistemi devono essere considerati "dati personali di natura delicata". Essi sono pertanto soggetti non solo a tutte le norme generali della direttiva sulla protezione dei dati personali, ma anche alle regole speciali di tutela relative al trattamento delle informazioni di natura delicata.

12

CAPITOLO 2 - Sistemi di CCE

In questo capitolo si vanno ad introdurre i sistemi di Cartella Clinica Elettronica (CCE) soffermandosi sui motivi che stanno portando ad un loro utilizzo via via crescente e inquadrando un contesto in cui le tematiche messe in evidenza nel capitolo precedente sulla normativa Europea 2016/679 trovano una loro applicabilità quando riferite ai dati sensibili trattati proprio nei suddetti documenti clinici.

Vengono in particolare analizzati due esempi di cartelle cliniche elettroniche come il fascicolo sanitario elettronico ed il dossier sanitario, evidenziando le differenze tra le due e soffermandosi particolarmente sul secondo poiché utile per definire il contesto lavorativo in cui si inserisce questo lavoro di tesi.

2.1 - Benefici per il paziente

La continua evoluzione tecnologica dei mezzi di informazione e archiviazione dei dati assieme al continuo aumento dei costi legati ai sistemi sanitari pubblici hanno portato ad un utilizzo sempre maggiore delle Cartelle Cliniche Elettroniche (CCE), migliorando l’efficienza economica delle cure mediche evitando così un’ulteriore crescita del deficit del bilancio sanitario, e fornendo i dati necessari per un controllo della qualità, per le statistiche e per la pianificazione nel settore sanitario pubblico.

Senza contare i benefici legati al paziente, la condivisione logica delle informazioni sulla salute del paziente tra gli operatori sanitari è infatti uno strumento utile a rendere più efficienti i processi di diagnosi e cura dello stesso, nonché per ridurre i costi della spesa sanitaria derivanti, ad esempio, dalla ripetizione di esami clinici.

È immediato, pertanto, capire perché le politiche di sanità integrata stanno investendo tempo e risorse in tale direzione sia in ambito nazionale che regionale.

Le iniziative nazionali e regionali per la realizzazione di cartelle cliniche elettroniche che possano contenere tutti i dati sulla salute di un individuo hanno portato all’istituzione

13

dell’ormai noto Fascicolo sanitario elettronico (Fse) e del cosiddetto dossier sanitario, con i quali si ricostruisce la storia clinica di un individuo e costituiscono l’insieme dei dati e documenti digitali sanitari e socio-sanitari relativi a eventi clinici presenti e passati.

Sebbene condividano la medesima funzione, mentre nel Fse i documenti e le informazioni sanitarie accessibili tramite tale strumento sono state generate da più strutture in qualità di autonomi titolari, nel dossier sanitario le informazioni raccolte sono relative agli eventi clinici occorsi esclusivamente presso un’unica struttura sanitaria (es. ospedale, azienda sanitaria, casa di cura) pertanto sono state generate da un solo titolare del trattamento.

2.2 - Fascicolo sanitario elettronico

Il Fascicolo sanitario elettronico (Fse) è lo strumento con cui si ricostruisce la storia clinica di un individuo; costituisce l’insieme dei dati e documenti digitali sanitari e socio-sanitari relativi a eventi clinici, anche passati. È per un individuo un punto di accesso unico, comodo e soprattutto sicuro per poter archiviare i dati della propria storia sanitaria.

Vaccini effettuati, referti degli esami del sangue e di radiologia, dati su ricoveri e dimissioni e tutti gli accessi al pronto soccorso sono alcune delle informazioni consultabili.

La sua gestione tecnica e informatica è demandata alla regione al fine di renderlo accessibile alle strutture sanitarie pubbliche operanti su tutto il territorio nazionale.

I dati personali nel Fse sono trattati con strumenti elettronici e reti telematiche da parte di soggetti pubblici quali il Servizio Sanitario Nazionale (SSN) per finalità di cura, consultando le informazioni sanitarie riguardanti l’individuo, inoltre è presente un dossier farmaceutico con le informazioni relative ai farmaci prescritti durante la storia clinica.

Il Fse può essere consultato dalla Regione e dal Ministero della Salute per finalità di studio e di ricerca scientifica. In aggiunta tali Enti, assieme al Ministero del Lavoro e delle Politiche Sociali (titolari del trattamento), possono accedere al Fse (in formato anonimo) per finalità di governo con fini di programmazione sanitaria, verifica della qualità delle cure e valutazione dell’assistenza sanitaria.

Il Fse è istituito solo previo consenso dell’individuo come previsto dalle normative nazionali. Il consenso si suddivide in:

14

 Consenso all’alimentazione: con tale consenso il Fascicolo Sanitario verrà alimentato da tutti i dati sanitari che saranno prodotti da questo momento in poi i quali potranno essere utilizzati solo per fini di ricerca e di governo in forma anonima.  Consenso alla consultazione da parte di terzi: il Fascicolo può essere consultato dai professionisti del SSN e dei servizi socio-sanitari regionali che prendono in cura il paziente fornendo così un quadro il più possibile completo dello stato di salute dell’individuo. Il tutto in totale accordo con le linee guida presenti nel “Codice in materia di protezione dei dati personali” (decreto legislativo 30 giugno 2003, n. 196), il quale definisce il trattamento dei dati e il rispetto dei diritti delle persone connessi all'utilizzo delle informazioni personali; ogni accesso al fascicolo infatti deve essere opportunamente motivato, tracciato e reso visibile sul fascicolo stesso.

 Consenso al recupero dei dati pregressi: acconsentendo così a recuperare, ove disponibili, i dati preesistenti rispetto alla data di attivazione del fascicolo.

In qualsiasi momento l’individuo ha la possibilità di revocare il consenso. Qualora si decidesse di revocare solamente il consenso alla consultazione, il Fse continuerà ad essere trattato in forma anonima solo per finalità di governo e ricerca. L’individuo, inoltre, ha il diritto di richiedere l’oscuramento dei dati e dei documenti presenti nel Fse relativi a un determinato evento clinico.

2.3 - Dossier sanitario

Secondo la definizione resa nelle “Linee guida in tema di Fascicolo sanitario elettronico (Fse) e di dossier sanitario” adottate dal GPDP con provvedimento del 16 luglio 2009, il dossier sanitario è lo strumento costituito presso un organismo sanitario in qualità di unico titolare del trattamento (es. ospedale, azienda sanitaria, casa di cura) al cui interno operino più professionisti, attraverso il quale sono rese accessibili informazioni, inerenti allo stato di salute di un individuo, relative ad eventi clinici presenti e trascorsi (es. referti di laboratorio, documentazione relativa a ricoveri, accessi al pronto soccorso), volte a documentarne la storia clinica.

Il dossier sanitario, dunque, raccoglie le informazioni relative agli eventi clinici occorsi all’interessato esclusivamente presso un’unica struttura sanitaria. In via principale, pertanto,

15

si differenzia dal Fse per la circostanza che i documenti e le informazioni sanitarie accessibili tramite tale strumento sono state generate da un solo titolare del trattamento e non da più strutture sanitarie in qualità di autonomi titolari, come avviene proprio per il Fse. Nonostante ciò, molte delle misure a tutela della protezione dei dati in occasione dell’esame dei testi normativi relativi all’istituzione del Fse si ritiene debbano trovare applicazione anche con riferimento ai trattamenti effettuati mediante il dossier sanitario.

2.4 - Linee guida in materia di dossier sanitario

Affinché i dossier sanitari in uso presso le strutture sanitarie siano effettivamente degli strumenti di ausilio nei processi di diagnosi e cura dei pazienti è necessario che questi siano realizzati con modalità tali da garantire in primo luogo la certezza dell’origine e della correttezza dei dati e l’accessibilità degli stessi solo da parte di soggetti legittimati.

Il dossier sanitario, costituendo l’insieme dei dati personali generati da eventi clinici presenti e trascorsi riguardanti l’interessato, messi in condivisione logica a vantaggio dei professionisti sanitari che presso lo stesso titolare del trattamento, l’ente pubblico o privato presso cui l’interessato viene preso in cura, lo assistono, rappresenta un trattamento di dati personali specifico, volto a documentare parte della storia clinica dell’interessato attraverso la realizzazione di un sistema integrato delle informazioni sul suo stato di salute accessibile da parte del personale sanitario che lo ha in cura.

In assenza del dossier, il professionista sanitario avrebbe accesso alle sole informazioni fornite in quel momento dal paziente e a quelle elaborate in relazione all’evento clinico per il quale lo stesso ha richiesto prestazione sanitaria; attraverso l’uso del dossier sanitario, invece, il professionista fornisce un ulteriore trattamento di dati sanitari mediante la consultazione delle informazioni elaborate nell’ambito dell’intera struttura sanitaria e non solo del suo reparto e quindi da professionisti diversi, in occasione di altri eventi clinici occorsi in passato all’interessato che siano riferibili anche a patologie differenti rispetto all’evento clinico per cui l’interessato riceve in quel momento prestazione sanitaria.

2.4.1 - INFORMATIVA E CONSENSO

Data la sensibilità dei dati trattati il dossier necessita di una specifica informativa, in particolare in tale informativa al dossier deve essere evidenziata l’intenzione del titolare del

16

trattamento di costituire un insieme di informazioni personali riguardanti l’interessato il più possibile completo che documenti parte della storia sanitaria dello stesso al fine di migliorare il suo processo di cura attraverso un accesso integrato di tali informazioni da parte del personale sanitario coinvolto.

Per poter alimentare il dossier sanitario di un individuo è necessario che egli stesso fornisca preventivamente un consenso informato. L’inserimento delle informazioni relative ad eventi sanitari precedenti all’istituzione del dossier necessita anch’esso di un consenso specifico ed informato dell’interessato.

L’acquisizione di dati attraverso il dossier sanitario costituisce un trattamento di dati personali specifico e ulteriore rispetto a quello effettuato dal professionista sanitario con le informazioni acquisite in occasione della cura del singolo evento clinico, questa, quindi, si configura come un trattamento facoltativo. Ad ogni paziente viene garantito, infatti, il diritto di scegliere in piena libertà che le sue informazioni cliniche siano trattate o meno in un dossier sanitario, garantendogli pertanto la possibilità che i dati sanitari restino disponibili solo al professionista sanitario che li ha redatti. Ciò significherebbe tuttavia che il professionista sanitario che lo prende in cura avrebbe a disposizione solo le informazioni rese in quel momento dallo stesso interessato (es. raccolta dell’anamnesi e delle informazioni relative all’esame della documentazione diagnostica prodotta) e quelle relative alle precedenti prestazioni erogate dallo stesso professionista. Analogamente anche il personale di reparto/ambulatorio avrà accesso solo alle informazioni relative ad eventuali prestazioni erogate in passato al soggetto dal medesimo reparto/ambulatorio.

È evidente, dunque, come la collezione di informazioni di eventi clinici distinti relativi a professionisti sanitari differenti operanti nella medesima struttura possa aiutare il professionista che in quel momento prende in cura il paziente nella diagnosi e nella cura dello stesso. I progetti di costruzione del dossier sanitario vengono perciò tipicamente accompagnati da delle campagne informative volte ad alzare il consenso al dossier sopra un certo punto percentuale.

Una volta che il paziente ha fornito il suo consenso all’istituzione del proprio dossier, ai fini dell’accesso allo stesso da parte del personale sanitario non è necessario che tale consenso venga acquisito volta per volta.

17

Revocare il consenso preventivamente fornito è un diritto dell’individuo, manifestabile in qualsiasi momento. Da quel momento in poi il dossier non sarà ulteriormente implementato e le informazioni sanitarie presenti resteranno disponibili al solo professionista o alla struttura interna al titolare che le ha redatte e non verranno più condivise con i professionisti degli altri reparti che prenderanno in seguito in cura l’interessato.

Inoltre i dati sanitari raccolti possono essere trattati, al pari di ogni altra informazione clinica, anche per fini di ricerca nel rispetto di quanto previsto dal “Codice in materia di protezione dei dati personali” (dlgs.n. 196/2003), previa, anche qui, l’acquisizione di un consenso informato del paziente (art. 110 del Codice).

2.4.2 - SISTEMI INFORMATIVI

A tutela dei dati del paziente, con specifico riferimento al collegamento telematico con la struttura ospedaliera titolare del trattamento dei dati, i sistemi informativi vengono pensati per garantire delle misure a protezione dell’identità del paziente, utilizzando canali di comunicazione sicuri e soprattutto adottando dei sistemi di autenticazione e autorizzazione che assicurino l’accesso selettivo ai dati in linea con i principi di necessità, pertinenza, non eccedenza e indispensabilità.

Pertanto tutte le operazioni di accesso devono essere registrate in appositi file di log ai fini della verifica della liceità del trattamento dei dati.

Indispensabile, inoltre, la realizzazione di procedure per assicurare l’integrità, la disponibilità dei dati e il ripristino degli stessi in caso di guasti, malfunzionamento o eventi disastrosi.

2.4.3 - DIRITTI DELL’INTERESSATO

È dovere del titolare del trattamento dei dati comunicare all’individuo che fa espressa richiesta di ottenere conferma dell’esistenza o meno di dati che lo riguardino, ogni dato su di lui esistente in forma intelligibile, con l’indicazione della loro origine, delle finalità e modalità del trattamento.

Inoltre un’importante garanzia a tutela della riservatezza dell’interessato che abbia manifestato la propria volontà in merito al trattamento dei dati personali consiste nella possibilità che lo stesso decida di oscurare alcuni dati o documenti sanitari consultabili tramite tale strumento. Sebbene sia stata evidenziata l’indubbia utilità di un dossier sanitario il più

18

completo possibile, il titolare del trattamento deve garantire la possibilità per l’interessato di non far confluire in esso alcune informazioni sanitarie.

A tal riguardo si evidenzia il fatto che il dossier sanitario costituisce comunque uno strumento informativo incompleto, indipendentemente dalle ipotesi di oscuramento, infatti al suo interno sono incluse solo le informazioni cliniche derivanti dagli accessi del paziente nella struttura sanitaria che utilizza tale strumento e non anche a quelle relative agli accessi effettuati presso altre strutture pubbliche e private.

È bene precisare che i dossier non certificano lo stato di salute dei pazienti bensì sono strumenti che aiutano il clinico ad inquadrare meglio e più rapidamente lo stato di salute di questi.

Pertanto si condivide l’esigenza, manifestata da più operatori del settore e da parte delle associazioni di pazienti, di ben illustrare all’interessato l’utilità per l’operatore sanitario di disporre di un quadro clinico il più completo possibile della sua salute, affinché egli possa comprendere le implicazioni mediche che un eventuale oscuramento di un certo evento clinico implicherebbe.

Prima che l’Autorità Garante della Protezione dei Dati Personali (GPDP) promuovesse le “Linee guida in materia di dossier sanitario” sono state numerose le segnalazioni ricevute dallo stesso Garante circa il trattamento dei dati personali effettuato mediante il dossier sanitario che lamentavano di accessi da parte di personale amministrativo o sanitario che non era mai stato coinvolto nel processo di cura dell’interessato.

Spesso gli accessi oggetto di segnalazione, infatti, non erano legati a finalità di cura dell’interessato, bensì per acquisire informazioni sanitarie per scopi personali (es. curiosità, cause giudiziarie tra le parti) o commerciali. In tali casi il soggetto che aveva effettuato l’accesso poteva con le proprie credenziali accedere a tutti i dossier sanitari aziendali, indipendentemente dalla circostanza di essere intervenuto nel processo di cura dei soggetti coinvolti o meno.

Tale realtà ha messo in risalto i concreti rischi di accesso non autorizzato ai dati personali trattati mediante il dossier che possono essere ben limitati attraverso l’adozione di idonee

19

misure di sicurezza e un’attenta individuazione dei profili e dei livelli di autenticazione e di accesso ai sistemi.

Si rende, pertanto, necessario riconoscere all’interessato il diritto di poter richiedere al titolare del trattamento quali siano stati gli accessi al proprio dossier sanitario, e conseguentemente il dovere ai titolari del trattamento di fornire all’interessato una lista completa degli accessi eseguiti sul proprio dossier con l’indicazione della struttura o del reparto che ha effettuato l’accesso, nonché della data e dell’ora dello stesso.

2.4.4 - ACCESSO AL DOSSIER

Al fine di garantire che chi abbia accesso al dossier sia solo il personale sanitario coinvolto nel processo di cura del paziente, devono essere adottate modalità tecniche di autenticazione al dossier che rispecchino le casistiche di accesso a tale strumento proprie di ciascuna struttura sanitaria.

Il titolare del trattamento deve individuare i possibili casi in cui il personale sanitario può avere la necessità di consultare il dossier sanitario per finalità di cura dell’interessato e di conseguenza definire i diversi profili di autorizzazione all’accesso.

L’accesso deve essere limitato al tempo in cui si articola il processo di cura, ferma restando la possibilità di accedere nuovamente al dossier qualora ciò si renda necessario.

Il titolare deve valutare in funzione dei diversi profili di autenticazione, se sia indispensabile che siano accessibili tutti i dati presenti nello stesso o solo una parte di essi, pertanto limitare la “profondità di accesso” al dossier ai soli dati indispensabili per svolgere i compiti ad essi demandati.

2.4.5 - SICUREZZA DEI DATI

Come già ribadito in precedenza, la delicatezza dei dati personali trattati mediante il dossier sanitario impone l’adozione di specifici accorgimenti tecnici per assicurare idonei livelli di sicurezza.

Numerosi sono i rischi da valutare nella scelta delle misure di sicurezza da adottare; accesso abusivo, furto o smarrimento parziale o integrale dei supporti di memorizzazione o dei sistemi di elaborazione portatili o fissi, comunicazione a soggetti non legittimati sono i principali rischi

20

incombenti sui dati personali cui possono incorrere i titolari del trattamento nell’utilizzo di tali sistemi.

A tal fine il titolare deve adottare idonei sistemi di autenticazione e di autorizzazione per gli incaricati in funzione dei ruoli nonché delle concrete esigenze di accesso ai dossier da parte del personale sanitario e amministrativo. Tali sistemi devono consentire un accesso selettivo al dossier sanitario fondato sul principio di indispensabilità del dato trattato.

Pur in assenza di disposizioni normative recanti obblighi in materia di tracciabilità delle operazioni, le strutture sanitarie devono realizzare sistemi di controllo delle operazioni effettuate sul dossier sanitario, questo mediante procedure che prevedano la registrazione automatica in appositi file di log degli accessi e delle operazioni compiute. In particolare i file di log devono registrare almeno le seguenti informazioni: il codice identificativo dell’operatore che ha effettuato l’operazione di accesso; la data e l’ora di esecuzione; il codice della postazione di lavoro utilizzata; l’identificativo del paziente interessato e la tipologia dell’operazione compiuta sui dati. È necessario che siano tracciate anche le operazioni di semplice consultazione.

Alla luce della enorme mole di accessi ai dossier sanitari che vengono effettuati giornalmente in modalità di sola consultazione, i log delle operazioni devono essere conservati per un periodo non inferiore a 24 mesi dalla data di registrazione dell’operazione.

2.4.6 - SISTEMA DI AUDIT

Il titolare del trattamento deve mettere in opera un sistema di audit per il controllo degli accessi anche al database e per il rilevamento di eventuali anomalie che possano configurare trattamenti illeciti, attraverso l’utilizzo di indicatori di anomalie utili per orientare successivi interventi di audit.

La gestione dei dati personali effettuata attraverso il dossier deve essere oggetto di una periodica attività di controllo interno da parte della struttura titolare del trattamento, che consenta di verificare in concreto l’adeguatezza delle misure di sicurezza, sia di tipo organizzativo, sia di tipo tecnico, riguardanti i trattamenti dei dati personali, e la loro rispondenza alle disposizioni vigenti. L’attività di controllo deve essere demandata a un’unità organizzativa o, comunque, a personale diverso rispetto a quello cui è affidato il trattamento dei dati sanitari dei pazienti.

21

I controlli devono comprendere anche verifiche a posteriori, a campioni o a seguito di allarme derivante da sistemi di alert, sulla legittimità e liceità degli accessi ai dati effettuati dagli incaricati, sull’integrità dei dati e delle procedure informatiche adoperate per il loro trattamento.

La stessa attività di controllo deve essere adeguatamente documentata in modo tale che sia sempre possibile risalire ai sistemi verificati, alle operazioni tecniche su di essi effettuate, ai risultati delle analisi condotte sugli accessi e alle eventuali criticità ivi riscontrate. Devono essere, inoltre, determinati dei criteri per la cifratura dei dati sensibili al fine di rendere gli stessi inintelligibili.

2.4.7 - DATA BREACH e DPO

La delicatezza delle informazioni trattate, nonché l’esigenza di garantire l’esattezza, l’integrità e la disponibilità dei dati e la protezione da accessi non autorizzati rendono necessario assoggettare il loro trattamento all’obbligo di comunicazione al GPDP del verificarsi di violazioni dei dati (data breach) o incidenti informatici (abusi, azioni di malware ect) che, pur non avendo un impatto diretto sui dati, possano comunque esporli a rischi di violazione.

Inoltre il titolare del trattamento ha il dovere di comunicare senza ritardo le operazioni di trattamento illecito dei dati effettuato dagli incaricati o da chiunque. Una tempestiva informazione, infatti, potrebbe consentire all’interessato di minimizzare i rischi connessi alla violazione della disciplina di protezione dei dati personali.

La struttura titolare del trattamento deve, inoltre, individuare al suo interno una figura di responsabile della protezione dei dati - Data protection officer o DPO - che svolga il ruolo di referente con il GPDP, anche in relazione ai casi su menzionati di data breach.

2.5 - Conclusioni

Date le tematiche discusse in questo capitolo specialmente quelle riferite al dossier sanitario, è evidente come la disposizione di cartelle cliniche elettroniche in cui raccogliere i dati sensibili dei pazienti presi in cura presso la FTGM abbia generato l’esigenza di sviluppare un sistema capace di tracciare e gestire le informazioni relative agli accessi alle cartelle cliniche elettroniche in maniera conforme alle direttive imposte dal GDPR.

22

Il sistema così sviluppato prende il nome di “sistema di Audit” ed ha la funzione di acquisire tutte le informazioni relative agli accessi alla cartella clinica elettronica di un paziente, che abbia precedentemente manifestato il consenso all’alimentazione e alla consultazione, da parte di tutti gli operatori competenti che vi accedono per motivi di cura e ricerca.

Tale sistema offre la possibilità di garantire al paziente un maggiore controllo sull’accessibilità ai propri dati sensibili a causa della delicatezza delle informazioni trattate unitamente agli specifici rischi di accesso non autorizzato e di trattamento non consentito.

23

CAPITOLO 3 - Biomedical Framework

Gran parte del lavoro necessario per sviluppare e implementare l’applicativo web di cui tratta questa tesi è stato possibile grazie all’ausilio di un particolare framework progettato e implementato dallo stesso settore tecnico informatico della FTGM.

Tale framework prende il nome di Biomedical Framework – più semplicemente indicato come BMF - e la sua versione attuale, la 3.x, che nasce dalle ceneri della versione precedente (2.x) di cui conserva la logica di funzionamento, implementa una serie di tecnologie per lo sviluppo software e pattern architetturali moderni che offrono innumerevoli vantaggi sia in termini di usabilità che di manutenibilità.

In questo capitolo, perciò, andrò a esplorare il funzionamento del Biomedical Framework, noto più semplicemente come BMF, senza addentrarmi eccessivamente in dettagli tecnici ma aprendo una finestra sulle funzionalità e potenzialità messe a disposizione dal framework, sulle tecnologie software implementate e sulla logica di funzionamento utili per creare in maniera semplice degli applicativi per il web. In particolar modo vengono introdotte le dinamiche relative alle applicazioni web dinamiche a “singola pagina”, costruite con un’architettura a tre livelli e basate sul pattern MVC, inoltre sono trattati e approfonditi i temi riguardanti il funzionamento del suddetto BMF3.

3.1 - Applicazioni web dinamiche e pattern MVC

Così come il suo predecessore, anche il BMF3 è un tool usato per la creazione di applicazioni web dinamiche, con lo scopo di fornire a chi avesse una buona conoscenza del linguaggio SQL e altresì non avesse competenze in ambito di sviluppo di applicativi web e non conoscesse i linguaggi di programmazione ad oggetti (Java, C++, ect), uno strumento semplice da usare che gli permetta di creare, una volta imparate le funzionalità messe a disposizione dal tool, delle nuove applicazioni accessibili tramite web.

24

Tali applicazioni, è stato detto, vengono sviluppate secondo il paradigma noto come web dinamico, che fa uso dei cosiddetti linguaggi di scripting (JavaScript) i quali si occupano della creazione della pagina Internet nel momento in cui questa viene visitata dal client, mettendo a disposizioni delle GUI (Graphical User Interface), ossia delle interfacce utente che permettano a quest’ultimo di interagire in modo visuale con la pagina (tipicamente tramite delle form). Queste interazioni vengono elaborate direttamente lato client, tramite il browser, aggiornando solo porzioni della pagina web in background senza la necessità di dover richiedere un ricaricamento integrale da server, questo perché i dati vengono recuperati dal server tramite delle chiamate asincrone (AJAX) senza fare redirect per visualizzare i risultati delle elaborazioni.

Lo schema architetturale implementato prende il nome di pattern MVC (Model-View-Controller) e permette di separare la logica di presentazione dei dati dalla logica di business, la logica applicativa che rende operativa un’applicazione. Sebbene storicamente questo tipo di pattern venisse implementato lato server, con lo sviluppo e la parziale standardizzazione di JavaScript (JS), oggi i framework implementano MVC direttamente lato client in puro JS. Uno dei primi è stato Backbone.js e proprio tale libreria JavaScript viene utilizzata dal BMF3. Il pattern è basato sulla separazione dei compiti fra i componenti software, il model fornisce i metodi per accedere ai dati utili all’applicazione, la view permette di visualizzare i dati contenuti nel model e si occupa dell’interazione con l’utente, mentre il controller riceve i comandi dell’utente e li attua modificando lo stato del model che a sua volta aggiorna lo stato della view.

Backbone.js, per l’esattezza, è basato su un pattern da esso derivato, il Model-View-Presenter (MVP), che si differenzia dal MVC in quanto il presenter permette di gestire il collegamento tra UI e database in maniera più efficiente, ogni interazione tra view e model infatti passa dapprima attraverso il presenter che fa da ponte tra i due componenti.

25

Figura 1: pattern MVC (sinistra) e pattern MVP (destra)

Immediato scorgere i vantaggi legati alla separazione logica delle varie funzionalità del software, suddivise in più strati o livelli software differenti in comunicazione tra loro. Tale architettura fornisce, infatti, un modello per gli sviluppatori per creare un’applicazione flessibile, che consente di modificare o aggiungere funzionalità modificando solo uno specifico livello, nonché scalabile, ovvero è possibile aggiungere ulteriori funzionalità senza doverne modificare le caratteristiche fondamentali.

3.2 - Single Page Application

Le applicazioni web del BMF rientrano nella categoria Single Page Application (SPA), ovvero, come suggerisce il nome, sono delle applicazioni che “vivono” in una singola pagina (tipicamente index.html).

Le SPA hanno un loro sistema di routing interno, la navigazione viene pertanto gestita dal client ed è possibile ripristinare (rehydrating) i singoli stati direttamente dall’url, inoltre è disponibile un “template engine” per generare l’HTML senza dover necessariamente comunicare con il server.

Lo sviluppo della tecnologia Ajax ha permesso al codice Javascript di aggiornare singole porzioni della pagina web in maniera asincrona, grazie poi all’ausilio di librerie JS (una su tutte jQuery) si è arrivati ad ottenere applicazioni web che non hanno bisogno di ricaricarsi mai.

26

Figura 2: ciclo di vita di una pagina web tradizionale (sinistra) e di una single page application (destra)

La pagina viene scaricata nel browser e successivamente comunica via HTTP, Ajax o WebSocket con il server tramite un formato standard (JSON), la cui implementazione ne è completamente indipendente. Dunque l’applicazione risulta essere indipendente dal backend, ossia dall’implementazione lato server, definendo una netta separazione tra server e client cosicché uno possa essere ridefinito senza dover ridefinire anche l’altro, essendo indipendente può dunque essere gestita come un progetto separato, permettendo una migliore manutenzione agli sviluppatori frontend.

3.3 - Architettura a 3 livelli

Per creare delle applicazioni web il BMF fa uso di una architettura a 3 livelli in grado di eseguire del codice Java. In particolare la suddetta struttura è costituita da un Web Server, un Application Server e un Database Server. Qualunque richiesta da parte del client viene presa in carico dal Web Server che ha il compito di mettere in comunicazione client e server e lo fa passando la richiesta all’Application Server il quale dapprima la elabora tramite codice Java, poi genera una nuova richiesta in formato PLSQL che invia stavolta al Database Server, questo infine elaborerà la richiesta ed eventualmente risponderà in PLSQL ripetendo il percorso inverso.

Questi tre componenti possono essere visti come una singola unità costituenti insieme l’implementazione software server side.

3.3.1 - Il Database

Come DBMS (DataBase Management System) viene usato Oracle Database, sistema per la gestione di basi di dati scritto in C, che è tra i più famosi e impiegati al mondo per la costruzione di basi di dati che implementano l’ormai standard modello relazionale.

27

Tale DBMS è alla base del funzionamento del framework in quanto al suo interno vengono salvati dei dati, in apposite tabelle, necessari per configurare gli oggetti che vengono realizzati mediante il tool.

Tra le tabelle più importanti abbiamo:

 T_TYPE_OBJECT: la tabella contiene i tipi di oggetti disponibili (es. report, inputForm, filter ect). Diversamente dal BMF2 vengono distinte con oggetti diversi le cartelle del menù di navigazione (menu_folder) dai pulsanti di navigazione contenuti nelle suddette cartelle (menu_item)

 T_OBJECT: tabella contenente tutti gli oggetti, sia quelli di configurazione per il frontend del BMF3.x utili per il funzionamento del framework, sia gli oggetti creati dagli utenti per la creazione di applicativi

 T_UTENTE: elenco degli utenti, coi dati anagrafici/amministrativi, user e password con cui accedere al proprio account sul BMF3.x

 T_PROFILO: elenco dei profili disponibili, di cui ‘AMMINISTRATORE DI SISTEMA’ è quello a cui son garantiti tutti i diritti in lettura/scrittura

 REL_UTENTE_PROFILO: relazione che associa i profili ai diversi utenti esistenti

 REL_MENU_FRONTEND: relazione che associa gli oggetti menu_item agli oggetti menu_folder definendo la struttura del menù

 REL_OBJECT_PROFILO: relazione contenente l’access control list (ACL) per il frontend del BMF3.x

 V_MENU_FRONTEND: vista necessaria per rappresentare il menù del sito

 P_SALVA_OBJECT_BMF3: store procedure per inserire o modificare un oggetto di tipo BMF3.x

 P_OBJECT_BMF3_SAVE_AS: store procedure per fare il “save as” di un oggetto di tipo BMF3

 TR_OBJECT: trigger per inserire in automatico i diritti sugli oggetti BMF3.x per il profilo amministratore del sito

3.3.2 - Server Side

La parte server side è stata implementata secondo lo stile architetturale REST (Representational State Transfer), oggi spesso preferito al protocollo SOAP (Simple Object

28

Access Protocol) per la sua efficienza e scalabilità e la sua capacità di conservare ed esaltare le caratteristiche intrinseche del Web senza la necessità di costruire sovrastrutture in aggiunta a quelle già messe a disposizione dal protocollo HTTP, sono stati pertanto creati una serie di Web Services RESTEasy che, tramite il Tomcat, comunicano con la parte client inviando le risposte in formato json. Tale formato è stato scelto per facilitare la separazione logica tra server e client, in quanto utilizzabile facilmente da qualsiasi linguaggio di programmazione, così da poter cambiare interamente all’occorrenza l’implementazione client side senza dover intervenire su quella server e viceversa.

Per la parte di configurazione e accesso al database viene utilizzato il framework di Spring. 3.3.3 - Web Server e Application Server

Come anticipato poc’anzi, la comunicazione tra server e client è presa in carico dal software della Apache Software Foundation, Apache Tomcat, o semplicemente Tomcat. Questa è una piattaforma software open source per l’esecuzione di applicazioni Web basato su Java ed è tra i più utilizzati tanto da essere quasi uno standard, in un’architettura a 3 livelli (DB server – Application Server – Web Server) è in grado di ricoprire ben due ruoli, difatti lavora sia da Web Server, gestendo le richieste di trasferimento di pagine web del client tramite protocollo HTTP o HTTPS, che da Application Server, implementando la logica di business dell’architettura multilivello.

Il Tomcat è inoltre un servlet container capace di gestire le servlet utili alla corretta fruizione dei servizi web e alla creazione delle pagine web dinamiche, queste vengono infatti create a runtime a partire da dei file JavaServer Pages (JSP) che implementano la logica di presentazione, i quali vengono compilati da un apposito motore JSP anch’esso contenuto nel Tomcat. JSP è una tecnologia alternativa rispetto a numerosi altri approcci per la generazione di pagine Web dinamiche, come per esempio PHP, ASP e CGI.

3.3.4 - Client Side

Alle nozioni su discusse della parte client possiamo aggiungere che questa è stata realizzata interamente in javascript mediante il supporto di diversi framework:

 jQuery  Backbone.js  Marionette.js

29  Underscore.js

 Require.js  Handlebars.js

La parte di template è realizzata in HTML5, mentre viene adoperato il framework Bootstrap per la parte grafica.

3.4 - Gli oggetti BMF

Il BMF mette a disposizione una gamma di funzionalità diverse che permettono di fare reportistica e dataentry sulle tabelle del database. Tra le funzionalità disponibili le più importanti permettono di creare dei report in forma tabellare, di utilizzare in alternativa o in aggiunta ai report grafici di vario tipo (es. istogrammi, grafici a torta, grafici lineari ect), di creare dei filtri di ricerca per fare query sui dati, di usare gli input form per fare INSERT o UPDATE su base di dati, di creare dei pulsanti (buttons o group buttons) che diano navigabilità all’applicazione.

Per aggiungere tali funzionalità all’applicazione è necessario creare e configurare i cosiddetti oggetti BMF (report, inputForm, filter ect), tali oggetti vengono configurati in formato json in quanto è facilmente gestibile via javascript ed è anche molto intuitivo per l’operatore finale che sviluppa l’applicazione. Il BMF, inoltre, mette a disposizione un tool per la configurazione guidata dei singoli oggetti, lasciando all’utente più esperto la possibilità di editare direttamente il json di configurazione.

30

Sono diversi gli oggetti messi a disposizione dal framework che possono essere aggiunti all’applicazione permettendo al programmatore di creare delle interfacce dinamiche con cui è possibile visualizzare il contenuto delle basi di dati, applicare dei filtri sulla ricerca dei dati tramite l’uso di parametri e all’occorrenza modificare le tabelle aggiornando dati esistenti o inserendone di nuovi. Gli oggetti più significativi utilizzati per la costruzione delle maschere che costituiscono l’applicazione di cui tratta questo lavoro di tesi sono i report e i filtri. 3.4.1 - Report

L’oggetto report serve per visualizzare le informazioni estrapolate da una base di dati in formato tabellare. In particolare nella configurazione dell’oggetto è presente un campo in cui va inserita la query che il database deve eseguire in cui nella clausola where, oltre alle condizioni statiche che si desidera soddisfare, è presente una speciale condizione del tipo “where/and <condizioni>”. Questo particolare tag viene elaborato lato client per integrare ulteriori condizioni in maniera dinamica qualora si applicassero ad esempio dei filtri di ricerca. {

"type": "report", "report": {

"title": "Lista Azioni", "className":"",

"collapse":"", "customUrlBase":"",

"customization":"datiAudit", "cols": {

"T_ACTION_OID":{"label":"Action OID"},

"EXTENSION":{"label":"EXTENSION (Schema/Table)"}, "ORG":{"label":"ORG (Schema/Table)"},

"T_MODE_ACTION_DEF_DESCR":{"label":"Azione"}, "DATA_AZIONE":{"label":"Data Azione"}, "ORA_AZIONE":{"label":"Ora Azione"}, "NOTE_AZIONE":{"label":"Note informative"} }, "idxs": [ "T_ACTION_OID", "EXTENSION", "ORG", "T_MODE_ACTION_DEF_DESCR", "DATA_AZIONE", "ORA_AZIONE", "NOTE_AZIONE" ] } }

Per quanto riguarda il json di configurazione, le proprietà più importanti e obbligatorie degli oggetti report sono cols e idxs, il primo è un oggetto javascript con all’interno delle coppie chiave-valore in cui per ogni campo della query che deve essere visualizzato (chiave) sono specificate alcune proprietà, come l’etichetta da mostrare nell’intestazione della tabella, sotto forma di oggetto js (valore), mentre il secondo è un vettore contenente l’intero elenco dei campi della query che devono essere mostrati nella tabella.

31 3.4.2 - Filtro

Il filtro è un oggetto che rende dinamica la visualizzazione del report mettendo a disposizione dell’utente dei campi che facoltativamente o obbligatoriamente vengono valorizzati da questo andando così ad aggiungere dinamicamente delle condizioni alla clausola ‘where’ della query presente nell’report modificandone così la risposta da parte della base di dati.

Una volta che i campi sono stati compilati e che la ricerca è stata lanciata i parametri inseriti vengono passati al tomcat dove sono elaborati attraverso una funzione java che genera dinamicamente una query in PLSQL con tutte le condizioni della clausola ‘where’ immesse dall’utente, questa viene inviata alla base di dati la quale risponde restituendo quei record che collimano con le condizioni imposte.

{

"type":"filter", "filter":{

"title":"Ricerca Operatore", "collapse":"N",

"dynamic":"N",

"buttonText":"Avvia Ricerca", "hidden":"", "customization":"filtroAudit", "fields":[ { "id":"FC_AUDIT_FiltroOperatore_id", "name":"FC_AUDIT_FiltroOperatore", "label":"", "session":"N", "default":"", "placeholder":"", "type":"hidden" }, { "id":"T_GU_UTENTE_CODICE_id", "name":"TAB1.T_GU_UTENTE_CODICE", "label":"Codice Operatore", "session":"N", "default":"", "placeholder":"", "type":"text" }, { "id":"T_GU_UTENTE_COGNOME_id", "name":"T_GU_UTENTE_COGNOME", "label":"Cognome Operatore", "session":"N", "default":"", "placeholder":"", "type":"text" }, { "id":"T_GU_UTENTE_NOME_id", "name":"T_GU_UTENTE_NOME", "label":"Nome Operatore", "session":"N", "default":"", "placeholder":"", "type":"text" } ] } }

Qui abbiamo un esempio del json di configurazione di un filtro la cui proprietà più importante è il campo fields, questo è un vettore contenente degli oggetti javascript all’interno dei quali vi sono le specifiche relative a tutti i campi che vogliamo implementare per eseguire il