Source: http://docplayer.it/1751169-Sistemi-di-cloud-computing-per-il-triage-automatizzato-di-pronto-soccorso-profili-e-criticita-di-carattere-tecnico-e-legale.html
Timestamp: 2016-10-24 18:54:13+00:00

Document:
⭐SISTEMI DI CLOUD COMPUTING PER IL TRIAGE AUTOMATIZZATO DI PRONTO SOCCORSO: PROFILI E CRITICITA' DI CARATTERE TECNICO E LEGALE
SISTEMI DI CLOUD COMPUTING PER IL TRIAGE AUTOMATIZZATO DI PRONTO SOCCORSO: PROFILI E CRITICITA' DI CARATTERE TECNICO E LEGALE
Download "SISTEMI DI CLOUD COMPUTING PER IL TRIAGE AUTOMATIZZATO DI PRONTO SOCCORSO: PROFILI E CRITICITA' DI CARATTERE TECNICO E LEGALE"
1 SISTEMI DI CLOUD COMPUTING PER IL TRIAGE AUTOMATIZZATO DI PRONTO SOCCORSO: PROFILI E CRITICITA' DI CARATTERE TECNICO E LEGALE Introduzione L Istituto Italiano per la Privacy, il CATTID de La Sapienza, Microsoft e il Centro Italiano per la Sanità Digitale hanno collaborato in questi mesi ad un progetto rivoluzionario ed estremamente avanzato, in grado di incidere fortemente sugli scenari dell e-health nazionale e internazionale: si analizza la possibilità di rielaborare tutti i dati sanitari (sintomi, diagnosi, cure) dei pazienti dell intero sistema sanitario nazionale, per poi generare attraverso un sistema esperto appoggiato su piattaforma cloud il triage dei pazienti che arrivano in pronto soccorso. Il triage è un sistema di valutazione rapida dell urgenza (normalmente declinata secondo i codici-colore bianco, verde, giallo, rosso): in base al risultato di triage, il paziente sarà considerato in prima istanza più o meno grave, e seguirà uno specifico iter di cura interno al pronto soccorso. Già oggi il sistema triage è utilizzato nei presidi di pronto soccorso: la differenza starebbe nella sua automatizzazione, grazie ad un cervello informatico in grado di rielaborare i miliardi di dati relativi a casi pregressi, per poi indicare quale potrebbe essere il codice-urgenza più probabile sulla base dei sintomi e delle altre informazioni raccolte nell immediato dal paziente, nel singolo caso in esame in quel momento. Questo progetto non mira ad escludere l intervento umano del medico di first aid, ma solo ad adiuvarlo nella capacità di valutazione, in particolare in tutte le situazioni nelle quali per ragioni organizzative, logistiche o fortuite lo sportello di pronto soccorso risulti sottodimensionato o privo di competenze specializzate. Naturalmente, 12 il riuso e l elaborazione di una mole così ampia e complessa di dati sarebbero resi possibili solo grazie all adozione di una tecnologia di cloud computing. Le problematiche affrontate nel lavoro sono sia di natura tecnologica, sia di carattere giuridico (si pensi ai temi della privacy dei pazienti e all anonimizzazione dei dati sanitari). Lo studio, che viene pubblicato in italiano e in inglese, rappresenta un passo d avanguardia in Europa per la ricerca giuridica e informatica sul tema, e può costituire un valido esempio per altre iniziative analoghe finalizzate alla valorizzazione del patrimonio informativo sanitario pubblico. La prima presentazione dello studio si è tenuta il 5 dicembre 2012 a Bruxelles nell'ambito del convegno "Innovating for better health: doing New with Less". La presentazione italiana avverrà presso il Parlamento, a Roma, nel primo trimestre del3 DATI SANITARI E CLOUD COMPUTING PER FINALITA' DI TRIAGE DI PRONTO SOCCORSO: PROFILI E CRITICITA' IN MATERIA DI PROTEZIONE DEI DATI PERSONALI (di Luca Bolognini, Diego Fulco, Enrico Pelino Istituto Italiano per la Privacy Scelte metodologiche e struttura della presente analisi giuridica Il Progetto Triage opera su dati idonei a rivelare lo stato di salute (sinteticamente: dati sanitari ) riferiti a un numero rilevante di soggetti. Come tale, ha un incidenza diretta sulla disciplina giuridica in materia di protezione dei dati personali. Di qui la necessità di analizzarlo alla luce della normativa suddetta, anche allo scopo di evidenziare quale possa essere la configurazione di minore impatto. La scelta della data minimisation questo è l obiettivo risponde da un lato a un vero e proprio obbligo di legge, espresso all art. 3 del Codice privacy (d.lgs. 30 giugno 2003), e ulteriormente ribadito agli art. 5.c e 23 del nuovo Regolamento sul trattamento dei dati personali di prossima adozione a livello europeo, dall altro si lega a considerazioni immediate e pratiche, connesse con un opportuna economia giuridica e di mezzi nella gestione del Progetto. All esame e all approfondimento di tali considerazioni sono dedicati i paragrafi che seguono. La soluzione più adeguata si vedrà appare quella di utilizzare dati anonimi, e di farlo già nella fase iniziale del flusso informativo che alimenta il database centrale del Progetto, in modo da far circolare all interno della struttura di cloud computing che fornisce la piattaforma informatica del sistema solo informazioni dissociate da una componente identificativa. Tutto ciò ha naturalmente ripercussioni di un certo rilievo nella definizione della complessiva architettura del Progetto. Va registrato comunque, in senso positivo, che 34 la scelta di impostare il più possibile l elaborazione su dati anonimi è stata già presa in considerazione dai partecipanti e si può dire che risponda perciò a un approccio condiviso. Strutturalmente, il presente documento si articola in tre sezioni: una prima dedicata all inquadramento in chiave giuridica degli elementi essenziali che compongono la fisionomia del Progetto, vale a dire: i flussi di dati, i soggetti coinvolti, le finalità; una seconda volta a esaminare in chiave generale il complesso dei profili giuridici, e con i essi le connesse difficoltà che il Progetto involge, avendo già in mente uno schema di massima delle scelte possibili per superare il livello di complessità che sarebbe altrimenti inevitabile: è in questa fase che si evidenzieranno le ragioni a supporto dell utilizzo di informazioni rese anonime; una terza e conclusiva fase sarà dedicata al raffinamento della struttura e all approfondimento di alcune questioni giuridiche conseguenti alle scelte strutturali adottate. L ultima parte evidentemente presuppone a monte una stabile definizione della struttura del Progetto e si presenta anche come la sede ideale per avanzare eventuali proposte di intervento normativo da sottoporre al vaglio del legislatore. 1. FISIONOMIA GIURIDICA MINIMA DEL PROGETTO TRIAGE 1.1 Obiettivi del Progetto e flussi di dati Il Progetto si articola intorno a un idea di base, quella di fornire indicazioni sanitarie utili e orientanti (più avanti definite sinteticamente output ) ai reparti di pronto soccorso nella fase di attribuzione dei codici cosiddetti triage. In sintesi estrema, si intende cercare una corrispondenza (match) tra elementi del quadro sintomatico e anamnestico del paziente di pronto soccorso ed elementi corrispondenti archiviati nel database del Progetto e riferiti a un numero considerevole di pazienti storici. I dati dei pazienti storici sono collegati a determinate diagnosi, cosicché, attraverso un elaborazione in chiave statistica o medico-statistica, i profili di tali diagnosi sono resi noti al personale di pronto soccorso, che di essi terrà dovuto conto nell attribuzione dei codici triage. 45 In tal modo si potrà utilizzare una conoscenza collettiva, sedimentata nel database che raccoglie gli interventi medici precedenti, da reimpiegare nella fase di attribuzione dei codici di urgenza ai pazienti, fase che si caratterizza per una particolare immediatezza d intervento e tempi contingentati. L utilità dell output di Progetto consiste quindi nel migliorare l efficienza e la tempistica della fase del triage, fornendo insieme al personale sanitario un utile strumento che integra la diagnosi e agli organismi sanitari una risorsa che contribuisca a ottimizzare l organizzazione dei reparti di pronto soccorso. La tecnologia che le parti hanno intenzione di utilizzare per lo storage dei dati che costituiscono il database, per il funzionamento generale del sistema e per la gestione dei flussi informativi è stata individuata, per ragioni di contenimento dei costi e di efficienza generale nelle prestazioni, in una tecnologia cloud. Ci si pone sul punto la questione delicata dell allocazione dei ruoli privacy rispetto a questo cloud, ossia l attribuzione della posizione di titolare e responsabile di trattamento ai soggetti coinvolti. Sul punto si tornerà più avanti. Il database condiviso sarebbe costituito e alimentato da informazioni sanitarie provenienti dalle documentazioni di pronto soccorso già in possesso degli organismi sanitari pubblici e privati che partecipano al Progetto, e che sono definiti di seguito anche quali provider. È immediato perciò individuare due flussi di dati per ciascun provider: uno in entrata, dai pazienti di pronto soccorso al provider, uno in uscita, da quest ultimo verso il database condiviso del Progetto. Non sembrano invece ravvisabili flussi di dati per così dire orizzontali, ossia da provider a provider. Se questo elemento fosse confermato, si otterrebbe il vantaggio di un opportuna semplificazione in termini di schemi privacy applicabili. Va poi individuato un terzo flusso di informazioni, quello per così dire di ritorno, che dal database condiviso veicola l output di Progetto ai singoli reparti di pronto soccorso, in modo che questi possano utilizzarli in raffronto con il quadro sanitario dei pazienti che di volta in volta accedono alla struttura. 56 Avendo in mente questo disegno essenziale del flusso informativo, è opportuno chiedersi se e in quale punto prevedere che il flusso suddetto sia costituito non da dati personali ma da dati anonimi. Sembra opportuno, come meglio si argomenterà, collocare tale momento nella fase in cui il dato sanitario viene gestito dal provider, ossia prima che questi lo conferisca al database condiviso. Della trasformazione in forma anonima si occuperebbe perciò direttamente il provider, seguendo regole comuni rispetto a tutte le strutture partecipanti al progetto. Non appare invece concretamente possibile, ancorché desiderabile, un ulteriore arretramento del momento di utilizzo di dati anonimi. La scelta di lavorare su dati anonimi comporta che eventuali correzioni delle informazioni dovute a una migliore definizione del quadro sanitario del paziente interessato non saranno di regola possibili dopo l anonimizzazione. Occorre valutare sul punto l impatto a livello medico-statistico. Insomma, la determinazione del passaggio in corrispondenza del quale utilizzare dati anonimi ha precise conseguenze anche di carattere scientifico sull architettura del Progetto. 1.2 I soggetti coinvolti Soggetti attivi di trattamento, ossia soggetti che svolgono attività di trattamento di dati riferibili a terzi, sono i provider. Può trattarsi di: - organismi sanitari pubblici; - organismi sanitari privati. Questi ultimi infatti, sia pure con differenze su base regionale, possono svolgere attività di pronto soccorso. Ai sensi dell art. 28 Codice va identificata come provider la struttura sanitaria nel suo complesso e non il singolo reparto di pronto soccorso. Ciò a meno che il reparto non eserciti un autonomo potere decisionale sul trattamento dei documenti di pronto soccorso. Oltre ai provider, potrebbe essere individuato come soggetto attivo di trattamento l eventuale entità centrale (sempre che vi sia) che si occupa della gestione del 67 database condiviso ed eventualmente anche della decisione sulle modalità di aggregazione e di elaborazione medico-statistica delle informazioni. Naturalmente, se si sceglie come appare preferibile e probabile di far operare questo eventuale soggetto centrale su dati già anonimi, esso si collocherebbe al di fuori dell applicazione della normativa in materia di tutela dei dati personali e dunque non potrebbe essere annoverato tra i soggetti attivi di trattamento. Ancora una volta è evidente l impatto dell anonimizzazione sull architettura del Progetto. A questo passaggio, e in generale ad un esame dei ruoli nel cloud, si riserverà comunque un maggiore approfondimento nel seguito. Sono invece soggetti passivi, ossia soggetti che subiscono le operazioni di trattamento svolte dai provider, i seguenti: - pazienti di pronto soccorso che potremmo definire, per praticità, storici, ossia persone fisiche che sono già state pazienti e alle quali è perciò già associata una documentazione di pronto soccorso. Sono propriamente la fonte da cui viene generato il primo flusso di dati personali, quello che alimenta le risorse informative del provider. Nella terminologia del Codice privacy si tratta di interessati di trattamento, ossia soggetti ai quali i dati si riferiscono; - pazienti destinatari della prestazione di pronto soccorso, che chiameremo anche nel prosieguo, ma solo per comodità, pazienti attuali, poiché si tratta dei pazienti a cui viene attualmente somministrata l attività di pronto soccorso e che sono quindi destinatari anche dell output di Progetto. I pazienti attuali possono evidentemente essere sia pazienti storici che tornano in una struttura di pronto soccorso come anche pazienti nuovi. Il paziente attuale può diventare a sua volta paziente storico se i suoi dati sono raccolti e immessi nel flusso di Progetto. La possibile dissociazione tra paziente storico, ossia interessato di trattamento, e destinatario di trattamento costituisce perciò un tratto saliente dell architettura del Progetto. Si tratta di una caratteristica di interesse nell analisi giuridica. 78 1.3 Finalità del Progetto Il passaggio relativo alle finalità del Progetto può sembrare di minore rilevanza o al limite autoevidente. Così non è. In effetti, le finalità del trattamento rappresentano sempre un elemento di portata determinante nella disciplina giuridica in materia di dati personali. Astrattamente, un progetto in ambito di ehealth può essere ricondotto, a seconda della specifica configurazione che gli viene data, a finalità diverse: di cura, di carattere amministrativo in ambito sanitario, di ricerca medica e medico-statistica. È chiaro che la classificazione nell una o nell altra dipende concretamente dall impostazione che si sceglie e dagli obiettivi che ci si pone. In base alle informazioni fornite e ai colloqui avuti con il team medico che partecipa al progetto, sembra possibile nel caso di specie individuare essenzialmente due finalità, compresenti: una di integrazione della diagnosi sanitaria di pronto soccorso e una di ausilio nella programmazione e gestione dell assistenza sanitaria fornita nei reparti di pronto soccorso, dunque finalità rispettivamente riconducibili agli artt. 85, co. 2 e 85, co. 1 Codice. Stando alla visione attuale del Progetto, non è possibile indicarne una come prevalente. Le finalità suddette rimandano a norme diverse e presentano scostamenti più o meno rilevanti nella disciplina applicabile, come si vedrà più oltre. Deve ritenersi, almeno stando alla visione che attualmente è consentito avere del Progetto, che non siano invece perseguite finalità propriamente di ricerca. Infatti il Progetto non mira ad espandere la conoscenza medica, ma soltanto a rendere rapidamente disponibile un ricco campione di associazioni tra quadro clinico e diagnosi: si propone quindi semmai l obiettivo di una mera velocizzazione dei tempi di decisione e quello di fornire agli operatori un ampio compendio delle diagnosi prospettabili con maggiore verosimiglianza, il tutto con vantaggi organizzativi per l intero reparto e con maggiore efficienza nella gestione dei pazienti. 89 Nell ipotesi, astratta, in cui dovessero emergere dall output del Progetto indicazioni scientifiche suscettibili di arricchire lo stato della conoscenza, si tratterebbe perciò non di risultati cercati quanto piuttosto di scoperte occasionali. Ugualmente, deve escludersi che il Progetto abbia la finalità di acquisizione di dati statistici, in quanto l elaborazione statistica costituisce nella specie uno strumento piuttosto che una finalità. Dovendo escludersi finalità direttamente statistiche e di ricerca scientifica in ambito medico, non si approfondirà nel seguito la peculiare disciplina ad esse collegata. Solo per completezza di analisi ci si limita a segnalare che l emanando Regolamento europeo sulla protezione dei dati personali all art. 81, co. 2 tratteggia, per linee sintetiche, il profilo di un attività che presenta dei punti di contatto con quella del Progetto 1, classificandola nell ambito statistico e scientifico. Si tratta a ben vedere di punti di contatto insufficienti ad attrarre il Progetto nell orbita dei trattamenti per finalità scientifica o statistica. L ipotesi comunque va tenuta sullo sfondo, anche alla luce dell approfondimento giuridico che il Regolamento registrerà nei prossimi mesi. 2. QUESTIONI GIURIDICHE DI CARATTERE GENERALE INERENTI AL PROGETTO Individuata in questi termini essenziali la fisionomia giuridica del progetto, il passaggio successivo, come anticipato, è quello dell esposizione dei principali istituti giuridici richiamati e delle loro conseguenze più evidenti, incluse le difficoltà da superare. In chiave solutiva, si potrà apprezzare l utilità apportata dalla scelta di operare su dati anonimi fin dal primo momento in cui ciò è possibile. 1 Si confronti sul punto l art. 81, co. 2 del Regolamento: Processing of personal data concerning health which uitis necessary for historical, statistical or scientific research purposes, such as patient registries set up for improving diagnoses and differentiating between similar types of diseases and preparing studies for therapies, is subject to the conditions and safeguards referred to in Article 83. 910 Sono essenzialmente tre le condizioni di liceità da osservare: informativa, consenso, autorizzazione del Garante. Mentre l informativa è requisito di applicazione omogenea, consenso e autorizzazione sono legati a parametri variabili, quali la finalità perseguita con il trattamento e la natura privata o pubblica del provider sanitario. Qui di seguito si procede all analisi di tali elementi, nell ordine dato. A tal fine è utile premettere alcune considerazioni a proposito della dissociazione tra interessato e destinatario del trattamento sanitario. Tale dissociazione costituisce infatti un tratto caratteristico del Progetto e si salda a una precisa fisionomia normativa del Codice privacy. In definitiva la dissociazione si prospetta tutte le volte in cui il paziente di pronto soccorso sia terzo rispetto ai pazienti storici. Si presentano quindi in definitiva due schemi, a seconda che l interessato di trattamento: a) sia anche il soggetto diretto destinatario della prestazione medica di pronto soccorso; b) non sia il soggetto diretto destinatario della prestazione medica di pronto soccorso. Ci si riferirà nel prosieguo all ipotesi a) come al modello normale o modello associato, anche per contrapporla all ipotesi b), che sarà indicata come il modello dissociato, tutto ciò con l avvertenza che non si tratta di terminologia del legislatore, ma soltanto di soluzione adottata qui per praticità di discorso. L utilità di distinguere questi due modelli sta nel fatto che la disciplina normativa è per essi diversa. 2.1 L obbligo di fornire l informativa all interessato e l esercizio dei diritti dell interessato L obbligo di fornire un informativa agli interessati è previsto per tutti i trattamenti di dati personali e deve di regola essere assolto prima della richiesta di consenso, che si qualifica per questo come consenso informato, ossia preceduto da una valida informativa. Va tuttavia precisato che mentre tutte le volte in cui il consenso è richiesto occorre che questo trovi il supporto di un informativa, non è vero necessariamente il contrario: ossia, l informativa è dovuta anche quando il consenso non è richiesto. Come si 1011 noterà tra breve, ad esempio, nel caso di finalità di programmazione, gestione, controllo e valutazione dell assistenza sanitaria da parte di organismi sanitari pubblici il consenso non è richiesto, benché l informativa risulti ugualmente dovuta. Ciò perché l informativa serve a dare contezza all interessato di una serie elementi conoscitivi di fondamentale importanza, anche in vista dell esercizio dei diritti riconosciuti al medesimo. Tra gli essenziali elementi conoscitivi che l informativa deve apportare occorre annoverare i seguenti: l identificazione del titolare del trattamento, la definizione dell ambito di conoscenza dei dati, le finalità del trattamento, l indicazione, come si è detto, dei diritti esercitabili. Assolvere all obbligo dell informativa per i provider pubblici e privati, un informativa evidentemente di carattere successivo e integrativo rispetto a quella fornita al momento dell originaria raccolta, potrebbe però tradursi in un aggravio notevole di costi ed avere un impatto considerevole sull organizzazione complessiva del Progetto. Una possibile soluzione potrebbe essere ravvisata nell applicazione dell art. 13, co. 5, lett. c), che consente di prescindere dall informativa cosiddetta successiva (ossia che interviene a trattamento già avvenuto) quando essa comporta un impiego di mezzi che il Garante, prescrivendo eventuali misure appropriate, dichiari manifestamente sproporzionati rispetto al diritto tutelato, ovvero si riveli, a giudizio del Garante, impossibile. Si tratta in ogni caso di un provvedimento rimesso alle valutazioni di un soggetto terzo, l Autorità garante. Peraltro, si deve segnalare che la disposizione appena citata fa riferimento all informativa resa da titolare diverso da quello che ha raccolto originariamente il dato presso l interessato, caso che non collima con quello del provider. Si vedrà più avanti che una valida soluzione può essere trovata piuttosto nella trasformazione in forma anonima dei dati sanitari. 1112 2.2 Il requisito del consenso Come si è osservato, l obbligo o no di acquisire il consenso dipende dalla finalità del trattamento e dalla natura pubblica o privata del provider. Di seguito si tracceranno le linee del quadro applicabile, distinguendo tra finalità di programmazione, gestione, controllo e valutazione dell assistenza sanitaria e finalità di cura, entrambe come si è detto compresenti nel caso in esame Finalità di programmazione, gestione, controllo e valutazione dell'assistenza sanitaria Diversa disciplina seguono gli organismi sanitari pubblici e quelli privati. Quanto ai primi, ai sensi del combinato disposto degli artt. 20 e 85, co. 1 Codice, il trattamento dei dati sanitari viene effettuato senza il consenso dell interessato, rientrando la finalità in esame tra quelle di rilevante interesse pubblico in ambito sanitario. In definitiva, l unico incombente per i soggetti pubblici resta quello della fornitura di un idonea informativa agli interessati. Gli organismi sanitari privati, diversamente, per poter trattare dati personali per la finalità di cui sopra sono tenuti a raccogliere il consenso degli interessati. Devono inoltre procedere in base a previa autorizzazione dell Autorità Garante. Come gli organismi pubblici, quelli privati sono tenuti a fornire un idonea informativa Finalità di cura L analisi qui è più complessa perché tiene conto non solo della differenza tra organismo sanitario privato e pubblico ma anche delle diverse norme applicabili a seconda che ricorra il modello dissociato o quello associato Partendo dal primo schema (dissociato: interessato e destinatario non coincidono), va detto che la disciplina applicabile si struttura per gli organismi pubblici e privati in maniera quasi del tutto analoga, pur collegandosi a disposizioni diverse del Codice privacy, e nonostante qualche differenza di formulazione 2. I provider sanitari pubblici 2 Per gli organismi sanitari privati è indicata una finalità di salvaguardia della vita e dell incolumità del terzo, mentre per gli organismi sanitari pubblici una finalità di tutela della salute e 1213 e privati non sono infatti tenuti a raccogliere il consenso dell interessato ma devono necessariamente procedere con la previa autorizzazione dell Autorità garante per la protezione dei dati personali. Si applicano qui rispettivamente gli articoli 26, co. 4, b) e 76 del Codice. L autorizzazione, sia per gli organismi privati sia per quelli pubblici, è al momento in cui si scrive la n. 2/2011. Nel caso invece in cui ricorra identità tra interessato e destinatario della prestazione sanitaria, ossia quello che si è più sopra definito come modello normale o associato (per distinguerlo dal precedente), il quadro presenta più evidenti differenze tra organismi pubblici e privati 3, in quanto solo gli organismi privati hanno bisogno di una previa autorizzazione del Garante (al momento vale l autorizzazione generale n. 2/2011), mentre entrambe le tipologie di provider sono tenute a richiedere il consenso dell interessato 4 (art. 26 Codice per i privati; articolo 76, co. 1, lett. a e art. 85, co. 2 Codice per i pubblici). Tale consenso, in ipotesi di impossibilità fisica, incapacità di agire o di intendere e di volere può essere prestato da una serie di sostituti. Per completare l esame, va infine evidenziato come in ambito sanitario si applicano al consenso una serie di semplificazioni, che si innestano sulle più generali regole di cui all art. 23 Codice. Vale la pena di passarle in veloce rassegna. In applicazione delle regole generali, il consenso deve essere: - espresso. Un consenso tacito, ad esempio per comportamento concludente, non è considerato sufficiente, almeno allo stato della disciplina attuale; - libero, ossia privo di condizionamenti e pressioni psicologiche 5 ; dell incolumità del terzo. La differenza di formulazione, pure esistente, non va esagerata, anche in considerazione del fatto che trova un denominatore comune nel riferimento all incolumità. 3 La finalità è per entrambi quella della tutela della salute e dell incolumità fisica. 4 Si segnala che questa impostazione del legislatore differisce da quella del legislatore europeo, che all art. 8.3 della Direttiva 95/46/EC aveva introdotto invece una deroga al consenso per l attività preventive, diagnostiche, di cura, post-terapeutiche. Conforme invece la disciplina nazionale sull attività di ricerca medica, che anche a livello europeo richiede il consenso. Cfr. sul punto Gruppo di lavoro ex art. 29 (è il gruppo dei Garanti europei), WP 131, p Cfr. Gruppo ex art. 29, Documento di lavoro sul trattamento dei dati personali relativi alla salute contenuti nelle cartelle cliniche elettroniche (CCE) sul fascicolo sanitario elettronico 2007, p. 8, lett. aa): Il consenso deve essere dato liberamente: consenso libero significa una decisione 1314 - informato, ossia preceduto da un informativa. Per effetto delle regole specifiche applicabili al settore sanitario (cfr. art. 81 Codice), il consenso al trattamento dei dati sanitari può essere: - espresso con unica dichiarazione per più trattamenti; - rilasciato oralmente. Va registrata la deroga alla regola generale che impone la forma scritta per il consenso relativo a dati sensibili; - annotato, in caso di espressione orale, da parte del titolare del trattamento, senza bisogno di ulteriori formalità per la sua documentazione. Le semplificazioni suddette si applicano sia agli organismi sanitari privati sia a quelli pubblici. 2.3 L autorizzazione del Garante Il terzo requisito evidenziato è costituito dall autorizzazione del Garante. Anche in questo caso ciò che incide sulla necessità di procedere con o senza previa autorizzazione è la diversa finalità e, in parte, la natura pubblica o privata del provider. Lo schema, che si è già visto, è il seguente: - se la finalità è di carattere amministrativo, l autorizzazione riguarda soltanto gli organismi sanitari privati; - se la finalità è di cura, l autorizzazione riguarda sempre gli organismi sanitari privati, e riguarda anche quelli pubblici nella sola ipotesi della dissociazione tra interessato e destinatario della prestazione. Quanto alla qualificazione giuridica dell autorizzazione del Garante, si può brevemente dire che si tratta di un atto amministrativo. Esso interviene al termine di una sequenza procedimentale che trae inizio dalla richiesta del titolare di trattamento e che si conclude con la decisione adottata dal Garante nel termine di quarantacinque volontaria, presa da una persona in pieno possesso di tutte le sue facoltà e senza alcuna forma di coercizione, sociale, finanziaria, psicologica o d'altro tipo. Un consenso dato in una situazione medica sotto la minaccia di non essere curati o di ricevere cure peggiori non può essere considerato libero. Il consenso dato da una persona che non abbia avuto la possibilità di fare veramente una scelta o che sia stata messa davanti al fatto compiuto non può essere considerato valido. 1415 giorni, decorsi i quali la mancata pronuncia equivale a rigetto. L Autorità garante può anche emettere autorizzazioni generali per categorie di interessati a norma dell art. 40 Codice. Come già notato, l autorizzazione al momento vigente è quella generale n. 2/2011 del 24 giugno 2011, doc. web n , valida fino al 31 dicembre 2012, che soddisfa pienamente le esigenze del Progetto. 2.4 La soluzione rappresentata dalla trasformazione in dati anonimi Come appare dal quadro appena tracciato, le differenze di finalità e di natura pubblica o privata dell organismo sanitario coinvolto determinano il richiamo di una disciplina molto articolata, nella quale sono evidenti i disallineamenti, le complessità e in ultima analisi i problemi di funzionamento che potrebbe subirne l organizzazione del Progetto. In definitiva si pone un problema non irrilevante di costi e in generale di impegno di risorse organizzative per provvedere alla fornitura dell informativa integrativa di quella già a suo tempo rilasciata e per la raccolta del consenso dell interessato, nei casi in cui ciò sia richiesto. C è poi il problema ulteriore di conciliare adempimenti che fanno capo almeno per quanto è possibile evincere dal primo schizzo del Progetto a due finalità compresenti. Simili elementi di articolazione possono essere sciolti con il ricorso a dati anonimi. Al punto si è già fatto cenno più volte in precedenza ed è questa ora la sede per approfondirlo. La trasformazione in dato anonimo del dato sanitario sarebbe rimessa direttamente ai provider, sulla base di regole omogenee condivise da tutti i partecipanti. Il successivo flusso da ciascuno di essi al database centrale sarebbe perciò formato da informazioni totalmente sganciate da qualsiasi collegamento con persone identificabili. Nello specifico, l anonimizzazione fa perdere di significato alla stessa individuazione delle finalità del trattamento, essendo irrilevante rispetto a dati anonimi l utilizzo che si intende fare dell informazione. Allo stesso modo, l obbligo di fornire un informativa o di raccogliere un consenso ha senso, e portata normativa, solo 1516 rispetto a dati personali, non certo ad informazioni prive di collegamento con un soggetto identificato. L orbita applicativa del Codice privacy coincide in definitiva con l orbita stessa del dato personale. Al più, in relazione all informativa può porsi il problema, molto circoscritto invero, se quella inizialmente fornita al momento della raccolta del dato sanitario (ossia l informativa ai pazienti storici ) dovesse menzionare espressamente la possibilità di rendere anonimo il dato e se, alla luce di ciò, essa vada opportunamente integrata. A rigore, l art. 13 Codice non prevede che l informativa elenchi i trattamenti, ma solo le finalità e le modalità di trattamento, mentre la trasformazione in forma anonima dei dati personali va considerata come un trattamento 6. Non si ritiene perciò necessario che l informativa la indichi. Nella parte speciale si approfondirà maggiormente il tipo di tecnica di anonimizzazione che il Progetto vorrà adottare, premettendo che l anonimato, per essere tale, deve avere il carattere dell irreversibilità. Tale scelta determina conseguenze che vanno apprezzate sul piano della funzionalità del Progetto e possono esserlo solo in un momento in cui lo schizzo iniziale andrà precisandosi e arricchendosi di dettagli. Può ulteriormente porsi, in materia di trasformazione anonima del dato sanitario, il problema se sia o no consentito agli organismi sanitari pubblici partecipanti al Progetto procedere tout court ad una anonimizzazione dei dati. In particolare, può porsi la questione del coordinamento con l art. 20 Codice, che consente a tali soggetti di effettuare un trattamento di dati sensibili solo in presenza di norma di legge che indichi i tipi di dati che possono essere trattati, le operazioni di trattamento eseguibili e le finalità di rilevante interesse pubblico perseguite. A ben guardare il problema appare superabile, sol che si faccia riferimento all art. 3 Codice. La norma in questione è dotata di immediato significato precettivo e dispone 6 La trasformazione in forma anonima si compone di una serie di operazioni che sono tipicamente di trattamento: consultazione dei dati sanitari, selezione di quelli rilevanti per finalità di progetto, dissociazione da una copia di questi ultimi della sola componente informativa. 1617 nei termini seguenti: I sistemi informativi e i programmi informatici sono configurati riducendo al minimo l utilizzazione di dati personali e di dati identificativi, in modo da escluderne il trattamento quando le finalità perseguite nei singoli casi possono essere realizzate mediante, rispettivamente, dati anonimi od opportune modalità che permettano di identificare l interessato solo in caso di necessità. La regola trova peraltro un richiamo espresso e una sua specifica declinazione all art. 94 Codice per le banche dati di dati idonei a rivelare lo stato di salute in ambito sanitario. In altre parole, tutte le volte in cui il trattamento di dati sanitari avvenga attraverso sistemi informatici, ed è il caso di specie, per finalità che possono essere realizzate attraverso dati anonimi, ed è il caso di specie, la trasformazione dei dati in forma anonima non rappresenta una semplice opzione ma un obbligo di legge, al quale i soggetti pubblici (come quelli privati) sono tenuti. Ulteriore questione, della quale ci si occuperà nella parte speciale di approfondimento, riguarda la possibilità che gli organismi pubblici considerino i dati sanitari anonimizzati del Progetto alla stregua di dati pubblici suscettibili di essere considerati nei termini della normativa sul riuso dei dati pubblici, ossia il d.lgs. 24 gennaio 2006, n. 36. La questione verrà esplorata in maggiore dettaglio una volta che saranno chiarite all interno del Progetto le determinazioni relative all eventuale riuso dei dati. 2.5 Ruoli privacy in un sistema di cloud e semplificazione derivante dall utilizzo di dati anonimi Occorre infine considerare il problema dell allocazione dei ruoli attivi di trattamento in un sistema cloud. I ruoli in questione sono quelli di titolare di trattamento e di responsabile di trattamento, cui sono connessi profili di responsabilità diversa nel Codice privacy. 1718 Sinteticamente, il titolare di trattamento è il soggetto apicale che effettua il trattamento, ossia quello che ne decide le finalità, le modalità e ha il potere di disegnare il quadro delle misure di sicurezza da adottare. Il responsabile è un soggetto preposto dal titolare al trattamento e ogni sua decisione deve inserirsi nell alveo delle scelte fatte a monte dal titolare. Ciò non toglie che il responsabile possa godere di un suo margine decisionale, pur entro la sfera di direzione e scelta che compete al titolare del trattamento. Va segnalato che nella pratica sorgono spesso difficoltà nell individuazione dell esatta linea di demarcazione tra responsabile esterno di trattamento (ossia esterno alla struttura del titolare) e titolare autonomo. L analisi va condotta caso per caso, e semplificando molto il discorso si basa su una misura dei reali rapporti di forza tra le parti. In grandi sistemi di cloud pubblici, il soggetto che fornisce il servizio, il cloud service provider, si trova spesso il condizione di forza contrattuale, come emerge dalla constatazione che è di regola il soggetto che decide il profilo della sicurezza del cloud e la configurazione tecnologica del medesimo. Il cloud service provider inoltre determina, per la parte che gli compete, le finalità del trattamento (ad es., la fornitura di un servizio di storage dei dati). Ancora: il cliente spesso fruisce del servizio per mera adesione a un contratto rispetto al quale non ha rilevante possibilità negoziale. La diversità di forza contrattuale tra cliente e cloud service provider in sistemi molto complessi ed estesi si rivela anche nei limitati poteri di controllo e verifica che il cliente ha nei confronti del cloud service provider. In definitiva, pur con variazioni possibili caso per caso, tutti questi indici fanno ritenere corretto ravvisare nel cloud pubblico un modello articolato su due titolari autonomi di trattamento (cliente e CSP). Discorso di segno opposto deve farsi di regola quando si consideri invece un cloud privato, ossia un cloud non aperto a tutti, ma anzi disegnato sulle esigenze di un particolare committente. In questo caso, i ruoli tendono a ribaltarsi e in linea di massima il cloud service provider andrebbe visto come responsabile di trattamento e il cliente come titolare di trattamento. 1819 Ci si può porre ulteriormente il problema se i vari organismi che partecipano al Progetto siano tutti titolari autonomi o svolgano un trattamento congiunto. Va tuttavia osservato che tutti questi problemi, come già anticipato, vengono a dissolversi, come viene a dissolversi l interesse ad un loro approfondimento, ove i dati elaborati nel cloud siano tutti dati anonimi, non potendo in alcun modo prospettarsi, rispetto a questi ultimi, anche a livello teorico, un allocazione di ruoli privacy. Ancora una volta, l utilizzo, già prospettato dai partecipanti al progetto, di dati anonimi abbatte in maniera decisiva le complessità giuridiche da affrontare. 2.6 Sintesi al termine della parte generale Al termine di questa parte dello studio giuridico, pare opportuno sintetizzare brevemente i risultati dell analisi condotta. Innanzitutto, si è chiarito che le finalità del trattamento posto in essere con il Progetto sono di due ordini, e cioè finalità di cura (nel senso di velocizzazione e precisazione della diagnosi) e finalità di organizzazione e programmazione dell assistenza sanitaria (nel senso di maggiore efficienza della medesima). Si è inoltre individuato un tratto significativo del Progetto nella (possibile) dissociazione tra interessato del trattamento e destinatario della prestazione sanitaria, notando come tale dissociazione assuma rilievo nella disciplina che il Codice riserva al trattamento per finalità di tutela della salute. In particolare, nel caso che destinatario del trattamento sia un terzo, è consentita la deroga al consenso obbligatorio ed invece richiesta l autorizzazione del Garante. Consenso e autorizzazione subiscono un inversione per i soggetti pubblici quando invece interessato e destinatario coincidano. Per gli organismi sanitari privati è richiesta, anche, la previa autorizzazione. Il quadro muta ancora nel caso in cui la finalità di trattamento sia di carattere amministrativo, come è una finalità di organizzazione e programmazione dell assistenza sanitaria. In ogni caso, quale che sia la finalità, è necessario fornire un informativa. 1920 Emerge una disciplina complessa, che alterna elementi fissi (l informativa) a elementi variabili (il consenso e l autorizzazione), e comporta, in linea generale, l allocazione di adeguate risorse. La soluzione più lineare in chiave di semplificazione di costi, di organizzazione e di impatto giuridico è quella di utilizzare informazioni anonime già al momento in cui il flusso informativo viene diretto dai provider al database condiviso. In questo modo, ogni adempimento inerente al circuito di informazioni che sostanzia il Progetto viene a collocarsi al di fuori del perimetro del Codice privacy. Ciò vale evidentemente anche per l intera configurazione del sistema di cloud, che verrebbe a operare su un database di informazioni completamente dissociate da una componente identificativa. Non solo peraltro il ricorso a dati anonimi si tradurrebbe in un economia giuridica e di risorse, ma costituirebbe per molti versi una strada obbligata, essendo richiesto da espressa norma di legge, l art. 3 del Codice. Se invece, in una successiva e più matura fase di evoluzione del Progetto si ritenga che rendere i dati sanitari irreversibilmente anonimi non soddisfi le esigenze sanitarie che si perseguono, si dovrà ritornare al quadro già tracciato nella prima parte della sezione generale di questo paper e dunque osservare il complesso reticolo di adempimenti già dettagliatamente segnalati. Il presente lavoro indica cioè una soluzione, pur lasciando aperta la possibilità di prescinderne, a seconda delle concrete necessità del Progetto. Nella sezione che segue, la terza e l ultima di questo lavoro, si approfondiranno i temi conseguenti a quelli appena esposti e in qualche misura definibili di dettaglio. Ovviamente sarà possibile affrontarli solo dopo che la fisionomia tecnica del Progetto abbia ulteriormente acquistato in definizione. Si può anticipare comunque già da ora che i temi da approfondire riguardano, almeno, le seguenti aree: - modalità e caratteristiche dell anonimizzazione che sarà applicata dai partecipanti al progetto, compresi i profili connessi con l irreversibilità del dato; - valutazione circa l opportunità di applicare misure di sicurezza a dati comunque anonimi; 2021 - possibili utilizzi ulteriori dei dati di Progetto e in particolare valutazione giuridica delle prospettive che saranno affacciate in tema di riuso dei dati; - eventuali proposte normative a livello nazionale o europeo. 2122 IL RIUTILIZZO DEI DATI NEL SETTORE DELLA SANITÀ PUBBLICA: IL PROGETTO E-TRIAGE TRIAGE ON THE CLOUD Francesco Bartoli, Carlo Maria Medaglia (C.A.T.T.I.D. Sapienza University Rome) 1. RACCOLTA REQUISITI Introduzione L approccio seguito per definire le specifiche dei requisiti del sistema etriage parte dall identificazione dei concetti necessari per l evoluzione dell attuale sistema Triage adottato come modello di valutazione a priori dell anamnesi del paziente. Saranno sviluppati i seguenti punti: 1. Identificazione dei potenziali attori e gruppi di utenti del sistema; 2. Raccolta dei fabbisogni e delle aspettative del sistema da un punto di vista funzionale, di sicurezza, di privacy e usabilità; 3. Formalizzazione dei requisiti e specifiche della piattaforma attraverso l uso dello standard UML (Unified Modeling Language). 1.1Categorie di Requisiti I requisiti saranno classificati in categorie differenti in modo tale da semplificarne la gestione e valutarne la singola obbligatorietà o opzionalità. Requisiti Funzionali sono definiti come l insieme delle azioni e funzioni fondamentali che devono essere implementate dal sistema a partire da sorgenti di dati in ingresso in maniera da generare output appropriati. Requisiti dei Dati sono definiti come l insieme delle condizioni che debbono sussistere sul contenuto del dato e la sua semantica senza tenere in considerazione i 2223 formati con cui vengono elaborati dal sistema etriage. Si assume che essi siano indipendenti dalla tipologia di database che sarà utilizzato. Requisiti di Interoperabilità specificano la capacità del sistema di condividere informazioni e servizi concentrandosi sulle interfacce che garantiscano l interoperabilità verso sistemi esterni e agli standard che debbono essere supportati per mettere in pratica tale condizione. Requisiti di Usabilità sono definiti come l insieme delle caratteristiche che definiscono l aspetto delle interfacce e la loro facilità d uso e di apprendimento. Requisiti di Operatività che specificano condizioni e livelli di performance ed esercibilità della piattaforma. Requisiti di Sicurezza specificano tutti i fattori che debbono proteggere l applicazione da modifiche, usi indesiderati, accessi dolosi o accidentali. Tra gli esempi ci saranno l utilizzo di tecniche crittografiche, restrizioni delle comunicazioni, integrità dei dati, etc. Requisiti Legali indicano tutta una serie di condizioni che regolino un adempimento delle norme di tutela della Privacy e di eventuali licenze o qualsiasi requisito attinente l ambito della giurisprudenza. 1.2 Livello di necessità Sono stati identificati tre livelli: Essenziale (Implica che il sistema non potrà essere accettato a meno che il requisito sia implementato nella maniera concordata) Condizionale (Implica che tale requisito aumenterebbe il valore del sistema, ma non lo renderebbe inaccettabile nel caso sia assente) 2324 Opzionale (Implica che la funzione potrebbe o no essere di effettivo valore e consente di proporre qualcosa che ecceda i requisiti desiderati) 1.3 Stakeholder etriage Prima di procedere ad un attenta valutazione dei requisiti funzionali e alla loro specifica sono stati individuati tutti gli attori e i portatori di interesse del presente sistema. Particolare enfasi è stata data ai fornitori di dati (data provider) che in questo caso costituiscono il cuore del sistema. Infatti l obiettivo funzionale di etriage è proprio quello di mettere a fattor comune in modo organico le informazioni raccolte da questo gruppo di attori. Il gruppo di utenti individuati come usufruitori dei dati (Data Retriever) e servizi etriage sono stati catalogati come pazienti di telemedicina (teleassistenza domiciliaria), servizi di pronto soccorso ambulatoriale o mobile (ambulanze) e addirittura piccole strutture ospedaliere che non hanno specifici reparti. L ultimo gruppo di attori del sistema è costituito dagli amministratori (Admin) della piattaforma. Nella realtà verrà contemplato nel modello concettuale del sistema e tra gli attori passivamente coinvolti nella definizione delle specifiche anche il Garante della Privacy in quanto soggetto indirettamente coinvolto nei processi di accesso ai dati sanitari. 1.4 Specifiche dei requisiti dalle indagini raccolte Requisiti funzionali RF1 Dominio di applicazione Categoria requisito Requisito Funzionale Livello di necessità (X) Essenziale (Implica che il sistema non potrà essere accettato a meno che il requisito sia implementato nella maniera concordata) 2425 Descrizione del requisito Attore Motivazione Valutazione Autori del requisito Il sistema contemplerà solo ed esclusivamente i referti, ossia i dati clinici contenuti nelle documentazioni di Pronto Soccorso Data provider, Data retriever Il quadro sinottico aggregato di un referto costituirà uno strumento di valore statistico probante a una qualsiasi valutazione in sede di ingresso in Pronto Soccorso Si ipotizza una semplificazione del modello che non contempli la storia delle Schede di Dimissione Ospedaliera SDO pregresse del singolo paziente Francesco Bartoli (CATTID) RF2 Fornitura dei dati Categoria requisito Requisito Funzionale Livello di necessità (X) Essenziale (Implica che il sistema non potrà essere accettato a meno che il requisito sia implementato nella maniera concordata) Descrizione del Il sistema sarà alimentato dalle fonti Triage dell attuale requisito sistema sanitario. Le fonti dovranno pilotare l inserimento dei dati nel sistema etriage attraverso delle interfacce di accesso ai dati dei pazienti depersonalizzati. Attore Data provider Motivazione Il dato sanitario è residente negli archivi dei data provider e non può essere condiviso liberamente unitamente all associazione anagrafica Valutazione Le interfacce potrebbero essere messe a disposizione come web service o in modalità RESTful Autori del requisito Francesco Bartoli (CATTID) Requisiti dei dati RdD1 Accessibilità Open Data Categoria requisito Requisito del Dato Livello di necessità (X) Condizionale (Implica che tale requisito aumenterebbe il valore del sistema, ma non lo renderebbe 2526 inaccettabile nel caso sia assente) Descrizione del Il sistema esporrebbe un sottoinsieme dei propri dati requisito pubblicamente accessibili con licenze Open Data Attore Data retriever Motivazione Alcuni sottoinsiemi del dato sanitario depersonalizzato possono essere forniti ai cittadini per conoscenza e servizi a valore aggiunto. Valutazione I dati potrebbero essere rilasciati secondo le licenze di tipo Creative Commons. Autori del requisito Francesco Bartoli (CATTID) RdD2 Paziente Categoria requisito Livello di necessità Descrizione del requisito Attore Motivazione Requisito del Dato (X) Essenziale (Implica che il sistema non potrà essere accettato a meno che il requisito sia implementato nella maniera concordata) Un paziente in etriage è definito da una tupla che raccoglie i concetti di sintomatologia, osservazioni e accertamenti diagnostici, diagnosi, in modo da modellizzare l analisi patologica nella prima fase di trattamento sanitario fino alla compilazione del referto di Pronto Soccorso Data retriever Il modello del paziente che giunge al pronto soccorso deve contemplare la storia della sua attuale malattia Valutazione Autori del requisito Francesco Bartoli (CATTID) RdD3 Referto Pronto Soccorso Categoria requisito Requisito del Dato Livello di necessità (X) Essenziale (Implica che il sistema non potrà essere accettato a meno che il requisito sia implementato nella maniera concordata) Descrizione del Un referto di pronto soccorso dovrà contenere almeno le requisito seguenti informazioni: insieme delle sintomatologie riportate dal paziente, l insieme degli accertamenti diagnostici effettuati nel percorso di Pronto Soccorso, la diagnosi medica emessa in detta sede. Attore Data retriever Motivazione La storia della malattia corrente del paziente è limitata 2627 temporalmente al singolo evento di ammissione in Pronto Soccorso e concettualmente alle categorie di informazioni elencate sopra Valutazione Una qualsiasi persona si reca al Pronto Soccorso sofferente di alcuni sintomi, viene accettato e sottomesso ai dovuti accertamenti ed esami diagnostici, dopodiché viene stabilita una diagnosi medica di ammissione che eventualmente può evolvere in un ricovero o in trattamenti ambulatoriali o farmaceutici Autori del requisito Francesco Bartoli (CATTID) RdD4 Codifica referti Pronto Soccorso Categoria requisito Livello di necessità Descrizione del requisito Attore Motivazione Valutazione Requisito del Dato (X) Essenziale (Implica che il sistema non potrà essere accettato a meno che il requisito sia implementato nella maniera concordata) La codifica dei dati clinici contenuti nei referti di Pronto Soccorso dovrà seguire lo standard ICD-9-CM già imputato alle Schede di Dimissione Ospedaliera SDO Data retriever Armonizzazione dell evoluzione nella storia ospedaliera del paziente fino alla SDO e univocità nel contemplare la classificazione delle malattie e delle diagnosi riconosciuta in campo internazionale. La struttura dell ICD9-CM prevede quattro sezioni principali di cui 2 relative alla classificazione delle malattie (codici di diagnosi): indice alfabetico delle malattie e dei traumatismi elenco sistematico delle malattie e dei traumatismi ed altre 2 relative alla classificazione delle procedure diagnostiche e terapeutiche: indice alfabetico degli interventi chirurgici e delle procedure diagnostiche e terapeutiche elenco sistematico degli interventi chirurgici e delle procedure diagnostiche e terapeutiche 2728 Inoltre sono presenti due classificazioni supplementari: la classificazione supplementare dei fattori che influenzano lo stato di salute ed il ricorso alle strutture sanitarie (codici V) la classificazione supplementare delle cause esterne di traumatismo e avvelenamento (codici E) Autori del requisito Francesco Bartoli (CATTID) Requisiti d interoperabilità RdI1 Formato dei dati in output Categoria requisito Requisito d Interoperabilità Livello di necessità (X) Essenziale (Implica che il sistema non potrà essere accettato a meno che il requisito sia implementato nella maniera concordata) Descrizione del requisito Il sistema espone i dati attraverso interfacce web service e API Restful con formati XML/JSON Attore Data retriever Motivazione Garantire l interoperabilità per l accesso e il riuso dei dati di trattamento sanitario di Pronto Soccorso. Valutazione Si può accedere al dato strutturato o a servizi specifici sempre attraverso il Web. Autori del requisito Francesco Bartoli (CATTID) RdI2 Formato dei dati in input Categoria requisito Requisito d Interoperabilità Livello di necessità (X) Essenziale (Implica che il sistema non potrà essere accettato a meno che il requisito sia implementato nella maniera concordata) Descrizione del Il sistema dovrà accettare i dati pilotati dalle fonti requisito attraverso interfacce web service e API Restful con formato rispettoso del protocollo standard di scambio dati in ambito clinico HL7 Attore Data provider Motivazione Garantire l interoperabilità e l utilizzo d interfacce 2829 comuni secondo le normative standard in vigore sullo scambio di informazioni cliniche. Valutazione L utilizzo di HL7 lascia campo aperto verso successive evoluzioni e adeguamenti normativi che la materia sanitaria potrà subire dal punto di vista dell Information Technology per la fase di Pronto Soccorso Autori del requisito Francesco Bartoli (CATTID) RdI2 Formato dei dati in input Categoria requisito Requisito d Interoperabilità Livello di necessità (X) Opzionale (Implica che la funzione potrebbe o no essere di effettivo valore e consente di proporre qualcosa che ecceda i requisiti desiderati) Descrizione del requisito Il sistema dovrà definire un HL7 CDA (Clinical Document Architecture) del referto di Pronto Soccorso Attore Data provider Motivazione Garantire l interoperabilità e l utilizzo d interfacce comuni secondo le normative standard in vigore sullo scambio di informazioni cliniche. Valutazione Un gruppo di lavoro per definire a livello nazionale un profilo di interoperabilità definito normativamente nelle strutture di Pronto Soccorso Autori del requisito Francesco Bartoli (CATTID) Requisiti di usabilità Non applicabili Requisiti di operatività RdO1 Hosting del sistema Categoria requisito Requisito di Operatività Livello di necessità (X) Essenziale (Implica che il sistema non potrà essere accettato a meno che il requisito sia implementato nella maniera concordata) Descrizione del Il sistema dovrà essere ospitato come servizio Cloud su requisito architettura Microsoft SQL Azure Attore Data Retriever Motivazione Microsoft SQL Azure garantisce un architettura innovativa e servizi per l usufruizione del dato da parte di dispositivi eterogenei i quali necessitano di disponibilità e 2930 accessibilità 24h/7d Valutazione SQL Azure può esporre servizi basati sui dati archiviati nel corrispondente database. Autori del requisito Francesco Bartoli (CATTID) Requisiti di sicurezza Non applicabili Requisiti legali RL1 Paziente depersonalizzato Categoria requisito Requisito Legale Livello di necessità (X) Essenziale (Implica che il sistema non potrà essere accettato a meno che il requisito sia implementato nella maniera concordata) Descrizione del requisito Il sistema dovrà accettare dalle fonti dei dati in origine (data provider) solo quadri sinottici depersonalizzati dall identità anagrafica del paziente al momento prevista nell attuale sistema sanitario nazionale. Attore Data provider Motivazione Il dato sanitario costituisce un dato sensibile ai sensi della legge sulla Privacy Valutazione Il paziente in etriage può essere pensato come un concetto slegato dall identità anagrafica Autori del requisito Francesco Bartoli (CATTID) RL2 Referto di Pronto Soccorso Categoria requisito Requisito Legale Livello di necessità (X) Condizionale (Implica che tale requisito aumenterebbe il valore del sistema, ma non lo renderebbe inaccettabile nel caso sia assente) Descrizione del requisito Il referto di Pronto Soccorso dovrà essere compilato secondo la codifica delle diagnosi e delle procedure utilizzando la classificazione ICD-9-CM. Attore Motivazione Data provider Il referto di pronto soccorso è un atto pubblico con valenza probatoria (art 2700 cc) che contiene informazioni utili a dimostrare la veridicità di quanto riportato al medico in occasione dell accesso e riporta dati anamnestici, obiettivi, diagnostico strumentali e 3031 prognostici Valutazione Autori del requisito Francesco Bartoli (CATTID) 2 ARCHITETTURA ETRIAGE L architettura del sistema etriage si prefigge di utilizzare i dati collezionati nelle strutture ospedaliere e di servirli in modo anonimo per offrire servizi di teleassistenza nella fase di primo intervento ed emergenza soprattutto in quei piccoli ospedali e nelle ambulanze dove sono prestate le prime cure, che a volte risultano decisive nell efficacia del trattamento patologico. A tendere lo scenario dei possibili utenti serviti dal sistema evolved Triage potrebbe evolvere coinvolgendo anche i grandi ospedali e offrire teleassistenza medica a domicilio. etriage prevede di ospitare questa enorme banca dati in un sistema Cloud che sia trasparente all identità personale dei pazienti in modo da tutelare la loro privacy e rendere la natura delle informazioni possedute dal sistema totalmente prive di alcuna limitazione dovuta alla sensibilità del dato. I data provider delle informazioni resterebbero gli ospedali che partecipano al pilota dove localmente rimangono confinate le identità personali dei pazienti che hanno subito trattamenti ospedalieri. In tal modo sarà disaccoppiato il concetto di identità personale da quello di paziente di una struttura ospedaliera. L architettura generale sarebbe quella della figura sottostante: 3132 Italian Triage - Architecture Data providers Triage data DB Triage data Italian Triage users Figure Architettura generale Triage 2.1 Modello concettuale Dal punto di vista concettuale il disegno del sistema deve sviluppare il modello di paziente come una triade di concetti strettamente sanitari slegati dall identità anagrafica per contemplare la riutilizzabilità del dato sanitario senza incontrare vincoli ostativi al trattamento di dati sensibili secondo la norma giuridica italiana. Il concetto cardine alla base di questo modello è il seguente: Un paziente non possiede un identità anagrafico-giuridica 3233 Ciò consente di focalizzare l attenzione sulle prime fasi di intervento (Pronto Soccorso) sulla patologia di un potenziale paziente e delineare quelli che sono i concetti e le relazioni che delineano il suo quadro clinico. Il modello logico funzionale descrive questi concetti basilari: Un paziente ha una sintomatologia Un paziente ha una serie di parametri vitali e sanitari che possono essere analizzati attraverso determinati accertamenti diagnostici Un paziente riceverà una diagnosi Questo è lo scenario che mostra il modello logico funzionale di un paziente ogni qual volta un soggetto si reca in una struttura ospedaliera per ricevere delle cure di primo soccorso in relazioni a sintomi emersi. In questa situazione una qualunque persona è declinata in un paziente e in particolare nel modello appena descritto. Italian Triage HealthCare Data Provider Scenario Vital Parameters Symptomatology Diagnosis Pa ent A user is ingested in a pa ent each he/she ends up to an hospital me Figure Modello concettuale di un paziente 3334 E importante rilevare come il modello ben si sposa con lo scopo di fornire servizi nella fase embrionale di un intervento in Pronto Soccorso. Ciò significa che i concetti presi in considerazione sono quelli formalmente indicativi per stabilire l identificazione della natura di una sintomatologia sebbene una malattia possa produrre successivi nuovi sintomi e non manifestarsi in maniera chiara sin da subito. Infatti, è evidente come il modello appena descritto sia fondamentalmente legato al tempo e alla storia del paziente e quindi come la diagnosi sia un fattore che può variare nel tempo rispetto alla corrente sintomatologia ma anche alle storie precedenti dello stesso paziente. Al momento si presume di trattare un modello semplificato, poco dipendente dal tempo, che racchiuda solo l'associazione concettuale di una singola storia sanitaria di Pronto Soccorso di un paziente. Il Cloud etriage fornirà valore aggiunto derivato dall unione di questi tre concetti in virtù di un architettura distribuita sulle sorgenti di dati Triage riferiti ai referti di Pronto Soccorso in modo da fornire servizi di consultazione rapida per una valutazione patologica di massima (suggerimenti diagnostici) secondo la codifica standard delle malattie che già è utilizzata per le SDO. 3435 Italian Triage - Priority Data providers Symtomatology Immediate Delayed Triage Patient data Vital framework Diagnosis Minor Morgue Immediate Delayed Triage Patient data Minor Morgue Italian Triage users Each ehealth data provider has its own repository and stores personal iden ty informa on of their pa ents locally Figure Modello servizi Triage e loro integrazione in etriage Il modello dei dati che sarà individuato avrà inoltre un bagaglio di informazione aggiuntiva in quanto collega ogni singola storia dei pazienti alla priorità con cui si è intervenuti nella fase preliminare di valutazione patologica, evidenziando di fatto la priorità di intervento non sulla singola codifica di diagnosi ma sul quadro sinottico aggregato delle informazioni di Sintomatologie, Accertamenti diagnostici, Diagnosi. Al momento la classificazione di un ammissione, infatti, è regolata da una scala piramidale (e un corrispondente colore) in base alla priorità di intervento: Urgente (colore rosso) In attesa (colore giallo) Modesta (colore verde) Insignificante (colore blu) 3536 2.2 Classificazioni e Standard utilizzati Sistema di classificazione nella sanità italiana Il sistema attualmente riconosciuto e adottato dal Ministero della Salute è quello della Classificazione internazionale delle malattie (ICD) che organizza le malattie ed i traumatismi in gruppi sulla base di precisi criteri. La classificazione è approvata in ambito internazionale e riconosciuta dal 1979 con la sigla ICD-9-CM nella versione ampia che include anche gli interventi e le procedure diagnostiche. In Italia a partire dal primo gennaio 2009 viene adottata su tutto il territorio nazionale la versione 2007 di ICD-9-CM per declinare le informazioni cliniche rilevate nella Scheda di Dimissione Ospedaliera sia per la codifica delle diagnosi, principali e secondarie, sia delle procedure, anch esse principali e secondarie. Visti i vantaggi di uniformità e armonizzazione di cui potrebbe beneficiare tutto il processo della filiera ospedaliera si è scelto di utilizzare la predetta codifica ICD-9- CM anche nel modello di codifica di un referto di Pronto Soccorso su sistema etriage Protocolli di comunicazione Sul fronte dello scambio dati in ambito sanitario è stato preso in esame HL7 che risulta essere lo standard per la comunicazione di messaggi più diffuso internazionalmente nel settore dell ICT sanità: esso descrive le interfacce tra applicazioni diverse, le definizioni dei dati da condividere, nonché gli eventuali stati di preclusione nella comunicazione. Lo scopo di tale protocollo risiede soprattutto nel comunicare le informazioni relative ad un paziente tra applicazioni diverse rendendo le varie entità del mondo sanitario interoperabili nel trattare i dati clinici. Tale scelta presuppone di lasciare ampio spazio all integrazione di un numero illimitato di data provider rendendo flessibile il processo secondo un meccanismo di tipo plug&play. 3637 L unico vincolo di riconducibilità alla fonte dati sarà quello di prevedere nelle modalità che saranno stabilite nella modellazione delle interfacce generali del nosologico relativo alla singola struttura ospedaliera. 2.3 Implementazione Database etriage Modello logico La progettazione della base dati ha tradotto l analisi dei requisiti soprastanti per la gestione dei dati di una cartella clinica di pronto soccorso in modo da organizzarla nel modello logico che proponiamo di seguito: Figure Modello logico della base dati etriage 3738 Nella figura è possibile notare in verde le entità coinvolte nella modellazione tra cui le principali: Il paziente come elemento cardine della struttura che viene descritto dalle informazioni rilevanti ai fini della cartella di Pronto Soccorso senza alcun riferimento ai dati personali; La scheda del trattamento di Pronto Soccorso associata a ciascun paziente; Le procedure eseguite secondo la codifica ICD-9-CM; La diagnosi ricevuta secondo la codifica ICD-9-CM Codifica ICD-9-CM Nella trasposizione del modello concettuale la tassonomia delle codifiche ICD-9-CM è stata predisposta di sana pianta dalla struttura ufficiale con cui è organizzata dal Ministero della Salute. Nella figura sottostante vediamo il prospetto del modello in opera sul database di SQL Azure: 3839 Figure Organizzazione codifiche delle malattie e procedure ICD-9-CM 2.4 Implementazione Servizi etriage Windows Azure Windows Azure è una piattaforma cloud aperta e flessibile che consente di compilare rapidamente, distribuire e gestire applicazioni attraverso una rete globale di data center gestiti da Microsoft. È possibile compilare applicazioni utilizzando qualsiasi linguaggio, strumento o framework. Le funzionalità e i servizi sono esposti utilizzando protocolli REST. È inoltre possibile integrare le applicazioni cloud pubbliche con l'ambiente IT esistente. 39 Vedere altro
Manuale Breve per la Digitalizzazione dei documenti sanitari: i principi fondamentali da tenere in considerazione nel sistema di conservazione digitale dei documenti sanitari di Andrea Lisi Avvocato specializzato Dettagli Cloud in Sanità: Vademecum essenziale sulla tutela della privacy
Cloud in Sanità: Vademecum essenziale sulla tutela della privacy MANUALE SUI PRINCIPI, SULLE CARATTERISTICHE, SULLE SPECIFICHE NORMATIVE IN MATERIA DI PROTEZIONE DEI DATI DA APPLICARE IN ITALIA ALL'EROGAZIONE Dettagli Riusabilità del software e delle applicazioni informatiche nella pubblica amministrazione
Riusabilità del software e delle applicazioni informatiche nella pubblica amministrazione Rapporto del gruppo di lavoro giugno 2004 Riusabilità del software e delle applicazioni informatiche rapporto del Dettagli PRIVACY E SCUOLA TRA LE NUVOLE
PRIVACY E SCUOLA TRA LE NUVOLE MANUALE PRIVACY PRATICO-GIURIDICO PER UNA SCELTA CONSAPEVOLE DI SOLUZIONI CLOUD IN AMBITO SCOLASTICO: CRITERI DI INDIVIDUAZIONE DEI DATI PERSONALI, DEFINIZIONE DEI RUOLI Dettagli Vademecum. Open Data. Come rendere aperti i dati delle. pubbliche amministrazioni
Vademecum Open Data Come rendere aperti i dati delle pubbliche amministrazioni Versione Beta 2011 2 3 Il presente documento, realizzato nell ambito delle attività finalizzate alla elaborazione delle Linee Dettagli SERVIZI DI CLOUD COMPUTING E PROTEZIONE DEI DATI PERSONALI IN AMBITO BANCARIO
SERVIZI DI CLOUD COMPUTING E PROTEZIONE DEI DATI PERSONALI IN AMBITO BANCARIO Avv. Luca Bolognini Presidente Istituto Italiano per la Privacy e la Valorizzazione dei Dati Founding Partner Studio ICT Legal Dettagli DIRETTIVA 2011/24/UE DEL PARLAMENTO EUROPEO E DEL CONSIGLIO
4.4.2011 Gazzetta ufficiale dell Unione europea L 88/45 DIRETTIVE DIRETTIVA 2011/24/UE DEL PARLAMENTO EUROPEO E DEL CONSIGLIO del 9 marzo 2011 concernente l applicazione dei diritti dei pazienti relativi Dettagli Gestire un progetto. Costruire il partneriato, governare la spesa, valorizzare i risultati
Linee guida per il riuso delle applicazioni informatiche nelle Amministrazioni pubbliche Parte 1 Riuso di applicazioni esistenti Pagina 1 Documento a cura di: Paola Minasi (CNIPA) Pagina 2 INDICE 1. INTRODUZIONE------------------------------------------------------------------------------------------ Dettagli LINEE GUIDA PER L ANALISI DEGLI EFFETTI SULL OCCUPAZIONE DEGLI INTERVENTI (*)
LINEE GUIDA PER L ANALISI DEGLI EFFETTI SULL OCCUPAZIONE DEGLI INTERVENTI (*) settembre 2001 INDICE 1 Contenuti generali e finalità del criterio Qualità del sistema di valutazione degli effetti sull occupazione Dettagli COVIP COMMISSIONE DI VIGILANZA SUI FONDI PENSIONE. Quaderni tematici. In questo numero:
COVIP COMMISSIONE DI VIGILANZA SUI FONDI PENSIONE Quaderni tematici In questo numero: LA CENTRALITÀ DELLA COMUNICAZIONE NELLA PREVIDENZA COMPLEMENTARE Atti del Convegno - Bologna 19 settembre 2002 Quaderno Dettagli DEL BUSINESS PLAN. A cura del Gruppo di Lavoro. Area Finanza Aziendale. Consigliere Delegato: Marcello Danisi
LINEE GUIDA ALLA REDAZIONE DEL BUSINESS PLAN A cura del Gruppo di Lavoro Area Finanza Aziendale Consigliere Delegato: Marcello Danisi Consiglieri Co Delegati: Giosuè Boldrini e Enrico Maria Guerra 1 SOMMARIO Dettagli Credito Cooperativo Mediocrati Policy di Classificazione della Clientela
Credito Cooperativo Mediocrati Policy di Classificazione della Clientela 1 INDICE I. PREMESSA... 3 II. RIFERIMENTI NORMATIVI... 7 III. CLASSIFICAZIONE STATICA DELLA CLIENTELA... 10 IV. GESTIONE DELLA CLIENTELA Dettagli Le schede. Osservatorio sull Analisi d Impatto della Regolazione. L AIR nell Autorità Garante nelle Comunicazioni S 9/2014
Le schede Osservatorio sull Analisi d Impatto della Regolazione Miriam Giorgio L AIR nell Autorità Garante nelle Comunicazioni S 9/2014 marzo 2014 L AIR NELL AUTORITà GARANTE NELLE COMUNICAZIONI Variazioni Dettagli GRUPPO DI LAVORO ARTICOLO 29 PER LA PROTEZIONE DEI DATI
GRUPPO DI LAVORO ARTICOLO 29 PER LA PROTEZIONE DEI DATI 01037/12/IT WP 196 Parere 05/2012 sul cloud computing adottato il 1 luglio 2012 Il gruppo di lavoro è stato istituito in virtù dell articolo 29 della Dettagli REGOLAMENTO DI GESTIONE DELLE OPERAZIONI CON SOGGETTI COLLEGATI
REGOLAMENTO DI GESTIONE DELLE OPERAZIONI CON SOGGETTI COLLEGATI EDIZIONE NOVEMBRE 2010 Approvato dal Consiglio d Amministrazione in data 30 Novembre 2010 Indice Premessa...3 A. PARTE GENERALE...5 1. Inquadramento...5 Dettagli RESOCONTO STENOGRAFICO n. 7
Giunte e Commissioni XV LEGISLATURA RESOCONTO STENOGRAFICO n. 7 COMMISSIONE PARLAMENTARE di vigilanza sull Anagrafe Tributaria INDAGINE CONOSCITIVA SULLE MODALITÀ DI GESTIONE E UTILIZZO DEI DATI DELL ANAGRAFE Dettagli Il Project Risk Management. Introduzione
Il Project Risk Management Introduzione Gestire il rischio di un progetto significa occuparsi attivamente del suo successo. Un progetto è per sua natura uno sforzo complesso, temporaneo, innovativo, interdisciplinare, Dettagli Codice documento: CRS-LG-SIEE#02 Versione: 02.1 PVCS: Data di emissione: 29-02-2012 Stato: EMESSO
LI Sistema Informativo Socio Sanitario Documento di : Pubblico Dominio Sistema Informativo Socio Sanitario Linee guida Regionali per la Cartella Clinica Elettronica Aziendale Codice documento: CRS-LG-SIEE#02 Dettagli Introduzione alla gestione per processi nelle organizzazioni Piero De Risi, Università degli studi di Pisa
Introduzione alla gestione per processi nelle organizzazioni Piero De Risi, Università degli studi di Pisa 1. I cambiamenti in atto nelle esigenze organizzative aziendali Aumentare la produttività, riuscendo Dettagli AUTONOMIA STATUTARIA E RECESSO DEL SOCIO NELLE SOCIETÀ COOPERATIVE
RESEARCH REPORT N.003 11 AUTONOMIA STATUTARIA E RECESSO DEL SOCIO NELLE SOCIETÀ COOPERATIVE Antonio Fici, Università del Molise / Euricse AUTONOMIA STATUTARIA E RECESSO DEL SOCIO NELLE SOCIETA COOPERATIVE Dettagli PROCEDURE E LINEE GUIDA PER UNA CORRETTA ESECUZIONE DELLA VALUTAZIONE DEI RISCHI
PROCEDURE E LINEE GUIDA PER UNA CORRETTA ESECUZIONE DELLA VALUTAZIONE DEI RISCHI 1. ORIENTAMENTI GENERALI La valutazione dei rischi da parte del datore di lavoro e la predisposizione dei conseguenti documenti Dettagli ESITI DELLA CONSULTAZIONE SUL MANUALE DI VALUTAZIONE DELLA TERZA MISSIONE
ESITI DELLA CONSULTAZIONE SUL MANUALE DI VALUTAZIONE DELLA TERZA MISSIONE Approvato dal Consiglio Direttivo nella seduta del 1 aprile 2015 Premessa È stato posto in consultazione pubblica il Manuale per Dettagli PROFILO DI COMPETENZA: IL COORDINATORE ALLO SPECCHIO
COLLEGIO PROVINCIALE INFERMIERI PROFESSIONALI ASSISTENTI SANITARI VIGILATRICI D INFANZIA di Gorizia Aggiornamento ECM/FVG CONOSCERE PER CRESCERE PROFILO DI COMPETENZA: IL COORDINATORE ALLO SPECCHIO Relatori: Dettagli GUIDA ALLA REDAZIONE DEL. Business Plan
GUIDA ALLA REDAZIONE DEL Business Plan INDICE GENERALE 1. Il Business Plan 1.1 La funzione del Business Plan 1.2 Consigli per la predisposizione 2. L articolazione del Business Plan 2.1 L Executive summary Dettagli Risposta alla consultazione CONSOB sulle proposte di modifica al Regolamento Intermediari e al Regolamento Mercati per l attuazione della MiFID
Risposta alla consultazione CONSOB sulle proposte di modifica al Regolamento Intermediari e al Regolamento Mercati per l attuazione della MiFID 17 settembre 2007 POSITION PAPER Osservazioni alle proposte Dettagli PROJECT WORK PREMESSA. 1. IL SISTEMA DI SUPPORTO DELLA FORMAZIONE 1.1 I modelli applicabili 3. 1.2 Il Data Warehouse (DW) della formazione.
PROJECT WORK PROGETTAZIONE DELLE LINEE GUIDA PER UN SISTEMA DI SUPPORTO ALLA GESTIONE DEI PROCESSI FORMATIVI PREMESSA 1. IL SISTEMA DI SUPPORTO DELLA FORMAZIONE 1.1 I modelli applicabili 3 1.2 Il Data Dettagli Modelli di Sistemi di Produzione
Modelli di Sistemi di Produzione 2 Indice 1 I sistemi di produzione 1 1.1 Generalità............................. 1 1.2 I principi dei sistemi manifatturieri............... 4 1.3 Descrizione dei principali Dettagli ACOI Associazione Chirurghi Ospedalieri Italiani. Gruppo di Studio Medicina e Legalità. di equipe
ACOI Associazione Chirurghi Ospedalieri Italiani Gruppo di Studio Medicina e Legalità La responsa bilità nel lavoro di equipe ISTRUZIONI PER L USO Introduzione Tutti sanno, non solo i medici e gli operatori Dettagli LA RETE DI IMPRESE Istruzioni per l uso

References: art. 3
 art. 5
 art. 28
 art. 81
 art. 81
 art. 13
 articolo 76
 art. 85
 art. 23
 art. 8
 art. 29
 art. 29
 art. 81
 art. 40
 art. 13
 art. 20
 art. 3
 art. 94
 art. 3
 ARTICOLO 29
 ARTICOLO 29
 articolo 29