Rispetto alle nuove modalità di erogazione dei servizi e di gestione dell’assistenza l’approccio alle soluzioni ICT, si evince dal lavoro FIASO, è però ancora frammentata e riguarda di solito singoli aspetti, senza una visione complessiva dei trend e delle soluzioni avanzate in corso. Per questo il volume che racchiude le conclusioni del Gruppo di lavoro FIASO non si limita ad una analisi dell’esistenze ma cerca di formulare risposte alle nuove esigenze. Risposte condensate nelle raccomandazioni che seguono.
• L’insieme dei sistemi di automazione destinati ai processi sia per gli ambiti clinici che per quelli amministrativi delle AO o ASL già risulta presente, sviluppato, nonché testato. Prima di una nuova acquisizione, una puntuale indagine, benchmarking, ecc., eviterà buona parte di possibili errori e/o sorprese. Il riferimento agli standard già esistenti e nel seguito menzionati sarà ulteriore fonte di sicurezza nelle scelte e nello sviluppo di ogni Sistema sia Informativo quanto organizzativo.
• L’insieme dei pacchetti SW, soluzioni HW, ovvero interi Sistemi più complessi debbono sempre e senza eccezione essere conformi a Standard specifici che ne consentano in prima istanza l’integrabilità nel tempo ovvero la scalabilità verso diverse soluzioni tecnologiche. Tale insieme non deve obbligare ad ulteriori dispendiosi e spesso non necessari acquisti; soprattutto se con ciò si intenda: acquisti obbligati da comportamenti,
policy o decisioni dei diversi fornitori.
• Nell’acquisto o anche nell’esternalizzazione di processi informatici, anche non necessariamente riferibili al core business, il committente manterrà il controllo, la conduzione e l’indirizzo del Sistema nonché la possibilità istantanea di gestione del dato di cui resta proprietario e responsabile come della struttura complessa dei database ove i dati risultano memorizzati. Il committente, dotato sempre di una adeguata competenza tecnica, dovrà essere in grado di ricercare, selezionare, estrarre e comprendere i dati caratterizzanti i suoi processi produttivi ed organizzativi.
• Ogni acquisto deve essere dotato di garanzia valida anche per periodi successivi la singola fornitura. Meglio se aggiornato alle nuove release della soluzione acquistata.
• Gli acquisti inerenti componenti hardware e software, ovvero di reti e di ambiente dovranno essere il più possibile autonomi tra di loro ed in ogni caso riconducibili a scelte e responsabilità del fornitore.
• Le forniture, ad ogni tipologia riconducibili, dovranno essere dotate di supporto H24 on site soprattutto se inerenti processi critici come i clinici ovvero gli economici degli ADT.
• Se disponibile commissionare un’apposita analisi tipo HTA (Health Technology Assessment)
• Relativamente all’architettura complessiva del sistema informativo:
– l’architettura della funzionalità utente deve essere web, senza richiedere l’installazione di componenti di sorta sulle stazioni di lavoro
– le applicazioni devono preferenzialmente essere in grado di operare anche su dispositivi mobili (Windows, Android, Apple)
– l’architettura deve prevedere la presenza di un repository aziendale integrato, nel quale organizzare tutti i dati – clinici, organizzativi ed amministrativi – ivi incluse le classificazioni, le codifiche e gli altri dati descrittivi di validità generale per tutta la struttura. La struttura del repository deve essere documentata, in modo da consentire all’Ente appaltante l’accesso autonomo alle informazioni, mediante il linguaggio SQL. Costituisce fattore preferenziale la rispondenza del repository allo standard ISO-EN-UNI 12967 “Health Informatics Service Architecture”
– le applicazioni, preferenzialmente, operano direttamente sul repository senza implementare una base dati nativa; alternativamente, possono operare su una propria base dati autonoma, mantenendo comunque la sincronizzazione dei dati (pazienti, episodi, prestazioni, codifiche, referti, ecc.) con il repository aziendale.
– il sistema, in tutte le aree applicative, deve essere in grado di interagire con sistemi di terze parti mediante messaggi conformi agli standard menzionati in questo documento (es. standard HL7), almeno per quanto riguarda: l’anagrafica pazienti, i ricoveri, il ciclo delle prestazioni (richiesta, programmazione, esecuzione), la distribuzione dei referti.
– il sistema deve preferibilmente implementare una logica di “single sign on” che consenta a tutti gli utenti di accedere con le stesse credenziali a tutte le applicazioni. Parallelamente, il sistema deve preferenzialmente implementare un ambiente unificato mediante il quale consentire agli uffici aziendali preposti di definire in modo centralizzato i profili di abilitazione per ogni utente a tutte le singole applicazioni, in termini di funzionalità eseguibili e dati a cui è concesso l’accesso.
– per tutte le applicazioni i sistema deve rispondere ai requisiti del Dlgs 196/2003 “Codice in materia di protezione dei dati personali”.
– per tutte le applicazioni, il sistema deve – preferenzialmente – tenere traccia di tutte le variazioni introdotte nel tempo sulle singole informazioni. Il periodo di conservazione di questa storia deve essere gestibile dai responsabili tecnici del sistema.
• Relativamente alla certificazione dei fornitori:
– i fornitori (diretti o sub-appaltatori) delle procedure software devono essere certificati secondo lo standard di qualità ISO 9001:2000, meglio se nella più recente versione ISO 9001:2008.
– elemento preferenziale sarà la certificazione –in aggiunta alla ISO 9001- anche secondo la norma UNI-CEI-EN-ISO 13485 “Dispositivi medici- sistemi di gestione della qualità” che definisce ulteriori requisiti qualità propri per la produzione di software sanitario.
