Linee di indirizzo alle Aziende Sanitarie per l'implementazione del sistema Informativo Sanitario Regionale

Capitolo 7. La carta dei principi tecnologici del procurement

Puoi partecipare alla Consultazione commentando il testo riportato in questa pagina. Per inviare il tuo contributo clicca sull'icona a destra del paragrafo che intendi commentare e inserisci il testo del tuo commento.

La carta dei principi tecnologici del procurement definisce i criteri minimi per lo sviluppo di servizi digitali della Pubblica Amministrazione che:permalink frase

+

• soddisfino le esigenze degli utenti/cittadini;permalink frase

+

• siano facilmente manutenibili;permalink frase

+

• siano capaci di evolvere in base alle esigenze dei cittadini e al progresso tecnologico;permalink frase

+

• siano indipendenti da singole componenti architetturali di terze parti;permalink frase

+

• riducano le situazioni di dipendenza da un ristretto numero di fornitori (lock-in).permalink frase

+

La carta dei principi tecnologici del procurement raccoglie ed estende le linee guida definite dal Codice dell’Amministrazione Digitale e dal Piano Triennale, riportando in alcuni casi anche norme di legge esistenti, per fornire una visione organica dei principi che la Pubblica Amministrazione e i suoi fornitori dovrebbero rispettare per lo sviluppo di nuovi servizi digitali e per la gestione del ciclo di vita di tali servizi.permalink frase

+

Partire sempre dalle esigenze degli utenti. Inserire nel capitolato di gara una specifica richiesta per seguire le linee guida di design e i processi di sviluppo di Designers Italia (https://designers.italia.it/) nella realizzazione dei servizi, seguendo un percorso di User Research, Service Design, User Interface Design e Content Design. Se ritenuto opportuno la fase di User Research può essere condotta anche in via preliminare dalle amministrazioni al fine di supportare la stesura della gara.permalink frase

+

Organizzare la progettazione e lo sviluppo dei servizi digitali adottando ove possibile processi incrementali per il rilascio, sfruttando interazioni brevi e frequenti. Il primo rilascio del servizio deve prevedere il numero minimo di funzionalità essenziali utili a raccogliere informazioni dagli utilizzatori e aggiustare il tiro delle fasi successive, che devono essere opportunamente pianificate in durata e numero tali da ottenere una roadmap con rilasci periodici. Ogni rilascio deve essere stato testato da utenti reali e documentato. I capitolati di gara devono prevedere l’applicazione di tale principio.permalink frase

+

Assicurarsi che la tecnologia e i servizi sviluppati siano accessibili agli utenti. Inserire nel capitolato l’obbligo di usare gli strumenti forniti da Designers Italia per assicurare che i servizi siano progettati a misura di cittadino, applicando criteri di usabilità e inclusività per aiutare le persone con disabilità (http://design-italia.readthedocs.io/it/stable/doc/service-design/accessibilita.html).permalink frase

+

Pubblicare il codice con licenze open source per migliorare la trasparenza, la flessibilità e la responsabilità: seguire le linee guida per l’acquisizione e il riuso del software (https://lg-acquisizione-e-riuso-software-per-la-pa.readthedocs.io/it/latest/). Inserire nel capitolato l’obbligo di rilasciare alla pubblica amministrazione la proprietà intellettuale del software che viene sviluppato ad hoc, incluse le pagine dei siti web, e di pubblicare il software sotto licenza aperta, registrandolo su Developers Italia con i processi indicati nelle linee guida.permalink frase

+

Usare standard aperti per garantire che la tecnologia sviluppata funzioni e comunichi con altre tecnologie e possa essere facilmente aggiornata e ampliata. Inserire nel capitolato l’obbligo di utilizzare standard e formati aperti per file e protocolli di comunicazione, l’obbligo di implementare le funzionalità in forma di API documentate secondo le linee guida di interoperabilità (https://developers.italia.it/), l’obbligo di fornire funzionalità di esportazione di tutti i dati in formati aperti, l’obbligo di documentare la futura procedura di migrazione verso un prodotto alternativo.permalink frase

+

Cloud First. Utilizzare sempre prima le risorse del Cloud della PA come indicato dal Piano Triennale in materia di cloud. Inserire nel capitolato l’obbligo di utilizzare le risorse qualificate nell’ambito del Cloud della PA (https://cloud.italia.it/projects/cloud-italia-docs/it/latest/), prediligendo i servizi SaaS dei fornitori qualificati, ogni qualvolta viene sviluppato un nuovo servizio. Qualora i servizi SaaS esistenti nell’ambito del Cloud della PA non siano rispondenti alle esigenze del progetto, prevedere l’utilizzo di servizi infrastrutturali IaaS e PaaS del Cloud della PA; inserire nel capitolato l’obbligo di supporto per il protocollo di rete IPv6.permalink frase

+

Mantenere sistemi e dati al sicuro rispettando i livelli minimi di sicurezza. Inserire nel capitolato l’obbligo di rispettare le Misure Minime di Sicurezza (https://www.agid.gov.it/it/sicurezza/misure-minime-sicurezza-ict), così come previsto dalle linee guida di sicurezza del Piano Triennale; inserire nel contratto clausole di manutenzione che impegnino il fornitore a rilasciare patch di sicurezza che verranno scoperte anche al termine del contratto.permalink frase

+

Assicurarsi che i diritti dei cittadini siano protetti integrando la privacy come parte essenziale del sistema. Inserire nel capitolato l’obbligo di rispettare le prescrizioni della normativa italiana ed europea sulla protezione dei dati personali (GDPR).permalink frase

+

Promuovere buone pratiche ed evitare duplicazione di sforzi condividendo e riutilizzando servizi, dati e componenti software. Inserire nel capitolato l’obbligo di integrare le piattaforme abilitanti come SPID, pagoPA e ANPR (ove applicabili), incluse le piattaforme condivise tipiche del dominio nel quale si opera, come ad esempio il Fascicolo Sanitario Elettronico (FSE), nel caso di una PA dell’ecosistema sanitario; inserire nel capitolato l’obbligo di riutilizzare software, servizi e API messi a disposizione da altre PA evitando ove possibile di re-implementare funzionalità che sono già state implementate da altri; nell’eventualità di sviluppo di nuovi servizi, richiedere che l’applicativo sia sviluppato tenendo presente che possa essere utilizzato da altre PA.permalink frase

+

La tecnologia sviluppata o acquistata deve funzionare con il resto delle tecnologie, i processi e le infrastrutture esistenti nell’organizzazione e deve poter adattarsi alle esigenze future. Eseguire una valutazione del debito tecnologico presente nell’organizzazione e pianificare la sostituzione delle tecnologie ormai obsolete per le quali il costo di manutenzione eccede il costo di sostituzione; inserire nel capitolato l’obbligo di utilizzare tecnologie aperte affermate sul mercato e supportate dalla presenza di un’ampia comunità di sviluppatori e utilizzatori; Studiare e implementare soluzioni per minimizzare la raccolta e facilitare il riutilizzo dei dati evitando la duplicazione di dati. Inserire nel capitolato l’obbligo di utilizzare i dataset rilasciati in open data da altre PA, l’obbligo di utilizzare i vocabolari controllati e le ontologie descritti nel Piano Triennale, l’obbligo di rilasciare in open data tutti i dati prodotti dagli applicativi per i quali la pubblicazione non sia esplicitamente vietata per legge.permalink frase

+

Ridisegnare i processi automatizzando il lavoro ripetitivo. È necessario ridisegnare e ripensare i processi rendendoli nativamente digitali, ridurre il più possibile l’intervento manuale nelle attività ricorrenti e non qualificate (data entry, etc.), automatizzando i processi necessari all’erogazione di un servizio e utilizzando l’intervento umano per il controllo della qualità e il monitoraggio.permalink frase

+

Stabilire i livelli di servizio per i servizi erogati. Utilizzare indicatori (SLI, Service Level Indicator) oggettivi e misurabili al fine di stabilire obiettivi specifici (SLO, Service Level Objectives) di affidabilità e qualità del servizio, definendo le necessarie penali in caso di mancato raggiungimento degli obiettivi (SLA, Service Level Agreement). Definire le competenze e i profili necessari per lo sviluppo dei servizi digitali. Valorizzare le professionalità a disposizione della PA seguendo le linee guida per la qualità delle competenze digitali nelle professionalità ICT (https://bit.ly/2RtOXyF).permalink frase

+

Introdurre sistemi di valutazione dei progetti ex-post. Nelle clausole dei contratti è necessario prevedere sistemi di valutazione dei progetti eseguiti così che le PA possano indirizzare le proprie scelte, anche tenendo conto delle recensioni di altre PA sull’operato di uno specifico fornitore.permalink frase

+

Pubblicare i documenti di postmortem quando si verifica un disservizio evidenziando le cause principali e le attività intraprese per evitare che riaccada. Incidenti ed errori sono all’ordine del giorno in ambito tecnologico ed è necessario apprendere da essi per evitare che accadano nuovamente in futuro. Nei contratti con i fornitori è necessario prevedere l’obbligo di fornire una comunicazione puntuale e trasparente delle cause che hanno procurato il disservizio producendo dei documenti di “postmortem” di dettaglio che potranno essere pubblicati dalle amministrazioni.permalink frase

+