Archivio della categoria: Normativa

CAD e dintorni: Regole tecniche in materia di documenti informatici

Agenzia per l'Italia Digitale

Agenzia per l’Italia Digitale

Continua la serie di articoli volti ad approfondire gli aspetti del CAD di maggiore interesse per le aziende sanitarie. In questo  articolo si dà notizia del recente Decreto del Presidente del Consiglio dei Ministri che tratta di “Regole tecniche in materia di formazione, trasmissione, copia, duplicazione, riproduzione e validazione temporale dei documenti informatici nonché di formazione e conservazione dei documenti informatici delle pubbliche amministrazioni ai sensi degli articoli 20, 22, 23-bis, 23-ter, 40, comma 1, 41, e 71, comma 1, del Codice dell’amministrazione digitale di cui al decreto legislativo n. 82 del 2005.

Di cosa tratta il decreto?

Il decreto – art. 1 – fornisce una serie di definizioni – allegato 1 – e descrive alcuni formati di documenti utilizzabili – allegato 2 -. Nell’allegato 3 riporta una serie di standard tecnici per la  formazione, la gestione e la conservazione dei documenti informatici. Nell’allegato 4 e 5 riporta rispettivamente le specifiche tecniche del pacchetto di archiviazione e dei metadati.

Inoltre – art. 2 – il DPCM detta le regole tecniche per i documenti informatici, per i documenti amministrativi informatici e per il fascicolo informatico.

Quali le principali novità e gli aspetti salienti

Vale la pena di sottolineare una interessante novità riportata al comma 2 dell’art. 10 – Copie su supporto informatico di documenti amministrativi analogici – laddove si dice che “L’attestazione di conformita’ di cui al comma 1, anche nel caso di uno o piu’ documenti amministrativi informatici, effettuata per raffronto dei documenti o attraverso certificazione di processo nei casi in cui siano adottate tecniche in grado di garantire la corrispondenza del contenuto dell’originale e della copia, puo’ essere prodotta come documento informatico separato contenente un riferimento temporale e l’impronta di ogni copia. Il documento informatico prodotto e’ sottoscritto con firma digitale o con firma elettronica qualificata del funzionario delegato.”

Tale enunciate sembra aprire la strada ad una modalità di attestazione della conformità che si basa su una certificazione di processo piuttosto che su una verifica sistematica attuata documento analogico per documento analogico, con ovvie ricadute di migliore efficienza e gestibili del processo.

L’ art. 12 – Misure di sicurezza – afferma che “Il responsabile della gestione documentale ovvero, ove nominato, il coordinatore della gestione documentale predispone, in accordo con il responsabile della sicurezza e il responsabile del sistema di conservazione, il piano della sicurezza del sistema di gestione informatica dei documenti, nell’ambito del piano generale della sicurezza ed in coerenza con quanto previsto in materia dagli articoli 50-bis e 51 del Codice e dalle relative linee guida emanate dall’Agenzia per l’Italia digitale. Le suddette misure sono indicate nel manuale di gestione.”

Ribadendo in questo modo l’obbligatorietà delle misure di Business Continuity e Disaster Recovery dovute in base agli articoli 50-bis e 51 del CAD.  

All’ art. 14 – Formazione dei registri e repertori informatici – comma 2, si afferma che “Le pubbliche amministrazioni gestiscono registri particolari informatici, espressamente previsti da norme o regolamenti interni, generati dal concorso di piu’ aree organizzative omogenee con le modalita’ previste ed espressamente descritte nel   manuale   di gestione, individuando un’area organizzativa omogenea responsabile.”

Ciò sembra autorizzare le pubbliche amministrazioni a gestire registri informatici particolari che danno titolo a modellare flussi informatici che abbiano gestioni particolari rispetto all’ordinario flusso di protocollazione che caratterizza lo scambio di documenti al confine delle PA.

Tempi di attuazione ed adeguamento dei sistemi

All’art. 17 si precisa che “Il presente decreto entra in vigore decorsi trenta giorni dalla data della sua pubblicazione nella   Gazzetta   Ufficiale   della Repubblica italiana – NOTA BENE: il DPCM è stato pubblicato in GU il 12/01/2015 -. Le pubbliche amministrazioni adeguano i propri sistemi di gestione informatica dei documenti entro e non oltre diciotto mesi dall’entrata in vigore del presente decreto. Fino al completamento di tale processo possono essere applicate le previgenti regole tecniche. Decorso tale termine si applicano le presenti regole tecniche. Il presente decreto e’ inviato ai competenti organi di controllo e pubblicato nella Gazzetta Ufficiale della Repubblica italiana.”

NOTA BENE: quanto riportato nel presente articolo è un estratto da norme vigenti e non garantisce la completezza che solo il testo originale può garantire. Le considerazioni dell’autore devono essere considerate alla stregua di opinioni personali e quindi, prima di ogni possibile utilizzo, devono essere confrontate con altre fonti autorevoli e fede facenti. Verificare sempre i testi completi e originali delle norme citate ricorrendo alle fonti ufficiali tenendo conto di ogni possibile modifica o integrazione intervenuta successivamente alla redazione del presente articolo.

PG.

Il testo vigente del CAD è reperibile sul sito di AGID.

Licenza Creative Commons

Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Codice dell’amministrazione digitale e dintorni, parte 4 – il domicilio digitale

Agenzia per l'Italia Digitale

Agenzia per l’Italia Digitale

Continua la serie di articoli volti ad approfondire gli aspetti del CAD di maggiore interesse per le aziende sanitarie. In questo  articolo si approfondisce il tema del Domicilio Digitale.

Il testo vigente del CAD, all’articolo 3-bis, definisce il cosiddetto “Domicilio digitale del cittadino”:

Comma 1. Al fine di facilitare la comunicazione tra pubbliche amministrazioni e cittadini, è facoltà di ogni cittadino indicare alla pubblica amministrazione, secondo le modalità stabilite al comma 3, un proprio indirizzo di posta elettronica certificata, rilasciato ai sensi dell’articolo 16-bis, comma 5, del decreto-legge 29 novembre 2008, n. 185 [NOTA: il cosiddetto decreto Brunetta che permise ad ogni cittadino di richiedere una casella di posta certificata gratuita], convertito, con modificazioni, dalla legge 28 gennaio 2009, n. 2 quale suo domicilio digitale.

Comma 2. L’indirizzo di cui al comma 1 è inserito nell’Anagrafe nazionale della popolazione residente-ANPR e reso disponibile a tutte le pubbliche amministrazioni e ai gestori o esercenti di pubblici servizi. [NOTA: l’ANPR non è ancora attiva]

Comma 3. Con decreto del Ministro dell’interno, di concerto con il Ministro per la pubblica amministrazione e la semplificazione e il Ministro delegato per l’innovazione tecnologica, sentita l’Agenzia per l’Italia digitale, sono definite le modalità di comunicazione, variazione e cancellazione del proprio domicilio digitale da parte del cittadino, nonché le modalità di consultazione dell’ANPR da parte dei gestori o esercenti di pubblici servizi ai fini del reperimento del domicilio digitale dei propri utenti. [Vedi NOTA precedente]

Comma 4. A decorrere dal 1° gennaio 2013, salvo i casi in cui è prevista dalla normativa vigente una diversa modalità di comunicazione o di pubblicazione in via telematica, le amministrazioni pubbliche e i gestori o esercenti di pubblici servizi comunicano con il cittadino esclusivamente tramite il domicilio digitale dallo stesso dichiarato, anche ai sensi dell’articolo 21-bis della legge 7 agosto 1990, n. 241, senza oneri di spedizione a suo carico. Ogni altra forma di comunicazione non può produrre effetti pregiudizievoli per il destinatario.

Comma 4.-bis In assenza del domicilio digitale di cui al comma 1, le amministrazioni possono predisporre le comunicazioni ai cittadini come documenti informatici sottoscritti con firma digitale o firma elettronica avanzata, da conservare nei propri archivi, ed inviare ai cittadini stessi, per posta ordinaria o raccomandata con avviso di ricevimento, copia analogica di tali documenti sottoscritti con firma autografa sostituita a mezzo stampa predisposta secondo le disposizioni di cui all’articolo 3 del decreto legislativo 12 dicembre 1993, n. 39.

Come riporta un interessante articolo sul sito Agenda Digitale,  anche l’art. 14 del DL 69/2013 prevedeva il domicilio digitale:  “All’atto della richiesta del documento unificato, ovvero all’atto dell’iscrizione anagrafica o della dichiarazione di cambio di residenza a partire dall’entrata a regime dell’Anagrafe nazionale della popolazione residente, è assegnata al cittadino una casella di posta elettronica certificata, con la funzione di domicilio digitale, ai sensi dell’articolo 3-bis del codice dell’amministrazione digitale, successivamente attivabile in modalità telematica dal medesimo cittadino.”

Dato che l’articolo sembra rinviare l’operatività della disposizione alla entrata a regime dell’Anagrafe Nazionale della Popolazione Residente (ANPR) o del documento unificato, appare dubbia la sua applicabilità stante lo stato attuale delle realizzazioni.

In questo contesto caratterizzato da poche certezze e da molti lodevoli intenti, chiude i battenti anche la CEC PAC – la posta elettronica valida per il colloquio la Pubblica amministrazione istituita dal cosiddetto decreto Brunetta -. I motivi di ciò, secondo l’articolo disponibile sul sito di AGID, sono riconducibili al suo scarso successo, non avrebbe raggiunto gli obiettivi prefissati di diffusione e anche fra coloro che l’hanno attivata l’uso sarebbe molto basso, e sono riconducibili al fatto che essa offre meno possibilità di una casella di PEC ordinaria.

Alla luce di questo stato di attuazione assai parziale, viene da dire che molta strada rimane ancora da fare su questi temi perché possano essere considerati davvero strumenti utili di colloquio fra la Pubblica Amministrazione e il cittadino.

PG.

Il testo vigente del CAD è reperibile sul sito di AGID.

Altri articoli della stessa serie sono reperibili ai seguenti indirizzi:

Articolo
CAD e dintorni: semplificate le procedure per la firma grafometrica
Codice dell’amministrazione digitale e dintorni, parte 3 – la continuità operativa
Luci ed ombre del futuro Sistema Pubblico di Identità Digitale – SPID –
Codice dell’amministrazione digitale e dintorni, parte 2
Codice dell’amministrazione digitale e dintorni, parte 1

NOTA BENE: quanto riportato nel presente articolo è un estratto da norme vigenti e non garantisce la completezza che solo il testo originale può garantire. Le considerazioni dell’autore devono essere considerate alla stregua di opinioni personali e quindi, prima di ogni possibile utilizzo, devono essere confrontate con altre fonti autorevoli e fede facenti. Verificare sempre i testi completi e originali delle norme citate ricorrendo alle fonti ufficiali tenendo conto di ogni possibile modifica o integrazione intervenuta successivamente alla redazione del presente articolo.

PG.

Licenza Creative Commons
Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Il cloud in sanità, solo una promessa?

Microsoft in Health

Microsoft in health

Di tutto ciò che ho letto di recente sul cloud utilizzato per applicazioni sanitarie mi ha colpito soprattutto la vaghezza e la superficialità. Due, sopra tutti gli altri, sembrano essere i temi che vengono suggeriti con assillante ripetitività come fondamentali nello switch verso questa nuova tecnologia: la diminuzione dei costi – spesso desunta da settori merceologici affatto diversi – e la scalabilità – spesso proposta in termini drastici del tipo “oggi anche un solo utente e domani il mondo intero” -.

Tuttavia, talvolta, capita di leggere qualcosa di assai meno scontato. Nell’articolo che potete trovare a questo indirizzo, Hemant Pathak dà un breve sunto della relazione che assieme al suo collega di Microsoft ha tenuto allo “U.S. News & World Report’s Hospital of Tomorrow forum” di Washington.

Mi permetto di riassumere le affermazioni che più che mi hanno colpito del loro articolo:

  • il cloud e le tecnologie mobili stanno accelerando le opportunità di collaborazione fra clinici, pazienti ed organizzazioni sanitarie;
  • entro il 2020 l’internet delle cose – Internet of Things – comprenderà miliardi di dispositivi intelligenti in grado di raccogliere dati in maniera continua;
  • c’è una verità trasversale all’informatica e alla sanità: la gente non usa ciò di cui non si fida; da ciò deriva la considerazione che la più incredibile delle applicazioni sanitarie non sarà utilizzata se pazienti e professionisti non riterranno che i dati da essa trattati non saranno sicuri; nel caso di soluzioni cloud, i pazienti e i professionisti ritengono fondamentale poter controllare con chi i dati vengano condivisi e come vengano usati;
  • pertanto le dimensioni da considerare nella valutazione di una offerta cloud sono essenzialmente quattro: la sicurezza informatica – cybersecurity -, la garanzia della privatezza delle informazioni gestite – privacy -, la aderenza alle norme – compliance – e infine la trasparenza – trasparency –, cioè la disponibilità a rendere note tutte quelle informazioni che mettono in grado l’organizzazione cliente di prendere le decisioni opportune in materia.

Devo dire che mi trovo molto d’accordo.

Il problema dell’utilizzo del cloud in sanità non è, infatti, di tipo tecnologico in senso stretto, anche se è pur vero che esistono specificità dell’ambito sanitario che consigliano di prendere con le molle troppo generiche estrapolazioni di ragionamenti desunti da esperienze in altri settori merceologici – ad esempio dall’ambito dei servizi in genere -, ma è un problema di fiducia e di modelli di servizio.

Di fiducia, in quanto non posso pensare che l’azienda sanitaria che mi cura ceda a chicchessia i miei dati sanitari solo perché deve far quadrare il bilancio e una certa nuova tecnologia ha un costo inferiore.

Di modelli di servizio in quanto la tutela della privatezza del dato e la aderenza alla normativa non si inventano da un giorno all’altro, ma richiedono un duro lavoro e tanta esperienza da parte del fornitore dei servizi.

Quindi? Non riusciremo mai ad assistere all’avvento del cloud anche in sanità?

No, a mio parere è vero il contrario: nei prossimi anni assisteremo alla esplosione dell’utilizzo del cloud in sanità, ma occorrerà molta cautela nella scelta delle soluzioni possibili e molta pazienza nello spiegare cosa si sta facendo a cittadini e professionisti, che dovranno condividere le scelte che verranno fatte.

PG.
Licenza Creative Commons
Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Luci ed ombre del futuro Sistema Pubblico di Identità Digitale – SPID –

Ancora prima di nascere il nuovo sistema pubblico di identità digitale – SPID – già alimenta discussioni e per ogni convinto sostenitore che esso annovera, almeno un altrettanto convinto detrattore sembra potersi trovare.

Ma cosa è SPID ?

Leggendo la bozza di D.P.C.M. qui scaricabile all’art. 1, comma 1, punto u) leggiamo che SPID è il Sistema Pubblico dell’Identità Digitale, istituito ai sensi dell’articolo 64 del CAD, modificato dall’articolo 17-ter del decreto-legge 21 giugno 2013, n. 69, convertito, con modificazioni, dalla legge 9 agosto 2013, n. 98, al quale aderiscono le pubbliche amministrazioni e le imprese [omissis].

Secondo AGID il sistema SPID è costituito come insieme aperto di soggetti pubblici e privati che, previo accreditamento da parte dell’Agenzia per l’Italia digitale, gestiscono i servizi di registrazione e di messa a disposizione delle credenziali e degli strumenti di accesso in rete nei riguardi di cittadini e imprese per conto delle pubbliche amministrazioni.

Ma chi sono questi soggetti pubblici e privati che gestiscono l’identità digitale ?

Sempre nella bozza di D.P.C.M. all’art 1, comma 1, punto l), leggiamo che i gestori dell’identità digitale sono “le persone giuridiche accreditate allo SPID che. previa identificazione certa dell’utente, assegnano, rendono disponibili e gestiscono gli attributi utilizzati dal medesimo utente al fine della sua identificazione informatica. Essi inoltre, in qualità di gestori di servizio pubblico, forniscono i servizi necessari a gestire l’attribuzione dell’identità digitale degli utenti, la distribuzione e l’interoperabilità delle credenziali di accesso, la riservatezza delle informazioni gestite e l’autenticazione informatica degli utenti;”

Ci si potrebbe chiedere come avvenga l’autenticazione informatica degli utenti a cura dei gestori dell’identità digitale. L’identificazione avviene per inserimento di un codice identificativo e di una credenziale di accesso così definite – punti g) e h) del D.C.P.M. -:

g) codice identificativo: il particolare attributo assegnato dal gestore dell’identità digitale che consente di individuare univocamente un’identità digitale nell’ambito dello SPID;

h)  credenziale di accesso: il particolare attributo di cui l’utente si avvale, unitamente al codice identificativo; per accedere in modo sicuro, tramite autenticazione informatica, a
i servizi qualificati erogati in rete dalle pubbliche amministrazioni e dalle imprese che aderiscono allo SPID.

Nella bozza delle specifiche di SPID messa a disposizione da AGID possiamo rintracciare questo schema che illustra il processo di autenticazione per mezzo del quale è possibile avere accesso ad un determinato servizio informatico:

Autenticazione SPID

Scheda di Autenticazione SPID tratto dalla bozza di specifiche tecniche delle interfacce SPID messo a disposizione da AGID

Tuttavia, affinché il service provider possa fattivamente erogare il servizio occorrerà che il titolare di una certa identità digitale sia caratterizzato da alcuni attributi che ne specificano le caratteristiche peculiari. Queste caratteristiche sono implementate attraverso attributi così definiti – punti b), c), d) ed e) del D.P.C.M. -:

b) attributi: informazioni o qualità di un utente utilizzate per rappresentare la sua 
identità, il suo stato, la sua forma giuridica o altre caratteristiche peculiari;

c) attributi identificativi: nome, cognome, luogo e data di nascita, sesso, ovvero ragione o denominazione sociale, sede legale, nonché il codice fiscale o la partita IVA e gli estremi del documento d’identità utilizzato ai fini dell’identificazione;

d) attributi secondari: il numero di telefonia mobile, l’indirizzo di posta elettronica, il domicilio fisico e digitale, nonché eventuali altri attributi individuati dal17Agenzia, funzionali alle comunicazioni;

e) attributi qualificati: le qualifiche, le abilitazioni professionali e i poteri di rappresentanza e qualsiasi altro tipo di attributo attestato da un gestore di attributi qualificati;

Sempre secondo il D.P.C.M. l’Agenzia per l’Italia Digitale cura l’attivazione dello SPID, gestisce l’accreditamento dei gestori dell’identità digitale e dei gestori di attributi qualificati, stipulando con essi apposite convenzioni, cura l’aggiornamento del registro SPID e svolge funzioni di vigilanza e controllo sull’operato dei soggetti che partecipano allo SPID.

Il registro tenuto da AGID è accessibile al pubblico e contiene l’elenco dei soggetti abilitati a operare in qualità di gestori dell’identità digitale, dei gestori degli attributi qualificati e di fornitori di servizi.

Fino a qua lo scenario per quanto articolato non sembra prestare il fianco a particolari critiche. Ma se andiamo a leggere un commento come quello dell’avvocato Eugenio Prosperetti riportato in “Ma lo SPID non ci identifica” capiamo che la cosa è un po’ più complessa di come sembra.

In tale articolo si precisa – a mio parere a ragione – che l’identità digitale gestita da SPID serve principalmente ad ottenere l’accesso ai servizi della P.A. e non necessariamente ha la finalità di permettere atti dispositivi. Sostanzialmente si afferma che una cosa è dire che è stata accertata – attraverso i meccanismi di SPID – la nostra identità digitale, altra cosa è affermare che quella identità digitale abbia tali e tante garanzie alle spalle da poter avere – ad esempio – la stessa valenza di una firma, con la quale disporre ed ordinare – atti dispositivi -.

Ma quali conseguenze possiamo derivare da tali considerazioni?

La prima è forse più importante conseguenza è che una autenticazione andata a buon fine in SPID non può essere garanzia, di per sé, che un servizio sia erogabile: dipenderà infatti da quale sia il servizio richiesto e da quali siano le caratteristiche dell’identità digitale richiedente.

Potranno esistere servizi che non richiedono particolari livelli di sicurezza che potranno essere erogati senza particolari cautele, ma altri servizi richiederanno caratteristiche più stringenti all’identità digitale per poter essere erogati.

Pensando all’ambito sanitario, quindi a contesti che molto spesso prevedono il trattamento di dati sensibili, ci si chiede quali dovranno essere i requisiti minimi che dovranno essere garantiti per poter erogare i requisiti richiesti.

Un esempio potrà forse aiutare a fissare le idee: si supponga che un’azienda ospedaliera decida di affacciare un servizio in internet per il rilascio delle copie conformi di cartella clinica. Il paziente che abbia subito un ricovero nella struttura ospedaliera potrà, una volta autenticato, richiedere il rilascio della copia conforme della propria cartella clinica e quando questa sia pronta potrà scaricarla direttamente sul proprio PC.

La consegna della copia conforme di una cartella clinica è un’operazione che richiede l’identificazione del consegnatario – oggi allo sportello si viene identificati per poter ricevere la copia -, quindi sarà necessario che l’identità digitale del cittadino abbia un valore identificativo – per poter ottenere la consegna della copia di cartella – e di firma – per poterla richiedere -. Sarà, pertanto, necessario che l’identità SPID sia stata assoggettata al massimo livello di autenticazione gestibile.

Viene da pensare che ciò sia ottenibile solo a fronte di un rilascio di credenziali SPID da parte di un gestore dell’identità digitale che abbia riconosciuto de visu il paziente, che abbia cioè adottato le modalità più stringenti di rilascio delle credenziali. In altri termini è pensabile che credenziali ottenute in maniera più agevole e che sarebbero adeguate per fruire di servizi meno sensibili non siano utilizzabili.

Viene quindi da concludere che molti dei servizi che si potrebbero ottenere dal Servizio Sanitario Nazionale aderendo a SPID dovranno confrontarsi con lo stesso scoglio che hanno dovuto superare tutti gli altri progetti di accesso a servizi eHealth oggi messi in campo: portare il cittadino ad uno sportello per riconoscerlo de visu e rilasciargli una credenziale forte che permetta il trattamento di dati sensibili quali quelli sanitari.

La vera, grossa, novità è che una volta ottenute queste credenziali potrebbero servire per ogni possibile accesso di rango inferiore grazie alla interoperabilità garantita da SPID. In un futuro, speriamo non troppo lontano, potrò forse accedere al mio fascicolo sanitario elettronico con le credenziali rilasciate dalla mia banca, chissà se potrò anche fare home banking con le credenziali rilasciate dall’azienda sanitaria per l’accesso al FSE.

Abbiamo di fronte scenari certamente stimolanti.

PG.

Licenza Creative Commons
Quest’opera è distribuita con Licenza Creative Commons Attribuzione 3.0 Italia.

Pertinenza e Non Eccedenza, un possibile modello

La gestione della pertinenza e non eccedenza dei trattamenti – secondo quanto disposto dal codice privacy – nei sistemi informativi sanitari è un tema complesso e ancora oggetto di interpretazioni divergenti.

Quello che qui si propone è un modello per garantire il rispetto dei principi di pertinenza e non eccedenza che tende, da un lato, a tutelare i diritti del paziente pur senza costringerlo ad ogni piè sospinto a dichiarare le proprie intenzioni, dall’altro, attraverso il concetto di “percorso di cura” si intende gestire una politica di accesso al dato che sia coerente con la sensibilità dei professionisti e con le reali necessità di cura.

Il modello, ben lungi dall’essere definitivo, vuole essere un punto di partenza per una discussione che miri a definire opzioni realmente implementabili ed usabili.

PG.

Il modello di consenso previsto nel FSE

HL7logo

AGID

 

Con la emanazione delle “Linee guida per la presentazione dei piani di progetto regionali per il FSE” da parte di AgID e Ministero della Salute – così come previsto dalla Legge n°98/2013, conversione del DL 179/2012 – si è posto un importante tassello non solo per la costituzione del Fascicolo Sanitario Elettronico, ma anche per la modellazione dei sistemi informativi sanitari conferenti informazioni alle infrastrutture di FSE.

Detta linea guida trae le mosse da due importanti lavori pubblicati nella apposita sezione del sito di HL7 Italia:

In questo articolo, in particolare, viene preso in esame il modello di consenso privacy previsto in questi documenti e le ricadute che un tale modello può avere per i sistemi informativi delle aziende sanitarie che dovranno conferire dati e documenti alla infrastruttura regionale di FSE.

Le linee guida prevedono diversi livelli di consenso, di seguito descritti.

Consenso alla alimentazione dell’FSE

Il FSE può essere alimentato solo con consenso esplicito, libero e informato reso dall’assistito o di chi lo rappresenta a seguito della visione della relativa informativa. Il consenso all’alimentazione del FSE, anche se manifestato unitamente a quello previsto per il trattamento dei dati a fini di cura all’interno dell’Azienda Sanitaria, deve essere autonomo e specifico. (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

NOTA BENE: occorre tenere presente che il cittadino deve poter acconsentire, o meno, anche al caricamento nell’FSE di dati pregressi alla fornitura di questo consenso, per cui – nella pratica – occorrerà chiedere al cittadino se intende autorizzare l’alimentazione dell’FSE da quel momento in avanti, ma anche se intende permettere il caricamento dei dati pregressi al consenso. PG.

Consenso alla consultazione dell’FSE

La consultazione dei dati e dei documenti presenti nel FSE, da parte dei MMG/PLS o degli operatori e professionisti sanitari e socio-sanitari che abbiano necessità di trattare i dati per finalità di cura, può avvenire solo previo consenso libero ed informato espresso dell’assistito. (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

Accesso all’FSE in emergenza

Deve essere garantito l’accesso in emergenza. Nello specifico, un professionista sanitario o del sociale, anche se non ricopre il ruolo per il quale è stata abilitata la consultazione (sulla base delle policy di visibilità indicate dall’assistito), può consultare le informazioni rese visibili dall’assistito, ossia, i dati e documenti non devono essere stati oscurati o essere stati anonimizzati da parte dell’assistito. Per ogni accesso in emergenza, il professionista deve fornire esplicita dichiarazione sottoscritta. Resta inteso che l’accesso in emergenza può essere effettuato solo se l’assistito ha espresso il consenso alla consultazione del FSE.  (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

Consenso per minore o sottoposto a tutela

Nel caso di assistito di minore età o sottoposto a tutela, sia il consenso all’alimentazione sia il consenso alla consultazione devono essere espressi dal soggetto che esercita la potestà o da colui che lo rappresenta legalmente, in qualità di tutore, amministratore di sostegno o altra legittimazione. Al raggiungimento della maggiore età, sia il consenso all’alimentazione che il consenso alla consultazione devono essere confermati da un’espressa dichiarazione di volontà del neo- maggiorenne, da rilasciarsi dopo aver preso visione dell’informativa. I consensi precedentemente resi devono essere automaticamente invalidati in attesa che il neo-maggiorenne esprima i nuovi consensi. (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

Consenso per dati a maggior tutela dell’anonimato

I dati e i documenti sanitari e socio-sanitari a maggior tutela dell’anonimato – dati relativi a sieropositività, interruzione volontaria di gravidanza, violenza, assunzione di sostanze stupefacenti/psicotrope/alcool, servizi offerti da consultori familiari – possono essere resi visibili previo consenso esplicito reso dall’assistito. E’ responsabilità dei professionisti o degli operatori sanitari che erogano la prestazione acquisire l’esplicito consenso dell’assistito. Inoltre, se l’assistito sceglie di ricorrere alle prestazioni in anonimato, tali dati e documenti non devono confluire nel FSE. (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

Oscuramento di dati e documenti

L’assistito può decidere, nel momento dell’accettazione, in sede di refertazione oppure in una fase successiva all’alimentazione, se e quali dati e documenti, creati in occasione delle singole prestazioni erogate, non devono essere resi visibili (ossia oscurati) nel proprio FSE senza che vi sia evidenza di tale scelta in fase di consultazione (oscuramento dell’oscuramento). I dati e i documenti oscurati devono essere consultabili solo dall’assistito e dal titolare che lo ha generato (ossia, l’autore del dato/documento). L’assistito ha comunque facoltà di rendere nuovamente visibile un dato o documento precedentemente oscurato. (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

Revoca dei consensi

Le forme di consenso precedentemente citate possono essere revocate. La revoca del consenso all’alimentazione determina l’interruzione dell’alimentazione del FSE senza conseguenze rispetto all’erogazione delle prestazioni del servizio sanitario e dei servizi socio-sanitari. Se il paziente revoca il consenso alla alimentazione e successivamente esprime un nuovo consenso (reso in forma esplicita, libera ed informata), vengono resi nuovamente visibili nel FSE i dati e i documenti che lo hanno alimentato fino alla precedente revoca del consenso alla alimentazione, in accordo con le regole di visibilità precedentemente impostate dall’assistito. Il FSE viene comunque alimentato da eventuali correzioni dei dati e dei documenti che lo hanno composto fino alla revoca del consenso, da parte degli organismi sanitari che li hanno generati e che mantengono la titolarità. I dati e documenti prodotti durante il periodo di revoca del consenso alla alimentazione del FSE non sono automaticamente inseriti a seguito del nuovo consenso. La revoca del consenso alla consultazione determina invece l’interruzione dell’accesso per la consultazione dei dati e documenti presenti nel FSE da parte dei MMG/PLS e degli operatori sanitari e socio-sanitari, inclusi gli operatori in emergenza. (TESTO ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica)

Schema riassuntivo delle diverse casistiche di consenso

Consenso all’alimentazione

Revoca del consenso all’alimentazione

Consenso alla consultazione

Il FSE viene alimentato.
Il FSE può essere consultato dall’assistito e dagli operatori il cui ruolo rispetta le policy di visibilità indicate dallo stesso. In caso di emergenza, l’accesso alle informazioni rese visibili dall’assistito – non oscurate o non anonimizzate – è consentito a tutti gli operatori che devono comunque esprimere esplicita dichiarazione di necessità di consultazione.

Il FSE non viene più alimentato, salvo per eventuali correzioni di dati e documenti che hanno composto il FSE prima della revoca.

Dati e documenti che hanno composto il FSE prima della revoca possono essere consultati dall’assistito e dagli operatori il cui ruolo rispetta le policy di visibilità indicate dallo stesso. In caso di emergenza, l’accesso alle informazioni rese vinili dall’assistito è consentito a tutti gli operatori che devono comunque esprimere esplicita dichiarazione di necessità di consultazione.

Revoca del consenso alla consultazione

Il FSE viene alimentato.
Il FSE può essere consultato solo dall’assistito e non può essere consultato dagli operatori sanitari e socio-sanitari, neanche in caso di emergenza.

Il FSE non viene più alimentato, salvo per eventuali correzioni di dati e documenti che hanno composto il FSE prima della revoca.

Dati e documenti che hanno composto il FSE prima della revoca possono essere consultati dall’assistito.
Il FSE non può essere consultato dagli operatori sanitari e socio-sanitari, neanche in caso di emergenza.

NOTA BENE: lo schema sopra riportato è stato ADATTATO DALLA LINEA GUIDA, si prega di fare riferimento al documento originario per confronto e verifica.

E’ quindi plausibile che le applicazioni aziendali che raccolgono dati e documenti che devono essere conferiti all’FSE – in cooperazione applicativa – debbano gestire questi consensi:

  1. consenso al trattamento specifico per l’episodio di cura – o recepimento della volontà del cittadino di oscurare/anonimizzare l’episodio sul sistema informativo aziendale -;
  2. consenso al conferimento all’FSE; NOTA BENE: di base tale consenso al conferimento dovrà essere negato per i dati soggetti a maggior tutela dell’anonimato, salvo diversa intenzione del cittadino; il cittadino potrà oscurare un qualsiasi conferimento all’FSE che di base sarebbe autorizzato per dati sensibili ordinari;
  3. eventuale verifica della policy di accesso al dato su FSE da parte del professionista nel caso l’accesso all’FSE avvenga in cooperazione applicativa; VEDI NOTA del successivo punto 2. dell’FSE;
  4. consenso all’accesso in emergenza all’FSE con raccolta della motivazione fornita dal professionista.

L’FSE – che sia in cooperazione applicativa con una certa realtà aziendale – dovrà invece gestire i seguenti consensi:

  1. consenso all’alimentazione dell’FSE e consenso all’eventuale caricamento dei dati sensibili esistenti pregressi alla fornitura del consenso alla alimentazione;
  2. consenso alla consultazione dell’FSE da parte di specifiche categorie di professionisti sanitari che operino dall’interno dell’azienda; NOTA BENE: la verifica delle policy di consultazione dell’FSE da parte dei professionisti potrebbe essere demandata ai sistemi informativi della aziende sanitarie che siano connessi in cooperazione applicativa;
  3. oscuramento/anonimizzazione di dati precedentemente conferiti.

Entrambi gli ambiti dovranno poter gestire la revoca dei consensi precedentemente forniti e i consensi per minori e i soggetti sottoposti a tutela.

Pur da una rapida analisi come quella sopra proposta, lo scenario complessivo risulta non di semplice realizzazione e gestione e non privo di ricadute per i sistemi informativi aziendali che debbano interoperare con un FSE.

PG.

Il software in ambito sanitario, la sfida e l’opportunità

Si è recentemente svolta presso l’Arcispedale S.Anna di Cona (FE) una interessante iniziativa che  ha visto la partecipazione di numerosi colleghi che operano nell’ambito dei dispositivi medici e del software sanitario.

L’occasione è stata propizia per discutere della non semplice applicazione della variegata normativa che regola il software usato in ambito sanitario, a partire dalla sua classificazione così come proposto dalla linea guida CEI  alla gestione del software e delle reti IT-medicali nel contesto sanitario – linea guida ancora non definitiva ed attualmente sottoposta ad inchiesta pubblica -.

Io ho avuto il piacere di portare il mio contributo con una relazione tesa a sintetizzare i principali vincoli normativi dai quali non si può prescindere quando ci ci trovi ad operare in un contesto così critico come quello sanitario.

L’auspicio con il quale ci siamo lasciati è che esistano altre occasioni nelle quali sviluppare i temi che l’incontro ha posto all’attenzione di tutti noi.

PG.