Archivio mensile:ottobre 2014

Cyber security e dispositivi medici

CyberSecurity

Cyber Security

È apparso di recente su MSN News un preoccupante articolo intitolato “U.S. government probes medical devices for possible cyber flaws“.

Per la verità il tema della vulnerabilità dei dispositivi medici ad attacchi di tipo informatico – Cyber attacchi – è all’attenzione degli addetti ai lavori ormai da tempo, ma per la prima volta viene documentata una vera e propria indagine svolta dall’Industrial Control Systems Cyber Emergency Response Team, o ICS-CERT, su alcuni dispositivi fra cui pompe di infusione e dispositivi cardiaci impiantatili. I membri dell’ICS-CERT hanno teso a precisare di non essere a conoscenza di attacchi che abbiano coinvolto i dispositivi sotto indagine, ma hanno affermato che l’indagine verte sulla possibilità che malintenzionati possano acquisire il controllo da remoto dei dispositivi e provocare problemi, ad esempio per sovradosaggio di farmaci nel caso l’attacco avvenga su pompe da infusione o altri effetti altrettanto nocivi nel caso l’attacco sia rivolto a dispositivi cardiaci impiantabili.

Al di là dei dispositivi specifici sotto indagine, la presenza di medical devices sulle reti delle nostre strutture sanitarie rappresenta un’oggettiva criticità che pone seri problemi di progettazione della infrastruttura e complessi vincoli di gestione.

Nonostante nel tempo siano stati proposti approcci teorici più o meno convincenti – ad esempio, di recente, il NIST ha proposto il modello Framework for improving Critical Infrastrutture Cybersecurity – è ormai accezione comune che ciò non basti e che vi sia un’evidente carenza che occorrerà colmare al più presto. Molti, infatti, pensano che non sia più differibile l’identificazione di una serie di buone pratiche tese a minimizzare il rischio di attacchi a reti miste – caratterizzate dalla presenza contemporanea di dispositivi medici e sistemi non medicali -. L’individuazione di scenari tecnici di riferimento, pur senza negare o contraddire la necessità di una metodologia di gestione della sicurezza, favorirebbe la rapida messa in campo di misure capaci di garantire una maggiore sicurezza degli impianti oggi in servizio.

Se da un lato infatti il citato modello del NIST rappresenta il necessario riferimento metodologico per la gestione di una qualsiasi infrastrutture tecnica critica, non fornisce tuttavia riferimenti implementabili che possano essere direttamente impiegati nelle diverse realtà sanitarie. Ciò che occorre fare è definire una serie di architetture di riferimento capaci di contrastare le principali minacce ipotizzabili, pur garantendo la necessaria usabilità complessiva e una sufficiente gestibilità.

E, probabilmente, occorrerà farlo il prima possibile.

PG.

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

Open Data, Ontologie e il sogno della interoperabilità semantica

RDF Linked Data Cloud

RDF Linked Data Cloud – Anja Jentzsch

Il paradigma RDF – Resource Description Framework – va ben oltre gli Open Data, insegue il sogno dell’interoperabilità semantica del WEB.

In fondo i dati possono essere resi pubblici anche attraverso paradigmi meno velleitari: un semplice file CSV, può anche bastare a superare la sostanziale immanipolabilità del pur portabilissimo PDF, il primo passo verso l’apertura dei dati. L’RDF va oltre, vuole arrivare al Sacro Graal dell’informatica: l’interoperabilità semantica.

Oggi mi sono divertito a scandagliare una delle migliori banche dati aperte, quella della Camera dei Deputati. Ho giocato con il motore di interrogazione SPARQL che viene messo a disposizione e ho toccato con mano quanto sia facile creare interrogazioni standard per l’accesso ai dati. In poco tempo, nonostante la mia approssimativa conoscenza del linguaggio, ho potuto estrarre i presidenti che si sono succeduti alla guida della repubblica con tanto di relativa foto.

# Query SPARQL di recupero dei Presidenti della repubblica

SELECT DISTINCT ?persona ?nome ?cognome ?descrizione ?immagine

WHERE { ?persona a ocd:presidenteRepubblica; rdfs:label ?descrizione; ocd:rif_persona ?rif_persona.

?rif_persona foaf:firstName ?nome; foaf:surname ?cognome; foaf:depiction ?immagine.}

Se si guarda l’interrogazione con attenzione, ci si rende conto che essa non solo dearchivia un’informazione presente nella banca dati, l’elenco dei presidenti, ma ci permette di conoscere anche il loro nome e cognome attraverso un’inferenza semantica: essendo il presidente della repubblica una persona, esso dispone anche di un “surname” e di un “firstName”. Chiaro, lapalissiano, quasi banale…

Ma non c’è nulla di banale in tutto ciò. Da anni, nei sistemi informativi sanitari, combattiamo una dura battaglia, quella della interoperabilità sintattica. Tutti confidiamo che la vittoria sia prossima, ma la guerra la vinceremo solo raggiungendo l’interoperabilità semantica.

Quando avremo il linked data cloud costituito dall’aggregazione degli RDF sanitari, in cui ogni singolo concetto faccia riferimento alla propria univoca ontologia?

Quando il nome e cognome di un paziente saranno consultabili come naturale conseguenza del fatto che ogni paziente è anche una persona?

PG.

Letture attinenti: LINEE GUIDA NAZIONALI PER LA VALORIZZAZIONE DEL PATRIMONIO INFORMATIVO PUBBLICO

.

Codice dell’amministrazione digitale e dintorni, parte 1

Agenzia per l'Italia Digitale

Agenzia per l’Italia Digitale

Questo è il primo di una serie di articoli volti ad approfondire gli aspetti del CAD di maggiore interesse per le aziende sanitarie. In questa prima parte si riportano alcune definizioni relative ai vari tipi di FIRMA ELETTRONICA.

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

È disponibile anche l’articolo CAD e dintorni, parte 2.

Firma Elettronica, Avanzata, Qualificata e Digitale

La definizione dei vari tipi di firma è è rintracciabile nel CAD all’art. 1, comma 1, punti da q ad s:

q) firma elettronica: l’insieme dei dati in forma elettronica, allegati oppure connessi tramite associazione logica ad altri dati elettronici, utilizzati come metodo di identificazione informatica;

q-bis) firma elettronica avanzata: insieme di dati in forma elettronica allegati oppure connessi a un documento informatico che consentono l’identificazione del firmatario del documento e garantiscono la connessione univoca al firmatario, creati con mezzi sui quali il firmatario può conservare un controllo esclusivo, collegati ai dati ai quali detta firma si riferisce in modo da consentire di rilevare se i dati stessi siano stati successivamente modificati;

r) firma elettronica qualificata: un particolare tipo di firma elettronica avanzata che sia basata su un certificato qualificato e realizzata mediante un dispositivo sicuro per la creazione della firma;

s) firma digitale: un particolare tipo di firma elettronica avanzata basata su un certificato qualificato e su un sistema di chiavi crittografiche, una pubblica e una privata, correlate tra loro, che consente al titolare tramite la chiave privata e al destinatario tramite la chiave pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l’integrità di un documento informatico o di un insieme di documenti informatici.

Particolarmente importanti per la generazione, l’apposizione e la verifica delle firme elettroniche avanzate, qualificate e digitali risultano essere le regole tecniche riportate nel DPCM del 22 febbraio 2013.

Firma forte e firma leggera

Nella linea guida alla firma digitale reperibile sul sito di AGID a pag. 9 si chiarisce che nel linguaggio corrente si definisce firma forte la firma digitale. Tutto ciò che non risponde, anche in minima parte, alle caratteristiche della firma forte, ma è compatibile con la definizione giuridica di firma elettronica è considerata una firma leggera.

Firma grafometrica

La firma grafometrica è una sottoscrizione autografa condotta su dispositivi elettronici – tablet o similari – che soddisfa i requisiti della firma elettronica avanzata.

Caratteristiche di validità giuridica dei documenti informatici firmati

Secondo l’art 21 del CAD, commi 1 e 2:

1. Il documento informatico, cui è apposta una firma elettronica, sul piano probatorio è liberamente valutabile in giudizio, tenuto conto delle sue caratteristiche oggettive di qualità, sicurezza, integrità e immodificabilità.

2. Il documento informatico sottoscritto con firma elettronica avanzata, qualificata o digitale, formato nel rispetto delle regole tecniche di cui all’ articolo 20 – del CAD -, comma 3 , che garantiscano l’identificabilità dell’autore, l’integrità e l’immodificabilità del documento, ha l’efficacia prevista dall’articolo 2702 del codice civile . L’utilizzo del dispositivo di firma elettronica qualificata o digitale si presume riconducibile al titolare, salvo che questi dia prova contraria.

Secondo l’interpretazione corrente il comma 1 attesta la valutabilità in giudizio di un documento firmato con firma elettronica, mentre il comma 2 attesta la equipollenza fra la firma autografa e la firma digitale – o qualificata – se apposta nel rispetto delle regole tecniche vigenti.

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 fattore umano nella sicurezza dei sistemi informativi sanitari

Sito HealthITSecurity

Sito HealthItSecurity

Nell’articolo Steps To Address Human Element Of Healthcare Data Security riportato sul sito Health IT Security vengono ribaditi alcuni concetti chiave della sicurezza informatica adattandoli all’ambito dei sistemi informativi sanitari.

L’articolo prende le mosse dai risultati dello studio del Ponemon Institute che mette in luce una preoccupante frequenza di deprecabili comportamenti messi in atto dai dipendenti dell’aziende degli intervistati che hanno condotto ad almeno un problema di sicurezza negli ultimi due anni  nel 78 percento dei casi. A ciò si aggiunge lo Studio dell’HIMSS, pubblicato nel 2014, che afferma che la maggiore motivazione alla consultazione inappropriata dei dati da parte dei dipendenti è riconducibile al desiderio di avere accesso a dati la cui consultazione dovrebbe essere riservata.

Se a questo si somma la cronica carenza di risorse dedicate alla sicurezza nelle aziende sanitarie – l’articolo parla del fatto che i dipartimenti IT delle aziende sanitarie statunitensi ricevono il 2 o 3 percento del budget che se confrontato con il 20 percento del budget che viene concesso ai dipartimenti IT nelle organizzazioni finanziarie o di vendita al dettaglio è ben poca cosa – si capisce come il compito sia assai sfidante. Considerazioni ancora più sconsolanti potrebbero essere fatte se rapportassimo queste disponibilità alla situazione italiana dove il budget dei dipartimenti IT delle aziende sanitarie in molti casi è ben al di sotto del citato 2 percento.

Nell’articolo si propongono alcune strategie volte a mitigare il rischio connesso al fattore umano che vale la pena citare:

  • addestrare il personale sulle buone pratiche di sicurezza ed enfatizzare quali siano i rischi di una gestione approssimativa della sicurezza;
  • rinforzare frequentemente le buone pratiche di sicurezza e ricordare le sanzioni in caso di inadempienza; ricordare di evitare cattive pratiche come l’utilizzo di password di gruppo e i bigliettini con le password affissi sulle stazioni di lavoro;
  • richiedere il cambio frequente della password e utilizzare strumenti che forzino i dipendenti a tale cambio;
  • usare sistemi di single-sign on che proteggano la sessione quando l’utente si scollega da un determinato ambito di lavoro;
  • registrare – e periodicamente esaminare – i tentativi di connessione per scongiurare tentativi di phishing e addestrare gli utenti a riconoscere queste minacce e a fornire adeguate risposte;
  • eliminare le password più deboli e comuni e adottare misure che forzino all’uso di password robuste.

Seppure quelle riportate nell’articolo non siano tematiche nuove, risulta preoccupante la frequenza delle problematiche di sicurezza che i vari studi citano come riconducibile a cause interne all’azienda. Questo porta  a pensare che, da un lato, vi sia la pressante necessità di fare evolvere i sistemi informativi in una direzione in grado di conciliare le esigenze di usabilità dei sistemi con quella di garanzia della privatezza delle informazioni gestite, ma dall’altro invita a non dimenticare l’importanza della formazione e del coinvolgimento degli utenti nella buona gestione dei sistemi informativi.

PG.

Il FSE sarà una APP?

Icona della APP salute

Icona della APP Salute di Apple.com

Quando ho scaricato l’ultima versione del sistema operativo iOS su iPhone mi sono ritrovato installata anche una intrigante app contraddistinta da un cuoricino rosso su campo bianco.

Cerco un po’ ed ecco spiegato l’arcano: nella sezione Health del sito della Apple trovo che il colosso di Cupertino si è lanciato nel mondo della salute e del fitness e quella dovrebbe esserne la porta di accesso.

Attiro l’attenzione di mia moglie e le indico l’icona sullo schermo del telefono. Mi chiede se è il fascicolo sanitario elettronico – FSE – di cui spesso le parlo. Sto per dirle che non è proprio così… poi ci penso su.

Ricordo molto bene quando Microsoft entrò nel settore con HealthVault, così come ricordo quando Google ci provò con il progetto Health e dopo qualche tempo chiuse i battenti per mancanza di adesioni. Non è una strada nuova, ci hanno già provato altri a percorrerla. Qualche anno fa, quando provai il servizio di Microsoft e quello di Google, non mi entusiasmarono. Allora tutto ciò che era disponibile era una interfaccia WEB, non esisteva una app che funzionasse sul telefonino che ho sempre fra le mani, non c’erano ancora tutti quei gadget in grado di raccogliere dati ed inviarli, o erano troppo costosi, o difficili da trovare.  Era una vita fa dal punto di vista della usabilità, ora molte cose sono cambiate.

Mi viene la voglia di riprovare. Mi butto ad inserire dati. Magari mi compro anche un contapassi bluetooth. Mi chiedo se Apple metterà a disposizione anche un servizio per interoperare con la banca dati?

Mia moglie, che mi vede trafficare, mi chiede che cosa stia facendo.  Con buona pace dei sacrosanti e paludati progetti FSE che si sta tentando di mandare avanti a livello nazionale, con buona pace dei dubbi su dove finiranno memorizzati i miei dati, rispondo che sto usando la mia cartella sanitaria on line.

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.

Le promesse della Telemedicina e dell’eHealth

Ci sono vocaboli così presenti nel nostro lessico che a lungo andare si logorano e finiscono per perdere la loro efficacia. Uno di questi è sicuramente il termine telemedicina. Gli addetti ai lavori ne sentono parlare da anni – almeno dal 2008 quando la commissione europea emanò la comunicazione COM(2008)689 avente per titolo “Telemedicina a beneficio dei pazienti, dei sistemi sanitari e della società” -.

Penso che non esista un professionista che si occupi di sistemi informativi sanitari che nell’ultimo lustro non abbia avuto a che fare con una qualche sperimentazione nell’ambito della telemedicina.

Ma c’è una bella differenza fra lo sperimentare e il dire che la telemedicina è ormai parte della nostra quotidianità.

Il confronto con le esperienze in corso all’estero potrebbe risultare impietoso se si pensa che già nel 2008 in Svezia il 75% degli ospedali partecipava ad iniziative di telemedicina nell’ambito della televisita, del telemonitoraggio, del teleconsulto radiologico.

Nel Regno Unito le incoraggianti prime sperimentazioni di telemedicina hanno portato alla adozione di un nuovo programma (“Three Million Lives” campaign) rivolto ai potenziali 3 milioni di candidati che potrebbero trarre beneficio da servizi di Teleassistenza e Telesalute.

Osservando il panorama italiano, così come viene fotografato dall’osservatorio nazionale e-care (www.onecare.cup2000.it), si ha l’impressione che nel nostro paese esista un numero anche piuttosto vasto di iniziative, ma che esse non afferiscano ad una regia organica di tipo nazionale o regionale in grado di rendere omogenea l’offerta dei diversi servizi su di un dato territorio.

Probabilmente quello che manca è una valutazione sistematica del rapporto costo/beneficio di tali nuove modalità di fare sanità.

L’impressione è che se esistesse un’affidabile valutazione dei servizi di telemedicina già oggi offribili, condotta secondo il convincente schema proposto dalle Linee di indirizzo sulla Telemedicina prodotte dal ministero della Salute, le cose sarebbero diverse.

Rapporto Costo / Efficacia delle soluzioni di telemedicina

Confronto Costo Efficacia. Linee di indirizzo nazionali sulla Telemedicina del Ministero della Salute

Qualora le regioni e le aziende disponessero di accreditate informazioni di questa natura, allora l’adozione di tecnologie eHealth e di soluzioni di Telemedicina diverrebbe routine e non una faticosa ed episodica sperimentazione di modelli che ormai nuovi non sono più.

PG.

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

L’usabilità del software sanitario, una questione di sicurezza

“Ma perché dovrei spendere denaro e sprecare tempo per cercare un’interfaccia utente migliore di questa per la mia applicazione aziendale? In fondo quello che conta è la Business Logic… Tutto il resto è fumo e perdita di denaro. Abbiamo viziato troppo i nostri utenti. Occorre tornare al nocciolo delle cose, senza fronzoli inutili e costosi.”

Interfacce Utente (Suffthatappens.com by Eric Burke)

L’interfaccia della App della mia azienda (Suffthatappens.com by Eric Burke)

Questo è quello che penso talvolta guardando una delle mie applicazioni aziendali… Poi mi accorgo che l’interfaccia che sto guardando è molto simile a quella rappresentata nella vignetta di Eric Burke e mi accorgo di quanto io stia sbagliando.

Ho avuto di recente modo di visitare la parte del sito di HIMSS dedicato alla usabilità e mi sono veramente stupito di quanto bene abbiano reso questi concetti.

In particolare ho trovato veramente illuminante la presentazione di Chriss Brancato che in modo semplice ed efficace ci spiega che fra le principali preoccupazioni connesse con l’informatizzazione di un processo sanitario ci sono:

  1. la preoccupazione che i sanitari non riescano ad inserire correttamente le informazioni nel sistema;
  2. la paura che l’informatizzazione rallenti l’esecuzione delle attività.

Tutte questioni che in qualche modo hanno a che fare con l’usabilità del sistema. Sono convinto che se fosse possibile misurare la perdita di produttività determinata da una interfaccia di minore qualità rispetto ad una più curata, troveremmo che i costi sopportati dall’organizzazione che scelga la realizzazione di minore qualità sono di molto superiori alla differenza di costo delle due applicazioni. Purtroppo non mi risulta esistano studi che diano ragione di ciò.

Quello che è certo è che, compatibilmente con le risorse a disposizione, si debba andare verso applicativi con una migliore interfaccia utente perché una interfaccia più curata significa una interazione più sicura ed efficiente con il dato sanitario.

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.