I documenti clinico sanitari verso la dematerializzazione: lo scenario italiano in uno studio dell’Osservatorio ICT in Sanità del Politecnico di Milano

Da ICT4Health.

Realisticamente parlando, nella Sanità è ancora troppo presto ipotizzare che i progetti di dematerializzazione possano abilitare scenari che prevedono la totale scomparsa dei documenti cartacei dalle strutture sanitarie, soprattutto in orizzonti temporali di breve periodo. Un’analisi corretta della diffusione di tali soluzione deve partire innanzitutto da una visione realistica del fenomeno.

Da questa considerazione prende le mosse la Ricerca dell’Osservatorio ICT in Sanità, “La Dematerializzazione in Sanità: dai documenti ai processi”, condotta sulle Direzioni ICT di 118 strutture sanitarie italiane, pubbliche e private. Emerge che il livello di diffusione delle soluzioni è ancora nelle prime fasi di sviluppo: circa un quarto del campione della ricerca non ha ancora deciso di investire, il 30% ha avviato dei progetti pilota, mentre più del 40% di aziende sanitarie (soprattutto aziende di grandi dimensioni, come confermato dalle interviste ai Chief Information Officer) sta già affrontando la tematica in ottica operativa, sull’intero ambito aziendale e con diversi livelli di estensione.

In particolare la dematerializzazione dei documenti è stata prevalentemente condotta in ambito clinico-sanitario piuttosto che in quello amministrativo per la presenza di sistemi, prevalentemente diagnostici, predisposti per la produzione di referti e immagini già originariamente in forma digitale. Dall’approfondimento condotto e dai dati rilevati sugli investimenti programmati si evince che la diffusione della dematerializzazione in questo ambito è destinata ad aumentare nell’immediato futuro.

Per avere una fotografia più precisa dello stato di diffusione e di maturità nelle aziende sanitarie nel rispetto delle indicazioni normative, le diverse realtà del campione di riferimento sono state mappate su una scala che comprende quattro stadi evolutivi, ricavati da un’analisi dei casi di maggior successo, che considerano:

presenza di un workflow automatizzato;

modalità di firma dei documenti;

effettuazione dell’archiviazione sostitutiva a norma;

modalità di esibizione a norma dei documenti informatici.

In seconda battuta sono state prese cinque macro aree funzionali ed è stato chiesto ai CIO di segnalare il livello di dematerializzazione in esse raggiunto: accoglienza e dimissione; diagnosi (radiologia e in generale tutte le diagnostiche per immagini, i servizi laboratoristici, ecc); cura; ciclo amministrativo e finanziario; ciclo logistico commerciale.

Emerge che nell’area funzionale della diagnosi la Dematerializzazione ha raggiunto livelli di completezza maggiori, e in particolare nei laboratori e dalla radiologia. In media infatti in quest’area il 71% del campione utilizza applicazioni che permettono di produrre l’output finale del processo (lastre, referto, diagrammi ecc.) in forma elettronica/digitale, il 52% prevede l’applicazione della firma digitale sui documenti informatici prodotti; il 32% circa effettua la conservazione sostitutiva dei documenti prodotti; il 20% dei casi dichiara di realizzare il processo di esibizione nel rispetto del quadro normativo attualmente in vigore.

Per quanto riguarda invece tutte le aree legate alla Dematerializzazione di documenti amministrativi, le aziende, pur essendo dotate (o in fase di dotazione) di sistemi gestionali che permetterebbero la gestione digitale delle pratiche in ottica di workflow non hanno ancora avviato un vero e proprio processo, se non per tipologie limitate di documenti amministrativi. Se è vero che dematerializzare in ambito sanitario abilita potenziali vantaggi molto più rilevanti rispetto alla sfera amministrativa, è altrettanto vero che quest’ultima area non deve essere dimenticata, soprattutto se si considerano gli obiettivi fissati dal Ministero per la Pubblica Amministrazione e l’Innovazione che puntano a una gestione dei pagamenti sempre più digitale.

Articoli Correlati

Amministratori di sistema: scadenza vicina. Una piccola guida.

Il 15 dicembre si sta avvicinando e con esso la scadenza per applicare in azienda il provvedimento del Garante della Privacy del 27 novembre 2008 come modificato dal provvedimento del 25 giugno 2009.

A seguito di un convegno a cui abbiamo assistito oggi, riporto quali sono gli adempimenti da fare in azienda. Tengo a precisare che tali discussioni sono ovviamente frutto di interpretazioni e che quindi vanno applicate coscientemente presso la propria azienda magari sentendo il proprio consulente o le proprie associazioni di categoria. Non ci rendiamo responsabili per applicazioni reali in azienda.

Il provvedimentro del Garante della Privacy del 25 giugno 2009 ha portato con se sostanzialmente due notizie degne di nota: Semplificazioni e proroga dell’individuazione del o degli amministratori di sistema e le attività connesse da mettere in essere.

Questi due provvedimenti hanno individuato, oltre ai ruoli di titolare, responsabile ed incaricato, anche il ruolo di Amministratore di sistema.

Cosa si intende per amministratore di sistema? Non solo il classico personaggio “smanettone” che gestisce i server ma in senso più lato anche:

  • Amministratore di server
  • Amministratore di Database
  • Amministratore di rete
  • Amministratore di sistema
  • Amministratore di software complessi
  • …..

L’individuazione del o degli amministratori di sistema deve essere fisica, cioè una persona, non una persona giuridica. Ne devono essere valutate le caratteristiche e le capacità e tali valutazioni devono essere documentate.

La designazione deve essere scritta e su base individuale.

Entro il 15 dicembre 2009 deve essere redatto un registro degli Amministratori di sistema (AS nel seguito) in cui sono contenuti gli estremi identificativi, le funzioni attribuite a ciascun AS. Nel caso di Outsourcing, tale elenco deve essere tenuto dall’Outsourcer (ma lo vedremo meglio più avanti). Questo registro deve esserci. Il posto migliore dove inserirlo è ovviamente il DPS ma l’azienda puo’ fare quello che vuole.

Nel caso in cui alcuni AS trattino dati dei lavoratori (o possano venirne a conoscenza), i lavoratori stessi devono essere informati (in vario modo, lettera scritta, pubblicazione su intranet, su lavagna, etc) dei nominativi. Quali sono i dati dei lavoratori? sicuramente quelli amministrativi ma anche dati di navigazione in internet, log delle mail, degli accessi. Praticamente questo sottoinsieme degli AS è praticamente identico all’insieme degli AS nella sua interezza.

Una volta all’anno l’azienda deve verificare l’attività degli AS e mantenere traccia di questa valutazione (documenti). Gli AS valutati devono essere sia quelli interni che quelli esterni.

Veniamo ad un altro obbligo che ha gettato molto scompiglio: la registrazione degli accessi (solo log in e log out) degli amministratori di sistema ai vari sistemi. E’ obbligatorio. Tali log vanno tenuti almeno sei mesi su un supporto non riscrivibile (CD o DVD non riscrivibile ad esempio). Non è proibito tenere i log di tutte le attività. E’ a discrezione dell’azienda .

Vediamo quindi in pratica cosa bisogna fare in due situazioni:

  1. AS interni;
  2. AS esterni.

Caso n.1, AS interni.

Nomina dell’AS, con raccolta della documentazione comprovante la competenza, ad es. curriculum e/o corsi di formazione; la nomina deve avere anche il profilo di autorizzazione e quali sono i trattamenti consentiti. Deve essere anche definita la Job descriprion, come meglio descritto nelle faq del garante, numero 7 e 8 che riportiamo in dettaglio:

  • Cosa si intende per descrizione analitica degli ambiti di operatività consentiti all’ADS? [Rif. comma 2, lettera  d]. Il provvedimento prevede che all’atto della designazione di un amministratore di sistema, venga fatta “elencazione analitica” degli ambiti di operatività consentiti in base al profilo di autorizzazione assegnato, ovvero la descrizione puntuale degli stessi, evitando l’attribuzione di ambiti insufficientemente definiti, analogamente a quanto previsto al comma 4 dell’art. 29 del Codice riguardante i responsabili del trattamento.
  • Oltre alla job description si deve andare più in dettaglio? Si devono indicare i singoli sistemi e le singole operazioni affidate?
    No, è sufficiente specificare l’ambito di operatività in termini più generali, per settori o per aree applicative, senza obbligo di specificarlo rispetto a singoli sistemi, a meno che non sia ritenuto necessario in casi specifici.

La  nomina deve essere individuale, fisica, deve essere conservata la ricevuta di nomina.

Deve essere comunicato ai dipendenti quale AS tratta i loro dati.

Bisogna registrare gli accessi degli AS (Log in e log out) ai vari sistemi (questi sono gli standard minimi). Attenzione ai riferimenti orari (c’e’ quindi la necessità di avere dei time server affidabili). Tali dati poi vanno periodicamente scritti su un supporto non riscrivibile e mantenuti per almeno 6 mesi.

Qui ci vengono in aiuto le faq 9, 10, 11, 12, 13, 14:

  • Cosa si intende per access log (log-in, log-out, tentativi falliti di accesso, altro?…) [Rif. comma 2, lettera f] Per access log si intende la registrazione degli eventi generati dal sistema di autenticazione informatica all’atto dell’accesso o tentativo di accesso da parte di un amministratore di sistema o all’atto della sua disconnessione nell’ambito di collegamenti interattivi a sistemi di elaborazione o a sistemi software. Gli event records generati dai sistemi di autenticazione contengono usualmente i riferimenti allo “username” utilizzato, alla data e all’ora dell’evento (timestamp), una descrizione dell’evento (sistema di elaborazione o software utilizzato, se si tratti di un evento di log-in, di log-out, o di una condizione di errore, quale linea di comunicazione o dispositivo terminale sia stato utilizzato…).
  • Laddove il file di log contenga informazioni più ampie, va preso tutto il log o solo la riga relativa all’access log? [Rif. comma 2, lettera f]
    Qualora il sistema di log adottato generi una raccolta dati più ampia, comunque non in contrasto con le disposizioni del Codice  e con i principi della protezione dei dati personali, il requisito del provvedimento è certamente soddisfatto. Comunque è sempre possibile effettuare un’estrazione o un filtraggio dei logfiles al fine di selezionare i soli dati pertinenti agli AdS.
  • Come va interpretata la caratteristica di completezza del log? Si intende che ci devono essere tutte le righe? L’adeguatezza rispetto allo scopo della verifica deve prevedere un’analisi dei rischi?
    La caratteristica di completezza è riferita all’insieme degli eventi censiti nel sistema di log, che deve comprendere tutti gli eventi di accesso interattivo che interessino gli amministratori di sistema su tutti i sistemi di elaborazione con cui vengono trattati, anche indirettamente, dati personali. L’analisi dei rischi aiuta a valutare l’adeguatezza delle misure di sicurezza in genere, e anche delle misure tecniche per garantire attendibilità ai log qui richiesti.
  • Come va interpretata la caratteristica di inalterabilità dei log? Caratteristiche di mantenimento dell’integrità dei dati raccolti dai sistemi di log sono in genere disponibili nei più diffusi sistemi operativi, o possono esservi agevolmente integrate con apposito software. Il requisito può essere ragionevolmente soddisfatto con la strumentazione software in dotazione, nei casi più semplici, e con l’eventuale esportazione periodica dei dati di log su supporti di memorizzazione non riscrivibili. In casi più complessi i titolari potranno ritenere di adottare sistemi più sofisticati, quali i log server centralizzati e “certificati”. E’ ben noto che il problema dell’attendibilità dei dati di audit, in genere, riguarda in primo luogo la effettiva generazione degli auditable events e, successivamente, la loro corretta registrazione e manutenzione. Tuttavia il provvedimento del Garante non affronta questi aspetti, prevedendo soltanto, come forma minima di documentazione dell’uso di un sistema informativo, la generazione del log degli “accessi” (login) e la loro archiviazione per almeno sei mesi in condizioni di ragionevole sicurezza e con strumenti adatti, in base al contesto in cui avviene il trattamento, senza alcuna pretesa di instaurare in modo generalizzato, e solo con le prescrizioni del provvedimento, un regime rigoroso di registrazione degli usage data dei sistemi informativi.
  • Si individuano livelli di robustezza specifici per la garanzia della integrità?
    No. La valutazione è lasciata al titolare, in base al contesto operativo (cfr. faq n. 14).
  • Quali potrebbero essere gli scopi di verifica rispetto ai quali valutare l’adeguatezza?
    Quelli descritti al paragrafo 4.4 del provvedimento e ribaditi al punto 2, lettera e), del dispositivo. L’adeguatezza è da valutare in rapporto alle condizioni organizzative e operative dell’organizzazione.

Ogni organizzazione è poi libera di decidere il suo livello di sicurezza, quindi si possono anche conservare i log di tutti, ma bisogna essere in grado di filtrare quelli degli AS.

Si devono quindi mettere in pratica delle verifiche periodiche sull’attività dell’AS e conservarne gli atti (vanno bene anche delle check list di controllo). Le verifiche devono essere almeno annuali.

Caso 2. AS Esterni.

In questo caso i compiti delegabili sono:

  • Nomina e conservazione del registro  degli AS
  • Verifica periodica delle attività degli AS

Non è delegabile invece la divulgazione degli AS che trattano dati del personale. La lista verrà data dagli Outsourcers.

Le modalità di delega:

  • Compiti delegati assegnati tramite lettera di incarico
  • Le lettere d’incarico devono essere sottoscritte per accettazione.

Ovviamente la funzione delegata deve gia’ essere stata incaricata al trattamento.

Ed ovviamente i casi possono essere diversi e vanno studiati volta per volta (Outsourcing completo, parziale, occasionale).

Quindi: prima del 15 dicembre è d’obbligo scrivere alle società che fanno trattamenti in Outsourcing o gestiscono in Outsourcing i sistemi.

E fino a qui gia’ i mal di testa sono notevoli. Ma si puo’ andare oltre, soprattutto in due casi ulteriori:

  1. Contratto di Outsourcing di società estera a cliente italiano;
  2. Contratto di Outsourcing di società italiana a cliente estero.

Nel primo caso: intra o extra UE? Che clausole di privacy utilizzare? Una cosa è certa: la società italiana è la titolare dei dati e quindi obbligo di nomina.

Nel secondo caso, la società italiana non è titolare ma deve comunque nominare il responsabile dei dati e comunque non si applica il provvedimento.

Penso sia tutto. Per il momento

Articoli Correlati