PHARMA Personal HospitalizAtion Records MAnagement

Transcript

1 UNIVERSITÀ DEGLI STUDI DI FIRENZE Facoltà di Ingegneria Dipartimento di Elettronica e Telecomunicazioni Corso di Laurea in Ingegneria Informatica Specialistica PHARMA Personal HospitalizAtion Records MAnagement Sistema Telematico REST per l Aggregazione e il Riuso di Dati Sanitari Distribuiti sul Web e la Collaborazione tra Personale Medico-Sanitario Tesi di Laurea di Lorenzo Bianchi Relatori Prof. Franco Pirri Correlatori Ing. Maria Chiara Pettenati Prof. Dino Giuli Ing. Lucia Ciofi Ing. Ernesto Iadanza Ing. Stefano Turchi Anno Accademico 2010/2011

2

3 Ringraziamenti Non mi sembra vero di essere giunto alla fine di questo percorso, lungo e spesso faticoso. La mia fortuna nell aver incontrato sempre persone che mi hanno sostenuto si somma alla determinazione che ho avuto nel voler raggiungere il traguardo finale. Ora si volta pagina, ricordando sempre da dove si viene, guardando al futuro. Ringrazio tutta la mia famiglia, è stata un pilastro più che un sostegno, nei successi e nei piccoli incidenti di percorso. Ringrazio la mia fidanzata Francesca che, da quando ci siamo conosciuti, ha avuto sempre parole stimolanti non solo per il compimento dei miei studi ed ha saputo comprendere le mie insicurezze. Ringrazio tutti i miei amici, quelli vicini e quelli lontani. Mi hanno fatto maturare, capire cose e gestire situazioni che quando si affrontano da soli si superano con difficoltà. Non voglio fare un elenco di tutti loro, vorrei però ringraziare Davide che è stato il compagno d avventura negli anni della formazione sia scolastica che universitaria. Ringrazio i miei relatori, il Prof. Franco Pirri e il Prof. Dino Giuli, perché sono esempi di professionalità e perché nei momenti di incontro avuti sono stati preziosi per il completamento del mio bagaglio culturale. Un grazie speciale a coloro che mi hanno accompagnato nel cammino della tesi, iniziando da Maria Chiara, persona davvero eccezionale, sempre disponibile a chiarire ogni mio dubbio ed incitarmi a guardare sempre oltre. Grazie a Lucia per la sua disponibilità e pazienza che ha avuto nell ascoltare le mie perplessità, il suo supporto è stato fondamentale per conseguire un risultato fantastico. Grazie a Stefano, per la sua competenza e per i confronti costruttivi avuti (comprese le risate nei momenti di pausa!). Grazie ad Ernesto, il quale è l ideatore di questo lavoro insieme a Maria Chiara, mi ha sempre spinto a migliorarmi ed è stato capace di tradurre le discussioni tecniche avute in un linguaggio semplice e chiaro.

4 Un ringraziamento anche a tutte le altre persone conosciute durante questi mesi, da Riccardo, altro membro del team, che ha saputo darmi utili consigli operativi e momenti divertenti trascorsi insieme agli altri, fino al personale della Regione Toscana che si è mostrato sempre molto disponibile: Dott.ssa Chiarugi, Dott.ssa Morelli, Dott. Cecatiello, Ing. Masi, Dott. Tartaglia, Dott.ssa Tanzini e Dott. Ranzani. Firenze, 1 luglio 2011 Lorenzo Bianchi

5 ...la felicità deriva dalla libertà e la libertà dal coraggio... Tucidide

6

7 A Francesca ed alla mia famiglia

8

9 Indice Introduzione xix I Stato dell arte, dati sanitari elettronici (e-health) 1 1 Electronic Health Record Le diverse terminologie adottate nel settore dell EHR Interoperabilità nell EHR Standard per interoperabilità Health Level 7 (HL7) CEN Standard di Interoperabilità Internazionali Attività connesse all Electronic Health Record in Italia Piano per la Sanità Elettronica in Italia Il Tavolo Permanente di Sanità Elettronica Il Fascicolo Sanitario Elettronico La Carta Nazionale dei Servizi Linee guida sul FSE Contenuti del Fascicolo Sanitario Elettronico Infrastruttura Nazionale per il Fascicolo Sanitario Elettronico Connectivity Layer - Sistema Pubblico di Connettività 22 Architettura del SPC

10 Indice Component Layer Il Fascicolo Sanitario Elettronico in Toscana Infrastruttura FSE per la Toscana La Cartella Clinica Elettronica La Scheda Terapeutica Unica Progetti a livello italiano per la cartella clinica elettronica Progetto iclinic Progetto BusterMED Progetto SiPad La Carta della Salute dell Ospedale Bambin Gesù II Stato dell arte, architettura Web per l interoperabilità 51 3 InterDataNet IDN Information Model Strutturare secondo il principio di responsabilità Identificazione dei nodi Storico dei documenti La propagazione delle modifiche I parametri di versione IDN Compliant Application IDN Service Architecture Attraversamento dei livelli Imbustamento di dati e metadati IDN naming system REST: metodologia di progettazione e pattern di utilizzo REST Principi Tecnologici La metodologia di progettazione REST Identificare le risorse di interesse Le relazioni fra le risorse Definizione di URI per le risorse viii

11 Indice Interfaccia uniforme per le risorse Disegnare e documentare le rappresentazioni delle risorse Implentazione e Testing Servizio composito RESTful Servizio composto RESTful III PHARMA 95 5 Progettazione in ottica REST del sistema PHARMA Identificazione delle Risorse Relazioni tra le Risorse Definizione degli URI Considerazioni Operazioni sulle Risorse Operazioni: Caso generale Definizione di Ruoli specifici (privilegi sulle Risorse) Attore MEDICO Attore CAPOSALA Attore INFERMIERE / OPERATORE Progettazione e Documentazione delle Risorse Progettazione dell Information Model Casi d uso, flussi di collaborazione MEDICO crea un Intervento / Trattamento in una Terapia Giornaliera OPERATORE esegue un Intervento / Trattamento in una Terapia Giornaliera MEDICO aggiunge un Referto ad un Intervento / Trattamento in una Terapia Giornaliera OPERATORE legge dati di una Terapia Giornaliera. 122 MEDICO modifica la Programmazione di una Prescrizione / Somministrazione in una Terapia Giornaliera Interazioni tra le entità in chiave REST Premesse ix

12 Indice Operazioni relative all attore MEDICO Operazioni relative all attore CAPOSALA Operazioni relative all attore INFERMIERE / ALTRO 148 Operazioni delegate alla parte server Implementazione e Testing Scelte di implementazione Interfaccia Grafica Utente (GUI) Finestra principale dell interfaccia grafica Finestra della Cartella Clinica dell interfaccia grafica Finestra della Terapia Giornaliera dell interfaccia grafica Finestra del Consenso dell interfaccia grafica Finestra del Referto dell interfaccia grafica Discussione Studio di Usabilità della GUI Analisi con Cognitive Walkthrough Descrizione del sistema Descrizione del compito da eseguire sul sistema: prescrizione di un nuovo farmaco (soggetto a consenso) ad un paziente per una prestabilita data Azioni necessarie per portare a termine il compito Descrizione delle Azioni Note sugli utenti in relazione al compito Operazioni sulla GUI relative all azione analizzata Questionario di valutazione della GUI Analisi della GUI da parte del Centro per la Gestione del Rischio Clinico e la Sicurezza del Paziente (GRC) della Regione Toscana Architettura del sistema PHARMA PHARMA Client La diffusione dei web browser Architettura di riferimento di un web browser Architettura di Mozilla Firefox x

13 Indice Tecnologie utilizzate e confronto con HTML PHARMA Server Tecnologie utilizzate IDN Stack Rappresentazione di un VR-Node Rappresentazione di un SI-Node Il pattern per la creazione di una applicazione IDN Pattern di utilizzo attuale per PHARMA Pattern di utilizzo previsto per le applicazioni IDN Elementi Evolutivi PHARMA e il Fascicolo Sanitario Elettronico Infrastruttura Tecnologica del Fascicolo Sanitario Elettronico Caso specifico: il FSE regionale toscano Funzioni e Caratteristiche da implementare IV Appendici 285 A Convenzioni tra PHARMA Client e PHARMA Server 287 A.1 Convenzioni sul VR-Document A.2 Convenzioni sugli attributi NodeLocalName e LocalName A.3 Convenzioni sull attributo Meta A.4 Convenzioni sui messaggi di risposta da parte del PHARMA Server B Confronto con prodotti simili a PHARMA 297 Conclusioni 300 Bibliografia 305 xi

14

15 Elenco delle figure 2.1 Infrastruttura FSE Gestione dei documenti - confronto degli approcci centralizzati e decentrati Tabella delle responsabilità Scheda Terapeutica Unica della Regione Toscana Logo del progetto IDN InterDataNet: visione d insieme Generazione delle revisioni Merge di due nodi Esempio di propagazione delle modifiche Esempi di last relativi al branch Esempio di elemento recente rispetto al nodo di partenza Espressione regolare per definire gli identificativi di versione Convenzione sui nomi dei nodi nello storico Livelli dell architettura IDN Interazione request/response applicata ad IDN Imbustamento di dati e metadati Classi di metadati in IDN Sistema dei nomi di InterDataNet Elementi architetturali REST Access control e caching Servizio Composito RESTful

16 Elenco delle figure 5.1 Logo dell applicazione PHARMA Relazione tra le Risorse progettate Caso generale delle possibili chiamate HTTP sulle Risorse Rappresentazione grafica dell operazione POST sulla risorsa virtuale Box Cartelle Rappresentazione grafica dell operazione POST sulla risorsa virtuale Box Terapie Rappresentazione grafica dell operazione POST sulla risorsa virtuale Box Referti Illustrazione delle possibili chiamate HTTP sulle Risorse da parte del MEDICO Illustrazione delle possibili chiamate HTTP sulle Risorse da parte del CAPOSALA Illustrazione delle possibili chiamate HTTP sulle Risorse da parte dell INFERMIERE / OPERATORE Information Model: prima parte relativa al Fascicolo Ospedaliero (Anagrafica) Information Model: seconda parte relativa al Fascicolo Ospedaliero (Cartelle Cliniche) Information Model: Dettaglio dei documenti Diario, Consulenze e Diagnosi (parte di Cartella Clinica) Information Model: Dettaglio dei documenti Trasferimenti e Scheda Dimissioni Ospedaliera (parte di Cartella Clinica) Information Model: Dettaglio del documento Terapia Giornaliera (parte di Cartella Clinica) Caso d uso: MEDICO crea un Intervento / Trattamento in una Terapia Giornaliera (prima parte) Caso d uso: MEDICO crea un Intervento / Trattamento in una Terapia Giornaliera (seconda parte) Caso d uso: OPERATORE esegue un Intervento / Trattamento in una Terapia Giornaliera (prima parte) Caso d uso: OPERATORE esegue un Intervento / Trattamento in una Terapia Giornaliera (seconda parte) xiv

17 Elenco delle figure 5.19 Caso d uso: MEDICO aggiunge un Referto un Intervento / Trattamento in una Terapia Giornaliera (prima parte) Caso d uso: MEDICO aggiunge un Referto un Intervento / Trattamento in una Terapia Giornaliera (seconda parte) Caso d uso: OPERATORE legge dati di una Terapia Giornaliera (prima parte) Caso d uso: OPERATORE legge dati di una Terapia Giornaliera (seconda parte) Caso d uso: MEDICO modifica la Programmazione di una Prescrizione / Somministrazione in una Terapia Giornaliera (prima parte) Caso d uso: MEDICO modifica la Programmazione di una Prescrizione / Somministrazione in una Terapia Giornaliera (seconda parte) Interazioni attraverso chiamate HTTP: Lettura dati della risorsa Terapia Giornaliera Interazioni attraverso chiamate HTTP: Creazione del documento Interventi / Trattamenti per un documento Terapia Giornaliera di una data Cartella Clinica Interazioni attraverso chiamate HTTP: Registrazione di avvenuta esecuzione di un Intervento / Trattamento per un documento Terapia Giornaliera di una data Cartella Clinica Interazioni attraverso chiamate HTTP: Modifica del Referto nel documento Intervento / Trattamento per un documento Terapia Giornaliera di una data Cartella Clinica Interazioni attraverso chiamate HTTP: Creazione di un documento Cartella Clinica (si considera qui anche la creazione, eventuale, della risorsa Fascicolo Ospedaliero) Interfaccia Grafica Utente di PHARMA: finestra principale. Nel riquadro verde si individua la sezione per l autenticazione utente, in rosso la parte per la ricerca di un paziente e in blu si trovano i dati del paziente stesso xv

18 Elenco delle figure 6.2 Interfaccia Grafica Utente di PHARMA: finestra Cartella Clinica. Nel riquadro giallo si individua la barra dei menù, in rosso la barra dei segnalibri, in blu la parte dei dati relativi al ricovero del paziente e in verde la sezione che elenca i documenti per il processo di cura della persona ricoverata Interfaccia Grafica Utente di PHARMA: finestra Terapia Giornaliera. Con i vari colori si identificano le parti che la compongono Interfaccia Grafica Utente di PHARMA: finestra Consenso. Nel riquadro giallo si individua la barra dei menù, in rosso la barra dei segnalibri, in verde i dati dell intestazione del documento, in blu scuro il corpo dell atto e in celeste la sezione che registra la firma del paziente Interfaccia Grafica Utente di PHARMA: finestra Referto. Nel riquadro giallo si individua la barra dei menù, in rosso la barra dei segnalibri, in verde i dati dell intestazione del documento e in blu scuro il corpo dell atto Interfaccia Grafica Utente di PHARMA: finestra principale (visione Infermiere / Altro). Si nota che la parte di Anagrafica è in modalità sola lettura Interfaccia Grafica Utente di PHARMA: finestra Terapia Giornaliera (visione Caposala). Si nota che la funzione Nuovo è disabilitata così come le parti relative alle Prescrizione e agli Interventi Visuale della finestra del browser Mozilla Firefox; nella barra di stato si evidenzia una tra le possibilità di avviare l applicazione PHARMA Finestra principale dell applicazione che viene mostrata una volta avviata PHARMA Dettaglio della finestra principale di PHARMA: sezione di Autenticazione; la freccia rossa indica il pulsante necessario per accedere al servizio Finestra principale dell applicazione dopo aver effettuato il login.227 xvi

19 Elenco delle figure 7.5 Dettaglio della finestra principale di PHARMA: sezione di Ricerca Dati Paziente; per prima cosa si deve sceglie il tipo di ricerca (freccia rossa) e successivamente si avvia la ricerca con l apposito comando indicato dalla freccia verde Finestra principale dell applicazione dopo il passaggio di ricerca della persona ricoverata; il caso mostrato è una ricerca con successo Finestra principale dell applicazione accesso ai dati delle Cartelle Cliniche; il caso mostrato indica come creare una Cartella Clinica per un paziente ricoverato (freccia rossa) Finestra principale dell applicazione accesso ai dati delle Cartelle Cliniche; la freccia rossa indica una delle diverse modalità per accedere ai dati di una Cartella Clinica, previa selezione della riga che la rappresenta Schermata della Cartella Clinica; la freccia rossa evidenzia uno tra i modi per aggiungere un nuovo documento alla Cartella stessa Finestra di dialogo della Terapia Giornaliera; la freccia rossa indica uno tra i modi esistenti per aggiungere un nuovo elemento alla Terapia stessa Finestra di dialogo della Terapia Giornaliera; la freccia rossa indica una voce (Prescrizione) aggiunta con il comando Nuovo Finestra di dialogo del Consenso; la schermata è relativa all apertura del documento dalla Terapia Giornaliera Riassunto delle problematiche riscontrate col Centro per la Gestione del Rischio Clinico Scenario di collaborazione all interno di una struttura ospedaliera tra attori distinti Dettaglio delle metodologie di collaborazione tra due attori su di un oggetto condiviso Architettura progettata mirata al lavoro collaborativo Architettura di riferimento di un browser Architettura di riferimento del browser Mozilla Firefox xvii

20 Elenco delle figure 8.6 Dettaglio dell architettura di riferimento del PHARMA Server Struttura della componente PHARMA Server Paradigma attuale per una applicazione IDN Paradigma previsto per una applicazione IDN B.1 Comparazione di PHARMA con prodotti analoghi disponibili sul mercato Italiano xviii

21 Introduzione Questo lavoro si colloca nel contesto della Sanità Elettronica e porta particolare contributo nella gestione informatizzata e distribuita delle cartelle cliniche di persone ricoverate all interno di una struttura ospedaliera. Il bisogno di gestire l informazione del paziente assistito in modo più efficace sostiene la tendenza ad avvalersi di documentazione digitale, interoperabile e portabile. Tuttavia, sono limitatissimi gli approcci unitari ed integrati al problema; spesso soluzioni ad-hoc o sviluppate localmente si diffondono nei presidi sanitari/ospedalieri come standard di fatto per la gestione delle cartelle cliniche elettroniche, senza che tali soluzioni vengano valutate rispetto ad importanti criteri che ne qualificano validità, efficacia e sicurezza. Tra le caratteristiche fondamentali degli approcci alla gestione elettronica delle cartelle cliniche questo lavoro enfatizza le seguenti qualità: la completezza dell informazione trattata nella cartella clinica (dalla scheda terapeutica al diario clinico, ai referti, ai consensi, etc.); la possibilità di collaborare su tutte le informazioni condivise e distribuite per tutti i soggetti coinvolti nel processo di cura; la scalabilità della soluzione proposta; il supporto alla gestione della cartella clinica in condizioni di mobilità;

22 Introduzione la gestione e riduzione del rischio clinico 1. Nel nostro Paese, il Tavolo permanente di Sanità Elettronica delle Regioni e delle Province Autonome (TSE) ha lo scopo di armonizzare gli interventi e definire un quadro di regole tecniche condivise per la Sanità Elettronica. Il TSE ha prodotto nell ottobre 2010 delle linee guida non prescrittive per quanto riguarda il Fascicolo Sanitario Elettronico (FSE) [Min] ed ha fotografato lo stato dell arte al dicembre 2010 [Pre10a] dei progetti che riguardano implementazioni del FSE per un totale di 16 iniziative tra Regioni e Province Autonome. A livello di singola regione emergono approcci significativi, anche di eccellenza, per l interoperabilità di dati sanitari in vista dell introduzione di un Fascicolo Sanitario Elettronico [fas] a livello nazionale e successivamente europeo. Tali iniziative sono spesso collegate con la Carta Nazionale dei Servizi (CNS) [CNS], come avviene per la Carta Sanitaria Elettronica [CSE] nel caso della Regione Toscana ideata per consentire ai cittadini e al personale tecnico-sanitario la consultazione di tutta la storia clinica degli assistiti. A livello europeo la realizzazione di un visione ehealth di Sanità digitalizzata, pienamente fruibile da tutti i cittadini dell Unione, è un obiettivo strategico e prioritario 2 perseguito col supporto di strumenti di governo, di aiuti alla ricerca e di incentivi all innovazione 3. In questa direzione, dal 2008 il progetto Europeo su larga scala epsos (European Patients Smart Open Services [eps]) si è posto l obiettivo di sviluppare una infrastruttura ICT in grado di assicurare l interoperabilità dei servizi di Patient Summary ed eprescription a livello europeo, al fine di migliorare 1 Il rischio clinico è la probabilità per un paziente di rimanere vittima di un evento avverso, cioè un danno o disagio imputabile (almeno in parte) alle cure mediche, che causa un prolungamento del ricovero ospedaliero / oppure un peggioramento delle condizioni di salute / oppure la morte. Fonte: ASL2 Lucca [LUC]. 2 ehealth-eu. htm. ICT for Sustainable and Interoperable Health Services. information_society/activities/health/cip_ict_psp/index_en.htm 3 La rete tematica CALLIOPE operante dal 2008 al 2010 ha prodotto la EU ehealthinteroperabilityroadmap [CAL]. xx

23 Introduzione l erogazione delle prestazioni da parte delle strutture ospedaliere e dei medici, facilitando l accesso alle cure sanitarie da parte di cittadini europei in uno Stato Membro diverso da quello di residenza. Il disegno strategico di informatizzazione della Sanità ai vari livelli - locale, regionale, nazionale, europeo - fa leva sui bisogni di abbassare i costi operativi alzando la qualità dei processi di cura e riducendo il rischio clinico. A tal fine le direzioni da perseguire riguardano principalmente: l estensione dell operatività del singolo reparto a tutta l organizzazione sanitaria, garantendo visibilità integrata e manipolazione dei dati sanitari del paziente da parte dei vari soggetti coinvolti; la possibilità di manipolare il mondo informativo complesso centrato sul paziente, attraverso uno strumento più agile e sicuro a supporto dell erogazione di una pluralità di prestazioni sanitarie da parte di competenze specialistiche e vari ruoli professionali tecnico-sanitari. L obiettivo di questo lavoro è quello di realizzare un sistema telematico per la gestione di cartelle cliniche elettroniche di un paziente ricoverato in un reparto. Il sistema è composto da un applicazione chiamata PHARMA (Personal HospitalizAtion Records MAnagement) e da una infrastruttura denominata InterDataNet [PCPG11]. Trattando dati personali distribuiti logicamente e fisicamente, PHAR- MA ha l obiettivo di valorizzare le proprietà e caratteristiche del middleware InterDataNet. L applicazione PHARMA consente la gestione di cartelle cliniche elettroniche di un paziente, introducendo anche il concetto di fascicolo ospedaliero che integra tutti i dati riferibili alla storia clinica di un paziente ricoverato. InterDataNet è un infrastruttura stratificata che consente ad utenti distribuiti nel tempo e nello spazio di collaborare intorno ad elementi informativi, appartenenti ad uno spazio globale di dati distribuiti, su cui è possibile interagire mediante la metafora dei documenti. Questi ultimi sono dotati di una xxi

24 Introduzione determinata struttura interna, un definito workflow e una particolare semantica delle parti. Gli elementi informativi che compongono tali documenti, così come i documenti stessi, devono potere essere identificati ed acceduti in un modo da favorirne il riuso collaborativo. Il contributo fornito nel corso di questo lavoro riguarda la progettazione e l implementazione del sistema telematico prototipale PHARMA, secondo un approccio in chiave REST [RR07]. PHARMA è accessibile all utente finale attraverso un entità client (PHAR- MA Client), con cui personale medico-sanitario e pazienti possono interagire e collaborare sul documento cartella clinica con i diritti di consultazione e modifica relativi al proprio ruolo. Scenari tipici all interno del contesto di PHARMA sono ad esempio: il medico prescrive un farmaco, l infermiere somministra il farmaco oppure il tecnico esegue il referto su una analisi di laboratorio. Il contenuto della tesi si articola in quattro parti, delle quali le prime due forniscono il contesto di riferimento e il quadro dello stato dell arte, la terza illustra la progettazione ed i risultati conseguiti attraverso questo lavoro mentre nell ultima delle quattro sono riportate le appendici. Parte I - Stato dell arte, dati sanitari elettronici (e-health) La prima parte, costituita da due capitoli, introduce il contesto di riferimento per gli obiettivi di questa tesi. Il primo capitolo presenta la terminologia nel contesto di analisi di PHARMA dando anche informazioni su standard usati attualmente per l interoperabilità di dati clinici; il secondo invece tratta le attività italiane connesse a questo tipo di sviluppi. Parte II - Stato dell arte, architettura Web per l interoperabilità La seconda parte, formata anch essa da due capitoli, fornisce lo stato dell arte su cui il sistema telematico PHARMA si basa. Il capitolo xxii

25 Introduzione 3 descrive l architettura stratificata InterDataNet mentre il capitolo 4 richiama la metodologia di progettazione REST ed il suo pattern di utilizzo, con particolare attenzone ai servizi compositi. Parte III - PHARMA La terza parte è quella centrale del presente lavoro ed ha lo scopo di dettagliare gli aspetti progettuali ed implementativi del contributo originale fornito. Essa si articola in cinque capitoli. Il capitolo 5 è il cuore della progettazione che riprende i dettami del capitolo 4 applicati al contesto della cartella clinica; i due successivi descrivono il disegno dell interfaccia grafica utente (GUI), illustrando le varie componenti della stessa interfaccia (capitolo 6) e fornendo anche dettagli sullo studio di usabilità effettuato nel corso del lavoro (capitolo 7). Il capitolo 8 illustra l architettura ideata per PHARMA dettagliandone anche le varie componenti presenti. Infine il capitolo 9 delinea lo stato attuale del sistema per valorizzarne ricadute e sviluppi ad esso collegati. Parte IV - Appendici L ultima parte, composta da due Appendici, mostra alcuni dettagli tecnici in termini di convenzioni usate tra PHARMA Client e PHARMA Server (Appendice A) e un confronto di PHARMA con alcune realtà presenti sul mercato Italiano (Appendice B). xxiii

26

27 Parte I Stato dell arte, dati sanitari elettronici (e-health)

28

29 Capitolo 1 Electronic Health Record Un Electronic Health Record (EHR) che riesca a cogliere in modo longitudinale tutti i dati relativi alla vita clinica di un paziente, rappresenta da molti anni una sfida per fornire una vista integrata e significativa dell intera storia clinica di un paziente. Purtroppo, sono state incontrate un numero elevato di difficoltà nella sua effettiva realizzazione. I principali problemi riscontrati riguardano la necessità di avere a disposizione standard per l interoperabilità che permettano di condividere dati clinici, riuscendo nello stesso tempo a mantenere fedelmente il loro significato clinico. Inoltre, significativi problemi sono relativi alla protezione della confidenzialità dei dati sensibili affinchè un paziente possa affidarsi, con ragionevole fiducia, a sistemi per la gestione dell EHR. Fino ad oggi la gestione integrata dei dati clinici, non considerando lettere e report sanitari cartacei, è stata principalmente basata su set di messagi elettronici trasmessi usando EDIFACT o HL7.

30 Electronic Health Record 1.1 Le diverse terminologie adottate nel settore dell EHR Nel settore dell Electronic Health Record sono proliferati con il tempo molteplici termini i cui significati sono ancora sfumati e non usati con coerenza [Hab10]. Per quanto riguarda il presente lavoro di tesi saranno utilizzati seguenti termini. Il Personal Health Record (PHR) è un sistema che permette ai singoli pazienti di mantenere e gestire le informazioni relative alla propria salute in modo privato, sicuro e confidenziale 1. L Electronic Health Record (EHR) è il sistema che permette a pazienti, medici e altri operatori sanitari di accedere ai dati clinici di un paziente presenti in diverse strutture aggiornati in tempo reale 1. Si deve notare che il PHR non costituisce un alternativa ma bensì un complemento per l EHR [SCMK10]. Tale sistema ha molteplici sorgenti fra cui l Electronic Medical Record (EMR) che costituisce l insieme di dati con validità legale che sono creati negli ospedali oppure negli ambulatori. Questo insieme di dati costituisce la sorgente per l Electronic Health Record e, nello specifico, è possibile considerare l Hospitalization Records (HR) l insieme dei dati personali e di informazioni cliniche significative relative ad un paziente per un singolo episodio di ospedalizzazione 2. 1 Definizione data da Office of the National Coordinator for Health Information Technology (ONC). 2 Ministero della Salute,

31 Electronic Health Record 1.2 Interoperabilità nell EHR L utilizzo di standard come formati di interscambio è uno dei prerequisiti per l interoperabilità dei sistemi EHR. Per persone o computer è possibile condividere dati clinici solo se: 1. hanno funzionalità che permettono di comunicare fisicamente (ad esempio parlare ed ascoltare, spedire e ricevere documenti o dati, condividere dati ed informazioni); in questi termini si parla di interoperabilità funzionale ; 2. parlano mediante un vocabolario comune (in termini di nomi, verbi, strutture grammaticali, etc.) e condividono lo stesso vocabolario che permette di capire processi e condizioni mediche; in questi termini si parla di interoperabilità semantica. L interoperabilità funzionale coinvolge i livelli più bassi del classico modello OSI (i sei livelli dal basso) mentre l ultimo obiettivo da raggiungere è l interoperabilità semantica che implica una compatibilità fra sistemi all ultimo livello (livello 7). Come persone provenienti da diverse nazioni, dove sono parlate lingue diverse, sono in grado di comunicare solo se parlano una lingua comune, le applicazioni per computer possono condividere informazioni solo se comunicano usando un protocollo condiviso. Esistono molti standard relazionati all EHR (sia formali che informali) che sono gestiti da diverse organizzazioni ad esempio CEN/TC 251, ISO/TC 215, HL7, DICOM, IEEE, etc. Sviluppatori di sistemi EHR necessitano di una guida che identifichi gli standard più rilevanti e aggiornati nel grande mare di tutti gli standard relativi al mondo EHR. 5

32 Electronic Health Record Standard per interoperabilità A livello internazionale è stato fatto un grande sforzo nel tentativo di sviluppare standard per lo scambio di informazioni per l EHR fra sistemi diversi. Principalmente, in Europa, si sono concentrati gli sforzi per la realizzazione di tali standard con la Committee for European Normalisation (CEN) il cui principale risultato è stato il modello CEN Attività complementari sono state realizzzate da HL7, che è di origine statunitense, e ISO. Sono però tuttora aperti problemi legati all interoperabilità semantica poichè ancora non sono state individuate soluzioni significative. e HL7. Saranno nel seguito brevemente ripresi concetti degli standard CEN Health Level 7 (HL7) L organizzazione Health Level 7 (HL7) [hl7] nasce nel 1987 negli Stati Uniti per affrontare la proliferazione di messaggi utilizzati dai fornitori di sistemi per il settore delle assicurazioni sanitarie. L obiettivo princiaple era creare un insieme di formati standard, per definire le interfacce per lo scambio dei dati in formato elettronico negli ambienti sanitari, dove era necessario far interagire applicazioni prodotte da diversi fornitori. Con il tempo, il protocollo di interoperabilità HL7 è divenuto uno standard internazionale accettato in tutto il mondo. Sono state realizzate tre diverse versioni dello standard HL7. La versione 2 ha previsto una standrdizzazione dei messaggi, principalmente per quanto riguarda gli aspetti concernenti le cure di un paziente all interno di un ospedale ed attualmente è ampiamente utilizzato nei sistemi informativi degli ospedali in tutto il mondo. 6

33 Electronic Health Record Nonostante la diffusione dell utilizzo di HL7 v.2 a livello internazionale, la nascita di vari problemi connessi ad implementazioni inconsistenti hanno limitato l effettiva realizzazione dell interoperabilità fra sistemi ospedalieri così come auspicato. In conseguenza di ciò, è stata definita una nuova versione dello standard, denominata HL7 v.3, che mette grande rilevanza sul Reference Information Model (RIM) il cui scopo è specificare il contentuto informativo dei messaggi per riuscire a garantire un uso consistente degli stessi. Nello specifico, il RIM rapprenseta le classi e gli attributi core che verranno adottati in diverse combinazioni dai diversi messaggi dello standard HL7 v.3. Il RIM definisce quattro principali classi di informazioni: entità: per esempio persone, organizzazioni, luoghi e strumenti; ruoli: per esempio il paziente o l impiegato; relazioni: per esempio quella fra medico e paziente; atti: per esempio le registrazioni relative a visite mediche o procedure adottate. La HL7 Clinical Document Architecture (CDA), che fa parte di HL7 v.3, definisce la struttura di un generico messaggio per la comunicazione di un documento clinico derivato dal RIM come modello per i messaggi. Si tratta di uno standard basato sul formato XML che specifica come l informazione granulare è organizzata all interno di un documento. Il HL7 Template Special Interest Group si occupa di lavorare ad una specifica per i vincoli sui modelli dei messaggi derivati dal RIM, basandosi sugli approcci openehr e su archetipi descritti più avanti (sezione 1.2.1). CEN Nel dicembre 2001 la Health Informatics Technical Committee, che fa parte delle organizazzione per la definizione delle norme europee (CEN), nominò una Task Force, nota come EHRcom, per rivedere il pre-standard 7

34 Electronic Health Record ENV del 1999 riguardante le comunicazioni per gli EHR, al fine di produrre una norma definitiva europea e che ha portato alla realizzazione del CEN [CEN]. La missione della task force era quella di produrre una rigorosa e durevole architettura delle informazioni per rappresentare gli EHR, al fine di supportare l interoperabilità di sistemi e componenti che devono interagire con servizi EHR: come i sistemi discreti o come componenti di middleware; per accedere, trasferire, aggiungere o modificare gli health record; tramite messaggi elettronici o oggetti distribuiti; mantenendo l originale significato clinico previsto dall autore; riflettere sulla riservatezza di tali dati come previsto dall autore e dal paziente. Il CEN è uno standard composto di cinque parti: Parte 1: Reference Model, è un modello generico di EHR disegnato sui risultati di quattordici anni di lavoro di progetti di ricerca e sviluppo (e di due precedenti standard CEN); ricalca il RIM e la Clinical Document Architecture di HL7. Parte 2: Archetype Interchange Specification, è un modello di informazione e di scambio di sintassi per la comunicazione di archetipi; questo specifica si rifà all adozione dell approccio openehr ad archetipi (paragrafo 1.2.1) e permette la compatibilità con HL7 Template specification. Parte 3: Reference Archetypes and Term Lists, contine una serie di vocabolari e liste di termini a sostegno del Reference Model, una guida su come utilizzare le classi e gli attributidi del modello di riferimento ed infine come progettare archetipi. Parte 4: Security, definisce le misure di sostegno al controllo degli accessi, il consenso e la verificabilità delle comunicazioni per gli EHR. 8

35 Electronic Health Record Parte 5: Exchange Models, definisce i messaggi e le interfacce di servizio per permettere la comunicazione fra gli archetipi e gli EHR. Il Reference Model è un modello generico in grado di rappresentare la struttura ed il contesto dei dati contenuti in un EHR di un paziente, al fine di permettere comunicazioni interoperabili tra sistemi e servizi che potrebbero richiedere o fornire dati all EHR. Non è stata però specificata l architettura interna o la progettazione di database di tali sistemi. Lo standard considera l EHR come la raccolta persistente e traversale di dati clinici e servizi di assistenza, relativi ad un unico soggetto in cura (il paziente), potenzialmente multienterprise o internazionale, creati e memorizzati in uno o più sistemi fisici al fine di fornire informazioni per le cure future del soggetto stesso, oltre che fornire un record di cura di natura medico-legale. Mentre un servizio di EHR avrà bisogno di interagire con molti altri servizi o sistemi che forniscono la terminologia, conoscenze mediche, linee guida, flusso di lavoro, sicurezza, registri di persone, fatturazione etc. Questo standard ha preso in condiderazione solo quelle aree dove è necessario tenere qualche traccia persistente delle interazioni avvenute. Può offrire un utile contributo alla progettazione di sistemi EHR, ma è essenzialmente un insieme di interfacce esterne e messaggi costruito su sistemi clinici che altrimenti risulterebbero eterogenei. Questo approccio sembra ragionevole in quanto è possibile prevedere un economia mista di sistemi generici e speicializzati prodotti da diverse organizzazioni. Standard di Interoperabilità Internazionali In questo settore è possibile collocare il lavoro della Fondazione OpenEHR che è stata fondata nel 2000 dall University College di Londra e dalla Ocean Informatics [Kal06]. Il principale obiettivo di tale fondazione è quello di facilitare la creazione e lo scambio di dati clinici tramite implementazioni basate su standard che 9

36 Electronic Health Record adottano una filosofia open-source. In particolare, ha dato significativo risalto ad un nuovo tipo di approccio denominato Dual Model Approach che è stato successivamente ripreso da HL7 e CEN. Il modello Dual Model Approach introduce due diversi tipi di modelli per l informazione: il Reference Model e l Archetype Model. Il Reference Model è un modello dell informazione che rappresenta le caratteristiche globali di componenti dell Health Record. In pratica, definisce i generici blocchi costitutivi degli EHR e viene introdotto in un sistema distribuito per la realizzazione di EHR tramite l impiego di specifici messaggi e interfacce. A questo modello è necessario associare un modello come l Archetype Model che indichi come i vari blocchi costituitivi, definiti nel Reference Model, debbono essere combinati per specifici domini applicativi. 10

37 Capitolo 2 Attività connesse all Electronic Health Record in Italia La realizzazione di quello che è l Electronic Health Record in Italia è oggetto dal 2008 di grande interesse da parte della Pubblica Amministrazione Italiana. Il progetto connesso è riferito con il termine Fascicolo Sanitario Elettronico. Gli sforzi realizzativi hanno tentato di portare una visione unificatrice a livello nazionale a quello che è il proliferare di soluzioni locali ad-hoc sviluppate dalle singole regioni e dalle diverse ASL. L idea di base è riuscire a far convergere dal basso la grande eterogeneità di soluzioni locali per riuscire ad avere una vista unificata dei dati sanitari di ciascun cittadino, indipendentemente dal luogo di residenza. Ad oggi la situazione sul territorio è ancora frammentata, anche se tutte le Regioni sono attivamente impegnate a sviluppare soluzioni condivise e l Italia partecipa con altri undici Stati Membri ad un progetto per l interoperabilità del FSE finanziato dalla Commissione Europea [gova]. Per quanto riguarda i dati che andranno a confluire in tale Fascicolo Elettronico, l aspetto relativo alla Cartella Clinica Elettronica, ovvero l insieme delle informazioni che riguardano i ricoveri ospedalieri di un cittadino,

38 Attività connesse all Electronic Health Record in Italia sono visti come un importante fonte di dati. A livello di cartella clinica le soluzioni adottate sono estremamente localizzate sul contesto di adozione, tenendo poco in considerazione la necessità di integrarsi come sorgente dati del Fascicolo Sanitario Elettronico. 2.1 Piano per la Sanità Elettronica in Italia Nel novembre 2008 è stato presentato il Piano per la Sanità Elettronica, parte specifica del più ampio Piano Industriale per l Innovazione [govb]. Le misure per la Sanità sono esplicitate in 5 aree di intervento, per ciascuna delle quali sono definite le risorse finanziarie destinate e le scadenze per l attuazione come segue: Fascicolo Sanitario Elettronico FSE (21 milioni di euro): realizzare il FSE entro giugno 2009; Rete dei medici di base (32 milioni di euro): connettere in rete tutti i medici di base entro giugno 2010; Certificati di malattia digitali (22 milioni di euro): realizzare il servizio entro dicembre 2009; Ricetta digitale (13 milioni di euro): in quattro contesti regionali (Lombardia, Emilia-Romagna, Veneto, Friuli Venezia Giulia) entro giugno 2009; Prenotazioni on-line (10 milioni di euro): realizzare un sistema sovraregionale (Umbria, Emilia-Romagna, Veneto, Marche e Provincia Autonoma di Trento) Il Tavolo Permanente di Sanità Elettronica Nel novembre 2008 nasce anche il Tavolo Permanente per l Innovazione nella Sanità Elettronica delle Regioni e delle Province Autonome (TSE)[Min]. 12

39 Attività connesse all Electronic Health Record in Italia Questa figura è la sede istituzionale di confronto e di consultazione per l armonizzazione degli interventi e la definizione di un quadro di regole tecniche condivise per la Sanità Elettronica. Il TSE è coordinato dal Dipartimento per la Digitalizzazione della Pubblica Amministrazione e l Innovazione Tecnologica (DDI) ed è composto dai rappresentanti del Ministero della Salute, del DDI e di tutte le Regioni e le Province Autonome. Il Tavolo, oltre a produrre proposte operative finali, definisce un nuovo metodo di lavoro, essenzialmente bottom-up, che andrà a saldarsi allo sforzo top-down del Governo, mentre il livello regionale è stato unanimamente riconosciuto come focale nel nuovo approccio all innovazione nella Sanità. Infatti, l innovazione sanitaria si sta sviluppando attraverso la progettazione e la realizzazione di interventi che sono posti sotto la responsabilità attuativa delle Regioni e delle Province Autonome. La costruzione di una infrastruttura nazionale per la Sanità Elettronica richiede un continuo processo di confronto e di armonizzazione tra i soggetti istituzionali coinvolti, sia a livello centrale che locale, per sviluppare in modalità congiunta e condivisa un quadro normativo di regole tecniche di riferimento. Queste regole costituiscono il presupposto per la realizzazione di una rete di sistemi locali tra loro interoperabili, orientati alla realizzazione dei servizi socio sanitari digitali. Quattro sono le priorità di lavoro individuate: gestire il passaggio dalla carta all elettronico, predisporre i fattori abilitanti per l innovazione, gestire in maniera ottimale ed efficiente il processo clinico-assistenziale sul cittadino e 13

40 Attività connesse all Electronic Health Record in Italia fornire, agli organi di governo del Sistema Sanitario Nazionale, elementi qualitativi e quantitativi sui quali poter decidere. Quattro obiettivi chiave su cui lavorare dal basso per portare il Sistema della Sanità italiana ad un livello di costo sostenibile, mantenendo, o meglio aumentando, la qualità del servizio. Il Tavolo si presenta come uno strumento di interscambio di esperienze e di riflessione non episodico ma duraturo nel tempo (permanente appunto), costruito dal basso, attraverso la collaborazione di coloro che l innovazione la pensano, la progettano e la sperimentano quotidianamente sul campo, ogni giorno, per far fronte alle sempre più pressanti esigenze di contenimento del budget e di aumento delle richieste di prestazioni da parte degli utenti. Gli attori di questo sistema di innovazione sono, in primis, i Direttori Generali di Aziende Sanitarie ed Ospedaliere, che sono i diretti interessati e responsabili del percorso di cambiamento del Sistema Sanitario Italiano, in secondo luogo i referenti del livello regionale e di quello centrale e, fondamentali, i partner tecnologici il cui compito individuato dal Tavolo non è quello di distribuire software, ma di progettare, insieme agli altri attori del sistema, le risposte alle questioni più pressanti. L obiettivo strategico è uno ed è quello di riuscire ad avere un Sistema Sanitario efficiente che, eliminando gli sprechi e riducendo i costi, riesca a tutelare meglio il Diritto alla Salute dei cittadini. Uno degli scogli principali per l innovazione nella Sanità è, infatti, quello di far passare il concetto che i settori amministrativo e clinico devono lavorare in maniera integrata per consentire una programmazione coerente ed orientata al cambiamento e all efficienza. Ed è proprio questo, difatti, uno tra i maggiori obiettivi del Tavolo: creare un luogo di incontro e confronto che riesca ad accreditarsi per autorevolezza come interlocutore ai tavoli della Politica. 14

41 Attività connesse all Electronic Health Record in Italia 2.2 Il Fascicolo Sanitario Elettronico Il Fascicolo Sanitario Elettronico (FSE) [fas] di un cittadino può essere visto come una composizione dinamica di tutti i documenti socio-sanitari inerenti al suo stato di salute. Numerose sono le iniziative in atto, volte a migliorare l efficienza del Servizio Sanitario attraverso azioni quali la personalizzazione delle cure, la riduzione dell errore umano e lo sviluppo di una Sanità centrata sul cittadino. Un pilastro su cui basarsi per il raggiungimento di tale obiettivo è appunto il Fascicolo Sanitario Elettronico: una carta d identità sanitaria, in grado di migliorare l assistenza e di permettere un intervento rapido ed efficace in caso di emergenze, realizzando anche un risparmio di risorse. Il FSE rappresenta lo strumento elettivo per favorire e supportare la cooperazione tra ospedale e territorio, ossia Medici di Medicina Generale (MMG) e Pediatri di Libera Scelta (PLS), e si posiziona al centro del processo di innovazione del Sistema Sanitario Regionale. Il FSE verrà realizzato dalle Regioni, previo consenso dell assistito, e consiste nell insieme dei dati e documenti digitali di tipo socio-sanitario generati da eventi clinici presenti e trascorsi, riguardanti il paziente. Coprirà l intera vita di quest ultimo e sarà costantemente aggiornato dai soggetti che lo prendono in cura. Nelle urgenze, il FSE permetterà agli operatori di inquadrare immediatamente i pazienti: consentirà la continuità delle cure, permetterà di condividere tra gli operatori le informazioni amministrative (ad esempio prenotazioni di visite specialistiche, ricette, etc.). L accesso al FSE potrà avvenire mediante l utilizzo della Carta d Identità Elettronica (CIE) e della Carta Nazionale dei Servizi (CNS). L accesso potrà essere consentito anche attraverso strumenti di autenticazione forte, con l utilizzo di smart card rilasciate da certificatori accreditati, o debole, con l u- 15

42 Attività connesse all Electronic Health Record in Italia tilizzo di userid e password, o con altre soluzioni, purché siano rispettate le misure minime di sicurezza nel rispetto del Codice in materia di protezione di dati personali. La Carta Nazionale dei Servizi La Carta Nazionale dei Servizi (CNS) [CNS] è una smart card per accedere ai servizi on-line della Pubblica Amministrazione su tutto il territorio nazionale. E lo strumento fondamentale per rendere immediatamente fruibili i servizi già in rete e per accelerarne la diffusione. La CNS è una straordinaria innovazione per una nuova e più efficace interazione tra cittadino e Pubblica Amministrazione. La Carta Nazionale dei Servizi permette: le funzionalità della firma digitale; l utilizzo dei servizi in rete da parte del titolare attraverso un certificato di autenticazione della carta, che, in combinazione con il PIN utente, consente le funzioni di riconoscimento in rete; le funzionalità della Carta Sanitaria (funzione facoltativa); l autenticazione del cittadino per servizi anagrafici, modulistica, servizi sanitari, pagamenti on-line; l utilizzo per funzioni di pagamento tra privati e Pubblica Amministrazione grazie ai protocolli di intesa tra queste ultime, le banche e le Poste Italiane; Un elenco di servizi abilitati all utilizzo della CNS oggi attivati dalle Pubbliche Amministrazioni è disponibile sul Portale Nazionale del Cittadino. 16

43 Attività connesse all Electronic Health Record in Italia Linee guida sul FSE Il Fascicolo Sanitario Elettronico che ogni italiano porterà con sé come una vera e propria Carta d Identità Sanitaria, consentirà di migliorare enormemente l assistenza sanitaria, permetterà di intervenire rapidamente ed efficacemente in caso di emergenze e farà risparmiare notevoli risorse al Sistema Sanitario. Le Linee guida individuano gli elementi necessari per una progettazione omogenea del Fascicolo Elettronico su base nazionale ed europea. Con l approvazione in Conferenza Stato-Regioni delle Linee guida sul Fascicolo Sanitario Elettronico proposte dal Ministero della Salute, il 10 febbraio 2011 è stato compiuto un importante passo avanti nell ambito del relativo progetto. Entro il 2012, il FSE potrà essere reso disponibile su tutto il territorio nazionale per i cittadini italiani. La necessità di Linee guida nazionali è nata da una ricognizione effettuata nel 2008 dal Ministero della Salute che ha indicato un buon dinamismo che si sta traducendo in progetti attivi in tutte le Regioni, ma con troppe differenziazioni nelle soluzioni applicative, nei modelli architetturali, negli standard semantici e nelle modalità di utilizzo dei sistemi. L obiettivo delle Linee guida è giungere ad una sintesi delle iniziative esistenti e promuovere l adozione di un modello omogeneo nazionale. L infrastruttura elaborativa si compone di un nodo centrale regionale e di un insieme di poli periferici, localizzati presso ciascuna delle sedi delle ASL presenti in Regione. Il nodo centrale espone i principali servizi oggetto di fornitura, mentre i nodi periferici ospitano i repository documentali. L accesso ai servizi è di tipo multicanale: prevede sia accessi diretti di 17

44 Attività connesse all Electronic Health Record in Italia operatori e utenti, sia accessi di applicativi, in modo da ottenere il massimo della fruibilità e della flessibilità del servizio. L architettura applicativa è stata costruita prediligendo il più possibile framework o librerie largamente diffuse, in modo da facilitarne l evoluzione e il riutilizzo. Se possibile ed opportuno, si è cercato di impiegare prodotti open source principalmente basati sul linguaggio Java. Un importante passo avanti nella realizzazione del progetto, che entro il 2012 potrà essere reso disponibile su tutto il territorio nazionale per i cittadini italiani. Il Fascicolo Elettronico verrà realizzato dalle Regioni previo consenso dell assistito, e consiste nell insieme dei dati e documenti digitali di tipo sanitario, riguardanti il paziente, generati da eventi clinici presenti e trascorsi. Diverse Regioni hanno già avviato attività progettuali (es. Lombardia, Toscana, Emilia Romagna, Friuli Venezia Giulia, Sardegna). Inoltre, il Fascicolo Elettronico coprirà l intera vita del malato e sarà costantemente aggiornato dai soggetti che lo prendono in cura. Il Fascicolo Sanitario Elettronico, che ha un orizzonte temporale che copre l intera vita del paziente, è alimentato in maniera continuativa dai soggetti che prendono in cura l assistito nell ambito del Servizio Sanitario Nazionale e dei Servizi Socio-Sanitari Regionali. Le sue proprietà principali: rende disponibile la storia clinica del paziente a tutti gli attori coinvolti; permette ad un operatore sanitario di inquadrare un paziente a lui sconosciuto durante il contatto in emergenza/urgenza; permette a diversi operatori, che hanno già in carico un paziente, di essere consapevoli delle iniziative diagnostiche e terapeutiche portate avanti dai colleghi; 18

45 Attività connesse all Electronic Health Record in Italia permette di condividere tra gli operatori le informazioni amministrative (ad esempio prenotazioni di visite specialistiche, ricette, etc.) od organizzative/ausiliarie per le reti di supporto ai pazienti nelle cronicità e/o nella riabilitazione Contenuti del Fascicolo Sanitario Elettronico Dati Identificativi dell anagrafica dell assistito - Prerequisito alla costituzione e alla gestione del Fascicolo Sanitario Elettronico. Tra i dati anagrafici è fondamentale, in particolare, il Codice Fiscale che rappresenta la chiave univoca di identificazione del cittadino. Dati amministrativi relativi all assistenza - Informazioni amministrative relative alla posizione del cittadino nei confronti del Servizio Sanitario Nazionale, sia con riferimento alla rete d offerta del SSN che ad altre informazioni, eventualmente correlate specificamente all organizzazione della Regione di assistenza. Documenti sanitari e socio-sanitari - Viene automaticamente aggiornato, tenendo conto anche dei contenuti informativi già disponibili, con i documenti sanitari e socio-sanitari certificati, cioè rilasciati dai soggetti del Servizio Sanitario Nazionale (ad esempio referti di laboratorio, radiologia e specialistica ambulatoriale) archiviati elettronicamente presso repository dedicati. Il FSE potrà contenere anche informazioni e/o documenti sanitari relativi ad eventi precedenti alla sua costituzione, ma solo nel caso in cui l assistito fornisca un consenso specifico. Profilo Sanitario Sintetico - Riassume la storia clinica del paziente e la sua situazione corrente. Tale documento è creato ed aggiornato dai MMG/PLS ogni qualvolta intervengono cambiamenti ritenuti rilevanti ai fini della storia clinica del paziente e, in particolare, contiene anche un set predefinito di dati clinici significativi utili in caso di emergenza. Lo scopo del documento Profilo Sanitario Sintetico è quello di favorire la continuità di cura, permettendo un rapido inquadramento del paziente al momento di un contatto non predeterminato come ad 19

46 Attività connesse all Electronic Health Record in Italia esempio in situazioni di emergenza e di pronto soccorso. Il documento è organizzato in varie sezioni, ognuna delle quali raccoglie dati clinici omogenei e relativi a specifiche problematiche del paziente. L accesso è possibile, oltre che da pc, anche da diversi tipi di device come palmari e smart phone. La piattaforma di gestione e visualizzazione è gestita in osservanza dei principi di privacy, integrità, tracciabilità ed affidabilità dei dati, a garanzia della sicurezza globale del sistema. Taccuino personale del cittadino - Una sezione riservata al cittadino per offrirgli la possibilità di inserire dati ed informazioni personali (ad esempio dati relativi al nucleo familiare, dati sull attività sportiva, etc.), file di documenti sanitari (per esempio referti di esami effettuati in strutture non convenzionate, referti archiviati in casa), un diario degli eventi rilevanti (visite, esami diagnostici, misure dei parametri di monitoraggio), promemoria per i controlli medici periodici. Questo consente di arricchire il FSE con ulteriori informazioni al fine di completare la descrizione dello stato di salute, ma tali informazioni e/o documenti risulteranno non certificate. Dichiarazione di volontà alla donazione di organi e tessuti (autocertificazione, DM 8 aprile 2000) - Il FSE deve mettere a disposizione del cittadino, inoltre, funzionalità che permettano, a lui in prima persona o per tramite del proprio medico curante, di esprimere la propria volontà in merito alla donazione degli organi, assicurando chiara ed idonea informativa specifica, garantendo la facoltà di variazione in ogni momento e registrando la collocazione temporale di ogni manifestazione di volontà Infrastruttura Nazionale per il Fascicolo Sanitario Elettronico L Infrastruttura Tecnologica del FSE (infse) [inf] è basata su un architettura (figura 2.1) multi-livello orientata ai servizi SOA (Service Oriented Architecture): 20

47 Attività connesse all Electronic Health Record in Italia il livello inferiore (connectivity layer) è rappresentato dal Sistema Pubblico di Connettività per la cooperazione operativa tra le Pubbliche Amministrazioni mediante busta egov; il livello intermedio (component layer) è costituito dalle componenti dell infrastruttura del FSE; il livello superiore (business layer) definisce i servizi di supporto ai processi sanitari quali, per esempio, l eprescription, la prenotazione di una visita specialistica. Figura 2.1: Infrastruttura FSE. 21

48 Attività connesse all Electronic Health Record in Italia Connectivity Layer - Sistema Pubblico di Connettività Il Sistema Pubblico di Connettività (SPC) [SPC] è un insieme di infrastrutture tecnologiche e di regole tecniche che ha lo scopo di federare le infrastrutture ICT delle Pubbliche Amministrazioni, per consentire la realizzazione di servizi integrati mediante regole e servizi condivisi. Tale integrazione permette di risparmiare sui costi e sui tempi e di realizzare i servizi finali centrati sull utente, evitando richieste continue di dati da parte delle amministrazioni, oltre che duplicazioni di informazioni e controlli. Funzioni e caratteristiche del SPC sono stabilite dal Codice dell Amministrazione Digitale (CAD), che così lo definisce: l insieme di infrastrutture tecnologiche e di regole tecniche, per lo sviluppo, la condivisione, l integrazione e la diffusione del patrimonio informativo e dei dati della pubblica amministrazione, necessarie per assicurare l interoperabilità di base ed evoluta e la cooperazione applicativa dei sistemi informatici e dei flussi informativi, garantendo la sicurezza, la riservatezza delle informazioni, nonché la salvaguardia e l autonomia del patrimonio informativo di ciascuna pubblica amministrazione. In altri termini, nel suo insieme di regole tecniche e nei suoi principi, il Sistema Pubblico di Connettività è un framework nazionale di interoperabilità: definisce, cioè, le modalità preferenziali che i sistemi informativi delle Pubbliche Amministrazioni devono adottare per essere tra loro interoperabili. Il Sistema Pubblico di Connettività stabilisce, inoltre, sia l enterprise architecture della PA italiana (cioè il sistema di riferimento per legare i processi operativi interamministrativi con i sistemi informativi che li supportano), sia le azioni sussidiarie, di coordinamento e di governance. L architettura è un modello SOA (Service Oriented Architecture). Gli aspetti di interoperabilità sono assicurati da regole e, soprattutto, da una serie di servizi, cooperazione e accesso che fanno parte delle cosiddette infrastrutture nazionali condivise 22

49 Attività connesse all Electronic Health Record in Italia SPC. DDI cura la progettazione, la realizzazione, la gestione e l evoluzione dell SPC. Inoltre ne gestisce le risorse condivise, presidiandone le strutture operative preposte al controllo e alla supervisione. Una delle sue attività è quella di istruire le gare per la selezione dei fornitori. Gli indirizzi strategici di SPC 1 vengono definiti dalla Commissione di Coordinamento SPC, presieduta da DDI. Cooperazione applicativa Con questo termnine si intende la capacità dei vari sistemi informativi di avvalersi, ciascuno nella propria logica e per le proprie finalità applicative, dell interscambio automatico di informazioni con gli altri sistemi. Lo scopo è di consentire ai cittadini ed alle imprese di fruire on-line ed in modo semplice ed unitario dati e servizi, riducendo il numero di interazioni con la PA. I servizi di cooperazione applicativa forniti in ambito SPC sono: porta di dominio, cooperazione applicativa e coordinamento processi. Interoperabilità di base Per Interoperabilità di base si intende quell insieme di servizi necessari allo scambio di dati e informazioni, come la posta elettronica, il trasferimento file (FTP) e l accesso al web. Interoperabilità evoluta I servizi di interoperabilità forniti in ambito SPC comprendono: la posta elettronica esclusiva, la posta elettronica certificata (PEC) e la videocomunicazione collaborativa. Porta di Dominio La Porta di Dominio delimita il confine di responsabilità di un ente aderente all SPC e racchiude al suo interno tutte le applicazioni che esso gestisce. Le comunicazioni da e verso un dominio devono quindi attraversare la sua Porta di Dominio. Le Porte di Dominio si parlano tra di 1 Sistema Pubblico di Connettività (SPC) - I concetti chiave. gov.it/spc/concetti-chiave 23

50 Attività connesse all Electronic Health Record in Italia loro scambiandosi richieste e risposte in un formato standard, denominato busta egov. Servizi Infrastrutturali e di Cooperazione Applicativa (SICA) I Servizi Infrastrutturali e di Cooperazione Applicativa (SICA) abilitano l interoperabilità e la cooperazione applicativa fra le Amministrazioni, oltre che l accesso ai servizi applicativi da queste sviluppati e resi disponibili sul SPC. Essi comprendono componenti come, ad esempio, la Porta di Dominio, l Indice Pubbliche Amministrazioni, la Gestione federata delle identità digitali, il Catalogo di schemi ed ontologie. Architettura del SPC L architettura tecnica del SPC è costituita da tre diversi strati (layers): 1. infrastruttura di connettività: fornisce servizi di trasporto dati wired e wireless, di fonia VoIP e di sicurezza con livelli garantiti di funzionalità e qualità; 2. servizi: di interoperabilità, quali posta elettronica e PEC, housing e hosting, gestione siti web, etc.; di cooperazione applicativa: consentono lo sviluppo ed il funzionamento di applicazioni cooperanti; 3. applicazioni cooperative: forniscono agli utenti, cittadini ed imprese, i risultati finali di procedimenti trasversali. L infrastruttura di connettività L infrastruttura di connettività si basa sulla interconnessione di intranet con requisiti di disponibilità, prestazioni e sicurezza end-to-end predefiniti e garantiti. La presenza di più fornitori (Q-ISP), qualificati secondo specifici criteri definiti da DDI, costituisce una reale apertura al mercato ed assicura le condizioni economiche più vantaggiose per le PA. Una struttura dedicata di interscambio (QXN, Qualified Exchange Network) consente la interconnessione delle reti dei diversi Q-ISP. 24

51 Attività connesse all Electronic Health Record in Italia Infine un Centro di Gestione (CG-SPC), indipendente dai Q-ISP, provvede alle verifiche relative alle prestazioni ed alla sicurezza. Ciascuna Amministrazione (PA) ha dunque una propria intranet, servita da un unico fonritore (Q-ISP), che costituisce il dominio interno alla singola Amministrazione e ne connette tutte le sue sedi distribuite sul territorio. La connessione con amministrazioni servite da altri fornitori è assicurata dalla QXN. Alla QXN possono collegarsi direttamente anche le Community Network pubbliche che si qualificano allo scopo (QCN, Qualified Community Network). Component Layer In questo quadro sono identificate tutte le componenti di base dell Infrastruttura del FSE, che rispondono al nome di: Interfaccia di Accesso Registro Indice Federato Gestore dei Documenti Gestore Gerarchico degli Eventi Gestore Politiche di Accesso Inoltre si dettaglia alcuni aspetti ritenuti importanti: Interfaccia di Accesso Questo componente funge da interfaccia all infrastruttura nazionale del FSE ed è presente in ogni nodo regionale e locale. L Interfaccia di Accesso è il componente che gestisce tutte le interazioni con i sistemi legacy, permettendo al dominio locale di interagire con altri domini. Essa prevede tutte le funzioni necessarie per richiedere, ottenere o pubblicare un documento sanitario. 25

52 Attività connesse all Electronic Health Record in Italia Gestore dei Documenti Il Gestore dei Documenti (figura 2.2) deve consentire la memorizzazione in maniera persistente, affidabile e sicura i documenti creati da un utente autorizzato ad ogni occorrenza di un evento sanitario di un assistito. Tale memorizzazione deve avvenire all interno di opportuni repository. Questi ultimi devono essere localizzati presso i nodi locali o regionali ed è fondamentale che questi componenti siano ad alta affidabilità e che siano in grado di conservare i documenti sanitari garantendone disponibilità, consistenza e non ripudio dei dati. Si noti che l attuale legislazione farebbe necessariamente propendere per una memorizzazione sui nodi locali. Tuttavia requisiti di alta affidabilità (disponibilità h24, no single-point-of-failure) richiederebbero necessariamente meccanismi di replicazione dei dati. Standard tecnologici Il formato dei documenti sanitari deve essere aderente allo standard HL7-CDA Rel E preferibile che tale formato sia in forma strutturata. Tutti i servizi componenti l architettura presentata devono essere esposti come Web Services. La tecnologia più indicata per lo sviluppo del Registro Indice Federato è ebxml 3.0, dal momento che consente di gestire grandi quantità di informazioni complesse in maniera sicura attraverso svariati servizi, mediante i quali è possibile condividere metadati tra le organizzazioni in un ambiente federato, inviare notifiche di eventi basate sul contenuto e gestire l identità federata tra i registri della federazione mediante lo standard SAML. Anche i Gestori dei Documenti possono essere sviluppati in accordo alle specifiche ebxml 3.0. Il modello informativo dei metadati del Registro Indice Federato deve essere aderente all ebrim, opportunamente verticalizzato per il dominio sanitario italiano. 26

53 Attività connesse all Electronic Health Record in Italia Ciascuno dei nodi del Gestore Gerarchico degli Eventi è un peer che implementa l interfaccia WS-BrokeredNotification, appartenente alla famiglia di specifiche WSNotification. Ogni utente può interagire con uno qualsiasi di loro e, in tal modo, l intero sistema agisce come un unico broker logico. Gestore Politiche di Accesso Le politiche di accesso ai documenti gestite dal componente Gestore Politiche di Accesso devono essere basate sullo standard XACML. L autenticazione degli utenti deve essere basata su identificazione forte, per esempio mediante Carta Nazionale dei Servizi, Carta d Identità Elettronica, Carta Operatore su standard CNS, CRS con TS, CNS-TS etc. La cooperazione applicativa tra i domini avviene conformemente alle specifiche SPC, adottando quanto emerso nel task infrastrutturale INF- 1 del progetto nazionale ICAR. L identificazione delle entità coinvolte (registri, repository, strutture sanitarie, etc.) deve adottare un sistema univoco a livello internazionale. E importante utilizzare gli standard per la sicurezza più affidabili. I più indicati sono XML-Signature per la firma digitale, XML-Encryption per la crittografazione dei documenti XML, WS-Security quale protocollo di sicurezza dei Web Services, Web Services Security X.509 Certificate Token Profile per lo scambio di certificati digitali X.509 tra Web Services e SAML per lo scambio di dati di autenticazione e autorizzazione tra domini di sicurezza Il Fascicolo Sanitario Elettronico in Toscana La Regione Toscana è fra le regioni italiane più virtuose nel settore dell informatizzazione. Ad esempio, la Regione Toscana si è impegnata nella messa in rete dei medici di medicina generale considerato la chiave di volta per rendere effettivi 27

54 Attività connesse all Electronic Health Record in Italia Figura 2.2: Gestione dei documenti - confronto degli approcci centralizzati e decentrati. e funzionanti progetti e iniziative particolari dando una notevole accelerata alla Sanità Digitale Regionale. Infatti la connessione consentirà ai medici molte altre operazioni: l alimentazione del Fascicolo Sanitario Elettronico (che può essere letto con la 28

55 Attività connesse all Electronic Health Record in Italia Carta Sanitaria Elettronica) attraverso la produzione in formato digitale di informazioni sul percorso sanitario di ciascun assistito (patient summary); la trasmissione telematica delle ricette al Ministero dell Economia (eprescription), l invio delle informazioni previste dagli accordi collettivi nazionali (ad esempio le visite ambulatoriali e domiciliari) e la realizzazione del progetto di attuazione a livello territoriale della Sanità. In particolare, l avvio del Fascicolo Sanitario Elettronico per ogni paziente aprirà la strada allo sviluppo e alla diffusione effettiva delle Carta Sanitaria Elettronica. Proprio per questo i medici saranno dotati di un apposito lettore per la Carta Sanitaria Elettronica. Sarà responsabilità delle Aziende Sanitarie assicurare l attivazione di punti di consegna dei lettori così come l attivazione di un canale ufficiale di supporto per l installazione del lettore e l attivazione di un percorso di formazione per i medici convenzionati che ne facciano richiesta. L accesso alle informazioni del Fascicolo Sanitario Elettronico (FSE) può avvenire esclusivamente mediante autenticazione forte basata sulla Carta Nazionale dei Servizi (CNS) che viene integrata nella Tessera Sanitaria (TS) di ciascun cittadino toscano [carb]. Tutte le comunicazioni che interessano il FSE avvengono utilizzando protocolli sicuri HTTPS. Il sistema del Fascicolo Sanitario Elettronico nel suo complesso coinvolge tutti i soggetti del Servizio Sanitario della Regione Toscana (SST), ed in particolare le Aziende Sanitarie ed Ospedaliero-Universitarie, con l obiettivo di mettere il cittadino al centro del sistema e di fornirgli la piena titolarità delle informazioni prodotte dal Servizio Sanitario della Toscana. RFC [rfc] Operativi all attivazione del FSE: RFC 85 Servizi Anagrafe Persone HL7v3 RFC 86 Servizi Generali Anagrafe Sanitaria HL7v3 29

56 Attività connesse all Electronic Health Record in Italia RFC 87, Gestione MMG e PLS HL7v3 RFC 101 Notifica eventi e consultazione dati diagnostici di Laboratorio Analisi RFC 106 Gestione eventi di Pronto Soccorso RFC 134 Gestione eventi Sistema 118 Flusso Scheda Nosologica Flussi Prestazioni Farmaceutiche e Farmaci Erogati Direttamente Flusso Esenzioni In corso di attivazione: RFC 115 Assistenza Domiciliare RFC 118 Prestazioni residenziali e semi-residenziali RFC 136 Referti di radiologia (RIS) RFC 133 Patient Summary La fase di trasporto delle informazioni prevede l invio da parte delle Aziende mediante il sistema di Cooperazione Applicativa sulla base degli standard RFC aperti e condivisi. Tali informazioni vengono trasportate al TIX [tix], scritte nel Database aziendale e indicizzate solo se il cittadino ha autorizzato la formazione del Fascicolo. La memorizzazione nei database Aziendali, come l invio, è sotto la titolarità dell Azienda inviante, i referti verranno memorizzati in forma crittografata. Durante il trasporto i contenuti sono trattati dalla Regione nella sua funzione infrastrutturale. Tale trattamento consiste nel trasporto su canali crittografati e senza memorizzazione stabile. La funzione di trasporto è censita fra i trattamenti regionali. 30

57 Attività connesse all Electronic Health Record in Italia Infrastruttura FSE per la Toscana L infrastruttura del Fascicolo Sanitario Elettronico (IFSE) [Bor10] è centralizzata presso il TIX e possiede i propri apparati di sicurezza perimetrale; garantisce servizi in alta affidabilità, un sottosistema di backup e restore con relativi dispositivi, un sottosistema per la gestione e monitoraggio dell IFSE nel suo complesso da parte degli amministratori dello stesso. Inoltre è dotata di apparati di rete e di sicurezza atti a realizzare i livelli multipli di sicurezza e separazione fisica dei componenti: firewall e apparati di rete dedicati in alta affidabilità per suddividere i front-end, back-end, etc. Il sistema registra il tracciamento degli accessi, relativamente sia al livello applicativo (accesso al FSE) che al livello di accesso alle basi dati per operazioni di manutenzione, backup etc. Riferimenti Tecnologici TIX Il TIX [tix], acronimo dell espressione inglese Tuscany Internet exchange, è un iniziativa della Rete Telematica Regionale Toscana (RTRT) per migliorare il livello dell infrastruttura telematica della Toscana. Il TIX è un Centro Servizi per Rete Telematica della Regione Toscana (RTRT), con lo scopo di garantire la qualità dei servizi erogati e l attivazione di un Help Desk; è inoltre centro per la cooperazione applicativa fra i soggetti di RTRT. Infine, costituisce anche il nodo regionale del Sistema Pubblico di Connettività, SPC. CART e ARPA CART [carc] è l infrastruttura tecnologica e di servizi a disposizione di tutti i soggetti pubblici e privati per la integrazione e comunicazione fra sistemi informativi diversi secondo una logica di cooperazione applicativa. Definisce un modello di cooperazione e interscambio in sicurezza dei dati, determina una architettura e degli standard tecnologici ed infine detta delle regole al fine di consentire a diverse applicazioni informatiche di diversi sistemi informativi allocati in enti diversi di interoperare e cooperare. ARPA [arp] è l infrastruttura di autenticazione ed accesso sicuro ai servizi di Regione Toscana e di RTRT, che consente di autenticare gli utenti in modo sicuro, di 31

58 Attività connesse all Electronic Health Record in Italia verificarne il ruolo o qualifica posseduto, offrire all utente un desktop personalizzato. RFC Nell infrastruttura di cooperazione applicativa CART, gli enti definiscono in maniera collaborativa documenti detti RFC e.toscana [rfc]; se condivisi e tecnicamente validi, gli RFC diventano gli standard con cui gli enti sono tenuti a scambiarsi le informazioni. Un RFC contiene il contesto applicativo e organizzativo di riferimento, i casi d uso, la struttura dei dati ed il formato dei messaggi scambiati. Le aziende produttrici di software (ad esempio applicativi di Pronto Soccorso) modificano le proprie applicazioni secondo gli RFC e.toscana Standard e accreditano a e.toscana Compliance le proprie soluzioni. 2.3 La Cartella Clinica Elettronica La cartella clinica è lo strumento utilizzato nelle strutture sanitarie per la gestione dei dati clinici del paziente. Le informazioni in essa contenute vengono raccolte durante gli incontri con gli operatori sanitari, in occasione di episodi di malattia o per la prevenzione. E ben immaginabile, quindi, che la cartella clinica sia un documento voluminoso e che al suo interno risulti talvolta piuttosto difficile reperire tempestivamente le informazioni delle quali si abbisogna. La funzione fondamentale della cartella clinica consiste nella raccolta delle informazioni attinenti alle singole persone ricoverate, finalizzata alla presa di decisioni per la soluzione dei relativi problemi di salute. I dati riportati nella cartella clinica soddisfano anche esigenze epidemiologiche, di ricerca scientifica, amministrative, gestionali e medico-legali. Le funzioni che essa può assolvere si possono quindi sintetizzare nei seguenti punti: fornire una base informativa per scelte assistenziali razionali e per garantire continuità assistenziale, documentando il quadro clinico, il processo diagnostico-terapeutico realizzato nel corso della degenza ed i risultati conseguiti; 32

59 Attività connesse all Electronic Health Record in Italia consentire la tracciabilità per le diverse attività svolte di: responsabilità delle azioni; cronologia delle stesse; modalità della loro esecuzione. facilitare l integrazione di competenze multiprofessionali nel processo diagnostico-terapeutico; costituire una fonte informativa per: ricerche clinico-scientifiche, formazione degli operatori; studi valutativi dell attività assistenziale; esigenze amministrative e gestionali. Ogni cartella clinica deve essere identificata dall anno di apertura del ricovero e da un numero progressivo (codice nosologico) e deve essere composta da diverse parti (struttura), che devono essere chiaramente individuabili. I documenti e le informazioni riportate in cartella clinica devono rispondere a criteri di [ef03]: rintracciabilità; chiarezza; accuratezza; veridicità; pertinenza; completezza. Rintracciabilità Per rintracciabilità si intende la possibilità di poter risalire a tutte le attività, agli esecutori, ai materiali ed ai documenti che costituiscono le componenti del ricovero, dall ammissione alla dimissione della persona assistita. 33

60 Attività connesse all Electronic Health Record in Italia Chiarezza La chiarezza riguarda la grafia e l esposizione. Il testo deve essere chiaramente leggibile e comprensibile da coloro che utilizzano la cartella clinica: medici, ed altri professionisti sanitari. L esposizione deve essere diretta e non dare adito a diverse interpretazioni. Va sconsigliato l uso di sigle quando non venga fornita una legenda in chiaro delle stesse al loro primo uso in cartella. Accuratezza Ogni struttura di ricovero deve definire con apposito regolamento procedure atte a garantire l accuratezza dei dati prodotti e delle loro eventuali trascrizioni (esempi: controlli di qualità sui dati di laboratorio, corrispondenza tra terapie prescritte e terapie somministrate, rilevazione e trascrizione dei parametri vitali, corrispondenza tra esami strumentali prescritti ed esami eseguiti e refertati). Veridicità Tutti i dati e gli eventi vanno annotati in cartella clinica contestualmente al loro verificarsi o nell immediata successione degli stessi. I dati e gli eventi riportati in Cartella Clinica debbono essere veritieri e corrispondenti ai dati oggettivi relativi al paziente rilevati in scienza e coscienza dal personale medico e infermieristico e agli effettivi accadimenti come si sono verificati. Non va mai usato il correttore e non sono consentite cancellazioni con gomma. Per errori commessi all atto della stesura, si provvede a tracciare una riga con inchiostro indelebile sulla scritta in modo tale che essa risulti comunque leggibile. Per errore od omissione rilevati in epoca successiva è necessario porre un annotazione che ne dia esplicitamente atto, accompagnata da data di stesura e firma dell estensore. Pertinenza Le informazioni riportate devono essere correlate con le esigenze informative definite sia dalle funzioni attribuite alla cartella clinica, sia dalle condizioni cliniche della persona assistita. Completezza Ogni cartella clinica identifica in modo univoco un ricovero. Essa viene aperta al momento di accettazione della persona assistita e chiusa, cioè completata in ogni sua parte, alla data di dimissione della stessa. Ogni struttura di ricovero dovrebbe mantenere procedure atte a controllare la com- 34

61 Attività connesse all Electronic Health Record in Italia pletezza della cartella clinica sia durante il ricovero che alla dimissione, con riferimento agli elementi che la compongono. In cartella clinica va allegato, quale parte integrante, un elenco di tutti i moduli ed allegati presenti. La struttura di una cartella clinica, sia essa cartacea o elettronica, può essere schematizzata come segue: Dati amministrativi: Dati di identificazione della cartella clinica; Dati identificativi della persona assistita; Dati amministrativi di apertura ricovero. Inquadramento iniziale della persona assistita: Proposta di ricovero; Inquadramento clinico. Processo di cura: Procedure diagnostiche; Procedure terapeutiche e assistenziali; Procedure riabilitative. Decorso del ricovero: Diario clinico; Foglio unico di terapia farmacologica; Prescrizioni nutrizionali; Rilevazione parametri vitali; Referti/Consulenze; Verbale Operatorio; Documentazione anestesiologica; Informativa e dichiarazione di volontà dell assistito. 35

62 Attività connesse all Electronic Health Record in Italia Dimissioni della persona assistita: Valutazione finale; Lettera di dimissione; Scheda di dimissione ospedaliera (SDO); Chiusura della cartella clinica. La cartella clinica cartacea, come noto dalla pratica di tutti i giorni, presenta innumerevoli limiti tra cui: la presenza in un solo posto per volta; può non essere disponibile quando serve o può persino essere smarrita; il contenuto può: non essere in ordine definito, essere difficilmente leggibile, essere incompleto, essere ambiguo; inutilità dal punto di vista della ricerca e creazione di basi di dati; ricerche difficoltose all interno della cartella stessa che possono sfociare in mancanza di dati e esami ripetuti (ricadute sulla qualità e sul costo del servizio); annotazioni e avvisi possono non essere subito visionati o notificati; annotare su carta ormai è obsoleto e antieconomico. Gli studi compiuti principalmente negli ultimi 30 anni hanno evidenziato, con dati quantitativi, che spesso la cartella clinica cartacea non è disponibile durante la visita (fino al 30% delle visite), e che per esempio gli esami di laboratorio vengono molte volte ripetuti perché i risultati non vengono resi disponibili al medico in modo tempestivo [DoM91]. Quando le cartelle sono disponibili, spesso alcuni dati essenziali non sono presenti. Ad esempio, in uno studio sui medici di medicina generale, è stato riscontrato che l età del paziente mancava nel 10% dei casi, che i farmaci non erano trascritti nel 30%, che la diagnosi mancava nel 40%. Tali limiti possono essere superati con l introduzione della cartella clinica informatizzata: negli Stati Uniti, nel 1991 è stato pubblicato un rapporto 36

63 Attività connesse all Electronic Health Record in Italia della National Academy of Science (Institute of Medicine), commissionato dal Congresso, in cui un Comitato di esperti statunitensi arrivava alla conclusione che una cartella clinica elettronica (Computer-based Patient Record - CPR) rappresenta una tecnologia essenziale per la Sanità. Il Comitato quindi proponeva una serie di raccomandazioni per una sua rapida realizzazione, recentemente trasformate in legge. Tale documento era centrato su: linee guida e protocolli di assistenza domiciliare; standard ed integrazione di dati; tematiche complementari: consenso informato, pianificazione dell assistenza al paziente, protocolli diagnostici e terapeutici, soddisfazione dell utente, valutazione della terapia, compliance del paziente, valutazione della qualità. Come conseguenza, è stato fondato un istituto per la cartella clinica elettronica (Computer-based Patient Record Institute - CPRI), con il contributo di finanziamenti pubblici e privati (industrie e associazioni professionali). Oramai tutti i principali ospedali si sono dotati di un HIM (Department of Health Information Management), con lo scopo di ridefinire ruoli strategici, esecutivi e gestionali per il trattamento elettronico dell informazione sanitaria. Al IX Congresso Internazionale di Informatica Medica [AgI01] si è svolto un CPR-Workshop che ha prodotto un consenso su questi principi: la cartella clinica elettronica è un approccio, non un prodotto (manca tuttora una comune definizione, non è ancora chiara la differenza tra sistemi informativi clinici e sofisticate cartelle cliniche specialistiche); la tecnologia è un opportunità, non un fine (l hardware ed il software sono disponibili ma possono essere ulteriormente adeguati alle crescenti necessità, i costi di alcuni sistemi sono molto elevati, vi è limitata disponibilità per le soluzioni ottimali; gli standard non sono ancora completi e definitivi, ma notevoli progressi sono in corso per gli standard di connettività); 37

64 Attività connesse all Electronic Health Record in Italia l aspetto fondamentale è l uomo, non la tecnologia (l innovazione tecnologica è determinata dall eccellenza del fattore umano: fondamentale l apporto della psicologia cognitiva e del comportamento organizzativo); il sistema deve essere sicuro (security, confidentiality e privacy sono le parole chiave dei sistemi che vengono richiesti alle industrie in tutti i continenti); occorrono un identificatore unico del paziente (a livello regionale o nazionale), lo sviluppo sia delle smart card che della telematica; la definizione di nomenclature e di una terminologia di riferimento; la promozione della evidence-based medicine. 2.4 La Scheda Terapeutica Unica La Scheda Terapeutica Unica (STU) nasce con lo scopo principale di diminuire gli eventi avversi che si possono manifestare durante le fasi di prescrizione, somministrazione e monitoraggio di un farmaco. Tale procedura, che si rivolge al personale medico e infermieristico delle strutture sanitarie, si pone come uno strumento per: garantire la sicurezza della persona assistita; individuare le responsabilità nella prescrizione e nella somministrazione/assunzione terapeutica, consentendo così la tracciabilità su un unico documento degli autori e di tutte le operazioni effettuate; evitare le doppie trascrizioni tra la cartella clinica e la documentazione infermieristica; consentire agli infermieri di identificare correttamente il prescrittore, e la terapia prescritta; documentare l attività svolta; gestire il tempo in modo efficiente; favorire la collaborazione multidisciplinare; 38

65 Attività connesse all Electronic Health Record in Italia rispettare la corretta procedura della somministrazione dei farmaci come indicato dalla regola delle 7 G : 1. giusta persona; 2. giusto farmaco; 3. giusta conservazione - scadenza; 4. giusta dose; 5. giusta via di somministrazione; 6. giusto tempo; 7. giusta registrazione. L utilizzo della Scheda Terapeutica Unica ripartisce le responsabilità come nella figura 2.3 che segue: Figura 2.3: Tabella delle responsabilità. La Scheda Terapeutica Unica dovrà quindi rispondere ai seguenti requisiti: 39

66 Attività connesse all Electronic Health Record in Italia 1. Per ogni prescrizione dovrà risultare chiara e comprensibile: Nome generico o nome commerciale del farmaco scritto con grafia leggibile; La forma farmaceutica prescritta (compresse, fiale, etc.) per intero senza alcuna abbreviazione; Il dosaggio che si vuole venga somministrato per singola somministrazione; Il numero di somministrazioni che si voglia somministrare nell arco della giornata; La via di somministrazione prescelta; Il medico che ha prescritto i farmaci in uso. 2. Dovrà essere rilevabile la somministrazione di ogni dose; 3. La mancata somministrazione di una dose dovrà essere registrata e motivata; 4. Dovrà essere rilevabile la data delle sospensione delle terapie effettuate durante il ricovero ed eventualmente sospese; 5. Dovrà essere identificabile il medico che ha sospeso una terapia; 6. Dovrà essere presente nel caso di utilizzo di abbreviazioni una legenda. A livello italiano esistono varie tipologie di STU, tutte molto simili tra loro, che variano solo per quanto riguarda la parte relativa alla simbologia utilizzata per la prescrizione, sospensione terapia, avvenuta e mancata somministrazione. Riteniamo quindi sufficiente riportare di seguito solo l esempio della STU applicata nella Regione Toscana [GRC05]. La STU in esame può essere giornaliera, con sette orari di somministrazione in formato A4 con stampa fronte-retro, o plurigiornaliere, di cui ne esistono due versioni: una trigiornaliera con sette orari di somministrazione ed una pentagiornaliera con cinque orari di somministrazione in formato A3 con stampa fronte-retro. 40

67 Attività connesse all Electronic Health Record in Italia La versione giornaliera è utile nelle Unità Operative dove quotidianamente vengono modificate le prescrizioni ed i pazienti sono sottoposti ad una notevole quantità di terapie, mentre quella plurigiornaliera risulta essere più adatta nelle realtà in cui vengono aggiunte o sospese dai medici soltanto alcune terapie della prescrizione iniziale [Nat07]. La STU (figura 2.4), che deve essere compilata a carattere stampatello esclusivamente con la penna di colore nero o blu, è suddivisa in sei sezioni: 1. Numerazione scheda e lato; 2. Azienda ed unità operativa; 3. Legenda; 4. Informazioni sul paziente; 5. Prescrizione terapie; 6. Programmazione terapie. 2.5 Progetti a livello italiano per la cartella clinica elettronica L interesse e l utilizzo di tablet nell ambito della Sanità Italiana sta crescendo. Ad esempio, di recente, hanno preso il via due progetti presso l ospedale Niguarda di Milano e il Policlinico Gemelli di Roma basati sull ipad. Il progetto iclinic, avviato all ospedale Niguarda di Milano e sviluppato su piattaforma ipad, adotta una soluzione applicativa messa a punto da Connexxa, una software house italiana. Grazie al sistema, i medici possono accedere da qualsiasi punto dell ospedale (dal letto del paziente, come dall ambulatorio) a tutti i dati relativi ad un paziente, dagli esami diagnostici alle immagini radiologiche. 41

68 Attività connesse all Electronic Health Record in Italia Nel dicembre 2010 è stata avviata una fase di sperimentazione dotando l ospedale di cinque tablet e sta per partire la seconda fase del progetto che prevede l estensione a tutto il Blocco Sud (450 posti letto) con l utilizzo di settanta ipad, per arrivare infine all applicazione in tutto l ospedale. Segue gli stessi obiettivi anche il progetto SiPad, partito da alcuni mesi presso alcuni reparti del policlinico Gemelli di Roma, tra cui quello di Cardiologia, e che consiste nell introdurre il tablet Apple nel Sistema Informativo dell ospedale, fornendo in una prima fase venti dispositivi agli operatori sanitari. Per ora l ipad è usato nel giro-visite solo per leggere tutti i dati clinici relativi al paziente, come per esempio l andamento temporale delle sue analisi del sangue. L obiettivo a breve termine è però di usare il tablet anche per inserire nuovi dati nella cartella clinica elettronica del paziente e per guardare referti come lastre o risonanze Progetto iclinic Il progetto iclinic [icl] costituisce una innovativa soluzione per la consultazione della Cartella Clinica Elettronica su iphone ed ipad frutto della collaborazione dell ospedale Niguarda di Milano con Telecom Italia e Connexxa. Mediante iphone, IPad e il Portale Clinico (cartella elettronica di Niguarda) è infatti possibile accedere, al letto del paziente e in totale mobilità, a tutta la gamma delle funzionalità riguardanti i processi medici e assistenziali. L attenzione e particolarmente rivolta all uso del diario clinico durante il giro visite. La sperimentazione è nata dall unione di soluzioni sofisticate, sia applicative ( Portale Clinico ) che strumentali (iphone ed ipad). Durante la sperimentazione verrà valutato il miglioramento in termini di sicurezza nell accesso e nell utilizzo del dato rispetto alle precedenti soluzioni indagate; verrà valutata anche la possibilità di utilizzare iclinic in assistenza domiciliare. 42

69 Attività connesse all Electronic Health Record in Italia Niguarda potrà garantire nella sperimentazione l apporto della propria conoscenza e delle soluzioni già implementate in termini di sicurezza e rispetto delle normative vigenti in materia di privacy Progetto BusterMED Il software BusterMED [bus] viene impiegato per la gestione logistica e clinica dei farmaci nelle strutture sanitarie. Si tratta di uno tra gli strumenti software prodotti dalla Spid S.p.A. forniti a corredo del distributore di farmaci robotizzato BUSTERSPID, permettondo di creare un processo integrato per la gestione dei farmaci. Il flusso delle attività, dalla prescrizione dei farmaci alla loro somministrazione, viene così coordinato completamente. L uniformità del processo riduce, in modo rilevante, i rischi dell errore clinico dovuti alla trascrizione e somministrazione scorretta delle terapie. La maneggevolezza dei Tablet PC e la flessibilità delle connessioni senza fili, permettono di usufruire dei vantaggi offerti dal Sistema BUSTERSPID, direttamente presso il degente, senza mutare le proprie consolidate abitudini lavorative. Già nella fase di prescrizione, ed in tempo reale, è possibile verificare la disponibilità dei farmaci presenti nell intera struttura, gestita dal Sistema BUSTERSPID, sia per il loro nome commerciale sia per il loro principio attivo. Il software è in realtà composto da più pacchetti applicativi, volti a realizzare il percorso prima descritto. Essi rispondono ai nomi di: Manager: versatile strumento che opera in totale coesione con il distributore BUSTERSPID e permette di condurre le operazioni legate alla gestione dei farmaci in tutte le fasi con la massima sicurezza e precisione. Il modulo d identificazione terapia/paziente/farmaco garantisce, al medico, l assoluta corrispondenza tra i farmaci prescritti e quelli somministrati. La convergenza tra il Manager e il distributore ottimizza le operazioni legate alla fornitura e conservazione dei farmaci: il costante 43

70 Attività connesse all Electronic Health Record in Italia monitoraggio delle scorte e la conseguente razionalizzazione degli ordini riducono significativamente la quantità dei farmaci in giacenza. Chart: permette al personale medico di controllare ed amministrare i percorsi terapeutici dei propri pazienti in modo semplice, rapido e sicuro. Con un interfaccia intuitiva che visualizza il percorso terapeutico del paziente nel classico stile termografica, il medico è in grado di vedere, ed eventualmente modificare, tutti i parametri riguardanti le prescrizioni e le somministrazioni dei farmaci dall inizio della terapia fino al momento dell indagine. Chrono: permette al personale infermieristico di controllare, minuto per minuto, lo stato di somministrazione delle terapie e di evitare gli eventuali errori legati al mancato rispetto dei tempi di somministrazione. Center: è un versatile gestionale pensato e creato appositamente per i servizi di farmacia. Il software supporta il farmacista in tutte le fasi del processo logistico del farmaco, dall approvvigionamento alla somministrazione. Inoltre è anche uno strumento di pianificazione in grado di offrire precise e preziose indicazioni alla farmacia centrale ed alle funzioni dirigenziali, in fase di definizione delle linee guida e di programmazione. Le funzionalità fornite dal BusterMED sono: Foglio terapia completa di tutte le informazioni previste dagli standard internazionali di qualità; Previsioni sul consumo dei farmaci; Resoconti sul consumo dei farmaci; Generazione automatica degli ordini periodici; Generazione automatica degli ordini urgenti; Rintracciabilità completa di tutte le operazioni eseguite; 44

71 Attività connesse all Electronic Health Record in Italia Gestione farmaci stupefacenti; Gestione delle comunicazioni tra gli utenti; Verifica della corrispondenza tra i prodotti farmaceutici ordinati e ricevuti; Integrazione con le procedure contabili di tipo analitico; Generazione di statistiche accurate; Accesso a profilo completamente personalizzabile; Gestione delle anagrafiche dei pazienti, delle terapie ed i profili terapeutici Progetto SiPad Il progetto SiPad [sip] nasce con lo scopo di sostituire la cartella clinica cartacea e tutti gli svantaggi collegati quali: il recupero della cartella dall archivio per accedere a dati dei precendenti ricoveri e il dover prendere appunti al letto del paziente durante le visite in reparto. E stato avviato al policlinico Agostino Gemelli ed è un progetto che si avvale dell utilizzo di tablet ipad per riuscire ad introdurre una cartella clinica elettronica. Tale approccio vuole adottare l uso della cartella clinica elettronica per riportare ed aggiornare la storia clinica di un paziente dal ricovero alle dimissioni. Il progetto denominato SiPad, è partiro nei primi mesi del 2010 e consiste nell introdurre l ipad Apple nel Sistema Informativo del Policlinico Gemelli, fornendo gli operatori sanitari di questo dispositivo mobile (per ora in questa fase sperimentale ne sono stati consegnati venti) per consetire di lavorare in piena mobilità affincandosi ai dispositivi già esistenti. Al Policlinico Gemelli si registrano oltre tretacinquemila accessi al sistema informatico ogni ora, ad oggi sono già informatizzati il ciclo del ricovero 45

72 Attività connesse all Electronic Health Record in Italia (dalla lista di attesa, all accettazione, alla degenza, alla dimissione); la prenotazione e programmazione delle prestazioni ambulatoriali; la gestione delle impegnative e della cassa; la richiesta, programmazione ed esecuzione delle prestazioni ai pazienti ricoverati (radiologia, laboratori, cardiologia, etc.); le attività infermieristiche in reparto (consegne, gestione letti, peso assistenziale, etc.); la gestione paperless dei referti, firmati con firma digitale e inviati ai reparti in forma elettronica, la gestione filmless delle immagini radiologiche e la visualizzazione dai reparti; le attività dei laboratori, della radiologia e delle sale operatorie, la gestione del rischio clinico, con il braccialetto identificativo per ogni paziente in modo da evitare il rischio di errori di persona; il prelievo personalizzato con l identificazione certa del paziente e della provetta e la gestione delle cartelle cliniche (anamnesi, diario clinico, lettera di dimissione, referti specialistici, etc.). Con SiPad l obiettivo è dotare il personale medico di dispositivi mobili per muoversi al letto del paziente e leggere e aggiornarne la cartella clinica in tempo reale man mano che il medico gira per il reparto e fa le visite. Inserire i dati in tempo reale al letto del paziente permetterà davvero di rendere del tutto elettronica, paperless, la cartella clinica del malato. Quindi saranno eliminati i problemi del rischio clinico connessi a pagine fuori posto in cartella clinica, difficoltà ad interpretare la scrittura di un collega che ha visitato o trattato il paziente e modificato la cartella a mano, ritardi nella notifica di una richiesta di prestazione a un degente, ritardi che possono causare lo scavallamento di un intera giornata nell erogazione di tale prestazione e in definitiva l aumento della durata (e dei costi) della degenza. Nel progetto SiPad sono stati coinvolti diversi utenti pilota in diversi settori del Policlinico, in particolare: Cardiologia, Medicina d Urgenza, Ginecologia, CEMI, Microbiologia, Medicina Interna, Endocrinologia, Chirurgia. L idea degli sviluppatori è di estendere il progetto a tutti i reparti: il costo 46

73 Attività connesse all Electronic Health Record in Italia per la messa a regime di un sistema simile, considerato che l infrastruttura di rete wireless già è disponibile nel Policlinico, è essenzialmente quello dei dispositivi ipad. Piuttosto che installare altri pc fissi (con problemi di spazio nei reparti, di code nell uso del sistema, e di costi per il cablaggio di ulteriori punti rete) l utilizzo degli ipad può risultare un risparmio. In generale, anche sulla base della letteratura e delle esperienze di altre realtà, si potrebbe dire che l utilizzo di dispositivi mobili comporta un aumento di efficienza ed una riduzione dei costi. L utilizzo di dispositivi mobili può aiutare molto verso l obiettivo di una cartella clinica completamente paperless e sempre a disposizione del medico ovunque si trovi. In alcuni settori questo è già raggiunto: tutti i dati del paziente sono informatizzati e quindi anche accessibili in momenti successivi (si pensi a ricoveri d urgenza, pazienti cronici, rientri, etc.) La Carta della Salute dell Ospedale Bambin Gesù L Ospedale Pediatrico Bambino Gesù ha avviato grossi cambiamenti per quanto riguarda l erogazione dei servizi in rete [cara]. Alcuni di tali servizi riguardano: Carta della Salute Elettronica, prenotazioni, pagamenti, ritiro dei referti on-line, promemoria via sms e un applicazione per iphone e ipad che consente di accedere tramite il proprio telefonino ai servizi dell Ospedale. La Carta della Salute è una Web Application che permette di consultare in qualsiasi momento e da qualsiasi luogo, il Fascicolo Sanitario Elettronico che contiene le cartelle cliniche, le diagnosi e tutti i referti ambulatoriali, di laboratorio e di diagnostica per immagini del bambino. Ad ogni paziente intestatario di una Carta della Saluta è assocaito un numero identificativo che, associato a un codice di sicurezza e al codice fiscale, garantisce il riconoscimento dell identità del titolare, il rispetto della privacy 47

74 Attività connesse all Electronic Health Record in Italia e la riservatezza delle informazioni. Il Fascicolo Sanitario Elettronico accessibile attraverso la Carta della Salute comprende la scansione integrale della cartella clinica di ricovero ordinario e/o i referti ambulatoriali relativi alle visite ambulatoriali e alle prestazioni diagnostiche (laboratorio analisi e dipartimento immagini) erogate dall Ospedale Pediatrico Bambino Gesù. Si potrà accedere ai dati da qualsiasi luogo tramite una Web Application su cui avverrà l accesso inserendo il numero identificativo della tessera, il codice fiscale del paziente ed il codice di sicurezza (PIN code). 48

75 Attività connesse all Electronic Health Record in Italia Figura 2.4: Scheda Terapeutica Unica della Regione Toscana. 49

76

77 Parte II Stato dell arte, architettura Web per l interoperabilità

78

79 Capitolo 3 InterDataNet La struttura InterDataNet [PCPG11, Chi09, Cio10] è un framework che consente ad utenti distribuiti nel tempo e nello spazio di collaborare intorno ad elementi informativi che appartengono ad uno spazio globale di dati distribuito con cui è possibile interagire mediante la metafora dei documenti. Il logo ufficiale del progetto è riportato in figura 3.1. Figura 3.1: Logo del progetto IDN. Coerentemente con [Val01, EM04, WN01] sono state adottate viste multiple del problema generale, al fine di separare comportamenti e funzionalità, formulare vincoli, requisiti e soluzioni. Il sistema IDN è quindi (logicamente e fisicamente) descritto tramite tre viste complementari ed integrate:

80 InterDataNet 1. vista sulle applicazioni; 2. vista sulle risorse e sull informazione; 3. vista sull architettura dei servizi. Ciascuna vista pone l attenzione su specifici aspetti del problema, partendo dalla rappresentazione astratta del contesto, delle informazioni e delle esigenze, per arrivare verso un livello più concreto relativo all introduzione dell architettura fino alla descrizione degli apparati necessari all implementazione. Internet HTTP IDN Information Model (IDN-IM) IDN REST API Servizi IDN (intra-dominio) RDBMS FileSystem HTTP (cross-dominio) IDN Information Model (IDN-IM) IDN REST API Servizi IDN (intra-dominio) Network HTTP RDBMS Vista 1 IDN Information Model (IDN-IM) IDN REST API Servizi IDN (intra-dominio) Storage Systems Storage Systems Storage Systems Network IDN Compliant Applications IDN Service Architecture Storage (legacy) Vista 2 Vista 3 Figura 3.2: InterDataNet: visione d insieme. IDN Information Model. La prima vista prende il nome di IDN Information Model (IDN-IM). Un modello dell informazione [PS03, CT04, HS90] che intende rappresentare ogni tipo di informazione (strutturata), recependo i principi di responsabilità, paternità, storicizzazione e ciclo di vita dell informazione. Definisce quindi le proprietà di base dell informazione che dovrà essere trattata, ma volutamente non fornisce specifiche soluzioni implementative (cioè è indipendente dai Data Model). Rappresenta quindi l informazione indipendentemente dalla tecnologia in maniera altamente strutturata, abilitando l interoperabilità fra sistemi eterogenei. 54

81 InterDataNet IDN Compliant Application. La seconda vista è costituita dalle applicazioni IDN che implementano le logiche di business per la risoluzione di specifici problemi di dominio e/o rappresentano lo user-agent per l interazione con il sistema. Facendo riferimento alla figura 3.2 è possibile notare come le applicazioni IDN operino trattando informazione conforme ai dettami fissati dall Information Model ed utilizzino l IDN-SA (vedi la vista successiva) per accedere-ai/manipolare-i documenti IDN-IM. IDN Service Architecture. La terza vista prende il nome di IDN Service Architecture (IDN-SA). Definisce in maniera stratificata i servizi necessari per soddisfare il modello informativo IDN-IM, in modo conforme ai principi REST [Fie00]. Implementa le varie funzionalità, definendo sottosistemi, protocolli ed interfacce per una gestione collaborativa del documento rappresentato tramite IDN-IM. IDN-SA espone una IDN-API (Application Programming Interface) REST utilizzata dalle applicazioni per la manipolazione di informazione rappresentata tramite IDN-IM. La API viene quindi utilizzata ricorrendo direttamente all uso del protocollo HTTP; questo è garanzia di scalabilità ed interoperabilità. L approccio REST viene utilizzato non solo per le interazioni fra le IDN application e IDN-SA, ma anche per le interazioni che si sviluppano fra le componenti interne di IDN-SA stessa (sicuramente fra componenti appartenenti a domini 1 diversi in cui è necessario interagire tramite interfacce standard, ma per garantire la massima interoperabilità è auspicabile che ciò avvenga in ogni circostanza). Nel presente capitolo verrà esposta una trattazione teorica e panoramica delle tre viste appena introdotte, partendo dall Information Model. 1 Con dominio si intende un insieme di sistemi omogeneo dal punto di vista amministrativo. Dal punto di vista geografico/politico i sistemi appartenenti allo stesso dominio possono essere dispiegati all interno di un unico datacenter così come dislocati su siti diversi, possono appartenere ad un unica organizzazione così come a consorzi di organizzazioni, un organizzazione più disporre di un unico dominio così come di un numero elevato di domini. 55

82 InterDataNet 3.1 IDN Information Model Si definisce Information Model una rappresentazione universale delle entità e delle loro proprietà, operazioni e relazioni, il cui scopo principale è quello di modellare gli oggetti ad un livello concettuale, indipendentemente da qualsiasi specifico repository, applicazione, protocollo o piattaforma. Esso non riguarda i dettagli, ma mira a catturare le astrazioni e i requisiti fondamentali delle entità da modellare. Un Data Model, invece, si occupa di gestire gli oggetti ad un livello di astrazione più basso, e comprende dettagli specifici dell implementazione e del protocollo, ad esempio regole che spieghino come mappare gli oggetti gestiti su costrutti protocollari di livello più basso [PS03]. A partire da un Information Model è possibile generare più Data Model, intesi come i modelli concreti dell Information Model. Questa capacità permette la scalabilità e l adattabilità del modello in contesti diversi. Un ulteriore conseguenza è la possibilità di scegliere, per la realizzazione, tra una vasta gamma di standard e tecnologie esistenti, se rispondenti alle esigenze. IDN-IM è dunque una rappresentazione omogenea, astratta e consistente dell informazione, che ne cattura i requisiti, i principi e le proprietà desiderabili in termini assoluti, oltre a rappresentare un modello di documento universale, indipendente dal particolare contesto e da tecnologie specifiche. In base ad esso l informazione viene rimodellata partendo dalle sue caratteristiche native e globali; di conseguenza, è altamente strutturata ed è dotata di informazioni ausiliarie, ossia i metadati, per abilitare la gestione dell informazione distribuita in un ambiente di rete collaborativo [PCPP07]. Tale modello di riferimento è stato derivato tenendo conto delle funzioni necessarie per i sistemi di gestione di documenti, come la creazione, la revisione, la pubblicazione, l accesso e l archiviazione, oltre alle funzioni telematiche per il supporto allo scambio ed alla collaborazione. L entità gestita dall ambiente IDN è un documento strutturato che risulta composto da contenuti, relazioni (implicite o esplicite tra i contenuti) e metadati. Parafrasando Rein, McCue, Slein e Buckland [Buc97, RMS97] un documento è la testimonianza di una evidenza fisica o intellettuale, memorizzata 56

83 InterDataNet e strutturata in una qualsiasi forma materiale, capace di essere compresa dall uomo, trattabile dalla macchina e comunicabile. Questa definizione si adatta perfettamente al concetto di unità informativa, così come presa in esame in InterDataNet, su cui basare la collaborazione. Conseguenza naturale è stata quella di prevedere nell Information Model il concetto di documento, visto come insieme strutturato di informazioni più elementari eventualmente documenti a loro volta. L importanza del concetto di documento è immediata conseguenza del fatto che, molto spesso, quando si considerano più informazioni distinte come un unica entità (raggruppate all interno del documento) il contenuto informativo della somma è maggiore della somma delle singole informazioni: il documento è di per sé informazione. Si evidenzia come l informazione aggiuntiva sia data da correlazioni presenti fra le varie informazioni e permetta di caratterizzare il documento come un entità strutturata 2. In IDN il documento viene modellato come un aggregato di informazioni elementari; la struttura e il contenuto sono completamente separati dalla presentazione, che può anche non essere presente. Ciascun elemento informativo viene isolato rispetto agli altri secondo un principio gerarchico che si basa sull associazione ad un responsabile. Si consideri l esempio di un documento che rappresenta una patente di guida. Per ogni contenuto informativo è possibile determinare un organizzazione che detiene l informazione: per i dati anagrafici del titolare si risale al Comune, per i dati relativi alla scadenza si risale alla Motorizzazione, e così via. Il procedimento tende quindi a strutturare rigidamente il documento, seguendo semplicemente le regole che ne hanno determinato il rilascio. Non è necessario che la sorgente di informazione sia unica e unitaria; anzi, questa strutturazione trova maggior beneficio quanto più è possibile distinguere gli enti che trattano le singole informazioni, costituendo in modo naturale un sistema distribuito dal punto di vista del documento considerato. La dinamicità e la flessibilità sono ottenute grazie all elevato grado di autonomia delle singole sorgenti che, in modo collaborativo ed indiretto, partecipano 2 Nel caso in cui questo aspetto sia trascurabile si parla di informazione non strutturata che comunque può essere vista come un caso particolare di quella strutturata. 57

84 InterDataNet alla costruzione di un documento capace di evolvere nel tempo; ogni parte del documento può infatti essere soggetta a variazioni. Inoltre, il documento è attivo, in quanto può evolvere e cambiare comportamento in dipendenza allo stato assunto ed alle relazioni espresse. Tornando all esempio della patente, se i punti vengono azzerati come effetto di una serie di contravvenzioni, il documento perde di validità e possono venire automaticamente notificati degli avvisi ad una serie di soggetti. Oltre ai contenuti informativi in quanto tali, un documento ingloba al proprio interno una seri di concetti addizionali come la presentazione, eventuali relazioni con altri documenti e/o informazioni aggiuntive finalizzate a caratterizzare il documento stesso e non i contenuti che veicola. Le categorie di informazioni individuabili in un documento risultano le seguenti: contenuti: elementi esplicitamente fruibili dall uomo che sono direttamente individuabili all interno del documento. Rientrano in questa categoria i testi, le immagini, le date, i nomi, i contenuti multimediali, etc.; relazioni: legami fra contenuti che possono essere di tipo esplicito o implicito. Un esempio di legame esplicito può essere il riferimento ad una pagina o paragrafo di un libro, ad un articolo presente in una legge, etc. Dualmente un legame implicito può essere quello esistente fra il titolo di un capitolo di un libro e il contenuto del capitolo stesso; informazioni aggiuntive: ulteriori informazioni associate al documento e/o che possono essere date per scontate (metadati). Ad esempio l autore di un brano musicale oppure il fatto che i contenuti presenti nella prima pagina di un quotidiano rappresentano un sunto delle notizie più importanti del giornale; presentazione: informazioni necessarie per mostrare correttamente il documento all utente. Rientra a pieno titolo in questa categoria l aspetto grafico, ovvero la scelta dei caratteri, dei colori, dell impaginazione, etc. Questa categoria di informazioni fornisce un valore aggiunto che in particolari casi è determinante per permettere la fruibilità delle informazioni contenute nel documento. 58

85 InterDataNet Strutturare secondo il principio di responsabilità Il responsabile è colui il quale ha la consapevolezza di dover rispondere degli effetti che possono scaturire a seguito della divulgazione dell informazione. Il responsabile può essere una persona fisica oppure giuridica che crea o modifica l informazione. Si osservi che questa metodologia assume un valore estremamente determinante quando viene coinvolto il trattamento di informazioni sensibili ed in generale da in punto di vista giuridico. Il contesto è quello di una organizzazione. Si consideri un informazione creata dalla collaborazione di più persone. Da un punto di vista organizzativo ciascuna persona avrà contribuito agendo su una parte e lasciando alle altre il compito di integrarla o di validare l unione. L organigramma aziendale, i ruoli ed il ciclo di vita dell informazione sono gli elementi che stabiliscono in maniera non ambigua chi è responsabile di cosa. Ciascuno deve essere abilitato ad agire sulle parti di sua competenza. Strutturare con il principio di responsabilità non presuppone la reingegnerizzazione dei processi, ma è evidente che se i processi fossero ben ingegnerizzati allora l applicazione del principio trova maggiore beneficio. Se si isolano le parti più elementari, assicurando la loro riusabilità ed indirizzabilità, è possibile sfruttarle come building-block per la costruzione di nuova informazione riarrangiando, integrando e ricomponendo gli elementi disponibili. Si prenda ad esempio un articolo di giornale: l autore è responsabile di ciò che vi ha scritto. Il direttore è responsabile della aggregazione ragionata di più articoli. Se il singolo articolo gode delle proprietà sopra esposte potrebbe essere adoperato da un altro direttore per la creazione di una pubblicazione diversa da quella per cui originariamente era stato concepito. Nel settore della Pubblica Amministrazione o comunque in tutti quei settori in cui esiste un elevato numero di elementi informativi ricorrenti e trasversali è possibile attuare una forte politica del riuso e la creazione di documenti in maniera dinamica, aumentando la qualità del dato. Il significato del singolo elemento dovrà essere comunque stabilito su larga scala, ma stavolta in aiuto intervengono normative e direttive aziendali che lasciano poco spazio alla interpretazione. 59

86 InterDataNet Strutturare con questa tecnica significa agire su un piano trasversale ai contenuti semantici del documento, che vengono ignorati a livello infrastrutturale. Su larga scala consente di realizzare in maniera automatizzata un insieme di mattoni informativi elementari che possono essere riutilizzati dalla comunità per costruire nuova informazione. Il principio di responsabilità può anche essere inteso come conseguenza naturale dei processi organizzativi e metodologici standard individuati all interno delle organizzazioni, ma sopratutto un modo relativamente più facile da automatizzare ed informatizzare che accompagna l informazione durante il suo ciclo di vita. Una importante osservazione è legata alla assegnazione selettiva dei diritti di accesso per le singole informazioni, quale condizione necessaria per poter parlare di responsabile. Al responsabile, per esercitare il suo ruolo, devono essere fornite le garanzie sulle modalità di gestione ed accesso all informazione Identificazione dei nodi Un elemento informativo per essere correttamente condiviso, divulgato e riusato necessita di possedere due proprietà fondamentali: individuabile ed accessibile. deve essere Nei sistemi telematici per individuare una risorsa si usa il suo indirizzamento e spesso l indirizzo stesso diviene anche per l accesso fisico (come nel caso degli URL 3 ). Nel modello IDN l identificazione dei nodi è una proprietà che deve essere mantenuta indipendente dai dettagli dell accesso fisico, poiché l accesso fisico non rappresenta un contesto di interesse per un Information Model. In altre parole è importante disporre di identificatori che vadano ad astrarre dalla localizzazione fisica delle risorse e siano quindi indipendenti dalla stessa. Questo è conseguenza della percezione che ha l essere umano del concetto di documento : ad esempio con categoria della patente di guida di Mario Rossi si intende un informazione ben precisa ed indipendente dal luogo e dal 3 Uniform Resource Locator [Hof05b, Hof05a], sono gli indirizzi utilizzati nel web per identificare ed accedere alle risorse. Sono un caso particolare di URI (Uniform Resource Identifiers [BLFM05]). 60

87 InterDataNet formato in cui viene conservata e acceduta. In pratica la categoria è la stessa informazione sia che questa venga memorizzata negli archivi elettronici della Motorizzazione Civile che stampata sul documento in formato cartaceo per il titolare della patente. L esempio relativo alla patente di guida evidenzia come l identificazione delle risorse sia un operazione concettualmente diversa dall accesso e pertanto, in generale, è opportuno che le due operazioni siano distinte per rispettare la separation-of-concern. In tal caso, una volta effettuata l identificazione in una prima fase, è possibile procedere, in una fase successiva, con l accesso. In IDN-IM sono definiti LRI (Logical Resource Identifier) i nomi logici delle risorse. In questo contesto una risorsa più essere un documento IDN, un nodo di un documento, un dato/metadato in esso contenuto; in generale una qualunque entità definita dal modello stesso. Sebbene gli LRI siano stati definiti come sottoclasse degli HTTP-URI garantiscono la completa separazione fra indirizzamento ed accesso. In analogia alle tante applicazioni presenti nel contesto del Semantic Web l indirizzamento avviene grazie al nome in sé, visto come stringa ordinata di caratteri. La particolarità di essere HTTP-URI permette di garantire l identificazione non ambigua a livello globale, senza la necessità di introdurre un ulteriore authority riconosciuta a livello universale per questo fine. Grazie al principio di responsabilità l authority dell URI 4 permette di individuare non tanto il server che detiene l informazione a cui l URI fa riferimento bensì il server responsabile su quella informazione. Come risulterà più chiaro nel seguito (dopo la descrizione di IDN-SA, paragrafo 3.4) l informazione verrà infatti ricostruita dinamicamente attivando una serie di elaborazioni che, partendo da server responsabile, interesseranno altri server, fino al reperimento effettivo di tutti i dati necessari, che risiederanno su sistemi remoti, per la ricomposizione dell informazione di interesse. Il responsabile non detiene quindi l informazione, ma è colui il quale deve orchestrare tutti i processi necessari per ricostruire l informazione; non solo: come responsabile stabilisce le condizioni sotto le quali rendere fruibili l informazione, negando ad esempio l accesso ai soggetti che non ne hanno diritto. 4 L authority è la componente compresa fra :// ed il primo / successivo, vedi la RFC3986 [BLFM05]. 61

88 InterDataNet 3.2 Storico dei documenti Il mantenimento delle versioni (revisioni) dell informazione e l automazione della generazione delle stesse garantiscono la massima tracciabilità, permettendo di ricostruire l evoluzione dell informazione nel tempo a fronte delle modifiche. IDN-IM è stato dotato dei principi del modello UEVM (Unified Extensional Versioning Model) [ABCM99], che organizza le versioni di documenti strutturati come DAG riuscendo a versionare, con tecniche automatizzate, sia i contenuti che gli aspetti strutturali. Ulteriori dettagli sul versioning in IDN-IM sono disponibili in [Chi05, Inn08]. Ogni documento, se necessario, può disporre quindi di caratteristiche atte a memorizzarne l evoluzione temporale, chiamata storico. Tale evoluzione, sebbene sia una caratteristica globale del documento, viene mantenuta memorizzando l evoluzione delle singole informazioni che lo costituiscono (a livello di nodo). Le evoluzioni temporali delle singole informazioni (che si ricorda essere strutturate a DAG), pur essendo mantenute separate ed associate ad esse, non sono indipendenti: una modifica effettuata ad un informazione che si trova ad un livello più basso della gerarchia si ripercuote, grazie ai link di segnalazione, su tutti i suoi predecessori. Questo fa sì che lo storico della radice comprenda, seppur indirettamente, l evoluzione temporale di tutto il documento. Volendo recuperare una data versione è previsto un meccanismo di navigazione nello storico che, partendo dalla radice ed attraversando i vari nodi del documento, permette di ricomporlo come richiesto. È utile evidenziare come il meccanismo, basandosi su un modello estensionale, permetta, a differenza di altri modelli di versioning, di ripercorrere lo storico del documento nel modo più naturale possibile per l utente: ogni versione del documento viene ricostruita correttamente sia per quel che riguarda i dati contenuti sia per quanto riguarda gli aspetti strutturali. Lo storico è interrogabile esprimendo esplicitamente la versione desiderata, comunque è possibile estendere l interrogazione anche attraverso alcuni parametri di versione (descritti nel paragrafo 3.2.2). Per descrivere i meccanismi di gestione dello storico è utile inizialmente 62

89 InterDataNet fare riferimento ad un documento costituito da un unico nodo e, successivamente, estendere il concetto al caso generale. Sotto l ipotesi che ogni nodo, una volta creato, sia una grandezza immutabile nel tempo l operazione di modifica dà vita ad un nuovo nodo. Si definisce versione un informazione primitiva ottenuta modificando il contenuto informativo di un nodo esistente. Anche la nascita di una nuova informazione rientra in questa definizione considerando che tale operazione può essere vista come la modifica dell informazione nulla. Viene definito uno stato UPDATE che viene associato ad ogni informazione per determinare se è necessario generare nuove versioni oppure effettuare sovrascritture. Il valore assunto dallo stato può essere frozen o changing rispettivamente. Lo stato changing non verrà discusso ulteriormente in questo paragrafo in quanto modella documenti e/o informazioni non versionati. A questo punto può essere utile chiarire cosa si intende con modifica di un informazione al variare del tipo di essa: nel caso di informazione atomica si parla di cambiamento di uno dei tre elementi <nome,tipo,valore>; nel caso di informazione primitiva si parla di cambiamento di una o più delle relazioni di aggregazione che escono dall informazione in esame (quindi della struttura dei documenti che la contengono) oppure della variazione delle informazioni atomiche contenute (quindi anche dei link di riferimento che si ricorda essere un caso particolare di informazione atomica). È possibile modificare solo e soltanto l ultimo nodo creato all interno dello storico e, nel caso in cui lo stato UPDATE sia frozen, quello che si genera è un insieme ordinato di revisioni. Viceversa per modificare un nodo che non sia l ultimo occorre creare una diramazione o branch (figura 3.3). Mentre la creazione della versione successiva (internamente al ramo corrente) è un operazione trasparente all utente il quale si limita a richiedere un aggiornamento dell ultima versione disponibile, la creazione di una nuova diramazione avviene sempre su esplicita richiesta. Ad esempio si consideri il ramo x al tempo t 0 in figura 3.3. La richiesta di nascita di una diramazione a partire dalla prima versione x.0 al tempo t 1 >t 0 comporta la creazione del 63

90 InterDataNet ramo y contenente la nuova versione y.0. Al tempo t 2 >t 1 la modifica di x.1 viene applicata nello stesso ramo con la revisione x.2. Figura 3.3: Generazione delle revisioni. Da un punto di vista concettuale effettuare un merge significa integrare le modifiche presenti su un branch in un altro branch. Nella pratica questa operazione può essere effettuata secondo modalità diverse che variano con il contesto. Supponendo quindi di operare con documenti IDN-IM occorre stabilire cosa significhi fondere informazioni atomiche e informazioni primitive, elementi che costituiscono i documenti presenti nei due branch di interesse. Il concetto di merge di informazioni atomiche è comunque necessario e si è scelto di implementare in IDN-IM delle modalità di fusione elementari a partire dalle quali sarà possibile definire metodologie di merge più complesse in base alle specifiche esigenze del dominio applicativo di interesse. È possibile definire un operazione di confronto fra due informazioni atomiche (che dipende dal tipo di informazione atomica trattata e quindi, in ultima analisi, dal contesto) che ne determina l uguaglianza o la differenza. Nel primo caso il merge è banale e il risultato è l informazione stessa; altrimenti l operazione di confronto può permettere di stabilire l entità della differenza e si possono presentare le seguenti situazioni: le informazioni sono diverse, ma confrontabili nei contenuti: in via automatica o sotto la supervisione dell utente è possibile generare una terza informazione atomica sulla base delle altre due. Come caso particolare la nuova informazione può coincidere nei contenuti con una delle altre due; 64

91 InterDataNet le informazioni non sono confrontabili e pertanto non è definibile / possibile l operazione di merge. Per quanto riguarda le informazioni primitive, occorre specificare cosa si intende per uguaglianza tra di esse. Da un punto di vista astratto è possibile considerarle come il punto di accesso all informazione complessiva che si sviluppa da esse fino alle foglie. Questo porta alla conclusione che il concetto di uguaglianza fra informazioni primitive non è esprimibile esclusivamente sulla base del confronto del contenuto informativo dei nodi che le rappresentano, ma in generale occorre andare a considerare e confrontare ricorsivamente i nodi che tali informazioni primitive aggregano (in altre parole l intero documento in esse radicato). A questo punto, in riferimento alla figura 3.4, è possibile fornire la seguente definizione di merging: fondere (merge) due elementi A e B appartenenti a branch diversi dello stesso storico, significa generare un terzo elemento C ottenuto da essi a seguito dell esecuzione di un determinato algoritmo. Il nuovo elemento C figura nello storico come successore sia di A che di B e, per convenzione, appartiene al ramo di A. La definizione e l esecuzione dell algoritmo di generazione non sono generalizzabili in quanto dipendono dal dominio applicativo ovvero dal tipo di informazione rappresentata attraverso il documento IDN-IM: il modello, come precedentemente affermato, si limita ad offrire le funzionalità di base per realizzare le operazioni, abilitando la possibilità di creare merge arbitrariamente complessi. Si osservi che, in questi termini, il merge è un operazione definita fra due branch che fonde il secondo sul primo. L operatore di merge non è quindi commutativo: fondere A e B su C è diverso da fondere B e A su C. Nel primo caso C appartiene al ramo di A mentre nel secondo al ramo di B. Alla luce del fatto che risulta possibile modificare in modo trasparente solamente l ultimo elemento di ogni ramo e del fatto che la creazione di un branch avviene sempre su esplicita richiesta, è possibile affermare che IDN- IM è un modello che permette l authoring collaborativo senza la necessità di prevedere meccanismi di locking. Il motivo è che risulta sempre possibile individuare i conflitti, permettendo quindi di attuare le opportune politiche di gestione. Con conflitto si intende il tentativo di modificare due o più volte la medesima informazione in istanti diversi e può verificarsi qualora due 65

92 InterDataNet Figura 3.4: Merge di due nodi. utenti, l uno indipendentemente dall altro, accedano alla stessa informazione nella versione v (x) (che si ipotizza essere l ultima disponibile nel momento dell accesso) e, dopo il tempo necessario ad elaborare la modifica, tentino l operazione di salvataggio. Il primo di essi riuscirà nell intento ed il sistema genererà la versione v (x+1). Il secondo invece verrà informato che la versione v (x) è diventata immutabile a causa del fatto che non è più l ultima versione disponibile dell informazione. A questo punto l utente può decidere di attuare una delle seguenti strategie: effettuare un merge (fusione) della propria modifica con quella apportata dall altro utente. In questo caso si hanno due opzioni possibili: l abbandono dell intenzione di apportare la modifica ad esempio perché già realizzata dall altro utente oppure la produzione della versione v (x+2) ottenuta dalla fusione di v (x) più le modifiche locali e v 5 (x+1) ; creare un nuovo branch sul quale apportare le proprie modifiche (eventualmente da fondere nel ramo di partenza in un momento futuro). 5 Come nel caso del merge di due rami anche in questo caso v (x+2) può essere uguale a v (x) (il secondo utente decide di annullare le modifiche del primo utente) oppure diverso sia da v (x) che da v (x+1). Il caso v (x+2) = v (x+1) non è significativo in quanto coincide con l opzione in cui il secondo utente rinuncia a creare v (x+2) lasciando v (x+1) come ultima versione dell informazione. 66

93 InterDataNet Ciò non esclude necessariamente che in ben determinati domini applicativi sia possibile utilizzare i metadati definibili nel modello stesso per implementare opportuni meccanismi di locking al fine di aumentare l awareness degli utenti La propagazione delle modifiche Per poter implementare il modello di versioning UEVM è necessario prevedere un meccanismo che permetta di propagare le modifiche dei figli verso i genitori. Il modello quindi prevede, proprio per questo fine, i link di segnalazione che permettono di risalire nella gerarchia dei nodi presenti nel dominio del grafo IDN-IM, come richiesto dal modello di versioning UEVM stesso. In corrispondenza dell ultima versione all interno di ogni branch di informazioni primitive per le quali si ha interesse a tracciare gli aggiornamenti delle altre informazioni primitive ad un livello più basso della gerarchia nel grafo IDN, si hanno i link di segnalazione che risultano entranti sulla PIU stessa. I link di segnalazione completano la vista strutturale sulle informazioni. In maniera complementare in corrispondenza dei link detti non propaganti non si hanno i link di segnalazione nel senso opposto. Ogni link propagante ha tutte le caratteristiche dei link discusse in precedenza, ma è tale per cui le modifiche apportate ai nodi a valle del link non si ripercuotono su quelli a monte. L introduzione di questo tipo di relazione è necessaria per modellare quelle casistiche in cui occorre relazionare a partire dal documento (per aggregazione oppure per riferimento) l informazione I specificatamente al tempo t = t i. A titolo esemplificativo è possibile ipotizzare un documento che rappresenti il modulo di licenza di matrimonio di un impiegato: in questo tipo di documento è necessario inserire le informazioni relative alla posizione lavorativa del dipendente al momento in cui la richiesta stessa viene prodotta. Una variazione della posizione lavorativa dell impiegato successiva al rientro della licenza matrimoniale non deve impattare sul documento appena citato, ma può/deve produrre, ad esempio, effetti sulla modalità di calcolo delle tasse che il lavoratore stesso dovrà versare al fisco. 67

94 InterDataNet Figura 3.5: Esempio di propagazione delle modifiche. Per chiarire le modalità con cui avviene la propagazione si faccia riferimento alla figura 3.5 nella quale il documento al tempo t 0 è costituito da una radice X1 che aggrega due figli Y1 e Z1 tramite opportuni link di aggregazione, rispettivamente A1 e A2. Dato che, per ipotesi, tali link di aggregazione sono propaganti esiste un link di segnalazione in senso inverso (S1 e S2) in corrispondenza di ognuno di essi. Il documento al tempo t 1 appare dopo una modifica (in conformità al meccanismo previsto in IDN-IM) relativa a Y e propagata alla radice X. In questo caso i link di segnalazione S1 e S2 sono stati rimossi e sono stati inseriti S3 e S4 in corrispondenza dei link di aggregazione A3 e A4 presenti nell ultima revisione della radice X I parametri di versione In questo paragrafo vengono descritti i parametri di versione che, in combinazione con il nome LRI di base, offrono la possibilità di navigare nello storico di informazioni primitive e documenti IDN. Nella definizione è stata usata la seguente convenzione: il nome del parametro è diviso, tramite il simbolo, in due parti: la prima è una singola lettera e serve per identificare l ambito in cui opera (i valori ammessi sono: R per revision, H per history, B per branch ed infine T per time), la secon- 68

95 InterDataNet da è una stringa che definisce una relazione all interno del contesto in cui il parametro è definito. I parametri, riportati di seguito, sono accompagnati da una breve descrizione: R NEXTNODE: Revision, Next Node. Si riferisce alla revisione successiva del nodo corrente. Si osservi che, a seguito di una richiesta con tale parametro di versione, possono presentarsi i seguenti casi: non esiste la revisione successiva: la risposta è quindi negativa. Questo è il caso dell ultimo elemento presente nel ramo; esiste la revisione successiva: la risposta fornisce il nodo che la contiene; ortogonalmente il nodo può essere radice di un branch, in questo caso la risposta contiene, se esiste, il nodo relativo alla revisione successiva e l indirizzo LRI più opportuno del primo elemento del branch. In questo modo viene soddisfatta la richiesta relativa alla revisione successiva ed i livelli superiori vengono messi a conoscenza dell esistenza del branch con la possibilità di indirizzarlo. R PREV: Revision, Previous. Si riferisce alla revisione precedente del nodo corrente. In modo duale a R NEXTNODE possono presentarsi i seguenti casi: non esiste la revisione precedente: la risposta è quindi negativa. Ciò si verifica solo per la radice dello storico; esiste la revisione precedente: la risposta fornisce il nodo che la contiene. il nodo può essere stato creato come nuova revisione o in seguito ad un operazione di merge. In quest ultimo caso, similmente a quanto è stato definito per le diramazioni, nella risposta sono presenti il nodo che contiene la revisione precedente (che si trova sullo stesso ramo del nodo di partenza) e l indirizzo LRI più opportuno dell elemento precedente presente nell altro branch. 69

96 InterDataNet H ROOT: History, Root. Questo parametro di versione si riferisce alla radice dello storico ovvero al primo elemento che è stato creato. B POINT: Branch, Point. Questo parametro di versione si riferisce al nodo, appartenente al ramo di origine, da cui sono stati generati uno o più branch. B ROOT: Branch, Root. Si riferisce alla radice del branch ovvero al primo elemento di un nuovo branch. Si osservi che per quanto riguarda i nodi appartenenti al ramo principale B ROOT coincide con H ROOT. B LAST: Branch, Last. Ultima revisione del branch. In riferimento al caso riportato in figura 3.6 il B LAST relativo ai nodi A, C, E ed F è F, mentre quello relativo ai nodi B e D è D. Si noti che questo Figura 3.6: Esempi di last relativi al branch. parametro è da considerarsi il default: in assenza di un parametro di versione, relativo o assoluto, il nome esprime l ultimo elemento del branch. Questo infatti permette di esporre una vista simile a quella offerta dalla semantica Unix (che, per ogni istante temporale, offre l accesso all ultima versione disponibile dell informazione) pur in presenza della semantica a file immutabili (ogni versione dell informazione è immutabile, apportare una modifica significa creare una nuova versione) introdotta, con il versioning, a questo livello. Lo scopo ultimo di questa scelta è quello di fare in modo che i nomi utilizzati dagli utenti, a meno che non contengano esplicitamente un parametro di versione, indichino la release corrente dell informazione. 70

97 InterDataNet Figura 3.7: Esempio di elemento recente rispetto al nodo di partenza. T ABSLAST: Time, Absolute Last. Elemento dello storico più recente (da un punto di vista temporale). T RELATLAST: Time, Relative Last. Elemento più recente presente nello storico, relativamente al nodo di partenza ovvero per il quale tale nodo figura fra gli antenati. Equivale al T ABSLAST dello storico ipotetico ottenuto considerando tutti i nodi dello storico iniziale a partire dal nodo in esame (tale nodo rappresenta quindi la radice dello storico ipotetico). In figura 3.7 è riportato un esempio: il nodo preso come riferimento è quello creato al tempo t=7. L elemento T ABSLAST relativo ad un qualunque elemento dello storico, e quindi anche al nodo creato al tempo t=7, è il nodo creato al tempo t=16. La risoluzione dell elemento T RELATLAST, ovvero quello più recente relativamente al nodo creato a t=7, è il T ABSLAST dello storico ipotetico di cui il nodo creato a t=7 è la radice e, nel caso specifico, è rappresentato dall elemento creato al tempo t=12. I parametri di versione relativi appena introdotti sono un meccanismo per navigare nello storico esprimendo una versione rispetto ad un altra. Il paradigma dei file immutabili viene raggiunto introducendo i parametri di versione assoluti. Un LRI con un parametro di versione assoluto indica in modo univoco e non ambiguo (e persistente) una ben precisa versione 71

98 InterDataNet dell informazione, indipendentemente dalla storia futura che l informazione avrà/ha-avuto dopo la creazione della versione in questione. La sintassi dei parametri di versione assoluti è definita tramite l espressione regolare [Goy06] riportata in figura 3.8. ([1-9][0-9]+\.[1-9][0-9]*\.)*[1-9][0-9]* Figura 3.8: Espressione regolare per definire gli identificativi di versione. Tale espressione regolare permette di rappresentare la categoria delle stringhe contenenti un numero arbitrario positivo di elementi costituiti da cifre terminanti con un punto e una sequenza terminale di cifre. Le sequenze di cifre rappresentano numeri interi e non possono iniziare con 0. Il numero di caratteri. è pari, vale a dire che la quantità di sequenze di cifre presenti è sempre dispari. Il motivo di questo vincolo sarà chiarito più avanti. Ad esempio, appartengono a questa classe le seguenti stringhe: 21, , etc. Non appartengono a questa classe le seguenti stringhe: 7.,.12, 01.3, Ver=1.4, , etc. In particolare l ultima mostrata non è valida in quanto è presente una quantità pari (non dispari) di sequenze di cifre. Figura 3.9: Convenzione sui nomi dei nodi nello storico. 72

99 InterDataNet La struttura dell identificativo è riportata in figura 3.9, mentre la figura 3.7 riporta i numeri di versione assoluti assegnati alle varie revisioni dell informazione mostrata nell esempio. Tale rappresentazione permette di individuare univocamente le versioni all interno dello storico e il branch di appartenenza. Per convenzione le prime N 1 cifre rappresentano l identificatore assoluto del branch all interno dello storico. Questo identificatore si ottiene aggiungendo al nome del nodo dal quale il branch è stato creato una cifra sequenziale, l identificatore relativo del branch. In questo modo il primo branch del nodo X.Y.Z è X.Y.Z.1, il secondo branch è X.Y.Z.2, etc. In ogni branch è presente almeno un nodo e l ultima cifra del nome identifica la revisione relativamente al branch. In riferimento all esempio precedente la prima revisione nel primo branch è X.Y.Z.1.1, la seconda revisione nel primo branch è X.Y.Z.1.2, la n-esima revisione nel m-esimo branch è X.Y.Z.m.n. 3.3 IDN Compliant Application Lo strato della IDN-SA offre i dati mentre la logica di manipolazione di questi dati avviene a livello di IDN-Compliant Application dove viene implementato un workflow distribuito in quanto vengono coinvolte diverse entità che usano anche applicazioni diverse per collaborare intorno a documenti condivisi. Quindi se abbiamo una molteplicità di applicazioni con logiche di business diverse grazie a documenti condivisi è possibile collaborare per avere un fine comune. Vincolare e dettagliare le applicazioni non risulta conveniente ai fini della crescita del sistema il cui obiettivo primario è proprio quello di definire un infrastruttura distribuita sopra la quale affrontare e risolvere specifici problemi di dominio (tramite applicazioni create ad-hoc). Sebbene le finalità siano essenzialmente diverse è possibile, esclusivamente a titolo esemplificativo, ipotizzare un parallelismo fra il mondo dei database, consolidato da anni e quindi ben noto, ed InterDataNet. In questo esempio è possibile associare IDN-IM al modello relazionale: entrambi i modelli catturano esclusivamente i principi astratti dell informazione, senza introdurre elementi implementativi. La Service Architecture (terza ed ultima vista) corrisponde alla specifica implementazione, ad esempio al database PostgreSQL. 73

100 InterDataNet È necessario osservare però che la differenza sostanziale fra un database ed InterDataNet risiede nel fatto che mentre ad n installazioni del database PostgreSQL corrispondono normalmente m > n silos di dati indipendenti (i singoli database) 6 l insieme di sistemi che implementano IDN-SA cooperano, per definizione, per la realizzazione di un unica ragnatela interconnessa di dati su scala di livello Web (almeno in via concettuale, niente vieta la possibilità di creare una Intranet InterDataNet confinata all interno di un ben determinato perimetro anche se questo vanificherebbe, almeno in parte, i benefici apportati dal sistema). InterDataNet infatti si muove nella direzione del Web, acquisendone i principi fondanti per estenderne le funzionalità al fine di far evolvere il Web stesso in modo da renderlo non solo l ambiente principe per la pubblicazione di informazione fruibile da umani, ma una piattaforma sopra la quale poter collaborare in modo efficace ed efficiente. Riprendendo l esempio, le applicazioni sono le entità che utilizzando il modello dell informazione proposto, dei database da un lato e IDN-IM dall altro, implementano le necessarie logiche di business per affrontare e risolvere specifici problemi di dominio. Nel mondo dei database gli esempi possibili di applicazioni sono in numero pressoché infinito, ma se la visione che ha guidato gli sviluppi di InterDataNet in questi anni dovesse concretizzarsi, anche gli esempi di applicazioni IDN saranno in numero elevato. Resta il fatto che tali applicazioni, date le caratteristiche del sistema, saranno orientate alla collaborazione su larga scala e non alla mera manipolazione di dati. Si pensi ai complessi workflow che vengono implementati per la produzione di un atto amministrativo: patenti di guida e carte di identità (solo per citare due esempi tanto ovvi quanto banali) potrebbero essere prodotte tramite decine di applicazioni IDN diverse. Ogni ente potrebbe realizzare la propria applicazione IDN per questo scopo, ma tutte le applicazioni sarebbero in grado di manipolare non solo le patenti di guida o le carte di identità da loro emesse, ma anche quelle emesse da uno qualunque degli altri enti (tramite altre applicazioni). Questo non deve stupire perché è ciò che accade da anni nel Web limitatamente al contesto della pubblicazione di documenti: 6 Si assume che ogni installazione di PostgreSQL esponga uno o più database. La federazione non è stata volutamente presa in considerazione per non complicare eccessivamente l esempio. 74

101 InterDataNet ogni ente/organizzazione è libero di selezionare il proprio stack tecnologico per la realizzazione del proprio sito web, conscio del fatto che gli utenti, con qualsiasi user-agent (entro certi limiti), potranno fruire dei contenuti pubblicati senza difficoltà. E nel caso in cui i contenuti non fossero esclusivamente di tipo HTML, ma espressi anche in altre forme (ad esempio RSS/Atom), gli user-agent potrebbero anche essere applicazioni diverse dai classici browser web (nell esempio aggregatori di feed). In questo caso gli attori che producono informazione e gli strumenti con cui la producono sono nettamente distinti da coloro i quali fruiscono dell informazione e dagli strumenti con cui la fruiscono, ma la pubblicazione in sé, in un formato standardizzato permette di raggiungere i risultati menzionati. InterDataNet intende far evolvere ulteriormente questo scenario, per fare in modo che la produzione stessa dell informazione avvenga in banda ovvero tramite gli stessi strumenti che vengono utilizzati per fruire dell informazione stessa ed in modo collaborativo. Ma a differenza di quanto accade nei diffusi social network di oggi, la pubblicazione e la collaborazione avviene tramite una modalità aperta che permette di abbattere le barriere attualmente presenti nel ventaglio delle alternative esistenti non in grado di interoperare (condividendo dati) le une con le altre, se non tramite soluzioni ad-hoc molto limitate. Nella visione InterDataNet le applicazioni interagiscono con i servizi IDN erogati in rete, servizi il cui obiettivo è esporre le funzionalità necessarie per la gestione di informazioni rappresentate secondo un linguaggio comune, in modo tale da permettere alle stesse, ed ad altre applicazioni, di utilizzare e ri-utilizzare le stesse informazioni per scopi diversi, in contesti diversi. Si pensi all indirizzo di residenza di un individuo e a quante volte ogni cittadino è costretto a fornire tale informazione ad enti diversi, con le inevitabili inconsistenze che nascono in corrispondenza del cambio di residenza. E non si sta solo facendo riferimento alla Pubblica Amministrazione la quale, se pur con grossi limiti e un margine di errore purtroppo non trascurabile, riesce a propagare tali aggiornamenti a tutti gli uffici interessati. Si pensi invece alle interazioni con banche, ai contratti di vario tipo, agli abbonamenti a riviste (l elenco è pressoché infinito) etc.: in corrispondenza dell aggiornamento della residenza è onere del cittadino provvedere a notificare tutti i soggetti interes- 75

102 InterDataNet sati per non rischiare di perdere informazioni importanti perché spedite, per posta ordinaria, all indirizzo non corretto. InterDataNet intende modificare questo scenario: l indirizzo di residenza è un dato sotto la responsabilità della Pubblica Amministrazione; il cittadino ha la possibilità di accedere a tale dato (e di richiederne l aggiornamento alla Pubblica Amministrazione nel caso di variazione della residenza) e di condividerlo con tutti i soggetti interessati stabilendo le politiche di privacy che più ritiene opportune. La Pubblica Amministrazione disporrà di una o più applicazioni IDN per la gestione dei dati anagrafici dei cittadini ognuna delle quali è in grado di trattare correttamente tale informazione. All apertura di un conto corrente bancario l operatore, utilizzando l applicazione IDN che la propria banca mette a disposizione per la gestione dei conti correnti, creerà un nuovo documento (che descrive il conto) nel quale verrà inserito non il valore dell indirizzo di residenza, ma un riferimento al dato detenuto dalla Pubblica Amministrazione. Nel momento della stampa dell estratto conto per l invio per posta ordinaria, l applicazione dedicata (IDN Compliant) consulterà il documento che descrive il conto corrente che a sua volta conterrà il riferimento all indirizzo di residenza. In questo scenario l aggiornamento della residenza non comporterebbe nessun problema in quanto in fase di stampa dell estratto conto (e in tutti i processi in cui è necessario accedere all indirizzo di residenza dell intestatario del conto corrente) la banca farebbe sempre riferimento alla versione più aggiornata dell indirizzo detenuta dalla Pubblica Amministrazione e non memorizzata in autonomia all interno di un proprio database. Questo scenario, enormemente semplificato, permette di intuire l etereogeneità delle possibile applicazioni IDN e le possibili implicazioni che potrebbero presentarsi in corrispondenza di un adozione di InterDataNet su larga scala. Sicuramente non saremmo di fronte alla rivoluzione di Internet, ma i benefici riscontrabili in molteplici contesti sarebbero indiscutibili. 3.4 IDN Service Architecture Allo scopo di identificare i servizi necessari per un implementazione efficace ed efficiente di IDN-IM, è stata concepita un architettura logica stratifi- 76

103 InterDataNet cata, chiamata InterDataNet Service Architecture (IDN-SA), in grado di catturare i concetti del modello dell informazione e di separare la complessità del problema su più livelli (figura 3.10), in modo da stabilire le basi per l architettura di rete. crescita dell'astrazione Informazioni complesse (documenti) Informazioni elementari (nodi) Byte (file, database) IDN Compliant Application IDN REST API Virtual Resource Layer Information History Layer Replica Management Layer Storage Interface Layer IDN Service Architecture Figura 3.10: Livelli dell architettura IDN. È chiaro che nel processo che porta alla definizione dell architettura concreta, un passo necessario è declinare l Information Model in uno (o più) Data Model trattabili dal sistema. Questo passo è parte integrante della progettazione delle interfacce esposte dalle varie componenti di IDN-SA. Tornando ad IDN-SA, la definizione delle componenti stratificate è topdown: si parte dal una analisi e progettazione di alto livello (logica) per arrivare ad una trattazione dei servizi di basso livello (fisici). Principalmente in IDN si applica l architectural pattern 7 della stratificazione. La struttura fisica e logica di IDN ricerca quindi una soluzione che, dal punto di vista del trattamento dell informazione, sia analoga a quella dei sistemi di comunicazione tra piattaforme eterogenee, ispirandosi al successo della suite TCP/IP. Così come Internet risolve i problemi della comunicazione per le reti interconnesse delegando a livelli diversi la cura di aspetti specifici [Alm92, KS06], IDN propone l uso di livelli differenti per abilitare a livello globale la collaborazione tra persone, imprese ed organizzazioni. Ogni livello affronta una pro- 7 Fornisce un insieme di sottosistemi predefiniti, specifica le loro responsabilità ed esplicita le regole e linee guida per organizzarli e relazionarli tra loro. 77

104 InterDataNet blematica o caratteristica propria dell informazione (documento) ponendola su un piano condiviso e collaborativo. IDN-SA (figura 3.10) descrive i livelli di servizi Virtual Resource, Information History e Replica Management. Come già discusso nel paragrafo 3.3, vincolare e dettagliare gli strati Application e Storage Interface, alle estremità dello stack, non risulta conveniente ai fini, rispettivamente, della crescita del sistema e dell adattabilità verso sistemi esistenti (legacy). Per quanto concerne la crescita viene infatti lasciata la massima libertà per quel che riguarda la definizione del contesto applicativo che può essere diversificato come descritto nel paragrafo 3.3. Analogamente non vengono fissate specifiche stringenti sul formato di storage dei dati. Quest ultimo aspetto permette quindi di diversificare anche le soluzioni di basso livello, aspetto che garantisce l adattabilità con il passato ovvero la possibilità di riutilizzare, definendo degli Storage Interface ad-hoc, i sistemi legacy. Si noti come questo approccio equivalga a quello utilizzato nella definizione della pila Internet per la quale è stata lasciata la massima libertà nella definizione del livello applicativo e dei livelli inferiori a quello di rete. I livelli più alti percepiscono l informazione come entità complessa sotto forma di documento, nello specifico si sta facendo riferimento a Virtual Resource ed al livello applicativo. Ogni documento, definito tramite IDN- IM, è costituito da una serie di informazioni elementari legate da relazioni strutturali. Spostando l attenzione verso i livelli intermedi gli aspetti strutturali dell informazione vengono meno: l informazione è vista come tante unità elementari indipendenti. È infatti onere di Virtual Resource aggregare (ed effettuare l operazione complementare di scomposizione) le informazioni elementari per strutturarle nei suddetti documenti IDN. I livelli Information History e Replica Management trattano esclusivamente elementi informativi non strutturati, implementato su di essi opportune politiche di versioning e di replicazione rispettivamente. Infine al livello più basso (Storage Interface) l informazione è semplicemente una particolare codifica delle entità definite ai livelli superiori, in altre parole sequenze di byte da memorizzare persistentemente (file e record di database). 78

105 InterDataNet Con questa prospettiva, nel presente lavoro, si parla di livello (o layer) per fare riferimento ad un contenitore logico di servizi e sottosistemi indipendenti che manipolano ed effettuano specifiche operazioni sull informazione. Tali sottosistemi interagiscono fornendo o richiedendo servizi ad altri sottosistemi appartenenti allo stesso livello logico oppure ad altri livelli adiacenti Attraversamento dei livelli L interazione fra i livelli avviene tramite il paradigma client/server: ogni livello è client di quello inferiore (al quale richiede servizi) e server di quello superiore (al quale fornisce dei servizi). Quindi, per ogni coppia di livelli, viene definito un protocollo di comunicazione che, essendo basato su HTTP (vedi [FGM + 99]), è request/response. Il paradigma convenzionale di interazione fra l utente e il sistema è di tipo pull: in seguito ad un azione dell utente la pila viene attraversata da una sequenza di request che si sviluppa dall alto verso il basso e da una sequenza corrispondente di response che la percorre in senso opposto. Ogni livello si attiva per generare la response a seguito di ogni request proveniente dal livello superiore (o da un azione dell utente per quanto riguarda il livello applicativo), eventualmente effettuando delle richieste ai livelli inferiori (come evidenziato in figura 3.11) per richiedere l espletamento di servizi necessari per il completamento dell operazione. Richiesta dell'utente Risposta all'utente Request - Response Livelli IDN Tempo Figura 3.11: Interazione request/response applicata ad IDN. 79

106 InterDataNet Un meccanismo di notifica in modalità push, risulta utile in svariate situazioni ad esempio per inoltrare segnalazioni in tempo reale all utente a seguito di eventi che si sono verificati nel sistema. Per questo motivo in IDN-SA è stato introdotto un meccanismo di notifica che permette di effettuare segnalazioni in modalità push sia verso documenti IDN che, indirettamente, verso le applicazioni (e quindi gli utenti) Imbustamento di dati e metadati L attraversamento dei livelli, descritto per la modalità di interazione (paragrafo 3.4.1), ha dei risvolti di interesse anche per le modalità con cui vengono trattate le informazioni. Infatti le informazioni vengono elaborate e trattate a seguito della comunicazione fra i livelli. Da un punto di vista generale è valida la seguente affermazione: ogni livello di IDN tratta le informazioni scomponendole, con la granularità necessaria, in dati elementari ed associa alle stesse un insieme di metadati. I dati quindi, indirizzabili con granularità arbitraria, codificano le informazioni vere e proprie; in aggiunta vengono associati ad essi tutti quei metadati necessari (o opzionali) per trattare le informazioni secondo quanto previsto dal modello IDN-IM. Entrando nel dettaglio, come rappresentato in figura 3.12, si ha la seguente situazione: le IDN-Application definiscono a proprio uso e consumo le rappresentazioni opportune delle informazioni in modo coerente al modello IDN-IM (ed alla IDN-API). In particolare consegnano all interfaccia del Virtual Resource sia dati veri propri (VR-UserData) sia metadati (VR-UserMeta) ad essi associati; Virtual Resource aggiunge poi tutti quei metadati (VR-LevelMETA in figura 3.12) necessari per il proprio funzionamento che sono di sua esclusiva competenza. L insieme di questi elementi (VR-LevelMETA), con l aggiunta del contenuto prettamente informativo, codificato in VR- UserDATA e dei metadati passati dal livello applicativo VR-UserMETA viene trasformato dal livello VR in dati (IH-UserMeta) e metadati (IH- 80

107 InterDataNet Figura 3.12: Imbustamento di dati e metadati. UserData) per il livello IH applicando delle specifiche funzioni di trasformazione; Information History aggiunge quindi quei metadati (IH-LevelMETA) 81

108 InterDataNet necessari alla gestione del versioning delle singole entità elementari (come se fossero non strutturate) e poi l insieme degli IH-UserData, IH- UserMeta e IH-LevelMETA viene trasformato mediante specifiche funzioni in RM-UserData e RM-UserMeta; e passato al livello Replica Management come un unica entità; Replica Management aggiunge a sua volta quei metadati (RM-LevelME- TA) necessari alla gestione della replicazione delle singole entità elementari (come se fossero non strutturate) e l insieme di RM-UserData e RM-UserMeta e RM-LevelMeta subisce delle trasformazioni da parte di apposite funzioni per dare origine a SI-UserData e SI-UserMeta; infine Storage Interface provvede ad esporre i dati memorizzati su sistemi di storage eterogenei, associando ad essi gli opportuni metadati (SI-LevelMETA). Il provvedimento top-down, appena illustrato, è utile per evidenziare l applicazione in IDN del principio di information hiding. Altrettanto utile è descrivere la visione bottom-up per capire come dati ed metadati (in generale le informazioni) vengono esposte ai livelli superiori. Infatti la descrizione appena fornita non permette di capire completamente come vengono trattati i metadati. Da un punto di vista generale è possibile osservare che ogni livello espone, secondo un interfaccia uniforme, i dati ed i metadati al livello superiore. Questo significa che il livello superiore, per ogni informazione alla quale intende accedere, ha la possibilità di richiedere la gestione dell informazione stessa (il dato) ed un opportuno insieme di metadati. Alla luce di queste considerazioni è possibile indicare per ogni livello le seguenti categorie di metadati (figura 3.13). Per semplicità fissiamo l attenzione sulla una coppia di livelli Information History (IH) e Replica Management (RM), da cui è immediato generalizzare per gli altri livelli. i metadati definiti dal livello superiore e solamente gestiti da quello in esame, in termini di creazione, accesso, modifica, e cancellazione (IH-UserMeta, in figura 3.13); 82

109 InterDataNet i metadati definiti dal livello in esame per il proprio funzionamento, ma esposti al livello superiore perché significativi per esso (in figura Exposed-LevelMETA); i metadati definiti dal livello in esame per il proprio funzionamento interno e non visibili al livello superiore (in figura Internal-LevelMETA). Information History Layer RM-API IH DATA RM-DATA IH META RM-META Exposed META Internal META Replica Management Layer Figura 3.13: Classi di metadati in IDN. Si faccia quindi nuovamente riferimento alla figura 3.12 e si consideri il livello Replica Management. Nell insieme di informazioni classificate con RM- UserData rientrano i dati veri e propri di livello IH ed i metadati RM-UserMeta definiti da IH la cui gestione, in termini di creazione, accesso, modifica, e cancellazione, viene delegata ad RM. In figura 3.13 sono esemplificate tutte le entità: RM-UserDATA, IH-UserDATA e RM-UserMETA. Ad esempio i dati potrebbero essere il contenuto vero e proprio relativo alla versione x di una data informazione ed uno dei metadati gestiti da RM potrebbe essere proprio il numero di versione <version_id,x>. Ovviamente, il numero di versione non è un elemento che RM è in grado di interpretare, può solo prendersi cura di memorizzarlo mantenendolo associato all informazione di base ed esporlo ad IH (livello che ne ha la responsabilità). Proseguendo attraverso esempi di metadati, è possibile citare la data di creazione di un unità informativa replicata. Questo tipo di metadato viene definito e gestito a livello RM, ma può essere di interesse anche al livello superiore e quindi sarà esposto ad esso. In questo caso, in riferimento alla figura 3.13, questo tipo di metadato rientra a pieno titolo in RM-LevelMETA 83

110 InterDataNet (Exposed-META) ed RM offrirà al livello superiore l accesso allo stesso (se pur con alcune limitazioni). Questo perché, essendo tale metadato di competenza di RM, tale livello non permetterà che IH possa modificarlo senza controllo. Nell esempio specifico non permetterà affatto che IH possa modificarlo, offrendogli solo la possibilità di accedere ad esso in sola lettura. Questo perché è RM che crea (eventualmente su richiesta di IH) le unità informative replicate e sarà quindi sua cura definire il campo <creation_date,date> 8.). Infine restano da analizzare i metadati definiti dal livello per il proprio funzionamento interno e non visibili al livello superiore (in figura 3.13 Internal META). Si pensi ad esempio all indirizzo fisico di una singola replica: questo tipo di metadato non è di interesse per il livello superiore (che vede solo entità delocalizzazione e replicate) e pertanto, pur rientrando nella classe RM-LevelMETA, non viene reso visibile al livello superiore. Quest ultima classe di metadati viene memorizzata dal livello inferiore (come per il numero di versione citato in precedenza), ma può essere generata dinamicamente, anche da sistemi esterni. Ciò apre la possibilità di definire un meccanismo di integrazione di metadati in maniera incrementale su informazioni provenienti da sistemi legacy IDN naming system Nei paragrafi precedenti è stato descritto il meccanismo di incapsulamento e trasformazione degli IDN-Node durante l attraversamento dei livelli. quella sede è stato volutamente tenuto al di fuori dell attenzione un aspetto di fondamentale importanza, ovvero come il livello superiore indirizzi quello inferiore per procedere con la successiva invocazione della richiesta di servizio. La questione che non è stata ancora affrontata riguarda come avviene il passaggio dalla classe di nomi che è a tutti gli effetti il Service Access Point (SAP) del livello superiore, alla classe che rappresenta il SAP del livello inferiore. 8 Si noti che in questo caso il campo non sarà più aggiornato per tutto il tempo di vita dell unità informativa. Si pensi però ad un metadato quale la data di ultimo accesso: sarà aggiornato da RM in corrispondenza di ogni richiesta di accesso all unità informativa e solo in tal caso. In 84

111 InterDataNet In IDN ogni livello eroga servizi al livello superiore attraverso l approccio REST. Questo significa che ogni livello espone delle risorse, indirizzabili a livello globale tramite nomi opportuni, sulle quali il livello superiore opera tramite un interfaccia uniforme. Ogni server IDN che implementa le funzionalità di un certo livello è indirettamente raggiungibile tramite il nome delle risorse su cui è autoritativo. Il SAP di ogni livello è quindi costituito dall insieme dei nomi delle risorse gestite da tutti i server che implementano le funzionalità del livello. Si definiscono quindi le seguenti classi di nomi: Logical Resource Identifiers (LRI): sono gli identificatori logici delle risorse che vanno ad individuare risorse di livello Virtual Resource. Alla luce di quanto affermato in precedenza sono quindi i nomi dei documenti IDN così come implementati da InterDataNet; Versioned Resource Identifiers (VRI): sono identificatori di risorse versionate. Risorse di questo tipo sono non strutturate e sono quelle gestite dal livello Information History ed utilizzate dal livello VR come contenitore dei singoli elementi che compongono documenti complessi; Persistent Resource Identifiers (PRI): sono identificatori di risorse replicate. Risorse di questo tipo sono non strutturate, non versionate e sono quelle gestite dal livello Replica Management ed utilizzate dal livello IH come contenitore delle singole revisioni che costituiscono lo storico di una risorsa versionata; Uniform Resource Locator (URL): sono classici URL che identificano risorse web standard, esposte dal livello Storage Interface ed utilizzate da RM come contenitore di singole copie di risorse replicate. In riferimento alla figura 3.14, che rappresenta la situazione descritta, occorre capire come vengono gestite le relazioni espresse tramite le frecce che legano i nomi LRI con i VRI, i VRI con i PRI ed infine i PRI con gli URL. In InterDataNet è stato quindi definito un sistema dei nomi che, similmente al DNS che offre (principalmente) il servizio di risoluzione da hostname ad indirizzo IP, permette di tradurre gli LRI in VRI, i VRI in PRI, i PRI in URL e, sotto alcune ipotesi operative, viceversa. 85

112 InterDataNet Figura 3.14: Sistema dei nomi di InterDataNet. In realtà non si tratta di un sistema monolitico che eroga il servizio di risoluzione, ma si hanno tre sottosistemi diversi che condividono i principi di funzionamento. In particolare, per la separazione dei compiti, si hanno: Logical Domain Name System (LDNS), sottoservizio di Virtual Resource, per la risoluzione diretta ed inversa da LRI in VRI; History Name System (HNS), sottoservizio di Information History, per la risoluzione diretta ed inversa da VRI in PRI; Localization Service (LS), sottoservizio di Replica Management, per la risoluzione diretta ed inversa da PRI in URL. 86

113 Capitolo 4 REST: metodologia di progettazione e pattern di utilizzo 4.1 REST Il termine REST è stato introdotto nel 2000 da Roy Fielding nella tesi di dottorato dal titolo Architectural Styles and the Design of Network-based Software Architectures 1. Il termine REST è l acronimo di Rappresentation State Transfer è stata originariamente introdotto per descrivere uno stile architetturale per sistemi di ipermedia distribuiti distribuiti su larga scala. Questo stile architetturale è un entità piuttosto astratta, i cui principi sono stati utilizzati per spiegare l eccellente scalabilità del protocollo HTTP 1.0 e hanno anche costretto il progetto della sua versione seguente, HTTP 1.1. Così, il termine REST, molto spesso viene utilizzato in combinazione con HTTP. 1

114 REST: metodologia di progettazione e pattern di utilizzo Principi Tecnologici Lo stile architetturale REST si basa sui seguenti quattro principi: Identificazione delle risorse attraverso URI. Un RESTful web service è un semplice web service implemento usando l HTTP e i principi del REST. Un Web service REST espone un insieme di risorse che individuano gli obiettivi di interazione con i propri clienti. Le risorse sono identificate da URI [BLFM05], che forniscono uno spazio di indirizzamento globale per la scoperta delle risorse e dei servizi. Interfaccia Uniforme. Le risorse sono manipolate utilizzando un insieme fisso di quattro operazione: creare, leggere, modificare, eliminare cui corrispondono rispettivamente alla PUT, GET, POST, e DELETE. PUT crea una nuova risorsa, che può essere poi eliminata utilizzando DELETE. GET recupera lo stato attuale di una risorsa in qualche rappresentazione. POST trasferimenti di un nuovo stato su una risorsa. Messaggio auto-descrittivi. Le risorse sono disaccoppiate dalla loro rappresentazione, di modo che al loro contenuto si può accedere in una varietà di formati (ad esempio, HTML, XML, testo, PDF, JPEG, ecc.). I metadati relativi alla risorsa sono usati, ad esempio, per il controllo caching, per rilevare errori di trasmissione, per negoziare l appropriato formato di rappresentazione, per eseguire il controllo di autenticazione o di accesso. Interazioni Stateful tramite collegamenti ipertestuali. Ogni interazione con una risorsa è stateless, cioè i messaggi di richiesta sono self-contained. Le iterazioni Stateful sono basate sul concetto di trasferimento dello stato esplicito. Esistono diverse tecniche per lo scambio di stato, ad esempio, l URI riscritto, cookies, e nei campi modulo nascosti. Gli stati possono essere incorporati in un messaggio di risposta per puntare agli stati futuri validi dell interazione. 88

115 REST: metodologia di progettazione e pattern di utilizzo 4.2 La metodologia di progettazione REST Le linee guide da seguire nella fase di progettazione REST, fanno riferimento ai seguenti passi come riportati in [PW10]: 1. Identificare le risorse che saranno esposte come servizi (e.g., un catalogo di libri, un ordine di acquisto, bugs aperti). 2. Modellare le relazioni fra le risorse in esame (e.g., contenimento, riferimento, transizioni di stato) tramite hyperlink che possono essere percorsi per ottenere maggiori informazioni oppure per ottenere transizioni di stato. 3. Definire dei nice URI per identificare le risorse. 4. Associare, per ogni risorsa, un significato alle operazioni esposte dall interfaccia uniforme ed eventualmente indicare se è consentito applicare tutti i metodi dell interfaccia REST sulla risorsa. 5. Disegnare e documentare le rappresentazioni delle risorse. 6. Implementazione e Testing. Vediamo nel dettaglio ognuno di questi punti Identificare le risorse di interesse Le risorse sono delle astrazioni che permettono di rappresentare funzionalità, stati e dati di un sistema. Le risorse sono dunque estremamente importanti per il REST in quanto costituiscono un unità di identificazione che può essere manipolata in remoto. Le risorse possono essere statiche, ovvero non subire cambiamenti nel tempo oppure dinamiche e nel qual caso il loro stato varierà al passare del tempo Le relazioni fra le risorse Le relazioni esistenti fra le risorse coinvolte costituiscono un aspetto importante da tenere in considerazione. Le risorse dovrebbero essere connesse 89

116 REST: metodologia di progettazione e pattern di utilizzo fra loro collegandole per realizzare diversi tipi di relazioni (ad esempio riferimento o contenimento o transizione di stato). Questo concetto può essere riassunto tramite il cosiddetto vincolo dell hypermedia (hypermedia costraint [Vin08]) infatti gli hyperlink rappresentano queste relazioni ed è possibile per una applicazione client esplorare le risorse sul server attraversando i vari hyperlink di risorsa in risorsa senza che il client debba necessariamente conoscere a priori la strutturazione delle risorse sul server Definizione di URI per le risorse Le risorse rappresentano delle unità di identificazione a cui sono associati degli URI (Uniform Resource Identifier [BLFM05]). Esistono diversi schemi di nomi per gli URI, in particolare i più conosciuti sono gli HTTP- URI che sono quelli usati per identificare le risorse sul Web attuale. Per quanto riguarda la presente trattazione, anche se il REST non specifica un particolare schema di nomi da adottare, saranno utilizzati gli HTTP-URI per identificare le risorse. In particolare verranno usati nice URI ([PZL08]) ovvero URI che godono di proprietà quali: persistenza, predicibilità, sinteticità, reificazione (ovvero preferire nomi a verbi), leggibilità, consistenza e astrazione da dettagli implementativi Interfaccia uniforme per le risorse Lo stile architetturale REST prevede l uso di un interfaccia uniforme (Uniform Resource Interface). L interfaccia uniforme in questione consiste di un certo insieme di ben definite operazioni per accedere e manipolare risorse. La stessa interfaccia è usata per qualsiasi tipo di risorsa ovvero l interfaccia uniforme è indipendente dalle risorse adottate. L interfaccia uniforme del REST è costituita dai metodi standard dell HTTP GET, PUT, POST e DELETE. 90

117 REST: metodologia di progettazione e pattern di utilizzo Disegnare e documentare le rappresentazioni delle risorse In realtà quello che viene trasferita fra client e server non è la stessa risorsa bensì una sua rappresentazione. È possibile che siano disponibili diverse rappresentazioni per una stessa risorsa in formati diversi. Il protocollo HTTP utilizza i MIME media type per identificare i formati di dati. È dunque indispensabile definire in fase di progettazione quali saranno i formati ritenuti necessari per la rappresentazione della risorsa e a questo punto andare a disegnare la rappresentazione della risorsa nel formato scelto. L applicativo client avrà la possibilità di recuperare una risorsa invece che un altra tramite il meccanismo della content negotiation. Per quanto riguarda le rappresentazioni degli IDN-Node sono previste rappresentazioni in XML e Json anche se il presente lavoro si occuperà solo di definire la rappresentazione in XML. Il MIME type considerato per la rappresentazione XML è application/xml in quanto si tratta di dati codificati tramite xml come è indicato dal sottotipo mentre il tipo application indica che su questa rappresentazione verrà eseguito un qualche tipo di elaborazione da parte di un applicazione Implentazione e Testing Queste due ultime fasi rappresentano l effettiva realizzazione dell applicazione, e il suo dispiego su Web server, e la prova del corretto funzionamento utilizzando un Web browser. 4.3 Servizio composito RESTful La composizione è uno dei principi fondamentali del service-oriented computing, e favorisce il riutilizzo dei servizi esistenti per mezzo di un loro assemblaggio in più applicazioni che li combinano in modi nuovi. Questo principio non è esplicitamente definito e non si trova nella definizione originale dello stile architetturale REST. Lo stile architetturale REST introduce una serie di elementi (user agent, proxy, gateway e gli origin server), che combinati opportunamente con- 91

118 REST: metodologia di progettazione e pattern di utilizzo sentono la costruzione di un sistema a più livelli e scalabile, permettendo così ad un numero elevato di clienti (o user agent) di accedere alle risorse pubblicate da un singolo origin server (vedi figura 4.1). Ogni elemento è collegato mediante il protocollo HTTP. Figura 4.1: Elementi architetturali REST. Componenti intermedi (cioè, proxy e gateway) sono opzionali e di solito aggiunti ad una architettura compatibile con lo stile REST per eseguire controllo degli accessi, caching, e una sorta di traduzione del protocollo. Per esempio, come in figura 4.2 un reverse proxy caching (o gateway) può essere introdotto per ridurre il carico sul server di origine imposto da un numero crescente di clienti. Allo stesso modo, [Pau09] un access control proxy può essere collegato ad user agent multipli e solo ad un sottoinsieme di essi è consentito di accedere agli origin server. Per entrambi gli esempi appena visti, ogni richiesta del client passa attraverso l elemento intermedio proxy (o gateway) ed è servita in maniera indipendente da un unico origin server. Considerando che possono esistere più server, essi sono visti come fonti di informazione autonome e scollegate il cui stato si evolve in maniera indipendente. I client possono accedere sequenzialmente a più server (ad esempio, al seguito di collegamenti ipertestuali da uno a l altro). Così facendo, i client possono anche raccogliere, in qualche modo, le informazioni provenienti da più server e di aggregarle a livello locale. Pertanto, il REST sembrerebbe sostenere una qualche forma di composizione limitata al client. Tuttavia, nessun elemento intermedio è esplicitamente prevista nel REST per aggregare informazioni da più server. 92

119 REST: metodologia di progettazione e pattern di utilizzo Figura 4.2: Access control e caching Servizio composto RESTful Nel contesto della discussione precedente, un servizio composto RESTful è un particolare tipo di elemento intermedio che, a differenza di proxy e gateway, non inoltra semplicemente le richieste agli origin server a monte, ma può scomporsi in un richiesta in modo che possa essere servito invocando più di un origin server (vedi figura 4.3). Figura 4.3: Servizio Composito RESTful. Data la natura ricorsiva della composizione, anche il servizio composto è un servizio RESTful. Espone una serie di risorse ai propri clienti, che interagiscono con loro secondo il principio uniforme interfaccia REST (cioè, usando il GET, POST, PUT, DELETE metodi). Inoltre, i client fanno le richieste senza sapere che le loro richieste sono servite da un servizio composto. 93

120 REST: metodologia di progettazione e pattern di utilizzo Perciò, i client potrebbero non sapere se il risultato di una richiesta GET viene calcolato localmente o attraverso il servizio composto (composite service) risultato dalla combinazione dei risultati di una serie di richieste GET inviati alla composizione degli origin server. Allo stesso modo, un client può inizializzare (POST), aggiornare (PUT) o eliminare (DELETE) lo stato di un servizio composto, le loro richieste possono essere conseguenza di risorse create, aggiornato o cancellato localmente, o in azioni simili siano effettuate dal servizio composto su un sottoinsieme di risorse pubblicate dalla composizione degli origin server. Da una prospettiva di attuazione, si possono distinguere due tipi di composite service: composizione stateless e composizione stateful. Una composizione stateful aumenta lo stato della composizione degli origin server con l informazione che è gestita e memorizzata sul servizi composto. Così, parte dello stato delle risorse composte è gestito a livello locale e il resto è suddiviso tra gli origin server. La composizioni stateless invece non mantiene lo stato locale e trasparentemente mappa tutte le richieste dei clienti allo stato degli origin server. La composizione stateful aumentare lo stato degli origin server con le informazioni gestite e memorizzata sul servizio composto. Così, parte dello stato delle risorse composte è gestita a livello locale e il resto è suddiviso tra gli origin server. La composizioni stateless invece non mantengono qualsiasi stato locale e trasparentemente mappa tutte le richieste dei clienti per lo stato degli origin server. 94

121 Parte III PHARMA

122

123 Capitolo 5 Progettazione in ottica REST del sistema PHARMA La progettazione in ottica REST di una applicazione web è la parte fondamentale del lavoro di tesi. In questo capitolo, seguendo quanto enunciato e descritto alla sezione 4, si propone la progettazione adottata per la realizzazione dell IDN-compliant application PHARMA (Personal HospitalizAtion Records MAnagement). 5.1 Identificazione delle Risorse Per quanto già detto al capitolo 4, in questo passaggio si identificano le risorse che debbono essere esposte dal servizio; vi sono diversi tipi di risorse: vi sono quelle predefinite, che sono utilizzabili per aspetti importanti dell applicazione, risorse che rappresentano ogni oggetto esposto attraverso il servizio e infine risorse ottenute mediante algoritmo. Si propone perciò nel seguito l elenco delle risorse definite primarie ed individuate per PHARMA.

124 Progettazione in ottica REST del sistema PHARMA Figura 5.1: Logo dell applicazione PHARMA. GESTORE FASCICOLI GESTORE CARTELLE CLINICHE GESTORE REFERTI FASCICOLO OSPEDALIERO CARTELLE CLINICHE CARTELLA CLINICA TERAPIE GIORNALIERE TERAPIA GIORNALIERA REFERTO CONSENSO BOX CARTELLE (virtuale) BOX TERAPIE (virtuale) BOX REFERTI (virtuale) 98

125 Progettazione in ottica REST del sistema PHARMA Si tratta tuttavia di una analisi limitata, con questo si intende che si considerano i documenti di tipo TERAPIA GIORNALIERA, parte di una CARTELLA CLINICA, su cui porre l attenzione. Tornando al caso di studio, si individuano tredici risorse primarie di cui tre virtuali: la loro introduzione si è resa necessaria in quanto esse devono fungere da interfaccia verso le entità in gioco. In altre parole, esse offrono dei servizi e sono utilizzate per mascherarne altri, di modo tale che le operazioni risultino trasparenti e si separi/distribuisca la gestione (e le responsabilità) dei documenti. Le risorse CARTELLE CLINICHE e TERAPIE GIORNALIERE hanno la funzione di documenti che fungono da contenitori per le risorse CARTEL- LA CLINICA, all interno di FASCICOLO OSPEDALIERO, e TERAPIE GIORNALIERE per quanto riguarda il documento CARTELLA CLINICA stesso. Se l introduzione di GESTORE FASCICOLI e GESTORE CAR- TELLE sembra naturale per una migliore gestione distribuita delle risorse e delle responsabilità delle stesse, l introduzione di GESTORE REFERTI potrebbe sembrare una ridondanza non necessaria, i benefici dati da questa soluzione sono riconducibili ad una migliore gestione dei documenti e delle responsabilità (come per altro per le risorse GESTORE precedenti), dato che l applicazione si viene a trovare all interno di un ambiente distribuito. Altro punto fondamentale è che le risorse CARTELLA CLINICA e TE- RAPIA GIORNALIERA prevedono metadati specifici per una gestione più rapida delle informazioni da parte delle applicazioni lato utente: sostanzialmente le informazioni specifiche si traducono in date cui corrisponde la competenza dei documenti e flag di validità (concetto più chiaro avanti). 5.2 Relazioni tra le Risorse Il secondo passaggio previsto dalla progettazione REST riguarda la modellazione delle relazioni tra le risorse attraverso dei collegamenti che permettano di cogliere maggiori dettagli. In figura 5.2 sono quindi mostrate le relazioni che sono presenti fra le risorse primarie prima individuate. 99

126 Progettazione in ottica REST del sistema PHARMA Figura 5.2: Relazione tra le Risorse progettate. 5.3 Definizione degli URI Altro punto molto importante, il terzo della progettazione REST, è la definizione dei cosiddetti nice URI, atti alla localizzazione e indirizzamento delle risorse esposte dal servizio. Di seguito sono elencati gli URI per le risorse citate al paragrafo 5.1. GESTORE FASCICOLI /gestorefascicoli FASCICOLO OSPEDALIERO /gestorefascicoli/fascicolo/{id fascicolo} CARTELLE CLINICHE /gestorefascicoli/fascicolo/{id fascicolo}/cartelle BOX CARTELLE /gestorefascicoli/fascicolo/{id fascicolo}/cartelle/boxcartelle 100

127 Progettazione in ottica REST del sistema PHARMA CARTELLA CLINICA (canonico) /gestorecartelle/cartella/{id cartella} CARTELLA CLINICA (alias) /gestorefascicoli/fascicolo/{id fascicolo}/cartelle/{id cartella} GESTORE CARTELLE CLINICHE /gestorecartelle TERAPIE GIORNALIERE /gestorecartelle/cartella/{id cartella}/terapie BOX TERAPIE /gestorecartelle/cartella/{id cartella}/terapie/boxterapie TERAPIA GIORNALIERA (canonico) /gestorecartelle/terapia/{id terapia} TERAPIA GIORNALIERA (alias) /gestorecartelle/cartella/{id cartella}/terapie/{id terapia} BOX REFERTI /gestorecartelle/terapia/{id terapia}/int tratt/{id int tratt}/boxreferti REFERTO (canonico) /gestorereferti/referto/{id referto} REFERTO (alias) /gestorecartelle/terapia/{id terapia}/int tratt/{id int tratt}/referto/{id referto} CONSENSO /gestorecartelle/terapia/{id terapia}/int tratt/{id int tratt}/consenso/{id consenso} /gestorecartelle/terapia/{id terapia}/presc somm/{id presc somm}/consenso/{id consenso} GESTORE REFERTI /gestorereferti 101

128 Progettazione in ottica REST del sistema PHARMA Considerazioni 1. La struttura degli URI è realizzata attraverso dei template per favorire la lettura a livello utente tale da permettere così una individuazione più facile (sempre lato umano) di cosa sia legato, in termini di risorse, a quella particolare locazione. Questo sistema di strutturare e definire i nomi delle risorse in gioco serve anche a permettere la generazione in automatico degli URI da parte dell applicativo. 2. L identificativo del FASCICOLO OSPEDALIERO (i.e. {id fascicolo}) è calcolato in modo tale da poter accedere direttamente a ciascun paziente archiviato: si pensa di combinare informazioni provenienti da fonti diverse per la definizione di altri URI con cui è possibile identificare un dato FASCICOLO. Per questo si realizzano degli alias che abilitano questo meccanismo per una identificazione certa del paziente ed un accesso diretto da parte di PHARMA. 3. Per il REFERTO il meccanismo di alias serve a considerare che una stessa risorsa, visto che questi documenti sono di responsabilità di GE- STORE REFERTI (URI canonico), compaiono nei documenti TERA- PIA GIORNALIERA (URI alias). 4. La struttura della CARTELLA CLINICA non prevede che vi siano dei collegamenti ai documenti REFERTI e CONSENSI: questa scelta è spiegabile grazie al fatto che si tratta di due risorse che dipendono da una specifica TERAPIA GIORNALIERA e più in particolare sono legati a singoli elementi quali PRESCRIZIONI / SOMMINISTRAZIO- NI e INTERVENTI / TRATTAMENTI. Una loro presenza direttamente nella CARTELLA CLINICA, oltre quindi ad essere concettualmente sbagliata, avrebbe appesantito la lettura della stessa generando confusione nell utilizzatore dell applicazione (per una comprensione più approfondita sulle risorse si faccia riferimento alla sezione 5.5). 102

129 Progettazione in ottica REST del sistema PHARMA 5.4 Operazioni sulle Risorse Le operazioni REST che è possibile svolgere sulle risorse specifiche variano a seconda del soggetto che vi interagisce; oltre a definire le corrispondenze di quali richieste HTTP è concesso l uso, si definisce anche il significato che tali metodi assumono sulle diverse entità. Ciò corrisponde al quarto passaggio della progettazione REST Operazioni: Caso generale In questa sezione sono descritte le possibili operazioni HTTP che, in generale, sono consentite (figura 5.3). Nella seconda parte del paragrafo vengono invece mostrate le operazioni che ciascun attore coinvolto può operare sui singoli documenti. Figura 5.3: Caso generale delle possibili chiamate HTTP sulle Risorse. GESTORE FASCICOLI GET: fare una richiesta di questo tipo (GET /gestorefascicoli) significa recuperare i documenti FASCICOLO OSPEDALIERO, ovvero questa ope- 103

130 Progettazione in ottica REST del sistema PHARMA Figura 5.4: Rappresentazione grafica dell operazione POST sulla risorsa virtuale Box Cartelle. Figura 5.5: Rappresentazione grafica dell operazione POST sulla risorsa virtuale Box Terapie. Figura 5.6: Rappresentazione grafica dell operazione POST sulla risorsa virtuale Box Referti. razione scatena GET su ciascun FASCICOLO OSPEDALIERO che si interrompono a questo livello (vale a dire si ottengono gli URI contenuti 104

131 Progettazione in ottica REST del sistema PHARMA all interno di ciascun FASCICOLO). Il recupero di tutti i FASCICOLI OSPEDALIERI presenti nella struttura sanitaria risulta senza dubbio molto oneroso, ed è comunque una operazione da prevedere perché in futuro potrebbe essere necessario analizzare tutti i dati archiviati (ad esempio per gestioni amministrative). POST: una POST su GESTORE FASCICOLI (POST /gestorefascicoli) rappresenta la creazione di un nuovo FASCICOLO OSPEDALIERO; l operazione in questione prevede che sia predisposto non solo il FASCICO- LO (/gestorefascicoli/fascicolo/{id fascicolo}) ma anche la parte di ANAGRAFI- CA (/gestorefascicoli/fascicolo/{id fascicolo}/anagrafica) e le altre risorse aggregate che lo compongono (cfr. paragrafo successivo) e la risorsa (virtuale) BOX CARTELLE (/gestorefascicoli/fascicolo/{id fascicolo}/boxcartelle). FASCICOLO OSPEDALIERO GET: questa operazione prevede di recuperare tutto il documento in esame, compresi l ANAGRAFICA e il documento CARTELLE CLINI- CHE entrambi a lui aggregati. Per quanto riguarda il recupero delle risorse CARTELLA CLINICA collegate ad un dato FASCICOLO OSPEDALIERO, questo viene eseguito mediante la risorsa CARTEL- LE CLINICHE che funge da contenitore per i ricoveri del paziente cui appartiene il FASCICOLO. PUT: questa operazione deve essere consentita in quanto è possibile fare un aggiornamento di questa risorsa sia in termini di modifica di dati in ANAGRAFICA che in termini di aggiunta di URI riferiti ai documenti CARTELLA CLINICA nello spazio di competenza del FA- SCICOLO OSPEDALIERO stesso. CARTELLE CLINICHE GET: una richiesta di questo tipo consente di recuperare gli URI delle risorse CARTELLA CLINICA registrati come link di riferimento. Per ottenere l ultima CARTELLA CLINICA, per esempio quella relativa 105

132 Progettazione in ottica REST del sistema PHARMA al ricovero attuale di un paziente, la selezione viene effettuata a livello applicativo attraverso l impiego di dati specifici (una sorta di metadati) che si rendono necessari per l individuazione di tale documento. PUT: questo metodo è qui impiegato per consentire di collegare una CARTELLA CLINICA ad un dato FASCICOLO OSPEDALIERO mediante appunto l aggiornamento della risorsa in esame. BOX CARTELLE POST: operazione che permette la creazione di una nuova CARTELLA CLINICA per mezzo della risorsa virtuale in oggetto (onpost /gestorefascicoli/fascicolo/{id fascicolo}/boxcartelle); Comporta le seguenti operazioni (figura 5.4): POST /gestorecartelle per la creazione di una CARTELLA CLINICA (la creazione deve essere fatta dalla risorsa GESTORE CARTELLE perché sono di sua competenza, infatti il FASCICOLO OSPEDALIERO ha sole relazioni di riferimento alle risorse CARTELLA CLINICA). GET /gestorefascicoli/fascicolo/{id fascicolo}/cartelle per permettere al lato server dell applicazione (la cui presenza è chiarita nel seguito) di ottenere la versione corrente del documento per operare delle modifiche che risulteranno consistenti. PUT /gestorefascicoli/fascicolo/{id fascicolo}/cartelle per quanto riguarda l aggiornamento del FASCICOLO OSPEDA- LIERO, ma che nel caso specifico si tratta del documento CAR- TELLE CLINICHE, con l URI della CARTELLA CLINICA creata (ottenuto dopo che la POST precedente è andata a buon fine). GESTORE CARTELLE POST: operazione che consente la creazione di una nuova CARTEL- LA CLINICA (POST /gestorecartelle). L operazione in esame deve inoltre 106

133 Progettazione in ottica REST del sistema PHARMA prevedere la creazione dei documenti aggregati a CARTELLA CLINI- CA (MODALITA RICOVERO e DATI PAZIENTE AL RICOVERO), nonché della risorsa virtuale BOX TERAPIE. Oltre a questo deve prevedere la creazione del documento TERAPIA GIORNALIERA secondo i tre template previsti per questa risorsa (quello con i figli DATA, INTERVENTI / TRATTAMENTI o PRESCRIZIONI / SOMMINI- STRAZIONI). CARTELLA CLINICA GET: una operazione di questo tipo (GET /gestorecartelle/cartella/{id cartella}) dovrebbe prevedere l ottenimento degli URI dei documenti che compongono la CARTELLA CLINICA, oltre che ottenere le risorse aggregate. Recuperare una data TERAPIA GIORNALIERA sarà compito di un filtraggio applicativo per questo tipo di documenti: per esempio si prevede che questa risorsa abbia associato una sorta di metadati in cui è codificata sostanzialmente la DATA relativa alla TERAPIA GIORNALIERA. PUT: questa operazione deve essere consentita in quanto è possibile fare un update di questa risorsa sia in termini di modifica di dati relativi al ricovero (i documenti aggregati MODALITA RICOVERO e DATI PAZIENTE AL RICOVERO) che in termini di aggiunta di URI riferiti per esempio alle risorse TERAPIA GIORNALIERA nello spazio di competenza della CARTELLA CLINICA stessa. TERAPIE GIORNALIERE GET: il metodo in questione è utilizzato per ottenere l elenco dei documenti TERAPIA GIORNALIERA che sono presenti nella CARTEL- LA CLINICA in esame. Siccome le singole risorse TERAPIA GIOR- NALIERA sono dei documenti riferiti all interno di TERAPIE GIOR- NALIERE, ciò che si ottiene come risposta da GET /gestorecartelle/cartella/ {id cartella}/terapie è un elenco di collegamenti ai singoli documenti (ovviamente ciò accade nel caso di successo). 107

134 Progettazione in ottica REST del sistema PHARMA PUT: operazione che consente di effettuare un aggiornamento della risorsa TERAPIE GIORNALIERE: questo serve perché è necessario aggiungere di volta in volta gli URI dei documenti di tipo TERAPIA GIORNALIERA alla CARTELLA CLINICA. BOX TERAPIE POST: operazione che permette la creazione di una nuova TERAPIA GIORNALIERA per mezzo della risorsa virtuale in oggetto (onpost /gestorecartelle/cartella/{id cartella}/terapie/boxterapie); la sua esecuzione comporta le seguenti operazioni (figura 5.5): POST /gestorecartelle per la creazione di una TERAPIA GIORNALIERA: infatti la creazione deve essere fatta dalla risorsa GESTORE CARTELLE perché, anche se le risorse TERAPIA GIORNALIERA non sono di sua diretta competenza, permette di snellire il recupero delle risorse CARTELLA CLINICA. Viene fatta col template del nodo DATA, figlio di TERAPIA GIORNALIERA, ed è una creazione non completa del documento (i.e. è una TERAPIA GIORNALIE- RA vuota in quanto per il momento non ha nessuna prescrizione o intervento). GET /gestorecartelle/cartella/{id cartella}/terapie per permettere al proxy di ottenere la versione corrente del documento per operare delle modifiche che risulteranno consistenti. PUT /gestorecartelle/cartella/{id cartella}/terapie per quanto riguarda l update della CARTELLA CLINICA, o per meglio dire della risorsa TERAPIE GIORNALIERE, con l URI della TERAPIA GIORNALIERA creata (ottenuto dopo che la POST precedente è andata a buon fine). In altre parole si esegue la connessione della TERAPIA GIORNALIERA appena generata alla CARTELLA CLINICA attuale. 108

135 Progettazione in ottica REST del sistema PHARMA TERAPIA GIORNALIERA GET: questa operazione (GET /gestorecartelle/terapia/{id terapia}) consente il recupero del documento in esame. PUT: è un operazione da prevedere perché gli aggiornamenti dei documenti aggregati a TERAPIA GIORNALIERA sono previsti (sarà però in qualche modo veicolato attraverso la struttura della TERAPIA GIORNALIERA che al momento della creazione con POST diventa noto). Ciò che si può modificare sono i documenti aggregati INTERVEN- TI / TRATTAMENTI e PRESCRIZIONI / SOMMINISTRAZIONI. Inoltre questo metodo viene usato anche per la creazione di nuovi documenti INTERVENTI / TRATTAMENTI e PRESCRIZIONI / SOM- MINISTRAZIONI (potendo costruire in automatico degli URI ben formati attraverso la definizione dei template). CONSENSO GET: operazione che permette di ottenere i dati relativi al documento CONSENSO (per esempio GET /gestorecartelle/terapia/{id terapia}/int tratt/ {id int tratt}/consenso/{id consenso}). PUT: aggiornamento della risorsa CONSENSO, la modifica deve essere prevista perché la sottoposizione al paziente del CONSENSO può avvenire in un secondo momento. Non è previsto l ingresso in campo di una nuova entità Paziente per la firma del CONSENSO: questo processo può essere assimilabile col fatto che sarà l Operatore che sottopone al Paziente il CONSNESO ad avere la responsabilità di segnalare che sia stata apportata la firma del Paziente stesso su di un supporto cartaceo. BOX REFERTI POST: operazione che permette la creazione di una nuovo REFERTO per mezzo della risorsa virtuale in oggetto (onpost /gestorecartelle/terapia/ {id terapia}/int tratt/{id int tratt}/boxreferti); comporta le seguenti operazioni (figura 5.6): 109

136 Progettazione in ottica REST del sistema PHARMA POST /gestorereferti per la creazione di un REFERTO: la creazione deve essere fatta dalla risorsa GESTORE REFERTI perché essi sono di sua diretta competenza, inoltre permette di snellire il recupero dei documenti CARTELLA CLINICA. GET /gestorecartelle/terapia/{id terapia}/int tratt/{id int tratt} per permettere al proxy di ottenere la versione corrente del documento per operare delle modifiche che risulteranno consistenti. PUT /gestorecartelle/terapia/{id terapia}/int tratt/{id int tratt} per quanto riguarda l update della TERAPIA GIORNALIERA con l URI del REFERTO creato (ottenuto dopo che la POST precedente è andata a buon fine). GESTORE REFERTI POST: operazione che consente la creazione di un nuovo REFERTO, inizialmente vuoto (POST /gestorereferti). Sostanzialmente verrà creato ma il server comunicherà che la sua creazione non è completa. REFERTO GET: operazione che permette di ottenere i dati relativi al documento REFERTO (è una risorsa che ha un URI canonico e un alias, pertanto sarà accessibile quindi con questi due riferimenti). PUT: update della risorsa REFERTO: la modifica deve essere prevista perché la sottoposizione al medico del REFERTO per la sua compilazione avviene di solito in un secondo momento. DELETE: cancellazione di un REFERTO: è un operazione negata a tutti gli attori in gioco ma deve essere prevista per la gestione dei fault, in questo caso si eliminano infatti solo referti vuoti. Ancora per rimarcare la questione, il documento REFERTO non viene creato in blocco con l INTERVENTO / TRATTAMENTO ma è delegato a 110

137 Progettazione in ottica REST del sistema PHARMA GESTORE REFERTI (creazione veicolata dalla risorsa virtuale BOX REFERTI), sorge la necessità di dover prevedere un annullamento della sua creazione per i problemi descritti in seguito sui fault dei server (cfr. sezione 5.5.3) Definizione di Ruoli specifici (privilegi sulle Risorse) Il contesto all interno del quale si trova il sistema PHARMA, permette di individuare tre distinte classi di Ruoli che operano sulle Risorse prima individuate e che possono sfruttare le operazioni descritte in precedenza per la gestione delle informazioni. Le tre classi si identificano con: MEDICO CAPOSALA INFERMIERE / OPERATORE Le operazioni che la classe di operatori registrati col ruolo MEDICO possono attuare sulle Risorse individuate, coincidono con quelle descritte nel caso generale: in altri termini, il MEDICO possiede i privilegi massimi che è possibile avere sulle risorse. Per gli altri due casi vengono introdotte delle limitazioni sugli accessi e sui privilegi; nel seguito i casi suddetti saranno trattati in modo separato e specificando di volta in volta il significato di ogni singola operazione che differisce dal caso generale illustrato in precedenza. Attore MEDICO Come già esposto in precedenza, la classe di operatori MEDICO possiede i privilegi massimi che è possibile avere sulle risorse. Si riporta perciò soltanto la visualizzazione delle possibili operazioni in figura 5.7 (in rosso sono evidenziate le differenze rispetto al caso generale). 111

138 Progettazione in ottica REST del sistema PHARMA Figura 5.7: Illustrazione delle possibili chiamate HTTP sulle Risorse da parte del MEDICO. Attore CAPOSALA Per quanto riguarda il gruppo di utenti registrati col ruolo CAPOSALA, vi sono alcune restrizioni maggiori in termini di operazioni sulle risorse come mostrato in figura 5.8. Il motivo è semplice da spiegare perché, ad esempio, solo il MEDICO è adibito alla prescrizione di nuove terapie mentre al CAPOSALA questa operazione è vietata (come nel caso precedente in rosso sono riportati i cambiamenti sulle richieste HTTP che vengono svolte sulle risorse). Inoltre vi sono alcune differenze nel significato di particolari operazioni evidenziate in giallo nella figura di riferimento. CARTELLA CLINICA PUT: questa operazione deve essere consentita a questo attore in quanto è possibile fare un update di questa risorsa in termini di modifica di dati relativi al ricovero (i documenti aggregati MODALITÀ RI- COVERO e DATI PAZIENTE AL RICOVERO). 112

139 Progettazione in ottica REST del sistema PHARMA Figura 5.8: Illustrazione delle possibili chiamate HTTP sulle Risorse da parte del CAPOSALA. TERAPIA GIORNALIERA PUT: questo metodo, nel caso in esame, consente di fare degli update sulle risorse (secondarie) STATO e OPERATORE del documento PRO- GRAMMAZIONE che a sua volta fa parte, in modo del tutto analogo, di INTERVENTI / TRATTAMENTI e PRESCRIZIONI / SOMMINI- STRAZIONI. Il significato è quello quindi di registrare la variazione di stato del relativo intervento (o somministrazione) da parte di un operatore che in questo caso è identificabile col ruolo di CAPOSALA. Attore INFERMIERE / OPERATORE Un altro caso ancora con più restrizioni è quello degli operatori col ruolo INFERMIERE / OPERATORE (figura 5.9). Anche qui, in rosso vi sono le operazioni vietate a tali attori e in giallo si evidenziano le differenze nel significato delle richieste HTTP. 113

140 Progettazione in ottica REST del sistema PHARMA Figura 5.9: Illustrazione delle possibili chiamate HTTP sulle Risorse da parte dell INFERMIERE / OPERATORE. TERAPIA GIORNALIERA PUT: questo metodo, nel caso in esame, consente di fare degli update sulle risorse (secondarie) STATO e OPERATORE del documento PRO- GRAMMAZIONE che a sua volta fa parte, in modo del tutto analogo, di INTERVENTI / TRATTAMENTI e PRESCRIZIONI / SOMMINI- STRAZIONI. Il significato è quello quindi di registrare la variazione di stato del relativo intervento (o somministrazione) da parte di un operatore (in questo caso identificabile col ruolo di INFERMIERE / OPERATORE). 5.5 Progettazione e Documentazione delle Risorse Una volta definite le operazioni REST sulle risorse, si procede a progettare e implementare la rappresentazione delle risorse stesse. Il presente paragrafo, che tratta questo argomento, si suddivide in tre parti: nella prima viene 114

141 Progettazione in ottica REST del sistema PHARMA illustrata la struttura dell Information Model e quindi dei documenti che lo compongono, successivamente vengono mostrati i casi d uso oggetto dello studio per il lavoro collaborativo tra gli attori in gioco sui fascicoli ospedalieri e infine, entrando più nel dettaglio, viene fornita la traduzione dei casi d uso della parte precedente in termini di messaggi HTTP scambiati tra le entità presenti Progettazione dell Information Model Il modello dell informazione (detto anche Information Model oppure IM) è la struttura sulla quale viene costruita poi l applicazione vera e propria, concede di utilizzare la meteafora dei documenti per la rappresentazione delle informazioni che sono fruibili da PHARMA (e più in generale da una IDN- Compliant Application) per mezzo delle IDN API ed è implementato dalla IDN-SA. Il modello usato per PHARMA è descritto dalle figure 5.10, 5.11, 5.12, 5.13 e 5.14; in rosso sono disegnate le relazioni di aggregazione tra i vari documenti, mentre in blu il rapporto di relazione è di riferimento tra i nodi. Figura 5.10: Information Model: prima parte relativa al Fascicolo Ospedaliero (Anagrafica). 115

142 Progettazione in ottica REST del sistema PHARMA Figura 5.11: Information Model: seconda parte relativa al Fascicolo Ospedaliero (Cartelle Cliniche). Per quanto detto ai paragrafi precedenti, l entità principale su cui si basa l applicativo PHARMA è il Fascicolo Ospedaliero (figura 5.10); i figli di tale nodo sono il nodo Anagrafica e il documento Cartelle: il primo raccoglie dati fondamentali per l identificazione certa del paziente, strutturati in modo tale che la loro rappresentazione sia la più riusabile possibile, il secondo invece è un contenitore di risorse Cartella Clinica. La strutturazione così realizzata permette di avere una Anagrafica unica al seguito di un elenco di ricoveri riconducibili ad una lista di Cartelle Cliniche. Tornando al nodo Anagrafica (figura 5.10), questo si compone di due parti denominate Dati Primari e Dati Secondari: la strutturizzazione in tale senso serve a dare più rilevanza a quelle informazioni necessarie a definire un identificazione certa di ciascun paziente; infatti nei Dati Primari sono contenuti, per i pazienti, Codice Fiscale, Nome, Cognome, Data di nascita, Sesso e dati della Tessera Sanitaria. Il documento Dati Secondari mostra altre informazioni comunque necessarie, ma a differenza delle precedenti non indispensabili. In figura 5.11 è mostrato invece il secondo nodo figlio di Fascicolo Ospedaliero, si tratta del documento Cartelle che, come già accennato, è un contenitore per risorse di tipo Cartella Clinica. Quest ultima tipologia di risorsa 116

143 Progettazione in ottica REST del sistema PHARMA Figura 5.12: Information Model: Dettaglio dei documenti Diario, Consulenze e Diagnosi (parte di Cartella Clinica). è composta da una serie di documenti molto importanti (Terapie Giornaliere, Diario, Consulenze, Diagnosi, Trasferimenti e Scheda Dimissioni) e da una serie di risorse aggregate che compongono i dati legati al ricovero cui la Cartella Clinica si riferisce (Modalità Ricovero e Dati Paziente al Ricovero). Il documento Diario mostrato in figura 5.12 si compone di due nodi figli: il Diario Medico e il Diario Infermieristico, entrambi hanno lo scopo di registrare informazioni di carattere descrittivo sulla vita del paziente durante il ricovero e la degenza in ospedale, segnalando anche la data e l ora nonché l operatore che osserva il paziente stesso. Analizzando il successivo nodo figlio di Cartella Clinica, il documento Consulenze visibile in figura 5.12, rappresenta il raccoglitore delle varie consulenze richieste per la cura della persona ricoverata. I documenti Consulenza vengono indirizzati a precisi operatori e nella Richiesta sono definiti i termini 117

144 Progettazione in ottica REST del sistema PHARMA della vera e propria consulenza domandata, oltre a contenere informazioni sulle generalità del paziente a cui ci si riferisce. Il nodo Diagnosi (figura 5.12) deve tenere traccia di tutte le diagnosi, dalla Diagnosi Iniziale stilata non appena avviene il ricovero, fino alla Diagnosi Finale che viene formulata insieme alla Scheda Dimissioni; ovviamente sono registrate anche le Diagnosi Intermedie che sono riscontrate nel corso della degenza. Altra entità è il nodo Trasferimenti visibile in figura 5.13, il quale registra tutti gli spostamenti che il paziente subisce durante il suo ricovero in ospedale (anche il passaggio da una area di attività ad un altra è qui riportato); come per il documento Diagnosi, Trasferimenti si compone di tre nodi figli: il primo è Trasferimento Ingresso che tiene conto della prima area di attività nella quale il paziente viene accolto, il secondo, nodo Trasferimento, registra uno spostamento intermedio e infine il documento Trasferimento Ultimo rappresenta l ultima ubicazione del ricoverato prima della sua dimissione. Se per esempio un paziente non subisse mai trasferimenti, oltre a quello registrato all atto dell inizio del ricovero, i documenti Trasferimento Ingresso e Trasferimento Ultimo sarebbero coincidenti. La Scheda Dimissioni (figura 5.13) è l ultimo atto di un ricovero nella struttura ospedaliera di una persona: si compone di una parte destinata direttamente al medico curante del paziente (lettera di dimissioni) ed una parte che raccoglie tutte le informazioni, come un riepilogo, di ciò che il paziente ha vissuto durante la sua degenza. Per questo motivo, la Scheda di Dimissioni Ospedaliera si compone in larga parte di dati riferiti, ovvero collegamenti ad altri dati che sono aggregati nei vari documenti della Cartella Clinica. L ultimo documento, non certo per ordine di importanza, è la Terapia Giornaliera (figura 5.14) che è la versione elettronica della Scheda Terapeutica Unica 1. Si tratta della risorsa su cui la collaborazione risulta massima, tutti gli attori in gioco infatti sono in grado di poter accedere e apportare modifiche a questo documento, ognuno secondo le policy definite alla sezione Seguendo appunto lo standard definito per le STU cartacee, il documento Terapia Giornaliera è formato da due parti principali: una che fa 1 Scheda Terapeutica Unica Regione Toscana G.R. n

145 Progettazione in ottica REST del sistema PHARMA riferimento alle Prescrizioni e Somministrazioni e una afferente agli Interventi e Trattamenti, il tutto riferibile ad una precisa data che è quella per cui la terapia è valida. Le due risorse appena citate sono due contenitori per i singoli nodi Prescrizione / Somministrazione e Intervento / Trattamento che sono i veri e propri elementi necessari alla cura del paziente. Ciascuna Prescrizione / Somministrazione fa riferimento ad un determinato farmaco, nonché ad una precisa posologia dello stesso e inoltre, attraverso i nodi figli Programmazione, si possono effettuare le prescrizioni alle ore ritenute necessarie; infine il figlio Consenso è necessario per formalizzare una situazione di accettazione di cura sperimentale data dall assunzione di particolari farmaci. La descrizione per il nodo Intervento / Trattamento è del tutto analoga a quella di ogni singola Prescrizione / Somministrazione con la differenza che il documento Consenso è relativo ad un atto medico quale un intervento e in più si trova un ulteriore entità denominata Referti: ogni intervento di qualsiasi natura esso sia, produce infatti un referto che riporta l esito dell esame una volta eseguito Casi d uso, flussi di collaborazione In questa sezione si illustrano e si descrivono i casi d uso propri della gestione collaborativa del lavoro tra le entità. Data la vastità delle operazioni disponibili sia per numero di attori che per quantità di documenti, si è scelto di puntare l attenzione su di una parte del Fascicolo Ospedaliero che è la Terapia Giornaliera (rappresentazione della Scheda Terapeutica Unica già citata in precedenza). La formalità seguita per la definizione dei diagrammi è il linguaggio BPMN (Business Process Model and Notation) [Gro11], mentre per la realizzazione degli stessi è stato impiegato il software BPMN Process Modeler [Biz11] che è stato sviluppato dalla BizAgi. Gli attori individuati per la descrizione dei casi d uso della collaborazione si identificano con tre ruoli: MEDICO CAPOSALA 119

146 Progettazione in ottica REST del sistema PHARMA INFERMIERE / OPERATORE I flussi sono rappresentativi di una vasta gamma di operazioni possibili sul documento Terapia Giornaliera; questi sono: MEDICO crea un Intervento / Trattamento in una Terapia Giornaliera OPERATORE esegue un Intervento / Trattamento in una Terapia Giornaliera MEDICO aggiunge un Referto ad un Intervento / Trattamento in una Terapia Giornaliera OPERATORE legge dati di una Terapia Giornaliera MEDICO modifica la Programmazione di una Prescrizione / Somministrazione in una Terapia Giornaliera MEDICO crea un Intervento / Trattamento in una Terapia Giornaliera Entità coinvolte: MEDICO, GESTORE FASCICOLI, GESTORE CAR- TELLE. Questo caso, tratta la creazione di un Intervento / Trattamento in una data Terapia Giornaliera (figure 5.15 e 5.16); il processo inizia con un Medico che formula una richiesta per avere accesso ai dati della Cartella Clinica di un preciso paziente rivolgendosi all entità Gestore Fascicoli. Quest ultimo inizia la ricerca del Fascicolo Ospedaliero associato alla persona indicata nella richiesta del Medico, una volta individuato il Fascicolo, il Gestore Fascicoli fornisce al Medico il riferimento alla Cartella Clinica che afferisce al ricovero attuale del paziente. Il controllo delle operazioni torna al Medico che formula una nuova richiesta al Gestore Cartelle, stavolta più precisa della prima, che mira ad ottenere le informazioni proprie del ricovero e nel caso specifico la Terapia Giornaliera desiderata. Come nel passaggio precedente, l entità a cui è rivolta la richiesta fornisce le indicazioni al richiedente; permettendo al Medico di avere tutti gli strumenti necessari ad inserire il nuovo Intervento nella Terapia ottenuta. Una volta che le modifiche sono state apportate, il 120

147 Progettazione in ottica REST del sistema PHARMA Medico le comunica ancora al Gestore Cartelle che procede alla registrazione effettiva dei dati; non solo, perché è necessario ottenere dal paziente la firma di un Consenso che dovrà essergli sottoposto. Il flusso termina quando Gestore Cartelle comunica al Medico che tutto è andato a buon fine. OPERATORE esegue un Intervento / Trattamento in una Terapia Giornaliera Entità coinvolte: OPERATORE, GESTORE FASCICOLI, GESTORE CARTELLE, GESTORE REFERTI. La collaborazione descritta di seguito e riportata nelle figure 5.17 e 5.18 è relativa all esecuzione di un Intervento / Trattamento da parte di un Operatore (che potrebbe essere un fisioterapista). La parte iniziale è ancora la stessa della sezione precedente, infatti quello che è fondamentale è la certa identificazione di un paziente; perciò avremo di nuovo la formulazione di una richiesta di una Cartella Clinica da parte dell Operatore al Gestore Fascicoli ed una successiva al Gestore Cartelle per l ottenimento della Terapia Giornaliera a cui l Intervento afferisce. La fase successiva, è l aggiunta delle informazioni necessarie sull Intervento alla Terapia in questione e l inoltro della stessa con le modifiche; il Gestore Cartelle, destinatario di tale fase, dopo aver realizzato che l intervento è stato eseguito interpellerà l entità Gestore Referti di modo tale che notifichi ad un attore che ricopre il ruolo di Medico, per esempio attraverso un sistema di , che deve essere compilato il Referto associato all Intervento. Il processo termina con il Gestore Cartelle che comunica la riuscita dell operazione all Operatore. MEDICO aggiunge un Referto ad un Intervento / Trattamento in una Terapia Giornaliera Entità coinvolte: MEDICO, GESTORE CARTELLE, GESTORE RE- FERTI. Il caso di collaborazione in esame mostra come un Medico aggiunga un Referto ad un dato Intervento, parte di Terapia Giornaliera (figure 5.19 e 5.20). L entità Gestore Referti inizia comunicando ad un Medico (scelto per esempio da una lista di Medici disponibili ad effettuare refertazioni) che 121

148 Progettazione in ottica REST del sistema PHARMA un preciso Referto deve essere compilato; il Medico destinatario della richiesta opera inserendo quanto ritiene necessario alla corretta compilazione, dopodichè restituisce il documento con le modifiche allo stesso Gestore Referti. L ultimo scambio avviene tra il Gestore Referti e il Gestore cartelle, il quale riceve l informazione sul Referto per la memorizzzione nella posizione corretta della Cartella Clinica di quel preciso paziente. Il flusso si conclude con la comunicazione al Gestore Referti, da parte del Gestore Cartelle, che tutto è andato a buon fine. OPERATORE legge dati di una Terapia Giornaliera Entità coinvolte: OPERATORE, GESTORE FASCICOLI, GESTORE CARTELLE. Il flusso qui descritto tratta di una semplice operazione di lettura dati su una determinata Terapia Giornaliera, come visibile anche nelle figure 5.21 e La parte iniziale, come più volte detto, è ancora la medesima: quindi il flusso procede dall Operatore al Gestore Fascicoli e viceversa, successivamente dall Operatore al Gestore Cartelle per il recupero di tutti i dati necessari. Una volta che l Operatore ha ricevuto e letto la Terapia del paziente richiesta, il processo termina. MEDICO modifica la Programmazione di una Prescrizione / Somministrazione in una Terapia Giornaliera Entità coinvolte: MEDICO, GESTORE FASCICOLI, GESTORE CAR- TELLE. L ultimo caso trattato mostra la modifica di una Programmazione di una Prescrizione per una migliore cura del paziente da parte di un Medico (figure 5.23 e 5.24). Ancora una volta la prima parte è atta alla certa identificazione del paziente con conseguente recupero delle informazioni riguardanti la sua degenza e il suo ricovero. Quindi, ottenuta la Terapia Giornaliera, il Medico appone le variazioni alla Programmazione che reputa necessarie; segue l inoltro delle modifiche dal Medico al Gestore Cartelle per la memorizzaione dei dati e infine la conclusione del processo con l invio della notifica dal Gestore Cartelle al Medico del corretto andamento del flusso. 122

149 Progettazione in ottica REST del sistema PHARMA Interazioni tra le entità in chiave REST Saranno qui di seguito descritte le interazioni che avvengono fra le entità più volte indicate in ottica REST. Vista la vastità delle possibili operazioni, si riportano solo alcune di esse che si possono definire più rappresentative e che coprono, in buona sostanza, la maggior parte dei casi d uso (o per meglio dire diagrammi di sequenza) per la collaborazione indicati in precedenza 2. Per la realizzazione dei diagrammi di sequenza, è stato utilizzato il software DIA [Fou09]. Premesse 1. Si analizzano nel seguito le interazioni HTTP che avvengono tra gli attori per la manipolazione del documento Terapia Giornaliera. Gli attori in esame sono (lato client dell applicazione, per maggiori dettagli cfr. capitolo 8): MEDICO CAPOSALA INFERMIERE / OPERATORE Le altre entità coinvolte nei flussi sono (lato server di PHARMA): GESTORE FASCICOLI GESTORE CARTELLE GESTORE REFERTI 2. Controllo degli accessi delegato ai server: il funzionamento prevede quindi che il client inserisca anche le proprie credenziali in ogni richiesta HTTP che eseguirà. Lato server avverrà un controllo sulla base delle politiche riportate nella sezione 5.4 Operazioni sulle risorse; in caso di operazione non valida, il server risponderà con un messaggio 401 UNAUTHORIZED. 2 Altri dettagli e convenzioni sono riportate in Appendice A. 123

150 Progettazione in ottica REST del sistema PHARMA 3. Politiche delle operazioni sulle risorse: si considerano gruppi di richieste/risposte come operazioni atomiche; tali operazioni atomiche nel seguito sono indicate da A(x,y), dove x indica il numero di azione atomica e y indica il numero di azione sub-atomica che compone quella indicata da x. 4. Invalidare le operazioni in caso di fallimento del server (ad esempio 500 INTERNAL SERVER ERROR): si deve ripristinare una situazione consistente al primo punto disponibile (punti individuati tra due operazioni non sub-atomiche), questo per non perdere l intero lavoro effettuato (prima di dichiarare l invalidazione ed attuare le politiche di consistenza sono concessi 3 tentativi per ogni richiesta). Per quanto riguarda l invalidazione di un azione atomica si deve precedere nel seguente modo: per ogni sub-azione sono concessi un numero prestabilito di tentativi di esecuzione (in questo caso 3); se una sub-azione non viene portata a termine si procede ad invalidare tutta l azione atomica cui è associata, annullando le modifiche a ritroso fino al primo punto consistente disponibile: per un operazione di PUT il conseguente annullamento consiste nell ottenere la versione precedente con il suffisso /prev della risorsa in esame e successivamente eseguire una richiesta di PUT con la versione precedente della risorsa ottenuta; per un operazione di POST l annullamento consiste inevitabilmente in una DELETE del documento creato in precedenza (la DELETE è valida per il solo documento Referto); se un azione atomica è composta da una sola operazione (richiesta HTTP) questa viene trattata come azione sub-atomica per quanto riguarda l applicazione delle politiche di annullamento e di consistenza. In altre parole, un azione atomica composta da una sola operazione non produce altri effetti dovuti ad altre azioni sub-atomiche. 124

151 Progettazione in ottica REST del sistema PHARMA 5. In presenza di conflitti su operazioni PUT oppure POST si procede nel seguente modo: il server risponde con un messaggio 409 CONFLICT indicando che la risorsa su cui si sta lavorando non è corretta, questo è possibile eseguendo un controllo sui valori ETag delle richieste; il client procede cercando di ottenere nuovamente la risorsa aggiornata (GET) e prosegue con un nuovo tentativo di modifica. Operazioni relative all attore MEDICO Secondo quanto introdotto alla sezione 5.5.2, si mostra una traduzione delle casistiche più rappresentative dei processi collaborativi in chiave REST per quanto riguarda la classe di attori identificabili col ruolo di MEDICO. I casi analizzati sono i seguenti: Lettura dati della risorsa Terapia Giornaliera Creazione del documento Interventi / Trattamenti per un documento Terapia Giornaliera di una data Cartella Clinica Registrazione di avvenuta esecuzione di un Intervento / Trattamento per un documento Terapia Giornaliera di una data Cartella Clinica Modifica del Referto nel documento Intervento / Trattamento per un documento Terapia Giornaliera di una data Cartella Clinica Creazione di un documento Cartella Clinica (si considera qui anche la creazione, eventuale, della risorsa Fascicolo Ospedaliero) Per ciascuno di essi verranno descritte qui di seguito le operazioni (chiamate HTTP) tra le entità coinvolte nei vari flussi. Qualora risultasse che il flusso di due o più diagrammi di sequenza risultassero analoghi, non si riporta la descrizione passo per passo della successione dei fatti in quanto il Medico può gestire tutti i possibili percorsi alternativi nello svolgimento dei compiti. 125

152 Progettazione in ottica REST del sistema PHARMA Lettura dati della risorsa Terapia Giornaliera Il caso in esame (figura 5.25) prende in considerazione la lettura di dati da parte di un Medico all interno di una precisa Terapia Giornaliera. Il processo inizia con una richiesta da parte del Medico di un Fascicolo Ospedaliero rivolgendosi all entità Gestore Fascicoli; supponendo che il paziente sia già ricoverato, la risposta attesa dal Gestore Fascicolo è un documento XML che contiene al suo interno tutte le informazioni sui dati anagrafici del paziente nonché delle sue cartelle cliniche che fanno riferimento ai vari ricoveri avuti e registrati. L azione successiva è necessaria all ottenimento della Cartella Clinica del paziente che afferisce al ricovero attuale dello stesso, il Medico per questo formula una richiesta al Gestore Cartelle. Rimanendo al caso precedente in cui si suppone che il paziente sia già registrato come ricoverato, la risposta attesa è un documento XML che contiene al suo interno i dati relativi a tutti i documenti presenti nella Cartella Clinica. L ultima richiesta riguarda proprio l obiettivo primario del caso d uso qui descritto, ovvero ottenere le informazioni di una precisa Terapia Giornaliera: la richiesta che il Medico effettua al Gestore Cartelle mira ad ottenere un altro documento XML che ne contenga i dati. 1. Attori: Medico Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo della risorsa Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} 2. Attori: Gestore Fascicoli Medico Valore ritornato: documento XML che contiene tutte le informazioni sul Fascicolo Ospedaliero richiesto Percorso alternativo 1: il Gestore Fascicoli indica che il Fascicolo Ospedaliero richiesto non esiste, il Medico decide di crearne uno nuovo (a) Attori: Medico Gestore Fascicoli Richiesta: HTTP GET 126

153 Progettazione in ottica REST del sistema PHARMA Request-URI: indirizzo della risorsa Fascicolo ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} (b) Attori: Gestore Fascicoli Medico Valore ritornato: messaggio HTTP di risposta con codice 404 (c) Attori: Medico Gestore Fascicoli Richiesta: HTTP POST Request-URI: indirizzo della risorsa Gestore Fascicoli /gestorefascicoli body: documento XML che contiene le informazioni iniziali per generare un nuovo Fascicolo Ospedaliero (i.e. l identificativo di chi sta eseguendo l operazione) (d) Attori: Gestore Fascicoli Medico Valore ritornato: messaggio HTTP di risposta con codice 201, che indica che il Fascicolo Ospedaliero è stato creato body: documento XML che contiene le informazioni iniziali per generare un nuovo Fascicolo Ospedaliero (i.e. l identificativo di chi sta eseguendo l operazione); serve per ulteriore conferma che la richiesta è andata a buon fine Percorso alternativo 2: il Gestore Fascicoli indica che il Fascicolo Ospedaliero richiesto non esiste, il processo termina (a) Attori: Medico Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo della risorsa Fascicolo ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} (b) Attori: Gestore Fascicoli Medico Valore ritornato: messaggio HTTP di risposta con codice Attori: Medico Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo della risorsa Cartella Clinica che fa riferimento al ricovero attuale /gesorecartelle/cartella/{id cartella}/ 4. Attori: Gestore Cartelle Medico Valore ritornato: documento XML che contiene tutte le infor- 127

154 Progettazione in ottica REST del sistema PHARMA mazioni sulla Cartella Clinica richiesta Percorso alternativo 1: il Medico non trova la Cartella Clinica relativa al ricovero attuale del paziente perché inesistente, il Medico decide di crearne una nuova (a) Attori: Medico Gestore Fascicoli Richiesta: HTTP POST Request-URI: indirizzo della risorsa virtuale per la generazione di una Cartella Clinica /gestorefascicoli/fascicolo/{id fascicolo}/boxcartelle body: documento XML che contiene le informazioni iniziali per generare una nuova Cartella Clinica (i.e. l identificativo di chi sta eseguendo l operazione) (b) Attori: Gestore Fascicoli Gestore Cartelle Richiesta: HTTP POST Request-URI: indirizzo del Gestore Cartelle /gestorecartelle body: documento XML che contiene le informazioni iniziali per generare una nuova Cartella Clinica (i.e. l identificativo di chi sta eseguendo l operazione) (c) Attori: Gestore Cartelle Gestore Fascicoli Valore ritornato: documento XML che contiene tutte le informazioni iniziali sulla Cartella Clinica creata (d) Attori: Gestore Fascicoli Medico Valore ritornato: messaggio HTTP di risposta con codice 201, che indica che la Cartella Clinica è stata creata body: documento XML che contiene le informazioni iniziali per generare una nuova Cartella Clinica (i.e. l identificativo di chi sta eseguendo l operazione); serve per ulteriore conferma che la richiesta è andata a buon fine (e) Attori: Medico Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo del contenitore Cartelle delle cartelle 128

155 Progettazione in ottica REST del sistema PHARMA cliniche per il dato Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo}/cartelle (f) Attori: Gestore Fascicoli Medico Valore ritornato: documento XML che contiene tutti i riferimenti delle risorse Cartella Clinica del Fascicolo Ospedaliero (g) Attori: Medico Gestore Fascicoli Richiesta: HTTP PUT Request-URI: indirizzo del contenitore Cartelle delle cartelle cliniche per il dato Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo}/cartelle body: documento XML che contiene il documento Cartelle ottenuto con la GET precedente, con l aggiunta di un riferimento alla Cartella Clinica creata (h) Attori: Gestore Fascicoli Medico Valore ritornato: messaggio di conferma della corretta esecuzione dell operazione Percorso alternativo 2: il Gestore Fascicoli indica che la Cartella Clinica richiesta non esiste, il processo termina 5. Attori: Medico Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo della risorsa Terapia Giornaliera che fa riferimento all obiettivo principale /gesorecartelle/terapia/{id terapia}/ 6. Attori: Gestore Cartelle Medico Valore ritornato: documento XML che contiene tutte le informazioni sulla Terapia Giornaliera richiesta Percorso alternativo 1: il Medico non trova la Terapia Giornaliera per il paziente perché inesistente, il processo termina 129

156 Progettazione in ottica REST del sistema PHARMA Creazione del documento Interventi / Trattamenti per un documento Terapia Giornaliera di una data Cartella Clinica La seguente descrizione (figura 5.26) contempla la creazione di un nuovo documento Intervento / Trattamento all interno di una precisa Terapia Giornaliera. Il flusso ha inizio con una richiesta, da parte di un Medico per ottenere un Fascicolo Ospedaliero rivolgendosi all entità Gestore Fascicoli; supponendo che il paziente sia già ricoverato, la risposta attesa dal Gestore Fascicolo è un documento XML che contiene al suo interno tutte le informazioni sui dati anagrafici del paziente nonché delle sue cartelle cliniche che fanno riferimento ai vari ricoveri avuti e registrati. Il passo successivo serve all ottenimento della Cartella Clinica del paziente che afferisce al ricovero attuale dello stesso, il Medico per questo formula una richiesta al Gestore Cartelle. Rimanendo al caso precedente in cui si suppone che il paziente sia già registrato come ricoverato, la risposta attesa è un documento XML che contiene al suo interno i dati relativi a tutti i documenti presenti nella Cartella Clinica. La fase di reale creazione del nuovo documento per l Intervento / Trattamento è preceduta da un ultima ricerca che serve alla selezione della Terapia Giornaliera oggetto della modifica. 1. Attori: Medico Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo della risorsa Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} 2. Attori: Gestore Fascicoli Medico Valore ritornato: documento XML che contiene tutte le informazioni sul Fascicolo Ospedaliero richiesto Percorso alternativo 1: il Gestore Fascicoli indica che il Fascicolo Ospedaliero richiesto non esiste, il Medico decide di crearne uno nuovo 130

157 Progettazione in ottica REST del sistema PHARMA (a) Attori: Medico Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo della risorsa Fascicolo ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} (b) Attori: Gestore Fascicoli Medico Valore ritornato: messaggio HTTP di risposta con codice 404 (c) Attori: Medico Gestore Fascicoli Richiesta: HTTP POST Request-URI: indirizzo della risorsa Gestore Fascicoli /gestorefascicoli body: documento XML che contiene le informazioni iniziali per generare un nuovo Fascicolo Ospedaliero (i.e. l identificativo di chi sta eseguendo l operazione) (d) Attori: Gestore Fascicoli Medico Valore ritornato: messaggio HTTP di risposta con codice 201, che indica che il Fascicolo Ospedaliero è stato creato body: documento XML che contiene le informazioni iniziali per generare un nuovo Fascicolo Ospedaliero (i.e. l identificativo di chi sta eseguendo l operazione); serve per ulteriore conferma che la richiesta è andata a buon fine Percorso alternativo 2: il Gestore Fascicoli indica che il Fascicolo Ospedaliero richiesto non esiste, il processo termina (a) Attori: Medico Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo della risorsa Fascicolo ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} (b) Attori: Gestore Fascicoli Medico Valore ritornato: messaggio HTTP di risposta con codice Attori: Medico Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo della risorsa Cartella Clinica che fa riferi- 131

158 Progettazione in ottica REST del sistema PHARMA mento al ricovero attuale /gesorecartelle/cartella/{id cartella}/ 4. Attori: Gestore Cartelle Medico Valore ritornato: documento XML che contiene tutte le informazioni sulla Cartella Clinica richiesta Percorso alternativo 1: il Medico non trova la Cartella Clinica relativa al ricovero attuale del paziente perché inesistente, il Medico decide di crearne una nuova (a) Attori: Medico Gestore Fascicoli Richiesta: HTTP POST Request-URI: indirizzo della risorsa virtuale per la generazione di una Cartella Clinica /gestorefascicoli/fascicolo/{id fascicolo}/boxcartelle body: documento XML che contiene le informazioni iniziali per generare una nuova Cartella Clinica (i.e. l identificativo di chi sta eseguendo l operazione) (b) Attori: Gestore Fascicoli Gestore Cartelle Richiesta: HTTP POST Request-URI: indirizzo del Gestore Cartelle /gestorecartelle body: documento XML che contiene le informazioni iniziali per generare una nuova Cartella Clinica (i.e. l identificativo di chi sta eseguendo l operazione) (c) Attori: Gestore Cartelle Gestore Fascicoli Valore ritornato: documento XML che contiene tutte le informazioni iniziali sulla Cartella Clinica creata (d) Attori: Gestore Fascicoli Medico Valore ritornato: messaggio HTTP di risposta con codice 201, che indica che la Cartella Clinica è stata creata body: documento XML che contiene le informazioni iniziali per generare una nuova Cartella Clinica (i.e. l identificativo di chi sta eseguendo l operazione); serve per ulteriore conferma 132

159 Progettazione in ottica REST del sistema PHARMA che la richiesta è andata a buon fine (e) Attori: Medico Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo del contenitore Cartelle delle cartelle cliniche per il dato Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo}/cartelle (f) Attori: Gestore Fascicoli Medico Valore ritornato: documento XML che contiene tutti i riferimenti delle risorse Cartella Clinica del Fascicolo Ospedaliero (g) Attori: Medico Gestore Fascicoli Richiesta: HTTP PUT Request-URI: indirizzo del contenitore Cartelle delle cartelle cliniche per il dato Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo}/cartelle body: documento XML che contiene il documento Cartelle ottenuto con la GET precedente, con l aggiunta di un riferimento alla Cartella Clinica creata (h) Attori: Gestore Fascicoli Medico Valore ritornato: messaggio di conferma della corretta esecuzione dell operazione Percorso alternativo 2: il Gestore Fascicoli indica che la Cartella Clinica richiesta non esiste, il processo termina 5. Attori: Medico Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo della risorsa Terapia Giornaliera che fa riferimento all obiettivo principale /gesorecartelle/terapia/{id terapia}/ 6. Attori: Gestore Cartelle Medico Valore ritornato: documento XML che contiene tutte le informazioni sulla Terapia Giornaliera richiesta Percorso alternativo 1: il Medico non trova la Terapia Giornaliera 133

160 Progettazione in ottica REST del sistema PHARMA per il paziente perché inesistente, si procede a creare un documento nuovo (a) Attori: Medico Gestore Cartelle Richiesta: HTTP POST Request-URI: indirizzo della risorsa virtuale per la generazione di una Terapia Giornaliera /gestorecartelle/cartelle/{id cartella}/boxterapie body: documento XML che contiene le informazioni iniziali per generare una nuova Terapia Giornaliera (i.e. l identificativo di chi sta eseguendo l operazione e la data di validità della Terapia Giornaliera) (b) Attori: Gestore Cartelle Gestore Cartelle Richiesta: HTTP POST Request-URI: indirizzo del Gestore Cartelle /gestorecartelle body: documento XML che contiene le informazioni iniziali per generare i nodi di una nuova Terapia Giornaliera (i.e. l identificativo di chi sta eseguendo l operazione) Commento: non è una vera e propria chiamata HTTP perché può essere vista come una elaborazione interna all entità Gestore Cartelle, ma qualora essa sia una chiamata destinata ad un altra entità Gestore Cartelle deve prevedere un messaggio di risposta HTTP (c) Attori: Gestore Cartelle Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo del contenitore Terapie delle terapie giornaliere afferente proprio alla Cartella Clinica in esame /gestorecartelle/cartella/{id cartella}/terapie Commento: non è una vera e propria chiamata HTTP perché può essere vista come una elaborazione interna all entità Gestore Cartelle, ma qualora essa sia una chiamata destinata ad un altra entità Gestore Cartelle deve prevedere un messaggio di risposta HTTP 134

161 Progettazione in ottica REST del sistema PHARMA (d) Attori: Gestore Cartelle Gestore Cartelle Richiesta: HTTP PUT Request-URI: indirizzo del contenitore Terapie delle terapie giornaliere afferente proprio alla Cartella Clinica in esame /gestorecartelle/cartella/{id cartella}/terapie body: documento XML che contiene i dati ricevuti con la GET precedente (che rappresentano l elenco delle terapie giornaliere contenute all interno della Cartella Clinica) con l aggiunta del riferimento all ultima Terapia Giornaliera creata Commento: non è una vera e propria chiamata HTTP perché può essere vista come una elaborazione interna all entità Gestore Cartelle, ma qualora essa sia una chiamata destinata ad un altra entità Gestore Cartelle deve prevedere un messaggio di risposta HTTP (e) Attori: Gestore Cartelle Medico Valore ritornato: documento XML che contiene tutte le informazioni sulla Terapia Giornaliera creata Percorso alternativo 2: il Medico non trova la Terapia Giornaliera per il paziente perché inesistente, il processo termina 7. Attori: Medico Gestore Cartelle Richiesta: HTTP PUT Request-URI: indirizzo della risorsa Terapia Giornaliera che fa riferimento all obiettivo principale /gesorecartelle/terapia/{id terapia}/ body: documento XML che contiene i dati della Terapia Giornaliera, comprensivi del nuovo documento relativo all Intervento / Trattamento Commento: il significato di tale operazione corrisponde al salvataggio della Terapia Giornaliera, qualora non siano presenti dei documenti questo passaggio permette di indicare che debbano essere allocate nuove risorse col metodo PUT 8. Attori: Gestore Cartelle Gestore Cartelle 135

162 Progettazione in ottica REST del sistema PHARMA Richiesta: HTTP POST Request-URI: indirizzo della risorsa virtuale Box Referti per la creazione di un documento Referto da collegare all Intervento / Trattamento /gesorecartelle/terapia/{id terapia}/int tratt/{id int tratt}/boxreferti body: documento XML che contiene i dati del Referto Commento: non è una vera e propria chiamata HTTP perché può essere vista come una elaborazione interna all entità Gestore Cartelle, ma qualora essa sia una chiamata destinata ad un altra entità Gestore Cartelle deve prevedere un messaggio di risposta HTTP 9. Attori: Gestore Cartelle Gestore Referti Richiesta: HTTP POST Request-URI: indirizzo dell entità Gestore Referti /gesorereferti body: documento XML che contiene i dati del Referto 10. Attori: Gestore Referti Gestore Cartelle Valore ritornato: documento XML che contiene la rappresentazione del documento Referto 11. Attori: Gestore Cartelle Gestore Cartelle Richiesta: HTTP PUT Request-URI: indirizzo dell Intervento / Trattamento a cui riferire il Referto /gesorecartelle/terapia/{id terapia}/int tratt/{id int tratt} body: documento XML che contiene i dati del nuovo Intervento / Trattamento Commento: non è una vera e propria chiamata HTTP perché può essere vista come una elaborazione interna all entità Gestore Cartelle, ma qualora essa sia una chiamata destinata ad un altra entità Gestore Cartelle deve prevedere un messaggio di risposta HTTP 12. Attori: Gestore Cartelle Medico Valore ritornato: documento XML che contiene tutte le infor- 136

163 Progettazione in ottica REST del sistema PHARMA mazioni sulla Terapia Giornaliera su cui era stata fatta la richiesta col metodo PUT Registrazione di avvenuta esecuzione di un Intervento / Trattamento per un documento Terapia Giornaliera di una data Cartella Clinica Il terzo diagramma di sequenza (figura 5.27) riguarda la registrazione che un Intervento / Trattamento è stato eseguito. Il processo comincia con una richiesta, da parte di un Medico per ottenere un Fascicolo Ospedaliero rivolgendosi all entità Gestore Fascicoli; supponendo che il paziente sia già ricoverato, la risposta attesa dal Gestore Fascicolo è un documento XML che contiene al suo interno tutte le informazioni sui dati anagrafici del paziente nonché delle sue cartelle cliniche che fanno riferimento ai vari ricoveri avuti e registrati. Il passo successivo serve all ottenimento della Cartella Clinica del paziente che afferisce al ricovero attuale dello stesso, il Medico per questo formula una richiesta al Gestore Cartelle. Rimanendo al caso precedente in cui si suppone che il paziente sia già registrato come ricoverato, la risposta attesa è un documento XML che contiene al suo interno i dati relativi a tutti i documenti presenti nella Cartella Clinica. Una volta ottenuta la Terapia Giornaliera ed apportate le modifiche del caso, si procede alla registrazione della Terapia Giornaliera stessa. Il flusso, in questo caso, risulta analogo a quello descritto al punto precedente; per questo non viene riportato. Modifica del Referto nel documento Intervento / Trattamento per un documento Terapia Giornaliera di una data Cartella Clinica Il diagramma di sequenza di figura 5.28 tratta la modifica di un Referto una volta che un Intervento / Trattamento è stato eseguito. Il processo comincia con una richiesta, da parte di un Medico per ottenere un Fascicolo Ospedaliero rivolgendosi all entità Gestore Fascicoli; supponendo che il paziente sia già ricoverato, la risposta attesa dal Gestore 137

164 Progettazione in ottica REST del sistema PHARMA Fascicolo è un documento XML che contiene al suo interno tutte le informazioni sui dati anagrafici del paziente nonché delle sue cartelle cliniche che fanno riferimento ai vari ricoveri avuti e registrati. Il passo successivo serve all ottenimento della Cartella Clinica del paziente che afferisce al ricovero attuale dello stesso, il Medico per questo formula una richiesta al Gestore Cartelle. Rimanendo al caso precedente in cui si suppone che il paziente sia già registrato come ricoverato, la risposta attesa è un documento XML che contiene al suo interno i dati relativi a tutti i documenti presenti nella Cartella Clinica. Per ottenere il Referto si deve necessariamente passare dal documento Terapia Giornaliera (vi sarà prorpio per questo una richiesta specifica atta ad ottenerla) per individuare l Intervento / Trattamento cui lo stesso Referto è legato. Il flusso, in questo caso, risulta analogo a quello descritto al punto che tratta la creazione di un nuovo Intervento / Trattamento; per questo non viene riportato. Ancora per sottolineare che il Medico ha dei poteri di muoversi tra i documenti, oltre che crearli, che gli consente di seguire i percorsi alternativi più disparati. Creazione di un documento Cartella Clinica (si considera qui anche la creazione, eventuale, della risorsa Fascicolo Ospedaliero) L ultimo caso (figura 5.29) espone i passi per la creazione di una nuova Cartella Clinica oltre che al Fascicolo Ospedaliero. Il processo descritto in tutti i casi riportati, non viene qui trattato per esteso: si rimanda perciò ai casi precedentemente illustrati. Operazioni relative all attore CAPOSALA La classe di operatori CAPOSALA prevede alcuni casi simili a quelli per il caso Medico. I possibili flussi individuabili, limitatamente ai documenti sotto analisi, sono identificabili coi seguenti: Lettura dati della risorsa Terapia Giornaliera 138

165 Progettazione in ottica REST del sistema PHARMA Registrazione di avvenuta esecuzione di un Intervento / Trattamento per un documento Terapia Giornaliera di una data Cartella Clinica Creazione di un documento Cartella Clinica (si considera qui anche la creazione, eventuale, della risorsa Fascicolo Ospedaliero) Per ciascuno di essi verranno descritte qui di seguito le operazioni (chiamate HTTP) tra le entità coinvolte nei vari flussi. Qualora risultasse che il flusso di due o più diagrammi di sequenza risultassero analoghi, non si riporta la descrizione passo per passo della successione dei fatti. Lettura dati della risorsa Terapia Giornaliera Prendendo a riferimento la figura 5.25 si illustra il caso in cui il Caposala proceda alla lettura di una certa Terapia Giornaliera. Il processo inizia con una richiesta da parte del Caposala di un Fascicolo Ospedaliero rivolgendosi all entità Gestore Fascicoli; supponendo che il paziente sia già ricoverato, la risposta attesa dal Gestore Fascicolo è un documento XML che contiene al suo interno tutte le informazioni sui dati anagrafici del paziente nonché delle sue cartelle cliniche che fanno riferimento ai vari ricoveri avuti e registrati. L azione successiva è necessaria all ottenimento della Cartella Clinica del paziente che afferisce al ricovero attuale dello stesso, il Caposala per questo formula una richiesta al Gestore Cartelle. Rimanendo al caso precedente in cui si suppone che il paziente sia già registrato come ricoverato, la risposta attesa è un documento XML che contiene al suo interno i dati relativi a tutti i documenti presenti nella Cartella Clinica. L ultima richiesta riguarda proprio l obiettivo primario del caso d uso qui descritto, ovvero ottenere le informazioni di una precisa Terapia Giornaliera: la richiesta che il Caposala effettua al Gestore Cartelle mira ad ottenere un altro documento XML che ne contenga i dati. 1. Attori: Caposala Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo della risorsa Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} 139

166 Progettazione in ottica REST del sistema PHARMA 2. Attori: Gestore Fascicoli Caposala Valore ritornato: documento XML che contiene tutte le informazioni sul Fascicolo Ospedaliero richiesto Percorso alternativo 1: il Gestore Fascicoli indica che il Fascicolo Ospedaliero richiesto non esiste, il Caposala decide di crearne uno nuovo (a) Attori: Caposala Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo della risorsa Fascicolo ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} (b) Attori: Gestore Fascicoli Caposala Valore ritornato: messaggio HTTP di risposta con codice 404 (c) Attori: Medico Gestore Fascicoli Richiesta: HTTP POST Request-URI: indirizzo della risorsa Gestore Fascicoli /gestorefascicoli body: documento XML che contiene le informazioni iniziali per generare un nuovo Fascicolo Ospedaliero (i.e. l identificativo di chi sta eseguendo l operazione) (d) Attori: Gestore Fascicoli Caposala Valore ritornato: messaggio HTTP di risposta con codice 201, che indica che il Fascicolo Ospedaliero è stato creato body: documento XML che contiene le informazioni iniziali per generare un nuovo Fascicolo Ospedaliero (i.e. l identificativo di chi sta eseguendo l operazione); serve per ulteriore conferma che la richiesta è andata a buon fine Percorso alternativo 2: il Gestore Fascicoli indica che il Fascicolo Ospedaliero richiesto non esiste, il processo termina (a) Attori: Caposala Gestore Fascicoli Richiesta: HTTP GET 140

167 Progettazione in ottica REST del sistema PHARMA Request-URI: indirizzo della risorsa Fascicolo ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} (b) Attori: Gestore Fascicoli Caposala Valore ritornato: messaggio HTTP di risposta con codice Attori: Caposala Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo della risorsa Cartella Clinica che fa riferimento al ricovero attuale /gesorecartelle/cartella/{id cartella}/ 4. Attori: Gestore Cartelle Caposala Valore ritornato: documento XML che contiene tutte le informazioni sulla Cartella Clinica richiesta Percorso alternativo 1: il Medico non trova la Cartella Clinica relativa al ricovero attuale del paziente perché inesistente, il Caposala decide di crearne una nuova (a) Attori: Caposala Gestore Fascicoli Richiesta: HTTP POST Request-URI: indirizzo della risorsa virtuale per la generazione di una Cartella Clinica /gestorefascicoli/fascicolo/{id fascicolo}/boxcartelle body: documento XML che contiene le informazioni iniziali per generare una nuova Cartella Clinica (i.e. l identificativo di chi sta eseguendo l operazione) (b) Attori: Gestore Fascicoli Gestore Cartelle Richiesta: HTTP POST Request-URI: indirizzo del Gestore Cartelle /gestorecartelle body: documento XML che contiene le informazioni iniziali per generare una nuova Cartella Clinica (i.e. l identificativo di chi sta eseguendo l operazione) 141

168 Progettazione in ottica REST del sistema PHARMA (c) Attori: Gestore Cartelle Gestore Fascicoli Valore ritornato: documento XML che contiene tutte le informazioni iniziali sulla Cartella Clinica creata (d) Attori: Gestore Fascicoli Caposala Valore ritornato: messaggio HTTP di risposta con codice 201, che indica che la Cartella Clinica è stata creata body: documento XML che contiene le informazioni iniziali per generare una nuova Cartella Clinica (i.e. l identificativo di chi sta eseguendo l operazione); serve per ulteriore conferma che la richiesta è andata a buon fine (e) Attori: Caposala Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo del contenitore Cartelle delle cartelle cliniche per il dato Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo}/cartelle (f) Attori: Gestore Fascicoli Caposala Valore ritornato: documento XML che contiene tutti i riferimenti delle risorse Cartella Clinica del Fascicolo Ospedaliero (g) Attori: Caposala Gestore Fascicoli Richiesta: HTTP PUT Request-URI: indirizzo del contenitore Cartelle delle cartelle cliniche per il dato Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo}/cartelle body: documento XML che contiene il documento Cartelle ottenuto con la GET precedente, con l aggiunta di un riferimento alla Cartella Clinica creata (h) Attori: Gestore Fascicoli Caposala Valore ritornato: messaggio di conferma della corretta esecuzione dell operazione Percorso alternativo 2: il Gestore Fascicoli indica che la Cartella Clinica richiesta non esiste, il processo termina 142

169 Progettazione in ottica REST del sistema PHARMA 5. Attori: Caposala Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo della risorsa Terapia Giornaliera che fa riferimento all obiettivo principale /gesorecartelle/terapia/{id terapia}/ 6. Attori: Gestore Cartelle Caposala Valore ritornato: documento XML che contiene tutte le informazioni sulla Terapia Giornaliera richiesta Percorso alternativo 1: il Caposala non trova la Terapia Giornaliera per il paziente perché inesistente, il processo termina Registrazione di avvenuta esecuzione di un Intervento / Trattamento per un documento Terapia Giornaliera di una data Cartella Clinica Il secondo diagramma di sequenza per questa tipologia di attori (per riferimento si consideri la figura 5.27) riguarda la registrazione che un Intervento / Trattamento è stato eseguito. Il processo comincia con una richiesta, da parte di un Caposala per ottenere un Fascicolo Ospedaliero rivolgendosi all entità Gestore Fascicoli; supponendo che il paziente sia già ricoverato, la risposta attesa dal Gestore Fascicolo è un documento XML che contiene al suo interno tutte le informazioni sui dati anagrafici del paziente nonché delle sue cartelle cliniche che fanno riferimento ai vari ricoveri avuti e registrati. Il passo successivo serve all ottenimento della Cartella Clinica del paziente che afferisce al ricovero attuale dello stesso, il Caposala per questo formula una richiesta al Gestore Cartelle. Rimanendo al caso precedente in cui si suppone che il paziente sia già registrato come ricoverato, la risposta attesa è un documento XML che contiene al suo interno i dati relativi a tutti i documenti presenti nella Cartella Clinica. Una volta ottenuta la Terapia Giornaliera ed apportate le modifiche del caso, si procede alla registrazione della Terapia Giornaliera stessa. 1. Attori: Caposala Gestore Fascicoli Richiesta: HTTP GET 143

170 Progettazione in ottica REST del sistema PHARMA Request-URI: indirizzo della risorsa Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} 2. Attori: Gestore Fascicoli Caposala Valore ritornato: documento XML che contiene tutte le informazioni sul Fascicolo Ospedaliero richiesto Percorso alternativo 1: il Gestore Fascicoli indica che il Fascicolo Ospedaliero richiesto non esiste, il Caposala decide di crearne uno nuovo (a) Attori: Caposala Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo della risorsa Fascicolo ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} (b) Attori: Gestore Fascicoli Caposala Valore ritornato: messaggio HTTP di risposta con codice 404 (c) Attori: Caposala Gestore Fascicoli Richiesta: HTTP POST Request-URI: indirizzo della risorsa Gestore Fascicoli /gestorefascicoli body: documento XML che contiene le informazioni iniziali per generare un nuovo Fascicolo Ospedaliero (i.e. l identificativo di chi sta eseguendo l operazione) (d) Attori: Gestore Fascicoli Caposala Valore ritornato: messaggio HTTP di risposta con codice 201, che indica che il Fascicolo Ospedaliero è stato creato body: documento XML che contiene le informazioni iniziali per generare un nuovo Fascicolo Ospedaliero (i.e. l identificativo di chi sta eseguendo l operazione); serve per ulteriore conferma che la richiesta è andata a buon fine Percorso alternativo 2: il Gestore Fascicoli indica che il Fascicolo Ospedaliero richiesto non esiste, il processo termina 144

171 Progettazione in ottica REST del sistema PHARMA (a) Attori: Caposala Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo della risorsa Fascicolo ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} (b) Attori: Gestore Fascicoli Caposala Valore ritornato: messaggio HTTP di risposta con codice Attori: Caposala Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo della risorsa Cartella Clinica che fa riferimento al ricovero attuale /gesorecartelle/cartella/{id cartella}/ 4. Attori: Gestore Cartelle Caposala Valore ritornato: documento XML che contiene tutte le informazioni sulla Cartella Clinica richiesta Percorso alternativo 1: il Caposala non trova la Cartella Clinica relativa al ricovero attuale del paziente perché inesistente, il Medico decide di crearne una nuova (a) Attori: Caposala Gestore Fascicoli Richiesta: HTTP POST Request-URI: indirizzo della risorsa virtuale per la generazione di una Cartella Clinica /gestorefascicoli/fascicolo/{id fascicolo}/boxcartelle body: documento XML che contiene le informazioni iniziali per generare una nuova Cartella Clinica (i.e. l identificativo di chi sta eseguendo l operazione) (b) Attori: Gestore Fascicoli Gestore Cartelle Richiesta: HTTP POST Request-URI: indirizzo del Gestore Cartelle /gestorecartelle body: documento XML che contiene le informazioni iniziali 145

172 Progettazione in ottica REST del sistema PHARMA per generare una nuova Cartella Clinica (i.e. l identificativo di chi sta eseguendo l operazione) (c) Attori: Gestore Cartelle Gestore Fascicoli Valore ritornato: documento XML che contiene tutte le informazioni iniziali sulla Cartella Clinica creata (d) Attori: Gestore Fascicoli Caposala Valore ritornato: messaggio HTTP di risposta con codice 201, che indica che la Cartella Clinica è stata creata body: documento XML che contiene le informazioni iniziali per generare una nuova Cartella Clinica (i.e. l identificativo di chi sta eseguendo l operazione); serve per ulteriore conferma che la richiesta è andata a buon fine (e) Attori: Caposala Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo del contenitore Cartelle delle cartelle cliniche per il dato Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo}/cartelle (f) Attori: Gestore Fascicoli Caposala Valore ritornato: documento XML che contiene tutti i riferimenti delle risorse Cartella Clinica del Fascicolo Ospedaliero (g) Attori: Caposala Gestore Fascicoli Richiesta: HTTP PUT Request-URI: indirizzo del contenitore Cartelle delle cartelle cliniche per il dato Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo}/cartelle body: documento XML che contiene il documento Cartelle ottenuto con la GET precedente, con l aggiunta di un riferimento alla Cartella Clinica creata (h) Attori: Gestore Fascicoli Caposala Valore ritornato: messaggio di conferma della corretta esecuzione dell operazione Percorso alternativo 2: il Gestore Fascicoli indica che la Cartella 146

173 Progettazione in ottica REST del sistema PHARMA Clinica richiesta non esiste, il processo termina 5. Attori: Caposala Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo della risorsa Terapia Giornaliera che fa riferimento all obiettivo principale /gesorecartelle/terapia/{id terapia}/ 6. Attori: Gestore Cartelle Caposala Valore ritornato: documento XML che contiene tutte le informazioni sulla Terapia Giornaliera richiesta Percorso alternativo 1: il Caposala non trova la Terapia Giornaliera per il paziente perché inesistente, il processo termina 7. Attori: Caposala Gestore Cartelle Richiesta: HTTP PUT Request-URI: indirizzo della risorsa Terapia Giornaliera che fa riferimento all obiettivo principale /gesorecartelle/terapia/{id terapia}/ body: documento XML che contiene i dati della Terapia Giornaliera, comprensivi del nuovo documento relativo all Intervento / Trattamento Commento: il significato di tale operazione corrisponde al salvataggio della Terapia Giornaliera 8. Attori: Gestore Cartelle Caposala Valore ritornato: documento XML che contiene tutte le informazioni sulla Terapia Giornaliera su cui era stata fatta la richiesta col metodo PUT Creazione di un documento Cartella Clinica (si considera qui anche la creazione, eventuale, della risorsa Fascicolo Ospedaliero) L ultimo caso per il Caposala (cfr. figura 5.29) tratta i passi per la creazione di una nuova Cartella Clinica oltre che al Fascicolo Ospeda- 147

174 Progettazione in ottica REST del sistema PHARMA liero. Il processo descritto in tutti i casi riportati, non viene qui trattato per esteso: si rimanda perciò ai casi precedentemente trattati. Operazioni relative all attore INFERMIERE / ALTRO La classe di operatori INFERMIERE / ALTRO (nel seguito della sezione solo Infermiere) prevede alcuni casi simili a quelli per il caso Caposala. I possibili flussi individuabili, limitatamente ai documenti sotto analisi, sono identificabili coi seguenti: Lettura dati della risorsa Terapia Giornaliera Registrazione di avvenuta esecuzione di un Intervento / Trattamento per un documento Terapia Giornaliera di una data Cartella Clinica Per entrambi verranno descritte qui di seguito le operazioni in termini di chiamate HTTP tra le entità coinvolte nei vari flussi. Lettura dati della risorsa Terapia Giornaliera Prendendo come riferimento la figura 5.25 si illustra il caso in cui l Infermiere proceda alla lettura di una certa Terapia Giornaliera. Il processo inizia con una richiesta, da parte dell Infermiere, di un Fascicolo Ospedaliero rivolgendosi all entità Gestore Fascicoli; supponendo che il paziente sia già ricoverato, quello che ci si attende dal Gestore Fascicolo è un documento XML che contiene al suo interno tutte le informazioni sui dati anagrafici del paziente nonché delle sue cartelle cliniche che fanno riferimento ai vari ricoveri avuti e registrati. L azione successiva consiste nell ottenimento della Cartella Clinica del paziente che afferisce al ricovero attuale dello stesso, l Infermiere per questo formula una richiesta al Gestore Cartelle. Rimanendo al caso precedente in cui si suppone che il paziente sia già registrato come ricoverato, la risposta attesa è un documento XML che contiene al suo interno i dati relativi a tutti i documenti presenti nella Cartella Clinica. Per ultimo è necessario ottenere, da parte dell Infermiere con apposita richiesta, un documento XML riguardante la Terapia Giornaliera. 148

175 Progettazione in ottica REST del sistema PHARMA 1. Attori: Infermiere Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo della risorsa Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} 2. Attori: Gestore Fascicoli Infermiere Valore ritornato: documento XML che contiene tutte le informazioni sul Fascicolo Ospedaliero richiesto Percorso alternativo 1: il Gestore Fascicoli indica che il Fascicolo Ospedaliero richiesto non esiste, il processo termina (a) Attori: Infermiere Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo della risorsa Fascicolo ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} (b) Attori: Gestore Fascicoli Infermiere Valore ritornato: messaggio HTTP di risposta con codice Attori: Infermiere Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo della risorsa Cartella Clinica che fa riferimento al ricovero attuale /gesorecartelle/cartella/{id cartella}/ 4. Attori: Gestore Cartelle Infermiere Valore ritornato: documento XML che contiene tutte le informazioni sulla Cartella Clinica richiesta Percorso alternativo 1: il Gestore Fascicoli indica che la Cartella Clinica richiesta non esiste, il processo termina 5. Attori: Infermiere Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo della risorsa Terapia Giornaliera che fa ri- 149

176 Progettazione in ottica REST del sistema PHARMA ferimento all obiettivo principale /gesorecartelle/terapia/{id terapia}/ 6. Attori: Gestore Cartelle Infermiere Valore ritornato: documento XML che contiene tutte le informazioni sulla Terapia Giornaliera richiesta Percorso alternativo 1: l Infermiere non trova la Terapia Giornaliera per il paziente perché inesistente, il processo termina Registrazione di avvenuta esecuzione di un Intervento / Trattamento per un documento Terapia Giornaliera di una data Cartella Clinica Il secondo e ultimo diagramma di sequenza per gli attori Infermiere (per riferimento si consideri la figura 5.27) riguarda la memorizzazione che un Intervento / Trattamento è stato effettuato. Il processo comincia come nel caso precedente con una richiesta, da parte di un Infermiere per ottenere un Fascicolo Ospedaliero rivolgendosi all entità Gestore Fascicoli; supponendo che il paziente sia già ricoverato, la risposta attesa dal Gestore Fascicolo è un documento XML che contiene al suo interno tutte le informazioni sui dati anagrafici del paziente nonché delle sue cartelle cliniche che fanno riferimento ai vari ricoveri avuti e registrati. Il passo seguente serve all ottenimento della Cartella Clinica del paziente che fa riferimento al ricovero corrente del paziente stesso, l Infermiere per questo formula una richiesta al Gestore Cartelle. Rimanendo al caso precedente in cui si suppone che il paziente sia già registrato come ricoverato, la risposta attesa è un documento XML che contiene al suo interno i dati relativi a tutti i documenti presenti nella Cartella Clinica. Per ultimo, una volta ottenuta la Terapia Giornaliera ed apportate le modifiche del caso, si procede alla registrazione della Terapia Giornaliera stessa. 1. Attori: Infermiere Gestore Fascicoli Richiesta: HTTP GET 150

177 Progettazione in ottica REST del sistema PHARMA Request-URI: indirizzo della risorsa Fascicolo Ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} 2. Attori: Gestore Fascicoli Infermiere Valore ritornato: documento XML che contiene tutte le informazioni sul Fascicolo Ospedaliero richiesto Percorso alternativo 1: il Gestore Fascicoli indica che il Fascicolo Ospedaliero richiesto non esiste, il processo termina (a) Attori: Infermiere Gestore Fascicoli Richiesta: HTTP GET Request-URI: indirizzo della risorsa Fascicolo ospedaliero /gestorefascicoli/fascicolo/{id fascicolo} (b) Attori: Gestore Fascicoli Infermiere Valore ritornato: messaggio HTTP di risposta con codice Attori: Infermiere Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo della risorsa Cartella Clinica che fa riferimento al ricovero attuale /gesorecartelle/cartella/{id cartella}/ 4. Attori: Gestore Cartelle Infermiere Valore ritornato: documento XML che contiene tutte le informazioni sulla Cartella Clinica richiesta Percorso alternativo 1: il Gestore Fascicoli indica che la Cartella Clinica richiesta non esiste, il processo termina 5. Attori: Infermiere Gestore Cartelle Richiesta: HTTP GET Request-URI: indirizzo della risorsa Terapia Giornaliera che fa riferimento all obiettivo principale /gesorecartelle/terapia/{id terapia}/ 151

178 Progettazione in ottica REST del sistema PHARMA 6. Attori: Gestore Cartelle Infermiere Valore ritornato: documento XML che contiene tutte le informazioni sulla Terapia Giornaliera richiesta Percorso alternativo 1: l Infermiere non trova la Terapia Giornaliera per il paziente perché inesistente, il processo termina 7. Attori: Infermiere Gestore Cartelle Richiesta: HTTP PUT Request-URI: indirizzo della risorsa Terapia Giornaliera che fa riferimento all obiettivo principale /gesorecartelle/terapia/{id terapia}/ body: documento XML che contiene i dati della Terapia Giornaliera, comprensivi del nuovo documento relativo all Intervento / Trattamento Commento: il significato di tale operazione corrisponde al salvataggio della Terapia Giornaliera 8. Attori: Gestore Cartelle Infermiere Valore ritornato: documento XML che contiene tutte le informazioni sulla Terapia Giornaliera su cui era stata fatta la richiesta col metodo PUT Operazioni delegate alla parte server Ogni richiesta formulata dagli attori presi in esame (in questo paragrafo denominati Client) è tradotta dalle entità coinvolte nei flussi riceventi i messaggi (qui denominate tutte Server) in una serie di azioni/compiti con l obiet-tivo di gestire il lavoro cooperativo 3. Per un apprendimento più profondo della sequenza degli eventi descritti, si reputa necessaria una lettura dei capitoli 6 e 8 che descrivono nel dettaglio l applicazione PHARMA. 3 Altri dettagli più specifici sono discussi in Appendice A. 152

179 Progettazione in ottica REST del sistema PHARMA Le azioni che un Client può demandare ad un Server, sulla base dei flussi di collaborazione tra gli attori e sulle basi delle necessità di gestione dei dati sotto forma di documenti, sono le seguenti: 1. Creazione di un Fascicolo Ospedaliero. 2. Modifica di un Fascicolo Ospedaliero (operazione di salvataggio). 3. Creazione di una Cartella Clinica dato un Fascicolo Ospedaliero. 4. Annullamento di una Cartella Clinica dato un Fascicolo Ospedaliero. 5. Ripristino di una Cartella Clinica dato un Fascicolo Ospedaliero. 6. Modifica di una Cartella Clinica (operazione di salvataggio del documento). 7. Creazione di una nuova Terapia Giornaliera data una Cartella Clinica. 8. Operazione di ripristino di una Terapia Giornaliera annullata data una Cartella Clinica. 9. Operazione di annullamento di una Terapia Giornaliera data una Cartella Clinica. 10. Modifica di una Terapia Giornaliera (operazione di salvataggio del documento). 11. Modifica di un Consenso (operazione di salvataggio del documento). 12. Modifica di un Referto (operazione di salvataggio del documento). In ciascuna descrizione fornita nel seguito, sono indicate le richieste che il Client effettua sul Server e il loro contenuto (il body della richiesta HTTP) dove sono citati i documenti che sono inviati. Infine si elencano le operazioni che il Server deve assolvere. 153

180 Progettazione in ottica REST del sistema PHARMA 1. Creazione di un Fascicolo Ospedaliero POST /gestorefascicoli body: documenti afferenti al Fascicolo Ospedaliero da creare. [Fascicolo Ospedaliero] [Anagrafica] [Dati Primari] [Generalità] [Tessera Sanitaria] [Dati Secondari] [Luogo Nascita] [Recapiti] [Indirizzo] [Cartelle] Operazioni del Server: (a) Scompatta il body in arrivo dal Client. (b) POST su tutti dei singoli documenti ottenuti dal Client. (c) Verso il Client il Server restituisce una risposta dove nel body sono compresi tutti i documenti creati. 2. Modifica di un Fascicolo Ospedaliero (operazione di salvataggio) PUT /gestorefascicoli/fascicolo/{id fascicolo}/ body: documenti che si riferiscono alle risorse aggregate ad un Fascicolo Ospedaliero. [Fascicolo Ospedaliero] [Anagrafica] [Dati Primari] [Generalità] [Tessera Sanitaria] [Dati Secondari] [Luogo Nascita] [Recapiti] [Indirizzo] 154

181 Progettazione in ottica REST del sistema PHARMA [Cartelle] Operazioni del Server: (a) Scompatta il body in arrivo dal Client. (b) PUT su tutti dei singoli documenti ottenuti dal Client. (c) Verso il Client il Server restituisce una risposta dove nel body sono compresi tutti i documenti modificati. 3. Creazione di una Cartella Clinica dato un Fascicolo Ospedaliero POST /gestorefascicoli/fascicolo/{id fascicolo}/boxcartelle body: documenti che si riferiscono alle risorse aggregate ad una Cartella Clinica. [Cartella Clinica] [Modalità Ricovero] [Dati Paziente al Ricovero] [Anamnesi] [Dati Iniziali al Ricovero] [Terapie] Operazioni del Server A: (a) POST /gestorecartelle (diretta ad un Server B) body: documenti della Cartella Clinica, esattamente quelli della precedente richiesta. [Cartella Clinica] [Modalità Ricovero] [Dati Paziente al Ricovero] [Anamnesi] [Dati Iniziali al Ricovero] [Terapie] Operazioni del Server B: i. Scompatta il body in arrivo dal Server A. ii. POST dei singoli documenti ottenuti dal Server A. 155

182 Progettazione in ottica REST del sistema PHARMA iii. Verso il Server A, il Server B restituisce una risposta dove nel body sono compresi tutti i documenti creati. (b) GET /gestorefascicoli/fascicolo/{id fascicolo}/cartelle (diretta ad un Server B) Operazioni del Server B: i. Restituisce al Server A, nella risposta, la risorsa [Cartelle] (c) PUT /gestorefascicoli/fascicolo/{id fascicolo}/cartelle (diretta ad un Server B) body: documento ottenuto dalla GET precedente con in aggiunta un riferimento alla risorsa [Cartella] che delinea la Cartella Clinica creata dal Server B. [Cartelle] Operazioni del Server B: i. PUT del documento ottenuto dal Server A. ii. Verso il Server A, il Server B restituisce una risposta dove nel body compare la risorsa oggetto della modifica. (d) Il Server A restituisce al Client i documenti della Cartella Clinica passati inizialmente dal Client stesso. 4. Annullamento di una Cartella Clinica dato un Fascicolo Ospedaliero PUT /gestorefascicoli/fascicolo/{id fascicolo}/cartelle body: risorsa che rappresenta il contenitore delle Cartelle Cliniche [Cartelle] Operazioni del Server: (a) PUT del documento [Cartelle] ottenuto dal Client. (b) Il Server restituisce al Client il documento [Cartelle]. 156

183 Progettazione in ottica REST del sistema PHARMA GET /gestorefascicoli/fascicolo/{id fascicolo}/cartelle/{id cartella} Operazioni del Server: (a) Restituzione della Cartella Clinica, ovvero il documento [Cartella Clinica]. PUT /gestorefascicoli/fascicolo/{id fascicolo}/cartelle/{id cartella} body: documento della Cartella Clinica (ottenuta con la GET precedente). [Cartella Clinica] Operazioni del Server: (a) PUT del documento [Cartella Clinica] ottenuto dal Client. (b) Il Server restituisce al Client il documento oggetto della modifica. 5. Ripristino di una Cartella Clinica dato un Fascicolo Ospedaliero PUT /gestorefascicoli/fascicolo/{id fascicolo}/cartelle body: risorsa che rappresenta il contenitore delle Cartelle Cliniche [Cartelle] Operazioni del Server: (a) PUT del documento [Cartelle] ottenuto dal Client. (b) Il Server restituisce al Client il documento [Cartelle]. GET /gestorefascicoli/fascicolo/{id fascicolo}/cartelle/{id cartella} Operazioni del Server: (a) Restituzione della Cartella Clinica, ovvero il documento [Cartella Clinica]. 157

184 Progettazione in ottica REST del sistema PHARMA PUT /gestorefascicoli/fascicolo/{id fascicolo}/cartelle/{id cartella} body: documento della Cartella Clinica (ottenuta con la GET precedente). [Cartella Clinica] Operazioni del Server: (a) PUT del documento [Cartella Clinica] ottenuto dal Client. (b) Il Server restituisce al Client il documento oggetto della modifica. 6. Modifica di una Cartella Clinica (operazione di salvataggio del documento) PUT /gestorecartelle/cartella/{id cartella}/ body: risorse che rappresentano la Cartella Clinica (dati aggregati a [Cartella Clinica]). [Cartella Clinica] [Modalità Ricovero] [Dati Paziente al Ricovero] [Anamnesi] [Dati Iniziali al Ricovero] [Terapie] Operazioni del Server: (a) Scompatta il body in arrivo dal Client. (b) PUT dei singoli documenti ottenuti dal Client. (c) Verso il Client, il Server restituisce una risposta dove nel body sono compresi tutti i documenti modificati. 7. Creazione di una nuova Terapia Giornaliera data una Cartella Clinica POST /gestorecartelle/cartella/{id cartella}/terapie/boxterapie body: risorse che rappresentano la Terapia Giornaliera (dati aggregati a [Terapia Giornaliera]). [Terapia Giornaliera] 158

185 Progettazione in ottica REST del sistema PHARMA [Interventi e Trattamenti] [Prescrizioni e Somministrazioni] Operazioni del Server A: (a) Scompatta il body in arrivo dal Client. (b) POST dei singoli documenti ottenuti dal Client. (c) GET /gestorecartelle/cartella/{id cartella}/terapie (ad un Server B) Operazioni del Server B: i. Il Server B restituisce al Server A il documento [Terapie]. (d) PUT /gestorecartelle/cartella/{id cartella}/terapie (ad un Server B) body: risorse che rappresenta il contenitore delle Terapie Giornaliere con aggiunto un riferimento alla [Terapia Giornaliera] creata in precedenza. [Terapie] Operazioni del Server B: i. PUT del documento acquisito dal Server A. ii. Il Server B restituisce al Server A il documento [Terapie]. (e) Il Server A comunica al Client la riuscita dell operazione 8. Operazione di ripristino di una Terapia Giornaliera annullata data una Cartella Clinica GET /gestorecartelle/cartella/{id cartella}/terapie/{id terapia}/ Operazioni del Server: (a) Torna indietro al Client i documenti aggregati alla [Terapia Giornaliera]. body: tutto il contenuto della [Terapia Giornaliera] (si illustra, a titolo di esempio, il caso in cui in una [Terapia Giornaliera] sia presente una risorsa [Intervento / Trattamento] e 159

186 Progettazione in ottica REST del sistema PHARMA una risorsa [Prescrizione / Somministrazione]). [Terapia Giornaliera] [Interventi e Trattamenti] [Prescrizioni e Somministrazioni] [{ID Prescrizione / Somministrazione}] [{ID Prescrizione / Somministrazione}/Consenso] [{ID Prescrizione / Somministrazione}/Consenso/Corpo] [{ID Prescrizione / Somministrazione}/Programmazione] [{ID Prescrizione / Somministrazione}/Programmazione/ID Programmazione] 12 elementi [{ID Intervento / Trattamento}] [{ID Intervento / Trattamento}/Referto] [{ID Intervento / Trattamento}/Consenso] [{ID Intervento / Trattamento}/Consenso/Corpo] [{ID Intervento / Trattamento}/Programmazione] [{ID Intervento / Trattamento}/Programmazione/ID Programmazione] 12 elementi PUT /gestorecartelle/terapia/{id terapia}/ body: tutti i documenti afferenti alla Terapia Giornaliera (quelli ottenuti con la GET precedente) con la modifica che adesso sono risorse valide. Le risorse non sono elencate in modo esplicito. Operazioni del Server: (a) Scompatta il body in arrivo dal Client. (b) PUT dei singoli documenti ottenuti dal Client. (c) Verso il Client, il Server restituisce una risposta dove nel body sono compresi tutti i documenti modificati. 9. Operazione di annullamento di una Terapia Giornaliera annullata data una Cartella Clinica GET /gestorecartelle/cartella/{id cartella}/terapie/{id terapia}/ 160

187 Progettazione in ottica REST del sistema PHARMA Operazioni del Server: (a) Torna indietro al Client i documenti aggregati alla [Terapia Giornaliera]. body: tutto il contenuto della [Terapia Giornaliera] (si illustra, a titolo di esempio, il caso in cui in una [Terapia Giornaliera] sia presente una risorsa [Intervento / Trattamento] e una risorsa [Prescrizione / Somministrazione]). [Terapia Giornaliera] [Interventi e Trattamenti] [Prescrizioni e Somministrazioni] [{ID Prescrizione / Somministrazione}] [{ID Prescrizione / Somministrazione}/Consenso] [{ID Prescrizione / Somministrazione}/Consenso/Corpo] [{ID Prescrizione / Somministrazione}/Programmazione] [{ID Prescrizione / Somministrazione}/Programmazione/ID Programmazione] 12 elementi [{ID Intervento / Trattamento}] [{ID Intervento / Trattamento}/Referto] [{ID Intervento / Trattamento}/Consenso] [{ID Intervento / Trattamento}/Consenso/Corpo] [{ID Intervento / Trattamento}/Programmazione] [{ID Intervento / Trattamento}/Programmazione/ID Programmazione] 12 elementi PUT /gestorecartelle/terapia/{id terapia}/ body: tutti i documenti afferenti alla Terapia Giornaliera (quelli ottenuti con la GET precedente) con la modifica che sono risorse valide. Le risorse non sono elencate in modo esplicito. Operazioni del Server: (a) Scompatta il body in arrivo dal Client. (b) PUT dei singoli documenti ottenuti dal Client. 161

188 Progettazione in ottica REST del sistema PHARMA (c) Verso il Client, il Server restituisce una risposta dove nel body sono compresi tutti i documenti modificati. 10. Modifica di una Terapia Giornaliera (operazione di salvataggio del documento) PUT /gestorecartelle/terapia/{id terapia}/ body: composto dai documenti aggregati che compongono la [Terapia Giornaliera]; con questo passaggio viene anche eseguita la creazione di quelle risorse, relative alle Prescrizioni ed agli Interventi, attraverso l impiego del metodo PUT (si illustra, a titolo di esempio, il caso in cui in una [Terapia Giornaliera] sia presente una risorsa [Intervento / Trattamento] e una risorsa [Prescrizione / Somministrazione]). [Terapia Giornaliera] [Interventi e Trattamenti] [Prescrizioni e Somministrazioni] [{ID Prescrizione / Somministrazione}] [{ID Prescrizione / Somministrazione}/Consenso] [{ID Prescrizione / Somministrazione}/Consenso/Corpo] [{ID Prescrizione / Somministrazione}/Programmazione] [{ID Prescrizione / Somministrazione}/Programmazione/ID Programmazione] 12 elementi [{ID Intervento / Trattamento}] [{ID Intervento / Trattamento}/Referto] [{ID Intervento / Trattamento}/Consenso] [{ID Intervento / Trattamento}/Consenso/Corpo] [{ID Intervento / Trattamento}/Programmazione] [{ID Intervento / Trattamento}/Programmazione/ID Programmazione] 12 elementi Operazioni del Server: (a) Scompatta il body in arrivo dal Client. (b) PUT su tutti i singoli documenti ottenuti dal Client sulle risorse individuate dagli URI di ciascun nodo; alcuni di questi, 162

189 Progettazione in ottica REST del sistema PHARMA quelli cioè relativi a nuovi Interventi o nuove Prescrizioni, vengono creati col metodo PUT. Caso particolare, gestione dei documenti [Intervento / Trattamento] (si ribadisce che sono aggregati ad una [Terapia Giornaliera]); dopo avere effettuato una PUT su tali risorse, il Server distingue il caso in cui questi nodi siano esistenti oppure no perché vi è una gestione separata delle risorse [Referti], nello specifico i passi da eseguire sono: * PUT URI del documento [Intervento / Trattamento] possibili risposte da parte della infrastruttura IDN: 200 OK oppure 201 CREATED In caso di 200 OK si procede con una richiesta PUT del [Referto] In caso di 201 CREATED si procede con una richiesta POST della risorsa [Referto] * ESEMPIO 1, creazione di un documento che rappresenta un [Intervento / Trattamento]: i. PUT URI del documento [Intervento / Trattamento] (eseguita da un Server A). RESPONSE: 201 CREATED ii. POST URI della relativa risorsa Box Referti diretta ad un Server B Operazioni del Server B: esegue una POST verso un Server C. Operazioni del Server C: effettua la creazione della risorsa [Referto] * ESEMPIO 2, aggiornamento di un documento che rappresenta un [Intervento / Trattamento]: i. PUT URI del documento [Intervento / Trattamento] (eseguita da un Server A). 163

190 Progettazione in ottica REST del sistema PHARMA RESPONSE: 200 OK ii. PUT URI della risorsa [Referto] (c) Verso il Client, il Server restituisce una risposta dove nel body sono compresi tutti i documenti modificati. 11. Modifica di un Consenso (operazione di salvataggio del documento) PUT /gestorecartelle/terapia/{id terapia}/presc somm/{id presc somm}/consenso/ oppure {id consenso}/ PUT /gestorecartelle/terapia/{id terapia}/int tratt/{id int tratt}/consenso/ {id consenso}/ body: composto dai documenti aggregati che compongono il Consenso. [{ID Prescrizione / Somministrazione}/Consenso] [{ID Prescrizione / Somministrazione}/Consenso/Corpo] oppure [{ID Intervento / Trattamento}/Consenso] [{ID Intervento / Trattamento}/Consenso/Corpo] Operazioni del Server: (a) Scompatta il body in arrivo dal Client. (b) PUT dei singoli documenti ottenuti dal Client. (c) Verso il Client, il Server restituisce una risposta dove nel body sono compresi tutti i documenti modificati. 12. Modifica di un Referto (operazione di salvataggio del documento) PUT /gestorecartelle/terapia/{id terapia}/int tratt/{id int tratt}/referto/{id referto} body: composto dalla risorsa si identifica col Referto. [{ID Intervento / Trattamento}/Referto] Operazioni del Server: (a) PUT del documento in arrivo dalla richiesta del Client. 164

191 Progettazione in ottica REST del sistema PHARMA (b) Verso il Client, il Server restituisce il Referto oggetto della modifica. 5.6 Implementazione e Testing Per quanto concerne alla trattazione degli ultimi due punti restanti della progettazione, si rimanda, per una migliore ed esaustiva illustrazione, ai capitoli dal numero 6 al numero Scelte di implementazione La realizzazione effettiva del sistema prevede che questo fornisca un potere computazionale maggiore ai client rispetto ad un classico sistema dove lo scenario prevede una comunicazione client-server in cui sono scambiati molti messaggi contenenti altrettante richieste HTTP. Dare quindi maggior potenza di calcolo al client comporta un beneficio sostanziale in termini di riduzione di richieste HTTP: infatti, come già accennato in precedenza, si tratterà di formulare delle richieste per l ottenimento di documenti più complessi, lasciando poi all applicazione utente la manipolazione più nel dettaglio delle informazioni. Al contrario, vi sono anche degli inconvenienti che inevitabilmente questo sistema fa nascere: infatti aumenta notevolmente il traffico in termini di trasferimento dati. segue: La scelta definita e qui proposta può essere giustificata secondo quanto non è possibile fare una stima delle richieste (HTTP) medie che si possono avere da parte degli utenti: questo dipende infatti dalle situazioni e dalle aree di attività in cui si esamina lo scenario. Si può immaginare che il caso pessimo sia dato da un area di attività nella quale sono ricoverati contemporaneamente venti/venticinque pazienti e, nello stesso momento, vi siano dieci utenti (infermieri che somministrano farmaci, medici che ottengono cartelle cliniche per consultarsi a vicenda 4 Per la caratterizzazione della fase di autenticazione utente e ricerca pazienti si posticipa la discussione al capitolo

192 Progettazione in ottica REST del sistema PHARMA sulle decisioni da prendere... ) che accedono al servizio. Altro caso, diametralmente opposto, potrebbe essere il reparto di diagnostica nel quale, pur avendo molto lavoro, questo è in qualche modo serializzato : verranno cioè esaminati i pazienti uno per volta il che comporta un ridotto numero di richieste da gestire nel contempo. Alla luce di tutto ciò risulta quindi una varianza elevata per quanto riguarda il numero di messaggi scambiati che non permette di usare una media quale caso di studio per il dimensionamento dell applicazione; non è possibile dire a priori quante richieste un server può gestire: solo dopo aver effettuato delle prove sul campo si potranno dimensionare delle repliche che permettano una migliore gestione delle richieste. In altre parole, in aree di attività con elevato traffico (trasferimento dati e numero di richieste HTTP da gestire) saranno necessari più server (repliche) rispetto a zone in cui il carico di lavoro è minore. Da quanto è emerso, si è quindi deciso di dare maggiori competenze ai client permettendo cioè una gestione più complessa a livello locale delle informazioni facendo fare lato server uno sforzo superiore in termini di trasferimento dati. 166

193 Progettazione in ottica REST del sistema PHARMA Figura 5.13: Information Model: Dettaglio dei documenti Trasferimenti e Scheda Dimissioni Ospedaliera (parte di Cartella Clinica). 167

194 Progettazione in ottica REST del sistema PHARMA Figura 5.14: Information Model: Dettaglio del documento Terapia Giornaliera (parte di Cartella Clinica). 168

195 Progettazione in ottica REST del sistema PHARMA Figura 5.15: Caso d uso: MEDICO crea un Intervento / Trattamento in una Terapia Giornaliera (prima parte). 169

196 Progettazione in ottica REST del sistema PHARMA Figura 5.16: Caso d uso: MEDICO crea un Intervento / Trattamento in una Terapia Giornaliera (seconda parte). 170

197 Progettazione in ottica REST del sistema PHARMA Figura 5.17: Caso d uso: OPERATORE esegue un Intervento / Trattamento in una Terapia Giornaliera (prima parte). 171

198 Progettazione in ottica REST del sistema PHARMA Figura 5.18: Caso d uso: OPERATORE esegue un Intervento / Trattamento in una Terapia Giornaliera (seconda parte). 172

199 Progettazione in ottica REST del sistema PHARMA Figura 5.19: Caso d uso: MEDICO aggiunge un Referto un Intervento / Trattamento in una Terapia Giornaliera (prima parte). 173

200 Progettazione in ottica REST del sistema PHARMA Figura 5.20: Caso d uso: MEDICO aggiunge un Referto un Intervento / Trattamento in una Terapia Giornaliera (seconda parte). 174

201 Progettazione in ottica REST del sistema PHARMA Figura 5.21: Caso d uso: OPERATORE legge dati di una Terapia Giornaliera (prima parte). 175

202 Progettazione in ottica REST del sistema PHARMA Figura 5.22: Caso d uso: OPERATORE legge dati di una Terapia Giornaliera (seconda parte). 176

203 Progettazione in ottica REST del sistema PHARMA Figura 5.23: Caso d uso: MEDICO modifica la Programmazione di una Prescrizione / Somministrazione in una Terapia Giornaliera (prima parte). 177

204 Progettazione in ottica REST del sistema PHARMA Figura 5.24: Caso d uso: MEDICO modifica la Programmazione di una Prescrizione / Somministrazione in una Terapia Giornaliera (seconda parte). 178

205 Progettazione in ottica REST del sistema PHARMA Figura 5.25: Interazioni attraverso chiamate HTTP: Lettura dati della risorsa Terapia Giornaliera. 179

206 Progettazione in ottica REST del sistema PHARMA Figura 5.26: Interazioni attraverso chiamate HTTP: Creazione del documento Interventi / Trattamenti per un documento Terapia Giornaliera di una data Cartella Clinica. 180

207 Progettazione in ottica REST del sistema PHARMA Figura 5.27: Interazioni attraverso chiamate HTTP: Registrazione di avvenuta esecuzione di un Intervento / Trattamento per un documento Terapia Giornaliera di una data Cartella Clinica. 181

208 Progettazione in ottica REST del sistema PHARMA Figura 5.28: Interazioni attraverso chiamate HTTP: Modifica del Referto nel documento Intervento / Trattamento per un documento Terapia Giornaliera di una data Cartella Clinica. 182

209 Progettazione in ottica REST del sistema PHARMA Figura 5.29: Interazioni attraverso chiamate HTTP: Creazione di un documento Cartella Clinica (si considera qui anche la creazione, eventuale, della risorsa Fascicolo Ospedaliero). 183

210

211 Capitolo 6 Interfaccia Grafica Utente (GUI) L interfaccia grafica utente (GUI - Graphical User Interface), comunemente abbreviata in interfaccia grafica, è un tipo di interfaccia utente che consente allo stesso di poter interagire con la macchina operando e manipolando oggetti grafici. Nel capitolo in questione è riportata la descrizione della GUI relativa all applicazione PHARMA, riportando il significato delle varie parti che la compongono, nel caso particolare della vista che viene proposta alla classe di utenti registrati come Medico. 6.1 Finestra principale dell interfaccia grafica La finestra principale della GUI (figura 6.1) è quella che viene mostrata all utente all avvio dell applicazione. In essa si individuano tre parti fondamentali: una parte per l autenticazione dell utente, una volta alla ricerca di pazienti e un ultima in cui appariranno tutte le informazioni relative ai pazienti stessi.

212 Interfaccia Grafica Utente (GUI) La prima parte atta all autenticazione visibile in figura 6.1 nel riquadro verde, contiene due campi da riempire in modo obbligatorio: essi sono i valori Username e Password. Si notano anche due pulsanti per la gestione dell accesso ai dati, il primo è il Login che permette l identificazione e il secondo è il Logout che esegue l uscita e la conseguente disconnessione dal servizio (termine della sessione di lavoro). Sulla base della tipologia di utente che si autentica, si riducono le possibili operazioni che l operatore può eseguire sull interfaccia grafica iniziando da un Medico, passando per un Caposala fino poi ad un Infermiere. La parte afferente alla ricerca (riquadro rosso nella figura 6.1) consente all operatore, una volta che si è autenticato, di cercare all interno del sistema i dati relativi ad un certo paziente in termini di Fascicolo Ospedaliero. Vi sono quattro diversi modi per ottenere informazioni di una persona ricoverata, considerando sempre l identificazione certa per un paziente: ricerca per Nome: inserendo Nome, Cognome e Data di nascita del paziente nei rispettivi campi; ricerca per Numero SSN : inserendo il Numero di Tessera Sanitaria del paziente nell apposito spazio; ricerca per Codice Fiscale: inserendo il valore del Codice Fiscale della persona ricoverata nel campo apposito; ricerca per Codice Interno RFID: inserendo il codice RFID del paziente nel campo omonimo. Infine, per completare la sezione di ricerca, sono presenti due pulsanti Cerca Fascicolo e Cambia Paziente che danno la possibilità di iniziare la ricerca secondo una delle modalità prima elencate (effettuata quindi in modo esclusivo) e la possibilità di ripetere la ricerca con altri criteri. Se il paziente non è presente nel sistema, l applicativo chiede in modo esplicito all operatore se desidera aggiungerlo. 186

213 Interfaccia Grafica Utente (GUI) L ultima parte di questa schermata individuabile col riquadro blu della figura 6.1, mostra la parte che descrive la persona ricoverata: tutte le informazioni anagrafiche e cliniche (limitatamente alla storia dei ricoveri avuti dal paziente stesso) sono qui riportate. Si tratta di una sezione gestita attraverso l uso si schede (altrimenti dette tab ), ognuna delle quali ha determinate proprietà e funzioni: Anagrafica: in questo tab sono visibili (e modificabili) le informazioni personali sul paziente di carattere anagrafico; nel tab è inoltre presente un pulsante Salva che permette di registrare le eventuali modifiche apportate. Gestione Cartelle Cliniche: qui sono riportate un elenco di riferimenti alle Cartelle Cliniche che fanno riferimento alla storia clinica del paziente nella struttura ospedaliera (per visualizzare questa parte si faccia riferimento alla figura 7.8); ogni riga corrisponde ad un ricovero che ha una data con in più l indicazione se si tratta oppure no del ricovero attuale della persona. Per accedere ad uno dei documenti elencati si può procedere in tre distinte modalità: con un doppio click del mouse su di esso, premendo il tasto INVIO una volta selezionata la Cartella Clinica, oppure selezionando il documento e operando sul pulsante Carica Cartella. Qualora non vi sia un ricovero attuale per la persona in esame, è possibile crearne uno attraverso il pulsante Crea Cartella. Come elemento finale si nota anche il bottone Annulla Cartella che consente all operatore di spostare nel Cestino Cartelle l elemento selezionato (questo comando è analogo premendo il tasto CANC della tastiera). Cestino Cartelle: anche questo elemento è un contenitore di Cartelle Cliniche che però, a differenza del precedente punto, non sono valide. Da questo tab si possono eseguire due operazioni, cioè si può accedere al documento selezionato secondo le modalità descritte al precedente caso (in modalità sola lettura) oppure si può ripristinare dei documenti (Cartelle Cliniche) con un preciso pulsante denominato Ripristina Cartella o con il tasto BACKSPACE previa selezione del documento. Non 187

214 Interfaccia Grafica Utente (GUI) si riporta una visuale della finestra principale con questo tab selezionato in quanto è analogo, con le dovute differenze citate, alla visuale del punto precedente. 6.2 Finestra della Cartella Clinica dell interfaccia grafica La seconda schermata qui presentata (figura 6.2) rappresenta la visualizzazione di una Cartella Clinica (versione informatizzata di una Cartella Clinica cartacea) ricca di contenuti informativi perché raccoglie tutti i documenti che seguono la degenza del paziente nella struttura ospedaliera. La prima parte che si identifica nella figura 6.2 riguarda la sezione dei comandi che sono raccolti in alto nella schermata: in giallo è presente la barra dei menù da cui si accede a tutte le azioni che è possibile effettuare sull interfaccia e la seconda è la barra dei segnalibri, in rosso, in cui sono riportate le scorciatoie ai comandi della barra dei menù. Dal menù File si accede alle funzionalità di creazione di un nuovo documento (Nuovo Documento) e all azione Salva che memorizza le modifiche apportate alle sezioni Modalità Ricovero e Dati Paziente al Ricovero rintracciabili dal riquadro blu della medesima figura. Queste due ultime parti citate contengono informazioni riguardo al ricovero della persona; in più nel riquadro blu è presente anche ID Scheda che contiene dati non modificabili inerenti al numero della Cartella Clinica e al nome, cognome e data di nascita del paziente cui i dati afferiscono. Dal menù Modifica si può scegliere fra tre operazioni per la gestione di un singolo documento selezionato nell albero della cartella (riquadro verde): Modifica Documento che permette di accedere all elemento, Ripristina Documento qualora un documento fosse annullato e si desideri renderlo nuovamente parte della cura del paziente (azione accessibile selezionando un atto nel Cestino) e Annulla Documento che dà la facoltà di spostare nel Cestino un dato elemento. 188

215 Interfaccia Grafica Utente (GUI) Prendendo in considerazione ora il riquadro in verde appena nominato, questo mostra tutti i documenti inclusi nella Cartella Clinica in esame: ogni qual volta ne viene aggiunto uno (col comando Nuovo Documento) esso compare nell albero della cartella. Più precisamente questo compare nell albero presente nel tab Contenuto Cartella Clinica, contenitore che tiene traccia degli atti validi per il processo di cura delle persone; l altro tab Cestino, del tutto identico al precedente nella forma ma non nel significato, mantiene i documenti annullati che sono quindi da prendere come non validi. Ogni azione possibile sui documenti qui elencati (che si trovano negli alberi di Contenuto Cartelle Cliniche e Cestino) possiede delle scorciatoie alternative ai pulsanti: per accedere ad un elemento in alternativa al pulsante Modifica Documento si può operare un doppio click su di esso oppure premere il tasto INVIO, per annullare un atto oltre al pulsante Annulla Documento si può operare col tasto CANC e infine per ripristinare un atto oltre al bottone Ripristina Documento si può usare il tasto BACKSPACE. Valgono inoltre le considerazioni del paragrafo precedente: non tutti gli utenti hanno accesso a tutte le operazioni possibili, questo perché la facoltà di creare, annullare e ripristinare nuovi documenti nella Cartella Clinica è delegata al Medico; infine i documenti annullati sono accessibili in modalità di sola lettura. 6.3 Finestra della Terapia Giornaliera dell interfaccia grafica La finestra della Terapia Giornaliera di figura 6.3 è l immagine della versione della Scheda Terapeutica Unica in cui sono osservabili i trattamenti e le prescrizioni valide per una certa data; si tratta di un documento fra i più importanti della Cartella Clinica in fatto di lavoro collaborativo fra gli attori in gioco. Come per il caso della sezione precedente, per prima cosa si localizzano in alto nella finestra due parti: in giallo è presente la barra dei menù da cui si 189

216 Interfaccia Grafica Utente (GUI) può accedere a tutte le azioni che è possibile effettuare sull interfaccia e poi la barra dei segnalibri, in rosso, in cui sono riportate le scorciatoie ai comandi della barra dei menù. Dal menù File si accede alle azioni che si può mettere in opera sulla finestra sotto esame: è possibile aggiungere una nuova voce alla Terapia Giornaliera mediante Nuovo e tali voci riguardano l aggiunta di nuove Prescrizioni / Somministrazioni e nuovi Interventi / Trattamenti; la corrispondente azione che l interfaccia svolge quando l utente opera un comando del genere, è l inserimento di un nuovo record nei rispettivi riquadri sottostanti siano essi Prescrizioni / Somministrazioni (nel riquadro blu scuro nella figura di riferimento) oppure Interventi / Trattamenti (nel riquadro celeste della medesima figura). L altra azione raggiungibile dal menù File è il salvataggio dell intero documento Terapia Giornaliera (comando Salva); nel caso in cui l attore che sta interagendo è un Medico, questa corrisponde ad apporre la firma alla Terapia Giornaliera, mentre se si tratta di un altro attore l operazione ha il significato di memorizzare le modifiche sulle somministrazioni dei farmaci e sugli interventi minori che non necessitano di un Medico (va da sé che quando un Medico salva/firma una Terapia Giornaliera registra le modifiche su di essa con gli annessi, per esempio, somministrazioni o interventi che sono adottati sul paziente). Andando avanti nella disamina delle componenti del documento, si individuano nella zona verde alcuni campi relativi alla data di validità della Terapia, al nome e alla data di nascita del paziente cui appartiene la stessa e una parte di segnalazione sulle eventuali allergie di cui tenere conto nelle prescrizioni che potrebbero interferire con la cura oltre che, soprattutto, intervenire sulla salute della persona ricoverata. Nelle zone riquadrate coi colori blu scuro e celeste sono visibili, come già accennato, le zone che sono parte principale della Terapia: esse sono rispettivamente il contenitore delle Prescrizioni / Somministrazioni e degli Interventi / Trattamenti. Prendendo in esame il primo, si nota che ciascuna riga, che fa riferimento ad una singola prescrizione, è formata da diversi campi: 190

217 Interfaccia Grafica Utente (GUI) VAL: indica se la Prescrizione è valida o se è stata annullata; in quest ultimo caso la riga viene posta in sola lettura e non sarà possibile apporvi modifiche fintanto che non si reintegri la prescrizione stessa. Farmaco: è un menù nel quale si può scegliere fra una serie di possibili farmaci prescrivibili. Posologia: è un campo che definisce la posologia di somministrazione del farmaco specificato al punto precedente. Modalità: indica la modalità di somministrazione del farmaco selezionato. 00 e seguenti undici campi: vengono utilizzate per segnalare l ora a cui il farmaco deve essere assunto dal paziente secondo una dicitura simbolica il cui significato è descritto di seguito. / : il farmaco è prescritto per la fascia oraria; // : la prescrizione del farmaco è sospesa; : il farmaco è in infusione contunua; X : il farmaco è stato somministrato per la fascia oraria; Ø1 : farmaco non somministrato a causa del rifiuto del paziente; Ø2 : farmaco non somministrato perché il paziente era digiuno; Ø3 : non è stato possibile effettuare la somministrazione perché la persona ricoverata non si trovava in reparto in quella fascia oraria; Ø4 : il farmaco non era disponibile e non è stata eseguita la somministrazione; Ø5 : farmaco non somministrato per via dell indisposizione del paziente; Ø6 : altri motivi di non somministrazione; Consenso: è un collegamento al documento di Consenso (eventuale) che deve essere sottoposto alla persona ricoverata (o di chi ne fa le veci) perché la cura, per esempio, potrebbe essere sperimentale; operando 191

218 Interfaccia Grafica Utente (GUI) sul pulsante in esame si passa alla finestra che mostra il documento del Consenso. Medico: rappresenta lo username del Medico che ha eseguito la prescrizione, esso viene aggiornato in automatico appena il farmaco è aggiunto alla sezione di Prescrizioni e Somministrazioni giornaliere. L ultimo elemento visibile nella sezione riquadrata in blu scuro della figura 6.3, tratta di una serie di bottoni sistemati su di una riga dal nome Inserimento firma per avvenuta Somministrazione con la dicitura Firma h.xx, dove il simbolo XX può assumere uno tra i valori delle fasce orarie (dalle 00 fino alle 22 ). Il loro siginificato è associato alla firma dell operatore che esegue la somministrazione: su tutti i farmaci presenti nella sezione le cui prescrizioni sono compatibili con la fascia oraria XX del pulsante su cui si opera, viene apposta la firma dell operatore stesso. La parte evidenziata dal rettangolo celeste mostra i dati relativi agli Interventi e Trattamenti giornalieri: la composizione, in linea di massima, è simile alla parte di Prescrizioni e Somministrazioni giornaliere perciò si evidenziano di seguito solo le differenze che vi sono da quest ultima. In ogni riga di questa parte si ritrovano i singoli Interventi / Trattamenti, i campi che differiscono dal caso precedente sono: Intervento/Trattamento: indica il nome dell intervento a cui il paziente deve essere sottoposto secondo la classificazione ICD9-CM [Min02]. Tipo: il tipo di Intervento (a seconda che sia un urgenza o meno). Referto: pulsante che concede di passare alla schermata dell atto Referto, qualora l Intervento / Trattamento sia stato eseguito. Per ultimo nel riquadro rosa si trova il campo Note, in cui sono apportate informazioni utili alla Terapia Giornaliera. Ad esempio, se un farmaco non viene somministrato con codice Ø6 l operatore inserisce il motivo in questo spazio. 192

219 Interfaccia Grafica Utente (GUI) 6.4 Finestra del Consenso dell interfaccia grafica Nella figura 6.4 è mostrato l equivalente elettronico del documento cartaceo Consenso. Questo atto viene utilizzato, oltre che per informare il paziente dei rischi che un procedimento medico comporta, per formalizzare la presa di coscienza della persona ricoverata ad un preciso processo di cura (accettando quindi la cura stessa). Come per le schermate già presentate, anche questa finestra possiede una parte in alto formata dalla barra dei menù (colore giallo nella figura 6.4) e dalla barra dei segnalibri (in rosso). Dal menù File si può accedere a due distinte azioni: la prima riguarda il salvataggio del documento per mezzo dell operazione Salva e la seconda, Stampa Consenso, permette di ottenere una versione cartacea del Consenso da consegnare all attenzione del paziente (per la lettura e per la firma). Il riquadro verde raccoglie informazioni sul paziente (in sola lettura), per avere ancora l identificazione certa dello stesso, e i dati concernenti l intestazione del documento Consenso, ovvero la data e il tipo specifico di atto. La parte circondata dal rettangolo blu scuro è il corpo del documento ed è la parte che viene consegnata, una volta stampata, alla persona oggetto delle cure. Come ultima parte, in celeste nella figura di riferimento, si trova una checkbox denominata Firma Paziente: il suo scopo è registrare, nel modello informatizzato, che il paziente ha apposto la sua firma sulla versione cartacea del Consenso accettando la cura. 193

220 Interfaccia Grafica Utente (GUI) 6.5 Finestra del Referto dell interfaccia grafica Il documento rappresentante il Referto è osservabile in figura 6.5; questo elemento è legato ad ogni Intervento / Trattamento (oltre che alle Consulenze, qui non riportate) in quanto ogni processo di tale tipo deve riportarne gli esiti. Si trovano ancora le parti afferenti alle barre dei menù e dei segnalibri rispettivamente in giallo e in rosso nella figura 6.5; dal menù File si accede all unica operazione qui prevista che è quella di salvataggio delle modifiche per mezzo del comando Salva. In verde, nella medesima figura, vi sono vari campi il cui significato è ancora quello di intestazione dell atto: si trovano alcuni dati personali del paziente in modalità sola lettura quali il suo nome e la data di nanscita e la data e il tipo specifico legati al Referto. Per ultimo, nel riquadro blu, si individua il corpo, che viene compilato dal Medico, ovvero l esito di qualsiasi esame a cui viene sottoposto la persona in cura. 6.6 Discussione Come già accennato all inizio del capitolo, la descrizione fa riferimento ad una particolare visuale afferente all utente che si autentica come Medico. Come è auspicabile ed immaginabile, l interfaccia si personalizza sulla base della tipologia di operatore: il caso del Medico, quello presentato, è illustrato dalle figure 6.1, 6.2, 6.3, 6.4 e 6.5 e per questa classe di utenza è possibile svolgere la totalità delle operazioni mostrate. Negli altri casi studiati, relativi alla classe di operatori Caposala e Infermiere / Altro, la GUI si modifica disabilitando alcune funzionalità; a dimostrazione di ciò si può 194

221 Interfaccia Grafica Utente (GUI) esaminare le figure 6.6 e 6.7 attinenti rispettivamente agli attori Infermiere / Altro e Caposala di cui però non viene prodotta una descrizione come invece accaduto per l attore Medico. 195

222 Interfaccia Grafica Utente (GUI) Figura 6.1: Interfaccia Grafica Utente di PHARMA: finestra principale. Nel riquadro verde si individua la sezione per l autenticazione utente, in rosso la parte per la ricerca di un paziente e in blu si trovano i dati del paziente stesso. 196

223 Interfaccia Grafica Utente (GUI) Figura 6.2: Interfaccia Grafica Utente di PHARMA: finestra Cartella Clinica. Nel riquadro giallo si individua la barra dei menù, in rosso la barra dei segnalibri, in blu la parte dei dati relativi al ricovero del paziente e in verde la sezione che elenca i documenti per il processo di cura della persona ricoverata. 197

224 Interfaccia Grafica Utente (GUI) Figura 6.3: Interfaccia Grafica Utente di PHARMA: finestra Terapia Giornaliera. Con i vari colori si identificano le parti che la compongono. 198

225 Interfaccia Grafica Utente (GUI) Figura 6.4: Interfaccia Grafica Utente di PHARMA: finestra Consenso. Nel riquadro giallo si individua la barra dei menù, in rosso la barra dei segnalibri, in verde i dati dell intestazione del documento, in blu scuro il corpo dell atto e in celeste la sezione che registra la firma del paziente. 199

226 Interfaccia Grafica Utente (GUI) Figura 6.5: Interfaccia Grafica Utente di PHARMA: finestra Referto. Nel riquadro giallo si individua la barra dei menù, in rosso la barra dei segnalibri, in verde i dati dell intestazione del documento e in blu scuro il corpo dell atto. 200

227 Interfaccia Grafica Utente (GUI) Figura 6.6: Interfaccia Grafica Utente di PHARMA: finestra principale (visione Infermiere / Altro). Si nota che la parte di Anagrafica è in modalità sola lettura. 201

228 Interfaccia Grafica Utente (GUI) Figura 6.7: Interfaccia Grafica Utente di PHARMA: finestra Terapia Giornaliera (visione Caposala). Si nota che la funzione Nuovo è disabilitata così come le parti relative alle Prescrizione e agli Interventi. 202

229 Capitolo 7 Studio di Usabilità della GUI L obiettivo di questo studio, oggetto del capitolo, è la valutazione dell usabilità dell interfaccia grafica utente (GUI) sviluppata in questa tesi, al fine di ridurre la presenza di errori all interno delle cartelle cliniche e rendere le stesse accessibili attraverso tecnologie informatiche. La base delle valutazioni qui affrontate è la norma CEI EN [CEI08]. L analisi, a cui è dedicata la prima parte del capitolo, si basa sullo studio di potenziali utenti che useranno l applicazione valutando le interazioni con l utilizzo della metodologia del Cognitive Walkthrough. La seconda parte del capitolo, invece, riporta i risultati di un questionario che i potenziali utenti hanno compilato dopo aver interagito con l interfaccia grafica: il questionario mira a valutare il grado di soddisfazione che gli stessi utenti hanno avuto nell uso della GUI. L ultimo paragrafo infine tratta le rilevazioni avute dal Centro per la Gestione del Rischio Clinico e la Sicurezza del Paziente (GRC) della Regione Toscana in cui esperti del settore hanno fornito il loro giudizio sulla GUI di PHARMA.

230 Studio di Usabilità della GUI 7.1 Analisi con Cognitive Walkthrough Il Cognitive Walkthrough [WP94, NM94] è un metodo di ispezione di usabilità focalizzato sulla valutazione di un progetto rispetto alla facilità di apprendimento. Lo scopo è di evidenziare eventuali errori di progettazione dell interfaccia che potrebbero interferire in modo negativo con le capacità dell utente di apprenderne facilmente le modalità di utilizzo. Per effettuare un Cognitive Walkthrough sono necessari: una descrizione del sistema; una descrizione del compito che l utente deve eseguire sul sistema; una lista completa delle azioni necessarie per portare a termine il compito con il dato prototipo; indicazioni sugli utenti e sul tipo di conoscenze ed esperienze che essi possiedono per svolgere il compito. Per ciascun passo associato alla lista completa delle azioni che l utente deve compiere, si procede a giudicare le caratteristiche delle schermate che si presentano e le interazioni richieste all utente rispondendo alle seguenti domande: 1. L utente sarà in grado di formulare gli obiettivi corretti? 2. L utente capirà qual è la corretta azione da eseguire sull interfaccia per raggiungere l obiettivo del compito? 3. L utente assocerà il risultato dell azione con l effetto ottenuto? 4. Se l utente ha eseguito una azione corretta, comprenderà in che misura si è avvicinato all obiettivo del compito? Per ogni risposta negativa, si cercherà di capirne la motivazione e successivamente si potrà suggerire una alternativa valida. Infine al termine del capitolo è riportata una sezione dedicata all illustrazione grafica dei passi da svolgere sulla GUI. 204

231 Studio di Usabilità della GUI Descrizione del sistema Una esaustiva descrizione del sistema, o per meglio dire dell interfaccia grafica utente (GUI), è individuabile al capitolo 6, cui si rimanda Descrizione del compito da eseguire sul sistema: prescrizione di un nuovo farmaco (soggetto a consenso) ad un paziente per una prestabilita data Come compito rappresentativo è stata scelta l operazione di prescrizione di un nuovo farmaco ad un determinato paziente per una prestabilita data; si assume che il paziente sia noto al sistema aziendale ma il ricovero in esame non è ancora stato registrato. Prima di procedere ad illustrare, passo dopo passo, le azioni necessarie atte a svolgere tale compito che l utente dovrà produrre sull interfaccia del programma (nel caso in esame l utente è un Medico), si riporta una descrizione di quella che dovrà essere la procedura di prescrizione in questo scenario. Definito a questo punto l obiettivo finale, l utente/medico dovrà avere accesso ad un computer collegato alla rete aziendale sia esso una postazione fissa oppure mobile. Il passo seguente sarà quello di avviare il browser Mozilla Firefox dopodiché dovrà eseguire l applicazione PHARMA attraverso l estensione (di Firefox) che la rappresenta. Una volta avviata l applicazione si rende necessario un accesso per il riconoscimento del Medico che sta eseguendo il compito per mezzo di un opportuno login al sistema; il passo seguente sarà la ricerca del paziente all interno dei database dell azienda nonché la creazione di una nuova cartella clinica e la selezione della stessa. Il Medico, ottenuta dal sistema la cartella clinica, si deve perciò preoccupare di generare il documento relativo alla terapia giornaliera per la data oggetto della prescrizione e successivamente potrà prescrivere il farmaco nella stessa terapia. Infine, il Medico procede al salvataggio delle modifiche apportate a quest ultimo documento menzionato. 205

232 Studio di Usabilità della GUI Azioni necessarie per portare a termine il compito Vengono adesso elencate le azioni necessarie che l utente dovrà svolgere sull interfaccia per la riuscita del compito, al termine di ogni passo si procede a valutare l interfaccia rispondendo alle già citate domande. Obiettivo: il Medico prescrive un nuovo farmaco (soggetto a consenso) ad un paziente per una prestabilita data. Lista delle azioni necessarie: 1. Apertura del browser Mozilla Firefox. 2. Avvio dell applicazione PHARMA. 3. Accesso, tramite il login, al servizio di gestione. 4. Ricerca del paziente cui deve essere prescritto il farmaco. 5. Creazione della Cartella Clinica del paziente. 6. Creazione del documento Terapia Giornaliera a cui fa riferimento la data nella quale si desidera prescrivere il farmaco al paziente. 7. Aggiungere il farmaco stabilito alla Terapia Giornaliera con relativo dosaggio e prescrizioni. 8. Allegare il Consenso da sottoporre al paziente. 9. Salvataggio delle modifiche apportate alla Terapia Giornaliera. Descrizione delle Azioni 1. Apertura del browser Mozilla Firefox In questo primo passo il Medico avvia il browser Mozilla Firefox, il fatto che questa applicazione sia presente nella postazione è un requisito indispensabile per portare a termine il compito. 206

233 Studio di Usabilità della GUI (a) L utente sarà in grado di formulare gli obiettivi corretti? Sì, perché si presuppone che l utente abbia l esperienza sufficiente per accedere ad un browser web. (b) L utente capirà qual è la corretta azione da eseguire sull interfaccia per raggiungere l obiettivo del compito? Non c è ancora una interazione con l interfaccia, qui si tratta infatti di un prerequisito per poter accedere all applicazione di gestione. (c) L utente assocerà il risultato dell azione con l effetto ottenuto? Sì, in quanto l utente sa che per esempio operando un doppio click sull icona che rappresenta il browser Firefox riuscirà a portare a termine questo primo passo. (d) Se l utente ha eseguito una azione corretta, comprenderà in che misura si è avvicinato all obiettivo del compito? Si tratta di un prerequisito, quindi per l utente non è possibile capire ancora se si sta avvicinando a portare a termine il compito/obiettivo principale. 2. Avvio dell applicazione PHARMA La seconda operazione del compito tratta l avvio dell estensione di Firefox relativo all applicazione PHARMA; l obiettivo intermedio illustrato può essere raggiunto in tre diversi modi: il primo attraverso il menù Strumenti del browser selezionando poi la voce PHARMA, il secondo attraverso l icona dell applicazione posta nella parte destra della barra di stato dello stesso browser, infine la terza modalità consiste nell avvio attraverso la combinazione di tasti CTRL+ALT+H sempre dal browser Firefox. (a) L utente sarà in grado di formulare gli obiettivi corretti? Sì, in quanto l utente, per sua esperienza, sa che l avvio di un estensione di Firefox è accessibile attraverso diverse modalità (come descritto in precedenza). (b) L utente capirà qual è la corretta azione da eseguire sull interfaccia per raggiungere l obiettivo del compito? 207

234 Studio di Usabilità della GUI Anche in questo caso, come nella precedente azione, non vi è ancora una interazione con l interfaccia; si procede solamente all avvio della applicazione di gestione. (c) L utente assocerà il risultato dell azione con l effetto ottenuto? Sì, per esperienza acquisita infatti l utente conosce che il risultato associato a tale azione sarà quello sperato, ovvero dopo aver operato su uno dei comandi disponibili per avviare l applicazione produrrà l apertura della stessa. (d) Se l utente ha eseguito una azione corretta, comprenderà in che misura si è avvicinato all obiettivo del compito? Come nel caso precedente si tratta di una azione preliminare, l avvio dell applicazione attraverso le varie metodologie fornite produce come feedback l avvio della stessa con conseguente apertura della finestra di dialogo principale del sistema di gestione. 3. Accesso, tramite il login, al servizio di gestione Per effettuare l autenticazione è necessario che l utente inserisca le proprie credenziali (username e password) all interno dei rispettivi campi nella sezione Autenticazione della finestra principale dell applicazione; per completare il passaggio in esame l utente fa click sul pulsante con etichetta Login. (a) L utente sarà in grado di formulare gli obiettivi corretti? Sì, perché il sistema guida l utente a compiere questa operazione; attraverso un login si può accedere poi ai servizi forniti dall applicativo. (b) L utente capirà qual è la corretta azione da eseguire sull interfaccia per raggiungere l obiettivo del compito? Si fa riferimento a personale con una esperienza tale per cui risulti naturale che, prima di poter usufruire di un servizio, si renda necessario accedere al sistema per mezzo di una autenticazione; inoltre si tratta di un operazione che si nota attraverso pulsanti ed etichette ben visibili. 208

235 Studio di Usabilità della GUI (c) L utente assocerà il risultato dell azione con l effetto ottenuto? L utente tipo considerato ha, come già ripetuto, una certa esperienza nell uso di sistemi (di autenticazione); inoltre non vi sono altre operazioni disponibili, per forza di cose l operatore associa l azione a ciò che sta eseguendo sull interfaccia. (d) Se l utente ha eseguito una azione corretta, comprenderà in che misura si è avvicinato all obiettivo del compito? Il sistema risponde cambiando nell interfaccia alcune label nella sezione Autenticazione: vengono mostrati nome, cognome e ruolo dell operatore che sono associati alle credenziali inserite; inoltre, come ulteriore risposta positiva del sistema, viene abilitata la sezione Dati Paziente che permette di iniziare la ricerca di un paziente. 4. Ricerca del paziente cui deve essere prescritto il farmaco Il quarto passaggio è un operazione analoga alla precedente in termini di azioni, ma con significato differente: la ricerca del paziente viene fatta inserendo per prima cosa il suo identificativo univoco nell apposito campo e successivamente l utente/medico fa un click sul pulsante con etichetta Cerca Fascicolo. (a) L utente sarà in grado di formulare gli obiettivi corretti? Il sistema mette di fronte l utente a dover portare a termine questo passaggio, l interfaccia veicola l operatore ad eseguire una ricerca per poter andare avanti. (b) L utente capirà qual è la corretta azione da eseguire sull interfaccia per raggiungere l obiettivo del compito? L azione risulta ben visibile sull interfaccia, questo fatto è anche supportato dalla presenza di pulsanti con etichette opportune. (c) L utente assocerà il risultato dell azione con l effetto ottenuto? L utente è obbligato dal sistema ad eseguire l azione, non ve ne sono altre disponibili per procedere oltre; inoltre ci sono indicazioni che collegano l azione da eseguire alle operazioni che devono essere attuate sull interfaccia. 209

236 Studio di Usabilità della GUI (d) Se l utente ha eseguito una azione corretta, comprenderà in che misura si è avvicinato all obiettivo del compito? Sì, perché il sistema fornisce un feedback all utente: in caso di successo (viene trovato il paziente oggetto della ricerca) il sistema mostra tutti i dati del fascicolo ospedaliero della sezione Dati Fascicolo Ospedaliero relativi al paziente ricercato. 5. Creazione della Cartella Clinica del paziente Questa azione è ancora atta a recuperare dati necessari per portare a termine il compito principale, l utente deve volgere la sua attenzione alla sezione Dati Fascicolo Ospedaliero della finestra principale e poi selezionare il tab con etichetta Gestione Cartelle Cliniche dove sono elencati i riferimenti dei ricoveri avuti dal paziente e registrati presso la struttura ospedaliera. I ricoveri sono elencati per riga e ad ognuna di esse corrisponde una cartella clinica: l azione da compiere è la creazione di una nuova cartella per mezzo del pulsante con etichetta Crea Cartella, il sistema chiede conferma e successivamente vi si può accedere mediante un doppio click sulla riga appena creata; ciò permette di passare alla finestra Cartella Clinica. (a) L utente sarà in grado di formulare gli obiettivi corretti? L utente è in grado di portare a termine anche questo passaggio in quanto, dalla sua esperienza, risulta naturale la navigazione tra schede (o tab ) fino all individuazione delle operazioni necessarie a terminare il passaggio in esame. (b) L utente capirà qual è la corretta azione da eseguire sull interfaccia per raggiungere l obiettivo del compito? Una volta che l operatore ha acceduto alla sezione Gestione Cartelle Cliniche risulta visibile il pulsante per la creazione di una nuova cartella clinica, perciò la risposta è positiva. (c) L utente assocerà il risultato dell azione con l effetto ottenuto? Una volta individuato il pulsante di creazione e successivamente aver operato un click su di esso, il sistema fornisce indicazioni 210

237 Studio di Usabilità della GUI chiare su quello che l utente sta eseguendo sull interfaccia attraverso il messaggio per confermare la creazione di una nuova cartella. (d) Se l utente ha eseguito una azione corretta, comprenderà in che misura si è avvicinato all obiettivo del compito? Il feedback fornito è l aggiunta di una riga nella tabella delle Cartelle Cliniche relative ai ricoveri del paziente, per l utente è noto che prima di poter arrivare al termine del compito primario si deve passare per questa azione che è ancora ad un livello preliminare. 6. Creazione del documento Terapia Giornaliera a cui fa riferimento la data nella quale si desidera prescrivere il farmaco al paziente L utente/medico deve operare l individuazione della Terapia Giornaliera nell albero che mostra il contenuto della Cartella Clinica sulla parte destra della finestra Cartella Clinica. Visto che il paziente non era ancora registrato, deve essere generata una Terapia Giornaliera e questo può essere compiuto con due diverse modalità: attraverso il menù File alla voce Nuovo Documento selezionando Terapia Giornaliera o per mezzo della scorciatoia nella barra dei segnalibri rappresentata dal pulsante Nuovo Documento, operando come nel caso precedente. Il sistema risponde aprendo un pop-up dal quale viene selezionato la data prescelta e successivamente viene confermata l azione con apposito pulsante. Si accede alla finestra Terapia Giornaliera. (a) L utente sarà in grado di formulare gli obiettivi corretti? Sì, perché l utente sa, per esperienza che niente ha a che vedere con l uso di sistemi di questo tipo, che la prescrizione di un farmaco deve risultare in un documento cartaceo Terapia Giornaliera e, qualora questo non fosse già presente in cartella clinica, deve inserirne uno nuovo nella cartella del paziente stesso: risulta perciò naturale cercare di portare a termine il compito spiegato in questo passaggio. (b) L utente capirà qual è la corretta azione da eseguire sull interfaccia per raggiungere l obiettivo del compito? Vi sono diversi modi di completare l azione in oggetto, il più visi- 211

238 Studio di Usabilità della GUI bile è il pulsante nella barra dei segnalibri Nuovo Documento che permette di creare anche il documento in questione. (c) L utente assocerà il risultato dell azione con l effetto ottenuto? Il sistema dialoga con l utente una volta selezionato il nuovo documento da creare: nel caso in esame l interfaccia si modifica con l apertura di un pop-up che chiede all operatore di selezionare la data per cui deve essere creata la terapia; dopo una conferma il risultato è l apertura della finestra che rappresenta proprio questo documento. (d) Se l utente ha eseguito una azione corretta, comprenderà in che misura si è avvicinato all obiettivo del compito? Il risultato prodotto dall azione descritta lo si può ritrovare anche nell albero di navigazione della cartella clinica nella finestra omonima; la cosa però più importante è che l utente si rende conto di essere vicino al completamento del compito primario perché la prescrizione avviene proprio nel documento appena creato. 7. Aggiungere il farmaco stabilito alla Terapia Giornaliera con relativo dosaggio e prescrizioni Il passaggio in esame si compone di due diverse operazioni. Per prima cosa l utente deve inserire un nuovo farmaco nella finestra Terapia Giornaliera e tale operazione si può portare a termine opzionalmente in due modi: selezionando dal menù File la voce Nuovo, Farmaco oppure dalla barra dei segnalibri mediante il pulsante con etichetta Nuovo seguendo il caso precedente. Il passaggio appena descritto provoca l aggiunta di un nuovo record nella sezione Prescrizioni e Somministrazioni giornaliere. La seconda parte è la prescrizione vera e propria del farmaco che avviene modificando opportunamente i campi del record appena creato. (a) L utente sarà in grado di formulare gli obiettivi corretti? Come nel caso precedente, l esperienza utente del ruolo di Medico lo porta a cercare un operazione che gli permetta di aggiungere il 212

239 Studio di Usabilità della GUI farmaco al documento Terapia Giornaliera. Il passaggio è intuitivo e perciò si fa riferimento alle conoscenze dell operatore. (b) L utente capirà qual è la corretta azione da eseguire sull interfaccia per raggiungere l obiettivo del compito? Ancora come nella precedente azione, vi sono dei dispositivi ben visibili sulla barra dei segnalibri che attirano l attenzione dell utente, e quindi la risposta è anche qui affermativa. (c) L utente assocerà il risultato dell azione con l effetto ottenuto? L effetto qui è l aggiunta di un record nella sezione Prescrizioni e Somministrazioni giornaliere il che porta l utente ad associare tale evento con le sue interazioni sull interfaccia. (d) Se l utente ha eseguito una azione corretta, comprenderà in che misura si è avvicinato all obiettivo del compito? L aggiunta del farmaco porta l utente vicino al traguardo finale, si può asserire ciò perché l utente è un Medico ed ha esperienza nel compiere azioni per prescrivere dei farmaci. 8. Allegare il Consenso da sottoporre al paziente Per allegare il documento di Consenso da sottoporre al paziente, l utente deve agire con un click sul pulsante con etichetta Consenso che si trova nel record del farmaco relativo alla prescrizione in oggetto. Il sistema comunica, con un opportuno messaggio, se si desidera creare il documento Consenso dal momento che quest ultimo non può essere già presente nel sistema in quanto si sta trattando una nuova prescrizione di un farmaco. Il Medico perciò conferma l aggiunta del documento e il sistema mostra la finestra Consenso nella quale si può scegliere se compilarlo in questa sede oppure sottoporlo in un secondo momento all attenzione dell assistito (si suppone di essere in quest ultimo caso). In ogni caso, la finestra Consenso dovrà essere chiusa per tornare alla schermata Terapia Giornaliera. (a) L utente sarà in grado di formulare gli obiettivi corretti? Si ipotizza che il Medico sappia che il paziente debba assumere un farmaco soggetto a consenso, questo lo porta a individuare 213

240 Studio di Usabilità della GUI un modo intuitivo per allegare un documento di questo tipo alla prescrizione. (b) L utente capirà qual è la corretta azione da eseguire sull interfaccia per raggiungerere l obiettivo del compito? Sì, perché nel record relativo alla prescrizione vi è un pulsante con una opportuna etichetta per accedere al documento relativo al consenso. (c) L utente assocerà il risultato dell azione con l effetto ottenuto? Vi è un dialogo tra il sistema e l utente nel corso del quale il primo chiede conferma dell azione che il secondo vuole operare sull interfaccia. (d) Se l utente ha eseguito una azione corretta, comprenderà in che misura si è avvicinato all obiettivo del compito? A questo punto l utente ha compiuto tutte le fasi dell obiettivo primario, ciò che resta da fare è il salvataggio delle modifiche apportate il che risulta naturale data l esperienza dell operatore che sta agendo sull interfaccia. 9. Salvataggio delle modifiche apportate alla Terapia Giornaliera L ultimo passaggio per portare a termine il compito principale tratta il salvataggio delle modifiche apportate nella Terapia Giornaliera, è necessario che l utente effettui un click sul pulsante nella barra dei segnalibri con etichetta Salva nella finestra della terapia stessa, oppure accedendo al menù File e poi fare click su Salva. (a) L utente sarà in grado di formulare gli obiettivi corretti? L ultima operazione disponibile fa perno sull esperienza dell utente nell uso di sistemi informatici: le modifiche appurate alle varie finestre di dialogo presentate dall interfaccia devono essere registrate. (b) L utente capirà qual è la corretta azione da eseguire sull interfaccia per raggiunge l obiettivo del compito? L azione di salvataggio è ben visibile grazie alle scorciatoie for- 214

241 Studio di Usabilità della GUI nite dal sistema nella barra dei segnalibri. L associazione perciò è intuitiva e naturale. (c) L utente assocerà il risultato dell azione con l effetto ottenuto? Le etichette associate ai vari comandi fanno sì che l operatore associ la giusta azione all effetto che produrrà il sistema. (d) Se l utente ha eseguito una azione corretta, comprenderà in che misura si è avvicinato all obiettivo del compito? Dall esperienza acquistata nell uso di sistemi informatici, nonché dalla presenza di una comunicazione esplicita da parte dell interfaccia, l utente sa che le modifiche sono state registrate e il compito primario è terminato Note sugli utenti in relazione al compito Si assume che la varietà degli utenti che possono eseguire operazioni sull applicazione PHARMA sia abbastanza limitata: si tratta di utenza che ha una conoscenza approfondita delle norme sanitarie vigenti (di conseguenza conosce anche la struttura dei documenti sotto esame) e che dovrebbe avere delle sufficienti nozioni per lavorare al meglio con PHARMA. In questo caso, per l esecuzione del compito, si fa riferimento ad una persona che abitualmente usa il computer, con una ragguardevole conoscenza delle tecnologie informatiche anche tra quelle meno note: dal sistema operativo che potrebbe essere Linux piuttosto che Windows (anche se non è necessaria perché l estensione è multipiattaforma), ai programmi per l ufficio, fino alla navigazione web Operazioni sulla GUI relative all azione analizzata I passaggi enunciati e descritti sono la traduzione di quanto accade sull interfaccia grafica. Nella sezione in esame quindi si mostra come un utente, che in questo caso è contraddistinto col ruolo Medico, debba operare realmente sulla GUI per portare a compimento il compito oggetto dell analisi di usabilità. 215

242 Studio di Usabilità della GUI Una volta avviato il browser Mozilla Firefox ed individuato una delle modalità per avviare l applicazione PHARMA (figura 7.1), l operatore si trova di fronte la finestra di dialogo rappresentata nella figura 7.2. Il passo seguente, ovvero l autenticazione al servizio tramite il login, è visibile nella figura 7.3: cliccando poi sul pulsante Login la GUI si modifica mostrando attivo il servizio di ricerca (figura 7.4). La quarta operazione descritta nel Cognitive Walkthrough è illustrata nell immagine 7.5 in cui il Medico inserisce, secondo il criterio di ricerca scelto, i parametri necessari per l individuazione certa della persona assistita. Effettuando il click sul pulsante Cerca Fascicolo, l interfaccia presenta all operatore la finestra principale come indicato dalla figura 7.6. Navigando poi tra i tab della sezione Dati Fascicolo Ospedaliero, il Medico seleziona la Cartella Clinica relativa al ricovero della persona in cura (figura 7.7). Per passare alla finestra della Cartella Clinica l operatore deve agire sul pulsante Crea Cartella perché il paziente non è registrato come attualmente ricoverato, poi effettuare un click sul pulsante Carica Cartella (illustrazione 7.8) così che l interfaccia grafica mostra la schermata relativa ai dati del ricovero selezionato (figura 7.9), ciò conclude il quinto passaggio. Per aggiungere il documento Terapia Giornaliera, si ipotizza che il Medico effettui tale compito mediante la scorciatoia del pulsante Nuovo Documento dalla barra dei segnalibri; il sistema quindi si comporta chiedendo conferma della data con cui l atto deve essere generato. Una volta confermato, si passa in automatico alla visuale della Terapia Giornaliera (immagine 7.10) su cui, per mezzo del pulsante etichettato con Nuovo nella barra dei segnalibri, l utente aggiunge il farmaco indicando poi la prescrizione (figura 7.11). Per allegare il documento relativo al Consenso, è sufficiente agire sul pulsante con etichetta Consenso nel record che indica la prescrizione, di conseguenza l interfaccia grafica mostra la finestra di dialogo del Consenso stesso (figura 7.12) su cui il Medico opera le modifiche del caso. L ultima operazione riguarda il salvataggio della Terapia ovvero, prendendo a riferimento l immagine 7.10, si tratta di agire sul pulsante etichettato con Salva. 216

243 Studio di Usabilità della GUI 7.2 Questionario di valutazione della GUI La seconda parte dello studio di usabilità qui proposto è volta a registrare le impressioni che gli utenti hanno avuto nell uso della GUI. Questo è utile perché in questo modo è possibile avere un feedback diretto da parte degli utilizzatori. Il questionario è composto da nove domande a cui viene assegnata una valutazione sottoforma di giudizio numerico da 1 a 7, dove 1 indica decisamente no e 7 indica decisamente sì. I punti oggetto della valutazione sono riportati di seguito: 1. Le dimensioni dell interfaccia aiutano l inserimento delle informazioni? 2. L interfaccia aiuta/guida l utente nell inserimento delle informazioni? 3. Il flusso delle operazioni del programma aiuta l utente nel suo compito? 4. L inserimento delle informazioni nell interfaccia è intuitivo? 5. La disposizione e le icone dei menù aiutano nell eseguire le operazioni? 6. Le modalità alternative (scorciatoie) fornite per eseguire le operazioni risultano utili? 7. Inserire le informazioni nel software risulta più veloce del riempimento dei campi nei documenti cartacei? 8. Recuperare e leggere informazioni con il software è più veloce rispetto alla lettura e il recupero di documenti cartacei? 9. Il software rispecchia il documento cartaceo? La media dei punteggi ha raggiunto un discreto valore con un risultato di 42/63, il che porta a concludere, nel complesso, che l applicazione rispecchia in modo abbastanza buono la realtà. 217

244 Studio di Usabilità della GUI 7.3 Analisi della GUI da parte del Centro per la Gestione del Rischio Clinico e la Sicurezza del Paziente (GRC) della Regione Toscana L interfaccia grafica utente dell applicazione PHARMA è stata sottoposta alla valutazione di usabilità ed ergonomia da parte del Centro per la Gestione del Rischio Clinico e la Sicurezza del Paziente (GRC) della Regione Toscana. La valutazione euristica [ZJP + 03] sulla quale si è basato questo studio di usabilità è stata operata su di un prototipo funzionante di PHARMA su cui poi esperti del settore del Centro hanno fornito le loro analisi ed osservazioni. Per la simulazione è stato impiegato un database locale e non la messa in opera dell architettura completa descritta al capitolo 8 visto che la valutazione ha riguardato la GUI di PHARMA. Tale indagine ha fatto emergere alcuni problemi e migliorie che sarebbe oppurtuno mettere in atto per lo sviluppo di una nuova versione dell applicazione PHARMA. Nel seguito saranno descritti i punti su cui agire e inoltre verrà presentato in figura 7.13 un riassunto delle rilevazioni avute, in cui sono presenti i livelli di priorità di realizzazione delle stesse (alta - media - bassa) oltre che indicazioni sulla tipologia a cui ci si riferisce secondo lo schema proposto: 1. richiesta di funzionalità: ad esempio poter ordinare i documenti di una cartella clinica per autore, inserire diciture in automatico nella compilazione dei campi, ecc. 2. difficoltà di navigazione e di strutturazione in PHARMA: ad esempio un utente visualizza informazioni su una finestra particolare e incontra difficoltà a tornare in un altro settore dell applicazione, i menù di navigazione non offrono sufficienti funzioni, ecc. 218

245 Studio di Usabilità della GUI 3. disposizione degli elementi nella pagine e usabilità generale: ad esempio disposizione ingannevole dei blocchi di informazioni, poca leggibilità dei contenuti, mancanza di collegamenti per azioni come cancellare un contenuto, ecc. 4. testi descrittivi o aiuto all utente: ad esempio testi di aiuto nella compilazione dei form, indicazione delle scorciatoie per i comandi, messaggi di benvenuto, ecc. Verranno ora descritti i punti rilevati dal Centro GRC della Regione Toscana: Invertire i campi nella sezione Autenticazione Utente (priorità bassa). Con questo si intende riferirsi alla sezione indicata nel riquadro verde in figura 6.1; la critica fatta dai tecnici del Centro è rivolta ad una strutturazione diversa dei campi Username e Password che dovrebbero trovarsi al posto del messaggio di benvenuto che l interfaccia fornisce all utente: in questo modo risulterebbero su di una stessa riga (ideale) il messaggio stesso e i pulsanti di Login e Logout. Oltre a ciò sarebbe utile, una volta eseguito l accesso, marcare ancora in modo più evidente l inattività dei campi esaminati che non sono a questo punto più necessari. Tipologia delle problematiche descritte: punti tre e quattro. Indicazione delle shortcut nelle etichette associate ai comandi (priorità bassa). L appunto qui fatto è rivolto ad enfatizzare la presenza delle shortcut dell applicazione; si dovrebbe perciò aggiungere alle etichette di ciascun comando la corrispondente scorciatoia da tastiera. Tipologia delle problematiche descritte: punto quattro. Trasparenza ulteriore delle icone inattive (priorità bassa). PHARMA modifica il proprio aspetto in base alla tipologia di utente autenticatosi al sistema, dando o meno possibilità di poter eseguire comandi specifici. Ciascun comando presente nella GUI ha una icona associata, quindi per quelli che sono attualmente inattivi la si dovrebbe rendere più trasparente al fine di una migliore comprensibilità da parte 219

246 Studio di Usabilità della GUI dell utilizzatore che l operazione è negata. Tipologia delle problematiche descritte: punto tre. Indicazioni per il lavoro collaborativo nella Cartella Clinica (priorità alta). Il problema relativo a questo punto afferisce alla schermata della Cartella Clinica (riquadro verde in figura 6.2) e più precisamente all albero di navigazione dei documenti della stessa Cartella. Qui infatti è stato introdotto, con l obiettivo di favorire il lavoro collaborativo, una colonna denominata Mod. dall ultimo accesso in cui è mostrato se un preciso documento è stato o meno modificato da altri soggetti in un tempo compreso tra due accessi per un preciso utente che si è autenticato. L indicazione ricevuta è quella di rendere più chiaro tale processo, modificando per prima cosa la dicitura della colonna in Modificato da e i relativi valori con la terna Utente-Data Modifica-Ora Modifica. Tipologia delle problematiche descritte: punti tre e quattro. Terapia Giornaliera 1: controllo sui farmaci prescritti (priprità media). Sarebbe molto interessante nonché utile ai fini dell usabilità e del rischio clinico, poter usufruire di un database nel quale risiedessero le interazioni dannose tra più prescrizioni (riquadro blu scuro di figura 6.3) e tra farmaci e allergie segnalate per le persone in cura. L obiettivo in questo caso sarebbe perciò quello di segnalare al medico esecutore della prescrizione l interazione dannosa mediante un messaggio di allarme. Altro punto, che si riferisce nello specifico alle prescrizioni, è che sarebbe opportuno avere un elenco dei farmaci intelligente e personalizzato per ciascun paziente: in altre parole si vuole proporre al medico prescrivente una lista di farmaci dove nelle prime posizioni compaiono proprio i preparati utilizzati più di frequente per il dato paziente in altre Terapie. Tipologia delle problematiche descritte: punti uno e tre. Terapia Giornaliera 2: ristrutturazione della sezione Prescrizioni e Somministrazioni giornaliere (priorità media). Sempre con riferimento alla figura 6.3 (riquadro blu scuro) è stato riscontrato che sarebbe più usabile, per gli attori che ricoprono il ruolo 220

247 Studio di Usabilità della GUI di medico, guidare l inserimento delle prescrizioni secondo i seguenti passaggi da compiere in sequenza: selezione del farmaco per principio attivo; selezione del dosaggio fra quelli disponibili per il farmaco prescelto (con eventuale collegamento con la farmacia/magazzino per le eventuali disponibilità dello stesso); selezione della forma farmaceutica (ad esempio compresse, polvere, ecc.); indicazione del numero di somministrazioni giornaliere (controllando poi che effettivamente risultino compilate nella scheda); selezione della modalità di somministrazione. Al momento PHARMA concede libertà al medico, nel senso che l ordine di selezione dei parametri è libero, tenendo anche conto che allo stato attuale il principio attivo, il dosaggio e la forma farmaceutica compaiono in una stessa lista. L operazione proposta invece consente un filtraggio progressivo in modo da ridurre il rischio di compiere una prescrizione sbagliata. Tipologia delle problematiche descritte: punti uno e tre. Terapia Giornaliera 3: nuovo simbolo per l Infusione Continua dei farmaci prescritti (priorità media). Una prescrizione che prevede una infusione continua di un farmaco segue una simbologia dedicata, è stato osservato che inserire una funzionalità nell applicazione che preveda il completamento automatico della prescrizione risulterebbe molto efficace, una volta che sia stato indicato l inizio e la fine dell infusione continua nella parte di Prescrizioni e Somministrazioni giornaliere della Terapia Giornaliera (figura 6.3, riquadro blu scuro). Tipologia delle problematiche descritte: punto uno. Terapia Giornaliera 4: eliminare il campo VAL dalle sezioni Prescrizioni e Interventi (priorità alta). Ancora una volta con riferimento alla figura 6.3 (riquadro blu scuro), è 221

248 Studio di Usabilità della GUI stato rilevato un fattore di notevole importanza relativamente al campo VAL delle Prescrizioni e degli Interventi. Si ricorda che tale campo viene utilizzato da PHARMA per dare la possibilità ai prescriventi di eliminare (o riammettere) dalla Terapia alcune prescrizioni/interventi ritenute non più necessarie (o viceversa nel caso duale). La presenza però di questo elemento porta, a giudizio degli esperti, a fuorviare i medici appesantendo la struttura della Terapia Giornaliera: l indicazione ricevuta è quella di eliminare il campo inserendo invece una apposita funzione di cancellazione dei record. Si vuole però rimarcare il motivo della presenza di tale campo nell applicazione: la causa è dovuta al fatto che si tratta di documentazioni che hanno anche un carattere legale, non è stata prevista una vera e propria cancellazione ma è stato perciò adottato questo sistema al fine di mantenere sempre visibili tutte le cure attuate sui pazienti. A concludere questo punto, si vuole far notare che la funzione introdotta dovrà soltanto nascondere i record non desiderati, mantenendoli però lo stesso per le motivazioni citate. Tipologia delle problematiche descritte: punti uno e due. Terapia Giornaliera 5: evidenziare le fasce orarie durante la visualizzazione del documento (priorità media). Il vantaggio di avere evidenziata la fascia oraria nella quale il documento viene visionato, rende lo stesso più leggibile permettendo la localizzazione immediata dell ora attuale per una potenziale somministrazione. Tipologia delle problematiche descritte: punto tre. Fluidità di navigazione fra le Terapie Giornaliere (priorità alta). Una parte considerata limitante è stata quella di non avere la possibilità di navigare tra i vari documenti afferenti alle Terapie Giornaliere, salvo passare dal documento Cartella Clinica che funge da contenitore per tutti gli atti. A partire dalla finestra della Terapia Giornaliera (figura 6.3) si necessita dell inserimento di pulsanti per poter passare da un documento all altro (comandi del tipo avanti e indietro ) supportati anche da un calendario per un accesso rapido ai documenti desiderati. Altra obiezione mossa attiene la possibilità di avere a disposizione una 222

249 Studio di Usabilità della GUI anteprima delle Terapie: tali viste dovrebbero essere organizzate secondo esigenze giornaliere (attuale visuale della Terapia), tri-giornaliere e settimanali quasi a rappresentare un calendario nel quale si evidenziano solo informazioni di carattere generale sulle prescrizioni dalle quali però si può accedere ai dettagli. La miglioria è volta proprio al lavoro collaborativo perché permette di avere una vista ampia di quelle che sono state le cure assegnate. Tipologia delle problematiche descritte: punti uno e due. Variazione delle diciture per i messaggi di conferma (priorità bassa). I messaggi di conferma che PHARMA propone agli utenti sono composti da una domanda alla quale deve essere espressa una risposta utilizzando uno tra i due comandi proposti di accettazione e rifiuto con etichette rispettivamente Ok e Annulla. Il suggerimento avuto in questo senso è quello di presentare finestre con pulsanti le cui etichette siano invece Sì e No. Tipologia delle problematiche descritte: punto quattro. Separazione nella GUI della parte di Accettazione Paziente dalla sezione Trasferimenti (priorità media). Da progettazione è stato previsto che la fase di accettazione dei pazienti sia considerata come un trasferimento (cfr.5.5.1), il fatto è ancora concettualmente valido ma potrebbe portare fuori strada se non separato a livello di interfaccia grafica. Tipologia delle problematiche descritte: punti due e tre. 223

250 Studio di Usabilità della GUI Figura 7.1: Visuale della finestra del browser Mozilla Firefox; nella barra di stato si evidenzia una tra le possibilità di avviare l applicazione PHARMA. 224

251 Studio di Usabilità della GUI Figura 7.2: Finestra principale dell applicazione che viene mostrata una volta avviata PHARMA. 225

252 Studio di Usabilità della GUI Figura 7.3: Dettaglio della finestra principale di PHARMA: sezione di Autenticazione; la freccia rossa indica il pulsante necessario per accedere al servizio. 226

253 Studio di Usabilità della GUI Figura 7.4: Finestra principale dell applicazione dopo aver effettuato il login. 227

254 Studio di Usabilità della GUI Figura 7.5: Dettaglio della finestra principale di PHARMA: sezione di Ricerca Dati Paziente; per prima cosa si deve sceglie il tipo di ricerca (freccia rossa) e successivamente si avvia la ricerca con l apposito comando indicato dalla freccia verde. 228