1 . Premessa

Le relazioni che legano gli argomenti di seguito trattati - approccio ai problemi dell'Information and Communication Technology (ICT) rispetto a privacy e security nei sistemi di welfare sanitario - sono oggi quanto mai complesse e di difficile illustrazione in un evento così denso di temi e problematiche come quello odierno. La complessità è ancora maggiore se si tiene conto dell'estrema dinamicità che connota il mondo dell'ICT in sanità nonché della variabilità di aspetti che la sanità oggi offre nel quadro della riforma regionalista del Titolo V della Costituzione.

E' parso comunque opportuno utilizzare l'occasione offerta per sottolineare come una corretta interpretazione di tali relazioni, oltre a costituire un doveroso adempimento di quanto previsto dalla legge nazionale, può costituire una risorsa molto significativa per i cittadini e per le strutture del servizio sanitario nazionale.

A patto di non dimenticare ciò che si è detto prima: si tratta di relazioni complesse in cui il privilegio di una variabile tende inevitabilmente a compromettere l'efficienza (ma anche l'efficacia) delle altre variabili in gioco. E' dunque necessario a nostro parere tenere bene in mente, prima di iniziare, alcuni concetti che cercheremo di illustrare nel corso della presente relazione:

PRIMO CONCETTO:

"la privacy è un diritto riconosciuto dalla Stato italiano a tutti i cittadini" al tempo stesso "il diritto alla privacy è regolamentato da norme e si esercita nell'ambito di possibilità tecniche e disposizioni organizzative e operative"

SECONDO CONCETTO:

"la security è uno strumento indispensabile sia per garantire la privacy sia per garantire la sopravvivenza e l'efficienza delle organizzazioni che devono assicurare il diritto alla privacy"

TERZO CONCETTO:

"privacy e security devono convivere permettendo tanto al cittadino quanto all'organizzazione di agire secondo criteri di standard di prestazione (performance standards)"

QUARTO CONCETTO:

"le operazioni per garantire la privacy in un quadro di sicurezza devono essere pianificate e monitorate comprendendo non solo i costi di investimento ma anche i costi operativi"

Il seguito di questa relazione esaminerà come i 4 concetti sopra richiamati si applichino all'utilizzo delle ICT nel quadro del sistema sanitario con un esempio derivato dall'approccio della Toscana al tema generale della sicurezza informatica.

La definizione di privacy che ci interessa deriva per l'Italia direttamente dalla legge 675/96 e successive modifiche, integrazioni e disposizioni del Garante e attiene, nello specifico di questa relazione, all'applicazione degli art.1, 2, 15, 22 e 23 della stessa legge. Per tale definizione, che sempre nel contesto della relazione si applica al trattamento dei dati personali (e "personali sensibili") da parte dei soggetti del Servizio sanitario¹ tramite ICT, si rimanda al disposto normativo e al quadro delle decisioni del Garante, evidenziando unicamente che la privacy assume per noi un contorno a più strati:

- quello relativo all'acquisizione del dato in relazione alle modalità di acquisizione del dato stesso

- quello relativo alla gestione del dato da parte di chi lo ha acquisito

- quello relativo alle modalità di accesso al dato da parte del soggetto proprietario del dato stesso

- quello relativo all'uso del dato da parte di soggetti diversi dal 'primo acquisitore', ai relativi profili di legittimità, e al combinato delle variabili sopra esposte nel caso i dati siano trattati da più soggetti nel loro 'ciclo di vita'

La definizione di security qui affrontata è circoscritta alla previsione dell'art.15 della legge 675/96 e attiene, nello specifico, alla "messa in sicurezza" degli archivi e dei circuiti informativi attraverso i quali sono ospitati o trasmessi dati personali oggetto della legge stessa.

La definizione di standard di prestazione (di performance) non è derivabile da alcuna legge in materia di privacy se non, indirettamente, dall'interpretazione dello stesso art.15. Valgono invece le disposizioni che regolano l'attività della Pubblica Amministrazione in generale (es.: L.241/90), in materia di contratti di fornitura (ad es.: L.R.12/2001), etc.

Osserviamo che:

- per l'oggetto privacy gli elementi definitori, per quanto complessi, riescono a delimitare in modo sostanziale il quadro degli interventi in materia di ICT ad un'unica problematica, quella della "titolarità" di un determinato ruolo nel percorso che fanno i dati personali dall'origine al termine, previsto dalla legge, della loro necessità di esistere - "titolarità" che ben si presta in ambito ICT ad essere da un lato ridefinita in termini di "profilo d'accesso" (con tutti i necessari attributi) alla tecnologia che tratta i dati, da un altro lato ad essere convogliata su specifici elementi di supporto che connotano il titolo di accesso ai dati (passwords, smart cards, etc.)

- per l'oggetto security il problema è di precisare in cosa consiste effettivamente la "messa in sicurezza" degli elementi tecnologico-informativi che permettono il trattamento dei dati. In sintesi, scorrendo molto rapidamente una specie di orange book² della sicurezza:

• i dati devono essere trattati solo da personale o procedure che siano legittimati a farlo: devono esistere dunque ulteriori procedure che permettano di acquisire e riscontrare i titoli di legittimità indicati per il livello privacy

• i dati devono essere mantenuti all'interno di supporti adeguati alla protezione contro intrusioni tecnologiche (interne o esterne) finalizzate alla visualizzazione/uso/asportazione dei dati stessi

• i medesimi supporti non devono altresì permettere intrusioni esterne finalizzate al danneggiamento tecnologico degli apparati e dei dati ivi contenuti

• la trasmissione o i cicli di trasmissione telematici (A/R) dei dati devono essere attentamente programmati utilizzando sistemi di certificazione, canali sicuri, eventualmente metodi di crittografazione a seconda della tipologia del canale e del livello di riservatezza dei dati in questione

e, inoltre,

• i dati devono essere trattati e archiviati su supporti che permettano il loro mantenimento in stato di efficienza e congruenza - nella modalità con cui è previsto che siano trattati o archiviati - per tutta la durata prevista dalla norma o disposizione che ne ha autorizzato e avviato il trattamento: ciò anche in presenza di errori umani, tecnici o procedurali che attentino all'integrità del dato o dell'apparato su cui il dato è gestito

• la logistica dei siti e degli apparati dove i dati sono mantenuti nonché dei canali attraverso i quali sono trasmessi deve permettere il superamento senza danni di incidenti fortuiti, attacchi dolosi o eventi catastrofici (incendi, terremoti, etc.)

- per l'oggetto standard di prestazione, infine, si tratta di definire con chiarezza una serie di "metriche" attraverso le quali misurare lo scarto tra processi implementati e attese prescritte o negoziate, stabilendo in base a tale rilevazione le misure da adottare per eliminare o contenere l'eventuale scarto. Posto che in tale quadro il problema principale è rappresentato dalla variabile "tempo di esecuzione" (di una prestazione, di un processo, etc.) lo standard va definito tanto rispetto ai processi interistituzionali

• in relazione alle norme (tipici, ad esempio, di procedure soggette alla L.241 /90)

• in relazione alla schedulazione dei processi in base a disposizioni amministrative/operative (citiamo tra tutti il flusso di dati - personali e sensibili - istituito dal Ministero della Salute in relazione alle schede di dimissione ospedaliera)

quanto per le relazioni Cittadino-Servizio sanitario.

3. ANALISI DEL PRIMO CONCETTO

"La privacy è un diritto riconosciuto dalla Stato italiano a tutti i cittadini" al tempo stesso "il diritto alla privacy è regolamentato da norme e si esercita nell'ambito di possibilità tecniche e disposizioni organizzative e operative".

Nel sistema italiano di welfare sanitario - meglio sarebbe forse dire, oggi, nell'insieme dei sistemi regionali e nazionale di welfare sanitario operanti in Italia - le operazioni di sistema informativo basate sull'impiego di ICT si svolgono con l'acquisizione, lo stoccaggio, l'elaborazione, la selezione, l'incrocio, il recupero, la cancellazione e il trasferimento di dati personali (e "personali sensibili") dei cittadini. La garanzia della privacy in tale contesto è quanto mai difficile, poiché le esigenze dei soggetti 'gestori' dei dati si sommano ed incrociano in modo quasi indistinguibile durante i processi di trattamento dei dati stessi e, anzi, tendono naturalmente a integrarsi per finalità di efficienza e contenimento dei costi. Definita la norma, dunque, la sua applicazione è demandata non solo ad ulteriori aspetti regolamentari caratteristici dell'introduzione della norma nelle singole organizzazioni ma, nel nostro caso:

- alle possibilità tecniche di operare un corretto controllo dell'applicazione della norma in tutti i cicli di trattamento del dato, sia che essi siano gestiti direttamente sia che essi siano trasferiti ad altre organizzazioni per ulteriori livelli di trattamento.

- alle disposizioni organizzative ed operative che si devono adottare durante i cicli di trattamento dei dati (anche qui: interni ed esterni all'organizzazione procedente)

Le due fattispecie segnalate configurano, nei trattamenti basati su ICT, la necessità di disporre di procedure informatiche e telematiche che consentano un rigoroso controllo e monitoraggio delle "titolarità" (di un soggetto o di un'altra procedura) nell'esecuzione di un'operazione di trattamento dati personali. Questo si traduce nella repertoriazione dei dati e delle procedure di trattamento dei dati stessi. A ciò fa seguito la pre-definizione, tramite apposite disposizioni che si traducono nell'implementazione/aggiornamento di archivi e procedure di controllo, di specifici "profili d'accesso" assegnati agli operatori e/o alle procedure coinvolti nei trattamenti indicati. Ogni profilo o classe di profili reca conseguentemente con sé, durante la fase operativa, la determinazione degli "attributi" di accesso ai dati e solo per quegli attributi si consente al soggetto o alla procedura di accedere alla porzione di dati necessari al trattamento del quale sono incaricati. Come è evidente, tale livello di controllo è abbastanza facile da progettare ed implementare all'interno di una singola organizzazione, molto più difficile, come premesso, quando i dati viaggiano - anche legittimamente - da un'organizzazione ad un'altra. Nel secondo caso gli unici livelli di controllo possibili risultano essere:

- quello sulla verifica di titolarità in ricezione ("ti invio un dato se sono certo che sei proprio tu, con un determinato profilo di titolarità, a riceverlo")

- quello sulla determinazione/verifica delle regole che l'organizzazione ricevente adotta per garantire a sua volta la privacy dei dati ("ti invio un dato se le tue regole coincidono con le norme e se sono allineate alle mie regole di trattamento dei dati")

4. ANALISI DEL SECONDO CONCETTO

"La security è uno strumento indispensabile sia per garantire la privacy sia per garantire la sopravvivenza e l'efficienza delle organizzazioni che devono assicurare il diritto alla privacy".

Da quanto sopra esposto sia in relazione ai termini generali del problema sia rispetto alla privacy assurance nell'impiego di ICT in Sanità, pensiamo inizi ad essere più evidente come per garantire la privacy ogni organizzazione che opera trattamenti informatici e telematici di dati personali debba definire e implementare una propria "politica di sicurezza" non solo in tutti i cicli di trattamento dei dati stessi ma come salvaguardia del proprio patrimonio informativo e del proprio know-how tecnico e operativo. Nessuna privacy di dati personali è possibile, ad esempio, se anche un solo personal computer (molto di più se si tratta di una macchina con funzioni di "server") di un'organizzazione è collegato ad una rete con la possibilità di accedere ad archivi 'sensibili' e tale computer non è protetto da appositi sistemi o procedure:

- quando la macchina viene avviata (protezione di accesso all'unità di elaborazione)

- quando la macchina viene momentaneamente abbandonata dopo essere stata avviata (protezione da intrusioni materiali della macchina, del software di base, di singole procedure, di singoli archivi, etc.)

- quando la macchina è attaccata da una procedura esterna che mira ad utilizzarla come "ponte" verso altre macchine (protezione da intrusioni informatiche, spamming, etc.)

- quando la macchina è attaccata da una procedura esterna che vuole danneggiarla/distruggerla o usarla come veicolo per il danneggiamento o la distruzione di altre macchine (protezione da virus, "cavalli di Troia ", etc.)

- quando la macchina si collega alla rete di appartenenza o ad altre reti (verifica dei diritti di accesso ed uso dell'operatore e della procedure, protezione del canale di trasmissione, protezione del sistema di accesso alla rete tramite sottosistemi proxy e firewall, protezione da lettura/utilizzo dei dati trasmessi tramite crittografazione, etc.)

- quando la macchina è soggetta a malfunzionamenti derivati dalla macchina stessa, dalle sue procedure, da procedure dell'organizzazione o da procedure di altre organizzazioni che, anche senza intento doloso, possono comprometterla o compromettere il circuito informativo a cui la macchina appartiene (protezione attiva del tipo "fault tolerance")

- quando la macchina è soggetta a crash di tipo elettrico, logistico, etc. (protezioni attive tramite Unità di Continuità elettrica, backup periodici dei dati e delle procedure, raddoppio delle unità che gestiscono procedure o archivi di livello critico, dislocazione delle unità di elaborazione e stoccaggio in differenti locali o in differenti edifici, sicurezza attiva nel controllo degli accessi agli edifici, etc.)

Ai livelli sopra indicati di security se ne è aggiunto abbastanza recentemente un altro, quello che permette di accertare, tramite l'erogazione ad una singola persona di uno specifico "certificato digitale" da parte di un soggetto a ciò abilitato in base a norme nazionali:

- la reale identità del soggetto in relazione alla redazione di un documento elettronico di qualunque contenuto, alla sua trasmissione, al suo recupero, etc. (certificato digitale a firma debole, c.d. "certificato di sicurezza")

- la legalità della firma apposta dal soggetto ad un documento elettronico di qualunque contenuto (certificato digitale a firma forte, c.d. "certificato di firma")

- il momento (data, ora, minuti, secondi, etc.) in cui il documento elettronico è stato completato e firmato (certificazione di "time stamping" erogata preferibilmente da un Ente terzo certificatore)

L'implementazione di uno o più dei sistemi sopra indicati nei vari livelli di operatività delle organizzazioni che trattano tramite ICT dati sanitari sensibili costituisce il nucleo della politica di sicurezza delle organizzazioni stesse ed è in diretta relazione con gli ultimi due concetti: livello di performance e compatibilità economica.

5. TERZO CONCETTO

"privacy e security devono convivere permettendo tanto al cittadino quanto all'organizzazione di agire secondo criteri di standard di prestazione (performance standards)"

In sostanza, come indicato nella premessa a questa relazione, ogni azione in ambito ICT che introduce controlli finalizzati alla politica di sicurezza tende ad aumentare in relazione diretta il livello di privacy ma tende a diminuire in relazione inversa il livello di performance con cui il sistema informatico o telematico gestisce i dati. Ciò sia sotto il profilo della progettazione che sotto il profilo dell'implementazione e della manutenzione dei sistemi coinvolti. E' intuitivo comprendere che l'accesso ad un archivio (ma anche le operazioni su tale archivio) è tanto più rapido quanto minori sono i livelli di protezione dell'archivio stesso, e questo sia che l'accesso ad un archivio sia di tipo "manuale" sia che si tratti di una procedura informatica che richiede l'utilizzo dell'archivio in parola. Il problema non ha, anche qui intuitivamente, una soluzione valida per ogni tipologia di trattamento ma deve essere inquadrato in una politica di accesso regolata, oltre ché dalle norme sulla privacy e dalle esigenze di security, dagli obiettivi dei trattamenti e dal ciclo di rilascio dei prodotti attesi dal trattamento dei dati in parola. Se, ad esempio, un'Azienda sanitaria ha attivato una procedura di gestione informatizzata delle Cartelle Cliniche e ha stabilito nella propria Carta dei Servizi che il tempo di rilascio al cittadino/utente di una Cartella clinica di ricovero è "immediato su richiesta dell'interessato/avente diritto", è scontato pensare a profilare i cicli interni di elaborazione, rilascio dati, stampa, firma e consegna (ed eventuale preriscossione dei diritti dovuti) in relazione diretta con il tempo prenegoziato. Si tratta dunque di prevedere, dato un certo tempo di assolvimento della funzione di rilascio, un tempo congruo rispetto alla richiesta dell'utente (in analogia con qualunque sistema di certificazione automatizzata, dalla Carta di identità al certificato di residenza, etc.). Ciò permette di gestire in un periodo prefissato il numero massimo atteso di utenti (massimizzazione dell'efficienza delle strutture organizzative e dei 'cicli macchina' e dell'efficacia nella fornitura del prodotto). Ciò può non essere sempre realizzabile, in un ciclo di produzione lineare, per carenza, ad es., di un certificato di firma necessario al completamento della procedura (ad es.: quello del Direttore sanitario dell'ospedale di dimissione), per la mancata automazione dei sistemi di riscossione e certificazione del riscosso e dell'identità del versante, etc. In un ciclo non lineare relativo al medesimo evento, ad es. in relazione ad una Cartella clinica in cui devono essere ricompresi esami basati su imaging digitale, è possibile pensare ad una procedura di formazione della Cartella che richiede immagini (ad es.: TAC) ad un sottosistema di archiviazione digitale (con collegamento PACS) controllato da altre procedure che richiedono tempi di predisposizione dell'immagine previ ulteriori livelli di autorizzazione all'accesso. Tenuto conto di quanto premesso nella sezione 2., il livello di performance sarà costituito dalla sommatoria dei tempi necessari alle elaborazioni procedurali previo esaurimento delle procedure di controllo e di sicurezza: tale tempo costituirà la misura da valutare in relazione all'appropriatezza dell'erogato rispetto al pattuito (in Carta dei Servizi) e, ove esistente, al dimensionamento del relativo scarto. Spostando lo sguardo sui processi "interni" alle organizzazione sanitarie, l'implementazione di molteplici livelli di security (specie se non coordinati da un'unica politica di sicurezza) tende a diminuire l'efficienza delle operazioni - a parità di efficienza tra prestazioni - al livello di performance della procedura connotata dal maggior livello di security. Ad esempio, in un quadro di "telepatologia" (telerefertazione attraverso l'impiego di un microscopio manovrato telematicamente da un anatomo patologo che formula e trasmette il referto attraverso un analogo canale telematico), le performance saranno teoricamente più alte se la teleanalisi e la refertazione avvengono nell'ambito dello stesso presidio ospedaliero (ipotizzando un livello di security basso nell'ambito della medesima "rete telematica locale" già protetta a monte e a valle da appositi sistemi); di livello medio se la prestazione avviene, nell'ambito della medesima organizzazione, tra due postazioni collegate tra di loro su "rete telematica pubblica" (per il necessario aumento del livello di security nel passaggio di dati sensibili su canali non protetti); più basse se la prestazione avviene, sempre su rete telematica, tra postazioni di differenti organizzazioni sanitarie (ad es.: nel caso di richiesta di una second opinion rispetto ad una casistica data) perché in quest'ultimo caso i livelli di protezione devono consentire anche la mutua autenticazione tra soggetti in tutti i passaggi del ciclo di prestazione sia rispetto ad uno standard security rate attivo per qualunque processo di rete geografica sia rispetto al tipo di sicurezza specificamente richiesto per le operazioni di telepatologia.

6. QUARTO CONCETTO

"Le operazioni per garantire la privacy in un quadro di sicurezza devono essere pianificate e monitorate comprendendo non solo i costi di investimento ma anche i costi operativi".

Non si insisterà che per poche righe sull'ultimo concetto che riteniamo ormai di chiara evidenza dopo la disamina dei precedenti paragrafi. Il concetto è molto semplice: nell'ambito della progettazione, dispiegamento e gestione dei processi sanitari basati su ICT la privacy costituisce, nel quadro sopra delineato, una variabile indipendente e un vincolo all'azione. Più tecnologia impiego in tali processi per garantire efficacia all'azione (di produzione di salute, di ricerca scientifica, di gestione amministrativa, etc.) più tale tecnologia deve essere adeguatamente supportata da un apposita politica di sicurezza.

Ogni passaggio in questa catena ha un costo, in linea di massima stimabile in sede di progettazione esecutiva, determinato dalla sommatoria dei costi dei singoli componenti controllati a cui va sommato il costo della sicurezza dell'intero circuito. Tali costi sono sostanzialmente di due tipi:

- i costi iniziali (rispetto ad ogni innovazione immessa per la prima volta o aggiunta ad un sistema dato) che vanno attentamente determinati anche in ordine ai piani di ammortamento e sostituzione delle tecnologie implicate nei processi

- i costi operativi, rappresentati dai costi di monitoraggio, dai costi dei contratti di manutenzione, dai costi dei contratti assicurativi, etc. che si riproducono nel corso del ciclo di vita delle procedure e influenzano in modo massiccio la c.d. "catena del valore" che connota il costo dei singoli prodotti finali (ad es.: il costo-prodotto della Cartella clinica sopra trattata anche in relazione alla quota di partecipazione dei cittadini). La mancata analisi, previsione e budgettizzazione in un'organizzazione di tali costi rispetto ai cicli di vita di processi privacy dependents porta, inevitabilmente, o ad un progressivo decadimento delle funzioni di sicurezza o a una riduzione dei livelli di performance. E ciò tende ad avvenire, per l'espansività dei processi gestiti "a rete", sia nei sottosistemi direttamente implicati sia nel sistema di riferimento sia, in cascata, nel sistema generale a cui l'organizzazione appartiene.

7.UN ESEMPIO Dl SECURITY E PRIVACY IN ICT NELLA REGIONE TOSCANA

L'esempio che si vuole di seguito illustrare è inserito nel contesto del nuovo modello di sistema informativo regionale per la sanità che la Regione Toscana ha avviato, come progettazione, nel corso del 2002. Attualmente in 6 Aziende sanitarie pilota sono in fase di dispiegamento le tecnologie che sostituiranno il vecchio modello di scambio dati tra Aziende e Regione con una nuova procedura basata sulla "cooperazione applicativa su eventi" (sistema c.d. di Publish and Subscribe sul quale è attestato anche il modello nazionale di cooperazione nell'ambito del progetto italiano di e-government).

Il modello si appoggia sostanzialmente sul seguente processo:

a) in Toscana ogni Azienda deve, in base a specifiche normative e disposizioni amministrative e tecniche, produrre dati analitici relativi alla propria attività sanitaria in una serie di settori che, attualmente, ricomprendono oltre l'80% del complesso delle attività sanitarie - esercitate dalle Aziende stesse o convenzionate con i soggetti accreditati (il resto dei dati è attualmente acquisito tramite strumenti di rilevazione di tipo sintetico). Fanno parte di tale insieme i dati dei ricoveri ospedalieri, delle prestazioni specialistiche ambulatoriali, delle prestazioni farmaceutiche erogate tramite farmacia, etc. ma anche i dati delle prestazioni protesiche, degli interventi di elisoccorso, dei Certificati di assistenza al parto, etc.

b) i dati sono acquisiti e processati nell'ambito di ogni singola Azienda con strumenti organizzativi e ICT propri ma devono essere trasmessi con metodologia e in formati standard regionali ai soggetti prescritti da specifiche disposizioni organizzative (tipicamente: la Regione Toscana, le altre Aziende sanitarie toscane, etc.). La Regione Toscana cura direttamente in questo contesto il livello di comunicazione con gli altri soggetti del SSN (Ministeri, altre Regioni e Prov. Autonome, etc.).

c) nel nuovo modello di sistema informativo si presenta il problema di gestire tramite ICT un trasferimento di dati personali da un titolare ad un altro titolare (o ad altri titolari) utilizzando - canali privati (quelli delle Aziende) e canali "pubblici" di trasmissione nel contemporaneo rispetto delle 3 variabili sopra elencate: privacy, security e livello di performance

d) il problema è stato affrontato sotto il profilo ICT alla luce della tecnologia (apparecchiature e procedure aziendali, apparecchiature e procedure regionali, canali di trasmissione, protocolli e servizi della Rete Telematica Regionale per la Sanità) preesistente all'avvio del nuovo modello del sistema informativo, al fine di minimizzare l'impatto tecnologico e organizzativo (e, conseguentemente, i costi di investimento e i costi di gestione) delle nuove procedure di comunicazione

e) la soluzione individuata è strutturata a più livelli dei quali qui risulta opportuno individuare solo i 4 che hanno una diretta attinenza con l'oggetto della presente relazione:

1. la comunicazione tra sistemi aziendali e sistema regionale avviene tramite una macchina di proprietà regionale che viene installata nelle Aziende sanitarie: tale macchina garantisce al tempo stesso il livello di controllo di titolarità nella trasmissione, il livello di controllo di congruenza dei dati con le regole imposte, il livello di smistamento dei dati ai soli soggetti legittimati alla loro visione/utilizzo (controllo di titolarità nella ricezione), il livello di controllo del circuito tra sistema aziendale e sistema regionale tramite una specifica applicazione Https - cioè tramite il protocollo normalmente utilizzato per le applicazioni Internet ma in versione 's' cioè 'sicura', quindi accessibile solo con uno specifico strumento di autenticazione individuato in una smart card a firma debole o forte a seconda dei livelli di gerarchia organizzativa interessati dal sistema di trasmissione, il livello di controllo del circuito nell'ambito del sistema regionale (che opera comunque su "rete telematica pubblica") tramite l'esportazione su tale sistema dei risultati delle procedure di autenticazione e l'utilizzo della crittografia a chiave pubblica per la sicurezza definitiva della trasmissione
2. l'accesso al sistema regionale per l'invio dati da parte del sistema aziendale avviene tramite il rilascio da parte della Regione Toscana, tramite il proprio servizio di Autorità di Certificazione digitale - Certification Authority (servizio appaltato ad un fornitore iscritto nell'Albo nazionale e caratterizzato da procedure di certificazione standard AIPA- Autorità per l'Informatica nella Pubblica Amministrazione), di uno specifico certificato digitale a responsabili di trattamento e comunicazione appositamente individuati dalle Aziende sanitarie di appartenenza: tali soggetti stipulano un apposito contratto con il fornitore della Regione Toscana per il rilascio del supporto digitale assumendosi specifiche responsabilità (personali) nel suo impiego all'interno del circuito informativo sopra delineato
3. analoga situazione viene attivata per gli altri soggetti aziendali nonché per il personale regionale incaricato del trattamento: ognuno dei soggetti abilitati alle funzioni di recupero dati è personalmente dotato - con la medesima procedura - di certificato digitale in base al quale (cioè: in base allo specifico "profilo" descritto nel certificato ed associato a particolari procedure di controllo d'accesso) è in grado di svolgere quelle operazioni necessarie al buon fine del processo secondo gli obiettivi e nel quadro delle norme previste
4. tutte le comunicazioni di cui sopra si appoggiano a sistemi tecnologici opportunamente ridondati e supportati da specifiche procedure di salvataggio e fault restore, sia sotto il profilo della tecnologia di base (alimentazione elettrica-, logistica, etc.) sia sotto il profilo dei sistemi di elaborazione, trasmissione e archiviazione. In tale quadro la Regione Toscana affianca al progetto qui descritto un'iniziativa di carattere sistemico (TlX-Tuscany Internet eXchange) attraverso la quale assicura anche la sicurezza tecnico-logistica dei siti deputati alla gestione e al governo delle transazioni qui ricordate

Il risultato del processo sopra descritto si può sintetizzare - in modo alquanto grezzo - in:

- comunicazione tra soggetti a "latenza zero" (quindi: assolvimento per definizione dei requisiti rispetto ai livelli di performance attesi)

- supporto strutturato ad una politica comune di messa in sicurezza di dati e circuiti (nell'ambito di un sistema di comunicazione interistituzionale) con conseguente assolvimento dei requisiti rispetto alla security

- analisi di dettaglio dei livelli di "titolarità" rispetto alle norme nelle varie fasi di accesso ai dati con pre-identificazione personale dell'operatore e attribuzione al medesimo dello specifico profilo di trattamento identificato da disposizioni organizzative aziendali o regionali (con conseguente assicurazione di privacy almeno nel quadro delle transazioni qui considerate)

- sostenuto costo di investimento (soprattutto per la dimensione regionale dell'iniziativa), medio-basso costo di gestione previsto per la capacità del sistema progettato di adeguare le specifiche interne con un solo livello di comunicazione "broadcast" rispetto ai soggetti accreditati nel sistema stesso.

NOTE
1 Tra i quali, a titolo esemplificativo, ricordiamo: lo Stato (Ministero della Salute, Ministero degli Interni, etc.), le Organizzazioni sanitarie di livello centrale (Istituto Superiore di Sanità, etc.), gli Istituti scientifici di ricerca e cura, le Università e i Centri di ricerca, le Regioni e le Province autonome, le Aziende sanitarie e le loro strutture organizzative, il sistema della Sanità privata, gli Enti e Associazioni di Volontariato, gli Enti e Associazioni di tutela, etc.

2 Pubblicato per la prima volta nel 1983, il documento del Dipartimento della Difesa USA "Trusted Computer System Evaluation Criteria, (DOD5200.28-STD)" è generalmente conosciuto come Orange Book ed è de facto ancora oggi lo standard per la sicurezza delle elaborazioni elettroniche. L'Orange Book, e altre pubblicazioni nelle Rainbow Series sono ancora il benchmark per i sistemi prodotti nelle ultime due decadi e le classificazioni Orange Book come la C2 offrono al tempo stesso un metodo rapido di definizione per i livelli base di security dei moderni sistemi operativi. Vedi All. 1