DOCUMENTO TECNICO
DOCUMENTO TECNICO
Applicativo web per la governance delle attività erogative di medicina del Lavoro di ATS Città Metropolitana di Milano
1.1 Altre definizioni, abbreviazioni e sigle
Sistema | Con sistema si intende complessivamente l’insieme dei moduli applicativi, delle basi dati e delle interfacce, grafiche e di comunicazione, che costituiscono l’oggetto della presente Fornitura. |
Utente | Con utente si intende un generico utilizzatore del sistema; ogni utente è caratterizzato da un proprio profilo ed ha la visibilità delle sole aree applicative connesse al proprio utilizzo del sistema. |
SPOC | Single Point Of Contact. Il referente unico di contatto del fornitore per tutta la durata del contratto. |
ANAC | Autorità Nazionale Anticorruzione. |
GDPR | General Data Protection Regulation (UE) 2016/679. |
AgID | Agenzia per l’Italia Digitale. |
ACN | Agenzia per la Cybersicurezza Nazionale. |
FP | Function Point è una metrica utilizzata per esprimere la dimensione o misura delle funzionalità fornite da un prodotto software (secondo la metodologia IFPUG 4.3 ed eventuali versioni successive). |
PA | Con il termine “PA” o “P.A.” va intesa la Pubblica Amministrazione. |
Piattaforma Sintel | Piattaforma di e-procurement di Regione Lombardia, istituita con lo scopo di realizzare un sistema di Intermediazione Telematica che supporti la Regione e tutte le PA della Lombardia nella realizzazione delle proprie gare. |
OE | Operatore Economico. |
OTP | One Time Password: password utilizzabile per una singola sessione (monouso). |
RL | Regione Lombardia. |
Cloud computing | Si indica un modello di erogazione di servizi offerti on demand da un fornitore ad un cliente finale attraverso la rete Internet. |
CSP | Cloud Service Provider |
SaaS | Software as a Service. |
È un paradigma di servizio cloud attraverso il quale il fornitore di software applicativo sviluppa e gestisce un'applicazione web che mette a disposizione dei propri clienti via Internet. | |
OWASP | Open Web Application Security Project. Progetto open-source con l'obiettivo di realizzare linee guida, strumenti e metodologie per migliorare la sicurezza delle applicazioni. |
AD | Active Directory. |
CA | Certification Authority. |
HA | High Availability. |
SSO | Single Sign On. |
QA | Quality Assurance. |
VAPT | Vulnerability Assessment & Penetration Test. |
SISS | Sistema Informativo Socio-Sanitario di Regione Lombardia. |
2 Premessa
2.1 Scopo del documento
ATS Città Metropolitana di Milano (ATS) ha l’esigenza di acquisire, la fornitura di un applicativo software web-based, nel seguito meglio dettagliato, destinato alla gestione della cartella sanitaria della medicina del lavoro.
2.2 Ambito della fornitura
La fornitura deve comprendere integralmente quanto segue:
• una applicazione web secondo la modalità di fornitura;
• la copertura di tutti i requisiti funzionali, non funzionali, tecnici, tecnologici ed operativi espressi nel presente documento;
• il rispetto dei principi di "Privacy by design". Il Fornitore deve dare evidenza di quelle che sono le soluzioni che intende adottare al fine di garantire:
✓ una difesa per livelli (cosiddetta “defense in depth”);
✓ la segregazione dei dati, ovvero componenti infrastrutturali separate (es. DB, logic app, web application server);
✓ il principio del "least privilege", ovvero minimizzazione dei privilegi di accesso a dati e funzionalità;
✓ la pubblicazione ed erogazione dell'applicazione su rete pubblica (Internet) attraverso una soluzione di Web Application Firewall che implementi l’ultima versione del set di policy OWASP. Il set di regole e policy dovrà essere mantenuto aggiornato nel tempo, le regole dovranno essere in modalità “block”;
✓ il monitoraggio da parte dell’ATS di Milano deve essere garantito attraverso:
o l’accesso in sola lettura alle risorse;
o la visibilità dei sistemi di sicurezza (log e regole); la soluzione software deve prevedere la funzionalità di review periodica degli accessi, consentendo agli amministratori delle utenze di verificare puntualmente tutti i soggetti autorizzati e i log di utilizzo (es. suggerimenti di utenti da disattivare in base all’ultimo accesso);
o l’accesso agli indicatori delle prestazioni infrastrutturali ed applicativi (analisi dei tempi di risposta, del numero di risposte di errore, del workflow di utilizzo dell’applicativo per valutare l’efficacia del flusso di lavoro previsto per l’utente finale;
o la verifica delle versioni delle componenti software che devono essere costantemente aggiornate, ovvero adozione delle ultime versioni dei protocolli di cifratura (HTTPS per le pagine web, TLS per comunicazioni con DB, autenticazione o altre risorse) e disabilitazione dei protocolli/versioni non più sicure (soggette a vulnerabilità riconosciute tramite CVE xxxxx://xxx.xxxxx.xxx/). Il fornitore deve assicurare e mantenere il vincolo degli aggiornamenti di tutte le componenti software (es. sistema operativo server, middleware, web server, DBMS, …) per tutta la durata contrattuale.
• l’attività di formazione all’utilizzo del sistema da parte delle diverse tipologie di utenza se previste, sia presso la sede di ATS che eventualmente in modalità da remoto da concordare con ATS;
• l’attività di assistenza tecnica e manutenzione correttiva, preventiva programmata, normativa ed evolutiva per garantire la continuità operativa a tutti gli utilizzatori del sistema in alta disponibilità, a partire dal rilascio in produzione fino alla scadenza prevista dal contratto;
• per tutta la durata contrattuale, la produzione di tutti i certificati digitali necessari per la gestione del sistema informativo e validi per tutti gli ambienti operativi messi a disposizione di ATS; tali certificati digitali dovranno essere intestati ad ATS ed emessi da una Certification Authority (CA) italiana pubblicamente riconosciuta;
• per tutta la durata contrattuale, il servizio di hosting di una infrastruttura in cloud SaaS in linea con la normativa vigente che garantisca almeno due ambienti operativi indipendenti (collaudo, produzione) in Alta Disponibilità (High Availability, HA);
• la predisposizione del repository del codice sorgente nella sottoscrizione Microsoft Azure DevOps di ATS e relativo caricamento unitamente a tutta la documentazione di progetto e di esercizio realizzata specificatamente per ATS;
• la cessione perpetua del codice sorgente relativo a tutte le personalizzazioni sviluppate per ATS, alle configurazioni sistemistiche, alla base dati integrale, nonché della documentazione tecnica e di esercizio prodotta per ATS;
• le attività connesse alla messa in riuso del codice sorgente realizzato relativo a tutte le personalizzazioni e integrazioni dedicate ad ATS, secondo quanto previsto dalle Linee
Guida AgID e dai relativi allegati tecnici; a questo proposito deve essere predisposto un ulteriore repository di codice “pulito” al fine della idonea pubblicazione del codice sorgente su Developers Italia;
• il supporto ad ATS e ai propri fornitori terzi per la messa a punto delle eventuali integrazioni applicative richieste;
• le attività di migrazione nel sistema in cloud dei dati storici secondo quanto indicato al requisito MIG1 – “Migrazione dati storici”; attività connesse alla standardizzazione, normalizzazione e importazione dei dati storici, anagrafiche ed elenco delle utenze che necessariamente andranno a popolare il DB dell’applicazione definendo una banca dati consistente di partenza.
I dati da considerare oggetto di importazione riguarderanno un arco temporale, da stabilire con ATS, antecedenti l’avvio del nuovo sistema in produzione. L’attività di importazione del pregresso dei dati sopra descritti deve essere stimata all’interno del cronogramma assieme alle altre attività pianificate. ATS si impegna a fornire i nominativi degli operatori (key user) a cui riferirsi per il reperimento dei dati di interesse;
• export dell’intera base dati, in un formato standard, aperto e documentato (attraverso metadati), senza oneri deve essere disponibile in ogni momento su richiesta di ATS e al termine del contratto con contestuali verifiche che attestino l’allineamento di quanto esportato rispetto a quanto presente in produzione per tutte le componenti del sistema. In caso si verifichino problematiche relative a quanto esportato, a termine del contratto, io fornitore dovrà garantire, senza oneri aggiuntivi, la coerenza e la consistenza della base dati esportata. In ogni momento su richiesta di ATS i dati sulla piattaforma SaaS del fornitore devono essere resi disponibili ad ATS; tale requisito deve sussistere soprattutto alla scadenza del contratto, quando il Fornitore deve garantire ad ATS il necessario supporto alla migrazione verso una nuova infrastruttura cloud qualificata ACN;
• implementazione di strumenti di test automatici (come Azure Test Plan) per garantire la non regressione delle funzionalità esistenti a fronte delle eventuali attività evolutive;
• attività di integrazione con la piattaforma SISS di Regione Lombardia (e successive evoluzioni legati alla tecnologia di firma remota) e supporto alla validazione di ARIA in merito ai relativi scenari di integrazione nel caso venissero contemplati.
2.4 Contesto normativo, tecnologico e operativo
Il sistema informativo richiesto da ATS prevede che tutte le componenti applicative e dati siano erogate in ambiente cloud, conformemente alla normativa vigente a cui si rimanda per completezza con particolare riferimento ai criteri per la qualificazione dei servizi cloud per la PA.
La soluzione applicativa dovrà essere basata su tecnologie di cloud computing secondo il paradigma SaaS (Software as a Service). A partire dalla data di sottoscrizione del contratto la fornitura richiesta dovrà contemplare il servizio di hosting di una infrastruttura in linea con la normativa vigente (fare riferimento al capitolo “Riferimenti documentali e normativi”). In considerazione delle caratteristiche tecnologiche richieste, la soluzione progettuale dovrà richiedere la disponibilità di risorse o infrastrutture integralmente a carico del fornitore. Il fornitore dovrà garantire la produzione di tutti i certificati digitali necessari per la gestione sicura dell’applicazione web erogata.
Con riferimento al Decreto direttoriale prot. N. 29 del 02/01/2023 dell’Agenzia per la Cybersicurezza Nazionale (ACN) è disponibile la procedura di qualificazione dei servizi cloud per la PA. A questo proposito ATS richiede che il servizio SaaS erogato dal fornitore venga “qualificato” da ACN e pubblicato nel relativo Cloud Marketplace (ACN Cloud Marketplace).
In relazione alla natura dei dati trattati e del servizio digitale erogato, il fornitore dovrà garantire un servizio qualificato almeno QC1 secondo quanto previsto da ACN.
ATS richiederà che il fornitore sia in possesso della certificazione secondo lo standard ISO/IEC 27001 estesa con i controlli degli standard ISO/IEC 27017 e ISO/IEC 27018. Tale certificazione dovrà essere stata rilasciata da organismi nazionali di accreditamento riconosciuti dalla Unione Europea. Ciò è volto ad assicurare che il fornitore abbia adottato misure tecniche ed organizzative volte a minimizzare il rischio di perdita di integrità (anche accidentale) dei dati, di accesso non autorizzato, di trasmissione non sicura, di illecita diffusione, di trattamento non consentito o non conforme alle finalità della raccolta. Il fornitore dovrà, in sintesi, mettere a disposizione di ATS una soluzione tecnologica ed operativa che garantisca il rispetto dei previsti obiettivi di sicurezza, dal punto di vista della confidenzialità, integrità e disponibilità dei dati trattati.
Il fornitore dovrà dare evidenza ad ATS di eventuali altri soggetti o subfornitori che concorrano all’erogazione del servizio di cloud hosting e quindi al trattamento dei dati. Il gestore dei servizi cloud (CSP, Cloud Service Provider) scelto dal fornitore dovrà garantire una infrastruttura qualificata almeno QI1 secondo quanto previsto da ACN. A maggior tutela dei dati personali trattati, ATS richiede che il CSP scelto dal fornitore garantisca la conservazione dei dati e/o delle relative chiavi di cifratura esclusivamente in data center collocati (region) nel territorio italiano.
È compito di ATS verificare l’effettivo rispetto delle dichiarazioni prodotte in sede di qualificazione dal fornitore. In caso di servizi non conformi a quanto dichiarato dal fornitore, ATS è tenuta a segnalare la circostanza ad AgID e ACN proponendo, in caso di esito confermativo dell’apposita verifica, la revoca della qualificazione.
In relazione agli obblighi e alle responsabilità del fornitore relativamente al trattamento dei dati, con particolare riferimento a quelli personali e sensibili, la Fornitura prevede la sottoscrizione di una adeguata polizza assicurativa per ottemperare alla responsabilità risarcitoria a fronte di eventuali danni, economici e/o di immagine, causati da violazioni agli obiettivi di sicurezza previsti da ATS ed i cui termini sono disciplinati all’interno nel documento “Capitolato Speciale di Appalto”. Occorre fare pertanto riferimento a tale documento per la descrizione esaustiva delle clausole, delle responsabilità e delle azioni contrattuali previste a carico del fornitore in relazione alla eventuale perdita, all’illecita diffusione dei dati trattati e gestiti nel cloud ed all’interruzione del servizio erogato. Si ricorda inoltre che nella nomina del fornitore a Responsabile al Trattamento Esterno dei dati (Regolamento UE 679/2016) sono già indicati i compiti, gli obblighi e le responsabilità contrattuali del fornitore previsti da ATS.
Per una copertura completa dei requisiti richiesti in ambito di servizi cloud occorre fare riferimento alla normativa nazionale vigente ed a quanto indicato al capitolo “Progettazione, realizzazione e delivery” del presente documento.
Al fine di permettere ad ATS di valutare l’efficacia del servizio SaaS erogato, il fornitore dovrà rendere disponibile ad ATS strumenti idonei di monitoraggio, di audit, di Quality Assurance (QA) e di accesso alle basi dati dell’applicativo, oltre che consentire di effettuare verifiche di conformità alla normativa in materia di privacy, sicurezza e accessibilità.
Si sottolinea che ogni passaggio in produzione di software sviluppato dal fornitore e di ogni personalizzazione dedicata ad ATS, dovrà essere necessariamente condiviso e concordato con i referenti di progetto di ATS a cui dovrà essere data evidenza del buon esito dei test automatici di non regressione effettuati.
L’utilizzo delle funzionalità del sistema informativo deve essere possibile attraverso i più diffusi browser Internet senza la necessità di installazione di software specifico sulle postazioni di lavoro (plug-in O agent); l’accesso ai dati ed alle funzionalità applicative deve essere possibile solo agli utenti abilitati in funzione dei previsti livelli e profili di accesso.
Le performance del sistema erogato dovranno in ogni caso essere adeguate all’effettivo numero di accessi concorrenti che si avranno a regime ed all’eventuale aumento dei dati trattati. La soluzione web dovrà prevedere l’espandibilità del numero di utenti e garantire la scalabilità delle risorse cloud per gestire efficacemente anche potenziali condizioni di picco delle attività, degli accessi e del trattamento dei dati.
2.5 CERTIFICAZIONI
A partire dalla data di sottoscrizione del contratto, il fornitore dovrà produrre tutti i certificati digitali necessari per la gestione del sistema informativo e relativi a tutti gli ambienti operativi dedicati ad ATS (collaudo, produzione) ed erogare i relativi servizi di cloud hosting attraverso una infrastruttura SaaS che garantisca ad ATS la disponibilità, come detto, di due ambienti operativi indipendenti (collaudo, produzione).
Tutti i certificati digitali, inoltre, devono necessariamente essere emessi da una Certification Authority (CA) italiana pubblicamente riconosciuta ed andranno intestati ad ATS.
Le attività di, formazione (comprensiva di fornitura di un corso in modalità FAD, come menzionato nel Cap.6) saranno preventivamente concordate con ATS a fronte della data di sottoscrizione del contratto.
In esito al collaudo positivo, decorrerà il servizio di assistenza tecnica e manutenzione che il fornitore dovrà garantire sino alla scadenza naturale del contratto.
Alla conclusione naturale del contratto è prevista la possibilità di prorogare i servizi di manutenzione correttiva e di assistenza tecnica, senza variazioni di canone.
Alla conclusione naturale del contratto il fornitore è tenuto a garantire ad ATS il trasferimento integrale della base dati, opportunamente documentata attraverso metadati ed in un formato aperto e non proprietario; per lo svolgimento di queste attività il fornitore non potrà imputare alcun costo ad ATS in quanto già dovuti e ricompresi nel presente contratto.
In generale, in linea con quanto previsto dalla normativa e dalle Linee Guida AgID, il fornitore è tenuto a garantire, in ogni momento e senza oneri per ATS, l’export dell’intera base dati, in un formato standard, aperto e documentato (attraverso metadata e schema E-R del DB relativa all’ultima versione funzionante in produzione).
In linea con la normativa vigente (fare riferimento al capitolo “Riferimenti documentali e normativi” del presente documento), al termine del contratto il fornitore deve consentire la migrazione dei dati del servizio verso un altro gestore SaaS, con conseguente eliminazione permanente dai propri archivi dei dati di proprietà di ATS.
Si ribadisce che al termine del contratto o in qualsiasi momento solo dopo esplicita richiesta del Titolare, i dati in possesso del fornitore o e/o di eventuali suoi subfornitori dovranno essere cancellati, in qualsiasi forma essi siano detenuti.
2.6 Titolarità del codice sorgente
Tutto il software sviluppato specificatamente per conto di ATS (nel caso si rendessero necessarie funzionalità non native del software acquisito in licenza d’uso) e relativo alla presente fornitura, unitamente a tutte le successive modifiche evolutive che verranno introdotte dal fornitore nel corso del contratto, unitamente a tutta la documentazione tecnica e di esercizio prodotta, devono intendersi di proprietà intellettuale di ATS, che avrà facoltà di poter cedere in riuso tutto il software sviluppato e le previste personalizzazioni agli Enti Pubblici che lo dovessero richiedere. Le personalizzazioni potranno essere segnalate ad AgID attraverso il repository Developers Italia, anche nel caso di fornitura di prodotto commerciale in licenza d’uso. Nella messa in riuso del codice sorgente, sviluppato specificatamente per conto di ATS, devono essere indicate tutte le dipendenze dal software proprietario offerto eventualmente in licenza d’uso.
3 Requisiti Funzionali di prodotto
Il sistema oggetto del presente capitolato tecnico prevede una serie di funzionalità generali del servizio, nonché aspetti specifici dell’applicativo richiesto.
Si sottolinea che, per completezza, sono da considerarsi parti integranti della presente specifica funzionale tutti i riferimenti tecnici e tecnologici (requisiti non funzionali), bibliografici, documentali e normativi referenziati all’interno del presente documento.
Tutti i requisiti funzionali oggetto del presente capitolo sono da considerarsi “obbligatori” (ovvero, ATS li ritiene indispensabili per l’avvio del sistema in produzione) ad eccezione di GEN2 E GEN3 di seguito descritti.
3.1 Requisiti generali del servizio
GEN1 | Console di amministrazione |
Il sistema deve prevedere una console di gestione dedicata agli amministratori per svolgere le necessarie attività di configurazione lato back-office, in particolare: • creazione, configurazione e profilazione delle diverse tipologie di utenza; • configurazione di tutte le proprietà degli oggetti gestiti dall’applicazione; • configurazione template reportistica; • configurazione alert di notifica / comunicazioni di servizio; • configurazione Informative Privacy (SEC3); • consultazione dei log applicativi relativi alle funzioni/attività degli utenti sul software. Si sottolinea che il sistema deve garantire l’integrità e quindi la non modificabilità dei log applicativi per finalità di controllo e di tracciamento delle attività degli utenti da parte di ATS con particolare riferimento agli aspetti di performance dell’applicativo. I dati sopra citati devo essere disponibili con una profondità temporale di almeno sei mesi. |
GEN2 | Identificazione & Autenticazione degli utenti |
Il sistema deve consentire l’identificazione e l’autenticazione (I&A) di utenti interni. Gli utenti interni ad ATS devono accedere al sistema tramite le credenziali del dominio Azure Active Directory (AD) di ATS. Questo unico requisito, probabilmente non nativo nell’applicazione acquisita, sarà oggetto di programmazione di realizzazione successiva concordata con ATS. Il sistema deve gestire ruoli e gruppi di utenti, per poter configurare i corretti privilegi di accesso ai dati. |
GEN3 | Single Sign On (SSO) |
Il sistema deve permettere ad ogni utente interno di ATS l’accesso alle funzionalità e risorse dell’applicativo in modalità Single Sign On (SSO) ovvero inserendo una sola volta le credenziali di accesso dalla propria postazione di lavoro (PdL), senza richiedere ulteriori richieste di autenticazione nel passaggio da un contesto applicativo all’altro, accedendo a tutte le aree dell’applicativo, ai moduli ed alle funzionalità per cui l’utente stesso è stato autorizzato. La funzionalità di SSO deve essere garantita a tutti gli utenti interni autorizzati di ATS attraverso l’integrazione e la sincronizzazione con i meccanismi di Azure AD del dominio ATS al fine di consentire l’accesso con le stesse credenziali di dominio (fare riferimento al requisito GEN2 “Identificazione & Autenticazione degli utenti”. |
GEN4 | Personalizzazioni |
Possibilità di personalizzare i protocolli sanitari e i parametri dei vari indicatori. | |
GEN5 | Gestione dei rischi |
Importazione ed esportazione massiva dei dati identificativi e di rischio di aziende e dipendenti. | |
GEN6 | Condivisione dei dati |
Possibilità di condivisione dei dati (es. invio giudizio idoneità e cartella sanitaria via e- mail). | |
GEN7 | Stampe, ricerca e reportistica |
Il sistema deve implementare le seguenti funzionalità applicate ai diversi contesti d’uso descritti nel documento: • gestione delle stampe; • strumenti e filtri di ricerca; • export dei dati e dei documenti nei formati standard maggiormente diffusi (ad esempio: Excel, PDF, …); • generazione report e statistiche relativi a ciascuna categoria di dati inseriti. In ragione della natura web-based dell’applicazione software richiesta, il sistema deve garantire la possibilità di effettuare stampe ed estrazioni dati da qualunque postazione di lavoro ed in modo autonomo da parte di un generico operatore ATS. |
poter essere estratti in formato standard e aperto (CSV, ODS, PDF elaborabile, …).
3.2 Requisiti specifici del servizio
MEDLAV1 | Gestione utenze interne |
La gestione delle utenze e dei ruoli devono prevedere diversi livelli di accesso. I livelli riguardano le diverse tipologie di attività espletate nell’applicativo. Nello specifico: • livello amministratore: può accedere e gestire tutte le configurazioni del software (inclusa quella della tabella utenti); • livello utente: può accedere alle specifiche aree configurate dall’amministratore; I ruoli devono essere differenziati in base a specifici profili relativi all’attività dello stesso. Gli accessi riguardano infatti le utenze interne (dipendenti ATS). |
MEDLA2 | Gestione anagrafica delle strutture a cui fanno riferimento i dipendenti |
Gestione anagrafica azienda con indicazione delle sedi, reparti |
MEDLA3 | Importazione/esportazione anagrafica ATS |
Gli utenti amministratori devono poter importare nel database le anagrafiche delle strutture /sedi decidendo se sovrascrivere i dati esistenti o se accodarli. L’attività di importazione deve rispettare vincoli formali relativi ai valori importati nei campi definiti da ATS Milano Gli utenti amministratori, inoltre, devono essere in grado di esportare questa anagrafica in formato .xlsx o .csv. |
MEDLA4 | Sorveglianza Sanitaria |
MEDLA5 | Programmazione visite |
Gestione agenda visite: possibilità di conoscere e pianificare gli accertamenti da svolgere in un determinato periodo con possibilità di esportare i dati in file di utilizzo comune (es. excel) |
MEDLA6 | Statistiche |
Possibilità di estrapolare dati relativi a dipendenti e azienda, statistiche relative a: • visite effettuate, visite da effettuare, test e accertamenti effettuati, parametri rilevati; • questionari somministrati; • Statistiche Covid-19 (soggetti fragili/casi registrati/test effettuati); • Elaborazione relazione sanitaria annuale ai sensi del D. Lgs 81/08; • Elaborazione allegato 3B per invio a INAIL . |
MEDLA7 | Monitoraggio Covid-19 |
• gestione per singola cartella dei dati delle visite
• gestione degli accertamenti (strumentali e di laboratorio) e l'anamnesi lavorativa, familiare, fisiologica patologica prossima e remota, raccordo anamnestico per le visite successive alla prima.
• Gestione di infortuni, malattie professionali ed i giudizi di idoneità.
• Inserimento esame obiettivo con dettagli per apparato e parametri
• Richiamo dei dati precedenti per ogni visita successiva.
• Possibilità di stampa della cartella sanitaria, dei giudizi di idoneità e degli accertamenti in vari formati
• Integrazione con questionari dedicati a valutazioni specifiche: assunzione di bevande alcoliche/stupefacenti; sintomi a carico dell’apparato muscoloscheletrico/visivo; questionario lavoro notturno etc
• Possibilità di condivisione dei dati (es. invio giudizio idoneità e cartella sanitaria via e-mail)
MEDLA8 | Area documenti |
Tutti gli utilizzatori del sistema devono poter scaricare moduli e documenti dal software, ad esempio la gestione informativa per il lavoratore integrata nel giudizio, in forma cartacea o in formato elettronico, trasparente, intellegibile e conforme all’art. 13 del Regolamento UE 2016/679 "GDPR". |
MEDLA9 | Alert |
• L’alert contiene informazioni dell’evento occorso e deve prevedere l’invio di una e-mail agli operatori ATS preposti al controllo (ad esempio MEDLAV4: possibilità di condivisione dei dati (es. invio giudizio idoneità e cartella sanitaria via e-mail) |
MEDLA10 | Strumenti di reportistica |
a) Reportistica Regionale b) Report per anomalie; Elenco reportistica e contenuto desiderato da condividere con ATS. |
- Visite: possibilità di segnalare un lavoratore con particolari fragilità (ipersuscettibilità al Covid-19);
- COVID-19 Test: gestione completa dei test antigenici con possibilità di stampare e firmare il consenso ed il risultato del test
4 Requisiti non funzionali
Si elencano di seguito i requisiti non funzionali, tecnici e tecnologici richiesti al sistema informativo oggetto della presente fornitura.
Tutti i requisiti non funzionali oggetto del presente capitolo sono da considerarsi “obbligatori” (ovvero, ATS li ritiene indispensabili per l’avvio del sistema in produzione).
4.1 Requisiti organizzativi
ORG1 | SPOC (Single Point of Contact) |
Al fine di rendere più efficaci le comunicazioni tra ATS e operatore economico, quest’ultimo dovrà individuare e comunicare ad ATS, fin dalle prime fasi di analisi e durante tutte le fasi operative, un referente unico di contatto (SPOC) per tutta la durata del servizio. |
ORG2 | Assistenza tecnica qualificata |
A seconda della tipologia di intervento richiesto, l’operatore economico metterà a disposizione di ATS un proprio servizio di assistenza tecnica specialistica in grado di intervenire efficacemente, eventualmente anche attraverso work-around temporanei, nonché tempestivamente in funzione del livello di gravità del malfunzionamento. |
ORG3 | Quality Assurance del Software |
richiesto che i fornitori dei servizi di erogazione e gestione del software siano in possesso di alcuni requisiti organizzativi attraverso i quali garantire la gestione dei seguenti processi legati all’erogazione del servizio: • gestione del cambiamento (change management); • gestione delle configurazioni (configuration management); • gestione degli incidenti (incident & problem management); |
4.2 Requisiti di security
SEC1 | Sicurezza logica, fisica e organizzativa |
Dato il grado di confidenzialità delle informazioni gestite dal sistema, l’operatore economico dovrà garantire tutte le misure di sicurezza logica (riservatezza, integrità, |
disponibilità dei dati) e organizzativa per garantire il rispetto della normativa vigente, tenendo conto delle best practices di sicurezza informatica. A tutela del patrimonio informativo dell’Agenzia e della continuità del servizio, il fornitore dovrà indicare quali strategie di disaster recovery e quale piano di business continuity intende adottare durante tutto il periodo contrattuale. |
SEC2 | Privacy |
Fare riferimento alla normativa sulla privacy secondo quanto riportato al capitolo “Riferimenti documentali e normativi” del presente documento. L’operatore economico sarà designato come Responsabile Esterno al trattamento dei dati e conseguentemente assoggettato a tutti gli obblighi previsti dalla normativa di riferimento. | |
SEC3 | Configurazioni Informative |
Il sistema, per tutti gli utenti dello stesso, deve poter gestire diversi avvisi configurabili dagli amministratori e relativi, ad esempio, alla policy Privacy, cookie Privacy, comunicazioni di servizio, etc. | |
SEC4 | GDPR (General Data Protection Regulation) – Regolamento UE 2016/679 |
Le prestazioni oggetto della presente fornitura dovranno essere conformi al Regolamento Generale sulla Protezione dei Dati (GDPR, General Data Protection Regulation – Regolamento UE 2016/679) e alla normativa italiana vigente in materia di protezione (D.lgs. n. 101/2018). |
SEC5 | Protocollo HTTPS |
Il software applicativo, oggetto della fornitura, dovrà essere fruibile dai client esclusivamente mediante protocollo HTTPS. L’operatore economico dovrà provvedere alla fornitura ed al rinnovo dei certificati necessari per il corretto funzionamento del sistema. Ogni certificato fornito dovrà essere emesso da una Certification Authority italiana pubblicamente riconosciuta ed intestato ad ATS. |
SEC6 | Accordi di Non Divulgazione (NDA) e di Trattamento dei Dati (DPA) |
L’operatore economico dovrà garantire la non divulgazione delle informazioni sensibili trattate dal sistema a cui avrà accesso nel corso delle fasi di progettazione, sviluppo, |
SEC7 | Audit e Monitoraggio |
ATS si riserva la facoltà di sottoporre ad audit e monitoraggio tutte le attività del servizio e in particolare relative al trattamento delle informazioni sensibili effettuate dall’operatore economico e dal personale di cui esso intende avvalersi, per tutta la durata del contratto di fornitura. |
NDA) dovranno valere anche dopo la conclusione della presente fornitura.
L’operatore economico dovrà garantire il rispetto di accordi specifici sul trattamento e la protezione dei dati (Data Protection Agreement, DPA), personali e sensibili secondo la normativa vigente, con cui verrà in contatto nel corso delle attività.
4.3 Requisiti e vincoli tecnologici e infrastrutturali
TEC1 | Accesso web |
Le funzionalità messe a disposizione dal sistema dovranno essere raggiungibili dagli utenti utilizzatori attraverso l’accesso alla rete Internet, col solo utilizzo di un browser, senza limitazioni di accessi concorrenti. Si sottolinea quindi che la fruizione delle informazioni tramite Internet non dovrà richiedere l’installazione sui PC dei convenzionati di componenti aggiuntivi oltre ad un web browser. Le funzionalità messe a disposizione dal sistema dovranno essere raggiungibili da qualsiasi dispositivo. Lato client, il sistema deve essere conforme alle normative nazionali in tema di accessibilità dei sistemi informatici. Il rispetto dei requisiti di accessibilità verrà verificato da ATS in fase di collaudo, riservandosi la facoltà di subordinare la valutazione del progetto al parere di una o più associazioni a tutela di disabilità di vario genere. Il sistema informativo dovrà rispettare in particolare i requisiti tecnici di accessibilità riportati nell’Allegato A del Decreto Ministeriale 8 luglio 2005 e successive modifiche. Una particolare attenzione dovrà essere prestata ai temi di accessibilità, secondo quanto previsto dalle più recenti linee guida AgID in tema di design di siti web. La progettazione del portale deve garantire la conformità massima ai requisiti del W3C (priorità 3, AAA) ed il rispetto delle linee guida W3C. Non deve essere richiesta l'installazione o l'utilizzo di componenti aggiuntivi (come ad esempio: plug-in, componenti ActiveX, java applet, DLL, …) né si devono rendere |
TEC2 | Interfaccia web |
Le funzionalità messe a disposizione dal sistema dovranno poter essere fruibili dagli utenti con tutti i principali browser presenti sul mercato, garantendo sempre la corretta rappresentazione dei contenuti da parte dei motori di rendering utilizzati. Per una rapida visualizzazione delle pagine web, il sistema deve garantire un peso pagina web ottimizzato dal punto di vista della dimensione. Le interfacce grafiche esposte dal servizio devono essere “responsive”, quindi in grado di adeguarsi alle esigenze di visualizzazione dei dispositivi mobile, ovvero riducendo al minimo la necessità per l'utente di scorrere o ridimensionare le pagine adattando la dimensione delle immagini ed in generale di tutti i contenuti a larghezza fissa alla risoluzione e alle dimensioni dello schermo visualizzante. La presentazione delle pagine web dovrà essere realizzata in HTML5, dovrà essere omogenea in tutti i contesti con modalità di navigazione quanto più ricorrenti per facilitare l'utente nell'accesso ai contenuti o servizi di interesse. Il sistema nel suo complesso dovrà utilizzare meccanismi di “url rewrite” o implementare un meccanismo di “smart URL” per generare URL di navigazione parlanti. |
TEC3 | Infrastruttura applicativa e scalabilità |
Il fornitore dovrà garantire, nel corso del contratto di manutenzione, l’adeguamento di tutte le componenti applicative e delle relative strutture dati a fronte di eventuali aggiornamenti che si rendano necessari per adeguamenti normativi, di sicurezza o tecnologici. Il sistema dovrà garantire la protezione dei dati memorizzati e gestiti attraverso opportuni meccanismi di backup in sinergia con la infrastruttura cloud utilizzata. Il sistema dovrà essere resiliente rispetto a potenziali rischi di perdita di integrità dei dati trattati anche a fronte di potenziali e imprevisti malfunzionamenti. Il sistema dovrà essere scalabile nella quantità di dati inseriti mantenendo prestazioni inalterate. Il sistema dovrà essere resiliente rispetto a potenziali rischi di degrado delle prestazioni e/o di interruzione, anche temporanea, del servizio erogato onde garantire ad ATS la continuità operativa anche a fronte di potenziali e impreviste attività di picco. L'applicazione non deve avere limitazioni tecniche (ad es., sul numero massimo di utenze attive, sul numero massimo di oggetti da trattare). |
operativi dei client.
TEC4 | Evoluzioni tecnologiche |
Il fornitore dovrà garantire l’adeguamento del sistema informativo oggetto del presente capitolato anche rispetto a nuove versioni ed aggiornamenti del software utilizzato, di browser, sistemi operativi, software di base, middleware che i vari vendor dovessero rilasciare per tutto il periodo di validità contrattuale. |
TEC6 | Performance |
Il sistema deve nel suo complesso (application server, database server, backup server, file server, …) garantire massimi livelli di scalabilità in termini di risorse di calcolo e banda trasmissiva per far fronte ad eventuali picchi di traffico o per eventuali espansioni future, senza alcun costo aggiuntivo per ATS. L’incremento delle risorse dovrà essere garantito “a caldo”, senza interruzioni di servizio. Il servizio di hosting in modalità cloud SaaS deve prevedere una velocità di trasmissione su connessione di rete Internet di 1 Gbit/sec. La capacità di banda trasmissiva dovrà prevedere una banda minima garantita non inferiore ai 100 Mbit/sec e non dovranno essere posti limiti di traffico. ATS richiede preferibilmente l’utilizzo di strumenti di analisi specifici (ad esempio: Google, GtMetrix, WebPageTest, Pingdom, …) per valutare la velocità di caricamento delle pagine del sito e procedere con eventuali ottimizzazioni. ATS richiede che, sia in condizioni nominali che di picco di traffico, una generica pagina web del sito sia caricata indicativamente entro un tempo massimo di 1 secondo (1.000 msec), sia in accesso da desktop che da mobile. Deve essere garantito un efficace monitoraggio, h24 per 365 giorni all'anno, dello stato di disponibilità del servizio di hosting e delle sue componenti (disponibilità del sito web e della banda di connessione) con notifica automatica (e-mail, sms) ad ATS in caso di eventuali disservizi. Il sistema dovrà prevedere la disponibilità di pagine di cortesia o “Landing Page” a cui indirizzare gli utenti del Portale ATS in caso di sua indisponibilità per potenziali disservizi o per attività di manutenzione programmata. La manutenzione programmata dovrà essere sempre condivisa e autorizzata da ATS. Il sistema deve preferibilmente prevedere tecnologie (“agent” Azure Arc o equivalenti) che consentano da parte di ATS il monitoraggio e la corretta applicazione delle policy di sicurezza e infrastrutturali adottate dal fornitore sulla propria sottoscrizione cloud. |
4.4 Requisiti normativi
REG1 | Hosting ed erogazione dei servizi cloud |
Fare riferimento al Decreto direttoriale prot. N. 29 del 02/01/2023 dell’Agenzia per la Cybersicurezza Nazionale (ACN) per la procedura di qualificazione dei servizi cloud per la PA. A questo proposito dovrà essere sodisfatto integralmente quanto specificato al paragrafo “Contesto normativo, tecnologico ed operativo”. |
4.5 Requisiti di usabilità
USA1 | Facilità d’Uso |
Il sistema dovrà essere progettato e implementato in modo da agevolare ogni categoria di utenza prevista durante le relative fasi operative. L’interfaccia grafica dovrà essere implementata in italiano. |
USA2 | Interfaccia applicativo |
L’interfaccia deve permettere di accedere, tramite motori di ricerca interni e specifici oggetti web (es.: voci di menu, listbox, caselle combinate, eTc.) ai dati di pertinenza. Nello specifico, l’utilizzatore deve poter accedere in maniera intuitiva alle funzioni di uso più comune (es.: schermata di ricerca e inserimento dati) comprese quelle di ricerca, salvataggio, modifica ed esportazione dei dati di interesse. |
USA3 | Interfacce Help-On-Line (HOL) |
Il sistema deve disporre di una guida in linea delle funzionalità, ad integrazione della documentazione utente e operativa. La guida in linea deve essere implementata in italiano. L’accesso ad un HOL attivabile dall’operatore per avere supporto sulle funzionalità degli elementi del servizio ed in particolare di quelli codificati deve essere per ogni scenario funzionale previsto. L'applicazione deve presentare eventuali segnalazioni di malfunzionamenti o di violazione di criteri applicativi in modo comprensibile all'utente e fornendo un supporto all'utente per le decisioni conseguenti. Tutte le segnalazioni devono essere inserite nella manualistica di riferimento. |
USA4 | Inserimento dati |
Il sistema deve disporre di opportuni controlli per evitare l’inserimento di informazioni errate e/o incomplete, garantendo controlli di congruenza dei dati inseriti dall’utente. L'applicazione deve cioè auto-proteggersi da eventuali comportamenti operativi non corretti da parte dell’utenza e deve guidare l’utente nella corretta esecuzione delle attività evitando che lo stesso possa svolgere attività non corrette. L'applicazione deve quindi supportare l’attività d'inserimento dati attraverso: − meccanismi che riducano i tempi di lavorazione e migliorino la qualità del dato attraverso la riduzione degli errori: ad esempio, per tutte le proprietà che possono assumere valori predefiniti, selezione dei dati da liste orientate all’utente. − validazione sintattica dei dati specificati: valori ammissibili rispetto alla singola proprietà; obbligatorietà dei dati. validazione semantica dei dati specificati: controlli di coerenza (cioè compatibilità) dei valori attribuiti a proprietà diverse. |
4.6 Requisiti di migrazione
MIG1 | Migrazione ed importazione dei dati storici | |
Vengono considerate secondo quanto indicato nel presente requisito: • Tutte le attività di migrazione nel sistema in cloud dei dati storici e dell’attuale SET di dati presenti costituente il DB dell’attuale fornitura. • Tutte le attività connesse all’ importazione dei dati storici, anagrafiche ed elenco delle utenze che necessariamente andranno a popolare il DB dell’applicazione definendo una banca dati consistente di partenza. Tutte le attività sopra citate e descritte sono totalmente a carico del fornitore e, dal medesimo, devono essere stimate all’interno del cronogramma assieme alle altre attività pianificate e concordate con ATS. La Fornitura dovrà prevedere la predisposizione dei database e dei file interni del sistema (import: anagrafiche, …) e garantire il porting dei dati storici verso la sottoscrizione cloud del fornitore, secondo le tempistiche stabilite da ATS. Tali attività saranno propedeutiche al collaudo, alla formazione ed all’avviamento del sistema in produzione. Sarà cura, pertanto, del fornitore della presente fornitura garantire il corretto e completo popolamento degli archivi per l’avvio del servizio. È fondamentale che ciò |
avvenga nell’assoluta garanzia di continuità di servizio, compreso il periodo di passaggio fra il sistema informativo esistente e quello nuovo offerto. Al termine del servizio è fatto obbligo al fornitore di fornire all’organizzazione eventualmente subentrante i supporti contenenti gli archivi, in formato standard, aperto (ovvero non proprietario) e documentato (metadati) secondo tracciati predefiniti. Tali servizi risultano compresi nei corrispettivi mensili contrattualmente definiti e pertanto nulla sarà dovuto relativamente alle suddette attività e servizi resi. È quindi obbligo del fornitore favorire la portabilità e la interoperabilità dei dati trattati in modo garantire, in ogni momento e su necessità di ATS, il trasferimento dei dati verso ATS, altro fornitore e terza parte individuata da ATS. | ||
4.7 Requisiti di integrazione
INT1 | Scenari di integrazione |
Tutti gli interfacciamenti/integrazioni applicative che il sistema deve preveder devono essere sviluppati offrendo integrazioni sia sincrone che asincrone. Il fornitore deve prevedere un’apposita fase di analisi dedicata alla rilevazione delle integrazioni in essere e, concordemente con i desiderata formulati dall’ATS, procedere con la realizzazione dei flussi di informazioni nel rispetto delle indicazioni sopra menzionate. |
5 Progettazione, realizzazione e delivery
5.1 Responsabilità
Il fornitore è responsabile di tutte le attività di progettazione, realizzazione, personalizzazione e messa in esercizio delle componenti software e personalizzazioni previste dal presente Documento Tecnico.
Per tutto quanto non espressamente menzionato nel presente Documento si richiama quanto disciplinato e previsto dal regolamento adottato dall’AgID con Determinazione del 15 dicembre 2021,
n. 628, dalle determine n. 306 e n. 307 del 18 gennaio 2022 dell’ACN e al Decreto direttoriale prot. N. 29 del 02/01/2023 di ACN e di tutti i relativi allegati.
Sono comprese nella fornitura tutte le attività di predisposizione e caricamento sulla sottoscrizione Microsoft Azure DevOps di ATS del codice sorgente sviluppato per conto di ATS e delle personalizzazioni dedicate ad ATS. Il deployment del software già esistente e degli sviluppi e
personalizzazioni dedicate ad ATS deve essere previsto negli ambienti operativi previsti (collaudo, produzione) in cloud in modalità SaaS, servizio gestito in hosting dal fornitore.
Il fornitore è tenuto a dare evidenza dell’applicazione delle best practices sulla conduzione del progetto, dalla pianificazione, alle scelte organizzative, alle metodologie adottate volte ad assicurare il controllo e la riduzione dei rischi di progetto per tutto il suo ciclo di vita.
Per assicurare ad ATS la supervisione e governance del progetto in tutte le sue fasi, il fornitore è tenuto a adottare gli strumenti Microsoft Azure DevOps utilizzati da ATS ed applicare la relativa metodologia Agile ed un approccio operativo di Continuous Integration/Continuous Delivery.
5.2 Strumenti di project management
Il fornitore è tenuto a adottare gli strumenti di project management Azure Boards, nella sottoscrizione Azure DevOps di ATS, per assicurare ad ATS la massima trasparenza e la governance in tutte le fasi del progetto, ivi comprese quelle di manutenzione ordinaria ed evolutiva.
L’utilizzo della piattaforma Azure DevOps da parte del fornitore deve prevedere:
• Il repository del codice dove devono essere adottate tutte le best practices, come ad esempio la creazione di un master branch che contiene la versione di rilascio consolidata o comunque il core della soluzione software su cui fare il merge degli altri branch di sviluppo solo tramite pull request
• Il repository del codice non deve contenere password, credenziali o stringhe di connessione cablate nel codice o in file di configurazione. È necessario utilizzare i variable groups e/o i key vault. Questo anche al fine di consentire la corretta pubblicazione nel portale governativo del riuso Developers Italia;
• analisi con strumenti di Quality Assurance delle componenti software utilizzate dal progetto per validare gli aspetti legati alle licenze, aggiornamenti delle librerie ed eventuali loro vulnerabilità, qualità del codice sorgente (es. Whitesource Bolt, Sonarqube);
• Pipeline per build e deploy della soluzione software;
• i template di build e deploy dovranno essere realizzati anche in formato compatibile con il cloud di ATS se l’infrastruttura scelta è in un cloud differente da Microsoft Azure. Dovranno essere utilizzati template ARM (Azure Resource Manager) e file YAML.
5.3 Testing, Collaudo ed avvio in produzione
Il sistema oggetto del presente Documento Tecnico è vincolato al superamento di un’opportuna procedura di testing e di collaudo, condivisa con ATS, prima dell’effettiva accettazione del sistema e quindi del relativo rilascio in produzione.
Per quanto riguarda la fase di testing, devono essere garantiti i seguenti aspetti:
• test di performance/carico simulando accesso simultaneo pari al doppio del carico previsto;
• esecuzione delle verifiche in ambiente di test o collaudo prima di ogni rilascio in produzione (procedura di test).
Il collaudo dovrà essere effettuato in un ambiente di test dedicato, messo a disposizione in hosting dal fornitore, idempotente, in termini di risorse cloud, a quello di produzione. In collaudo verranno utilizzate postazioni client coerenti con quanto previsto dal contratto di Fornitura.
Si sottolinea che ogni futura modifica, correttiva o evolutiva o migliorativa, da apportare al sistema dovrà essere anch’essa soggetta a collaudo preventivo prima dell’effettivo rilascio in produzione.
Anche nel contesto di erogazione del servizio SaaS, ATS richiede che ogni eventuale modifica all’ambiente di utilizzo (software d’ambiente, patch, upgrade, …) sia soggetta a specifiche procedure di verifica da parte del fornitore per garantire la non regressione delle funzionalità applicative, dandone evidenza ad ATS.
ATS richiede che il fornitore garantisca la non regressione delle funzionalità esistenti attraverso l’adozione di specifici strumenti di test automatico (in particolare Azure Test Plan) e di dare ad ATS evidenza del loro utilizzo.
Prima di eventuali sessioni di precollaudo e delle effettive sessioni di collaudo, il fornitore è tenuto a presentare un’opportuna documentazione (test list di collaudo) soggetta ad eventuali integrazioni ed alla accettazione finale da parte dei referenti di ATS.
In caso di inadempimenti del fornitore legati al rilascio in produzione di funzionalità o modifiche non condivise o che non abbiano positivamente superato le procedure di collaudo, ATS si riserva la facoltà di valutare l’applicazione di penali secondo quanto previsto dal contratto di Fornitura.
Nel caso in cui una o più specifiche funzionali, non funzionali e tecniche o altri aspetti rilevanti della Fornitura, inclusi nel presente Documento Tecnico e/o eventualmente forniti come requisiti migliorativi dal fornitore, non superino il collaudo (requisito non implementato o con gravi mancanze), il collaudo terminerà con esito negativo.
Nel caso in cui il collaudo sia superato solo parzialmente, a causa di problemi minori risolvibili in un tempo stimato limitato, il collaudo terminerà con esito di superamento parziale (con riserve). Il fornitore rilascerà l’elenco dei problemi da risolvere con un piano temporale di risoluzione concordato con ATS. La verifica della risoluzione dei problemi sarà oggetto di una ulteriore sessione di collaudo congiunta.
Al superamento del collaudo, l’effettivo rilascio in produzione avverrà secondo un piano di avviamento che assicuri, al momento dell’apertura del servizio in produzione, la corretta operatività a tutti gli utenti finali del sistema, sia interni che esterni ad ATS.
Una volta rilasciato il sistema in esercizio, ATS si riserva la facoltà di monitorare il corretto andamento del funzionamento a regime del sistema in produzione per un periodo di sei mesi (fase di avvio) allo scopo di valutare l’affidabilità del software introdotto dal fornitore. In questa finestra temporale il sistema viene ad essere infatti effettivamente misurato nel reale contesto lavorativo dell’utenza (estremamente eterogenea e distribuita sul territorio) in un ambiente “conforme” e rispondente ad impatti di diversa natura, ad esempio, anche solo organizzativi, di processo o sistemistici che non siano emersi in precedenza in un ambiente “omologo” di collaudo o che non abbiano comportato evidenti azioni di relativa e necessaria gestione risolutiva. Durante questo periodo di “osservazione” del sistema, il fornitore deve garantire affiancamento e supporto costanti, nonché interventi di presa in
carico (servizio di help desk) e di attività correttive/migliorative immediati che non vengano valutati alla stregua di “manutenzioni evolutive” ma devono venire considerate comprese all’interno dell’attuale fornitura e senza alcun onere aggiuntivo a carico di ATS.
5.4 Servizi cloud
Il fornitore dovrà erogare i servizi cloud richiesti dalla presente fornitura conformemente ai vincoli e requisiti dettati dalla normativa vigente garantendo in particolare quanto di seguito riportato:
• Qualificazione ACN almeno QC1 del servizio digitale erogato;
• Utilizzo di un’infrastruttura CSP qualificata almeno QI1
• Nell’individuazione del CSP, il fornitore dovrà prendere in considerazione solo fornitori conformi al Regolamento ACN già citato ed alla normativa nazionale ed europea sulla protezione dei dati personali.
• Nell’individuazione del CSP, il fornitore dovrà prendere in considerazione solo fornitori conformi alle linee guida in materia emanate da AgID e ACN in tema di interoperabilità dei sistemi.
• Nell’individuazione del CSP, il fornitore dovrà prendere in considerazione solo fornitori che garantiscano l’adozione di misure tecniche organizzative di sicurezza a protezione dei dati per tutto il ciclo di vita del trattamento (salvataggio, trasmissione, conservazione, elaborazione, cancellazione), nonché la presenza di politiche di Business Continuity.
• Il fornitore ed il relativo CSP non dovranno utilizzare i dati di ATS per qualsiasi altro scopo secondario non autorizzato.
• Il fornitore dovrà informare tempestivamente ATS di qualsiasi violazione ai propri servizi e/o dati che possa avere un impatto diretto o indiretto su ATS stessa.
• Il fornitore dovrà garantire l’eliminazione completa di qualsiasi traccia di dati e/o informazioni sia al termine del contratto con ATS che durante l’esecuzione dello stesso a richiesta di ATS o secondo tempistiche standard, adottando adeguate pratiche di distruzione e sanificazione.
5.5 Governance e monitoraggio in produzione
In caso di non conformità dell’infrastruttura di erogazione del servizio a carico del fornitore, rilevate nel corso delle sessioni di audit periodiche da parte di una commissione ATS, l’Agenzia si riserva la facoltà di valutare l’applicazione di penali secondo quanto previsto dal contratto di Fornitura.
Fare riferimento a quanto indicato nel requisito SEC6 – “Audit e Monitoraggio”.
6 Formazione utenti
La presente fornitura comprende il servizio formativo relativo all’utilizzo del sistema dedicato agli utenti di ATS, sia in presenza che eventualmente in modalità a distanza.
Saranno programmate giornate di formazione da garantire ad ATS per tutta la durata contrattuale, di cui una partea consumo. La formazione può essere fruita anche tramite mezze giornate. L’eventuale attività d’aula sarà effettuata presso la sede che verrà indicata da ATS. Tale sede si troverà sul territorio di competenza di ATS. Se concordato con ATS, alcune fasi dell’attività di formazione potranno essere effettuate in teleconferenza.
Dovrà inoltre essere predisposto un corso in modalità FAD che, differenziato per destinatari (utenti ATS, utenti esterni e per livello di accesso) deve affrontare tutti gli aspetti relativi alla logica applicativa, dell’interfaccia utente ed alle funzionalità del gestionale per tutti i livelli di utilizzo.
Il corso in modalità FAD, sviluppato come tutorial online con video, slide commentate (con audio) e altri materiali didattici, deve essere reso disponibile sulla piattaforma FAD di ATS Milano in formato SCORM o in formato video .mp4.
A supporto degli utenti del sistema, il fornitore dovrà prevedere la produzione, la consegna, il mantenimento di un’adeguata documentazione tecnica ed operativa, comprendendo in generale tutto quanto, anche successivamente, si rendesse necessario produrre per documentare modifiche e/o adeguamenti al sistema in esercizio. In particolare, devono essere messi a disposizione di ATS i seguenti manuali:
• Manuale d’Uso dell’Utente, eventualmente suddiviso in più moduli dedicati alle diverse tipologie di utenti, contenente le informazioni di riferimento necessarie per il corretto uso del sistema in tutti gli scenari di utilizzo previsti.
• Manuale di Amministrazione di Sistema, contenente la descrizione esaustiva di tutte le funzioni specifiche dell’Amministratore di Sistema.
La documentazione tecnica, utente ed operativa deve essere messa a disposizione anche attraverso help-on-line (come specificato tra i requisiti tecnici, in USA2 – “Interfacce Help-On-Line”), con specifici rimandi dalle varie sezioni.
7 Servizi di assistenza e manutenzione
Il fornitore è tenuto a garantire, per tutta la durata contrattuale, la manutenzione e l’assistenza tecnica del sistema tale da assicurare la continuità operativa del servizio.
Le eventuali chiusure aziendali del fornitore dovranno essere preventivamente comunicate ad ATS e comunque non dovranno inficiare la normale attività lavorativa (neppure per i mesi di agosto e di dicembre).
7.1 Manutenzione correttiva ed assistenza
Il servizio di manutenzione correttiva include:
• la correzione di difetti del prodotto software emersi a seguito di malfunzionamenti rilevati durante l'esercizio o individuati anche autonomamente dal fornitore;
• il rilascio di nuove release del prodotto.
L’individuazione e la correzione di eventuali anomalie devono essere estese a tutto il software esistente ed alle sue successive modifiche correttive ed evolutive, escludendo potenziali regressioni, funzionali e no, che possano impattare le funzionalità e le performance dell’applicativo in produzione.
Tutte le attività relative ad aggiornamenti, modifiche, rilascio di nuove release dovranno essere preventivamente condivise con ATS ed opportunamente pianificate e gestite in modo coordinato, al fine di minimizzare i disagi alle attività operative e i blocchi temporanei del servizio.
Il servizio di assistenza tecnica include:
• un servizio di help desk di secondo livello attivabile direttamente dall’Ufficio preposto di ATS o attraverso i servizi di help desk di primo livello di ATS. Il servizio potrà essere richiesto sia a seguito di malfunzionamenti e/o disservizi sia per richiesta di attività di supporto all'operatività. Tutte le attività di help desk di secondo livello hanno carattere esclusivamente informatico.
• Il servizio di help desk dovrà essere garantito nei giorni feriali da lunedì a venerdì, dalle ore 09:00 alle 18:00, secondo quanto specificato nel capitolo “SLA richiesti e criteri di misura”.
• La garanzia di adattamento dell'applicazione (e di conseguente piena e corretta operatività dell'applicazione) alle nuove versioni disponibili di software di base, di ambiente sia server che client (inclusi i più diffusi internet browser quali Microsoft Edge), di RDBMS utilizzati dalla soluzione proposta che saranno rilasciate nel periodo contrattuale.
Il servizio di manutenzione correttiva e assistenza tecnica comprende:
• mano d’opera (illimitata);
• assistenza telefonica (illimitata);
• teleassistenza (illimitata);
• eventuali costi di trasferta del personale del fornitore o dei consulenti di cui vorrà avvalersi (illimitati).
Il fornitore dovrà fornire ad ATS idonee e chiare istruzioni operative relative all'attivazione del servizio.
Gli interventi dovranno potersi effettuare sia in loco che a distanza, anche in teleassistenza.
Il fornitore dovrà impegnarsi, nel caso di attivazione del servizio di secondo livello, a dare riscontro ad ATS di tutte le fasi di gestione della richiesta di assistenza (presa in carico, risoluzione, chiusura), attraverso un sistema di gestione dei ticket.
Tutti gli interventi di tipo sistemistico conseguenti alle attività sopra indicate dovranno essere preventivamente pianificati e concordati con ATS.
I servizi di manutenzione correttiva e di assistenza tecnica si applicano negli stessi termini anche alle integrazioni realizzate con altri sistemi.
7.2 Manutenzione normativa
Il fornitore s'impegna a fornire, nel periodo contrattuale e senza oneri aggiuntivi per ATS, gli adeguamenti del software applicativo alle intervenute disposizioni legislative, regolamentari, dispositive provenienti a vario titolo dalle Pubbliche Amministrazioni competenti nelle materie riguardanti le informazioni gestite dal sistema oggetto dell’appalto.
Le attività di adeguamento dell’applicazione software ricomprese nel presente articolo riguardano le modifiche e/o gli aggiornamenti e/o evoluzioni di funzionalità presenti, anche solo parzialmente, e gestite nella soluzione applicativa in uso. Le eventuali attività necessarie all’adeguamento normativo che richiedessero la realizzazione di funzionalità totalmente assenti, dunque funzionalità completamente nuove saranno considerate manutenzione evolutive e regolate secondo quanto indicato nel successivo paragrafo 8.3.
Tutte le attività relative ad aggiornamenti, modifiche, rilascio di nuove release dell'applicazione software dovranno essere opportunamente pianificate con ATS e l’avvio in produzione dovrà essere preventivamente autorizzato mediante apposito collaudo funzionale al fine di minimizzare i disagi alle attività operative e/o blocchi temporanei alle procedure.
Le tempistiche di intervento saranno di volta in volta concordate con il fornitore e comunque non oltre il limite di cinque giorni lavorativi dalla richiesta o entro il limite di applicazione fissato dalla disposizione legislativa, regolamentare, dispositiva intervenuta.
A seguito del rilascio in produzione, una modifica o nuova funzionalità relativa alla manutenzione normativa diventa parte integrante dell'applicazione software e ad essa si applica quanto definito nelle restanti parti del capitolato (ad esempio, manutenzione correttiva).
La manutenzione normativa dell'applicazione software si applica negli stessi termini anche alle integrazioni realizzate con altri sistemi.
7.3 Manutenzione evolutiva
Per quanto riguarda il periodo “di osservazione” relativo ai primi mesi(lavorativi) successivi (da concordare con ATS) all’avvio a regime in produzione del software rilasciato dal fornitore, si rimanda a quanto scritto nel paragrafo 5.3 ovvero, che il fornitore deve garantire affiancamento e supporto costanti, nonché interventi di presa in carico (servizio di help desk) e di attività correttive/migliorative immediati che non vengano valutati alla stregua di “manutenzioni evolutive” ma devono venire considerate comprese all’interno dell’attuale fornitura e senza alcun onere aggiuntivo a carico di ATS.
Non essendo identificabili a priori gli interventi evolutivi determinati da necessità non comprese nelle specifiche iniziali del presente documento, la realizzazione di tali attività presuppone la preventiva analisi dei bisogni, la quotazione delle attività, la pianificazione degli interventi, la realizzazione ed il relativo collaudo. Tutte le fasi del processo sopra descritto sono da concordarsi con ATS.
Per lo svolgimento di tali attività, ATS richiede al fornitore di quotare per lo sviluppo di tali interventi evolutivi, un “pacchetto” di giornate-uomo, da utilizzarsi “a consumo” ovvero l’utilizzo di giornate o anche mezze giornate di attività.
Il pacchetto di giornate-uomo richiesto è di 30 giornate (10 all’anno) e sarà utilizzabile per tutta la durata contrattuale eventualmente fruibili anche in 60 (sessanta) mezze giornate/uomo. Tali giornate potranno anche essere utilizzate solo in parte da ATS; in tal caso ATS corrisponderà al fornitore solo il costo delle giornate/mezze giornate effettivamente erogate e preventivamente concordate con ATS sulla base di un documento tecnico, redatto dal fornitore che dia evidenza delle attività effettivamente previste.
Il Fornitore è tenuto ad allineare tutta la documentazione tecnica ed operativa del sistema.
A seguito del rilascio in produzione, ogni modifica evolutiva o nuova funzionalità diventa parte integrante del sistema stesso e comporta quanto definito nelle restanti parti del Documento Tecnico.
Si sottolinea che ogni futura modifica, correttiva o evolutiva o migliorativa, da apportare al sistema dovrà essere sempre soggetta a collaudo preventivo prima dell’effettivo rilascio in produzione.
Per ogni evolutiva rilasciata in esercizio, ATS si riserva la facoltà di monitorare il corretto andamento del funzionamento del sistema in produzione per un per periodo di due mesi (fase di avvio) per valutare l’affidabilità delle evolutive rilasciate e l’assenza di regressioni sulle funzionalità preesistenti del sistema.
Il software integralmente e le relative componenti evolutive potranno essere segnalati ad AgID e pubblicati sul repository Developers Italia.
8 SLA richiesti e criteri di misura
Dato l’impatto che tale applicativo ha sulla immagine e operatività di ATS, un importante elemento di valutazione è la qualità del servizio offerto agli utenti del sistema, con particolare riferimento ai tempi di risoluzione di eventuali problematiche o anomalie o difetti che dovessero emergere e verificarsi in esercizio, considerando soprattutto che la stragrande maggioranza di utenti fruitori sono esterni ad ATS e distribuiti in modo eterogeneo.
Coerentemente con quanto riportato nel paragrafo 5.3, nella fase iniziale di avvio in produzione, a valle di un positivo collaudo, deve essere previsto un periodo (concordato con ATS) durante il quale venga predisposto un canale diretto con le risorse interne del fornitore per l’inoltro di richieste di assistenza, correzioni, segnalazioni di difformità e anomalie del sistema da parte degli utenti (es. indirizzo mail di risorse interne dedicate).
Il fornitore è tenuto a garantire il servizio di manutenzione ed assistenza tecnica secondo la seguente copertura oraria:
Giorno | Copertura |
Lunedì | dalle 9:00 alle 18:00 |
Martedì | dalle 9:00 alle 18:00 |
Mercoledì | dalle 9:00 alle 18:00 |
Giovedì | dalle 9:00 alle 18:00 |
Venerdì | dalle 9:00 alle 18:00 |
Negli stessi orari devono essere garantiti i seguenti servizi:
• help desk;
• raccolta, registrazione e instradamento delle richieste di intervento in caso di guasto;
• verifica dell’esecuzione dell’intervento riparatore e registrazione della conclusione del ticket.
Il sistema di tracciatura utilizzato dal fornitore deve permettere ad ATS la ricezione di notifiche o comunicazioni relative ad ogni cambio di stato delle segnalazioni effettuate fino alla chiusura dei ticket da parte dei gruppi tecnici preposti.
9 Riferimenti documentali e normativi
Accessibilità | Il portale dovrà rispondere ai requisiti tecnici di accessibilità definiti nei seguenti atti normativi e di indirizzo: • Linee Guida AgID per l’Accessibilità degli strumenti informatici. • Legge 4 del 9 gennaio 2004, (Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici) e successivo D.M. 8 luglio 2005 (Regolamento di attuazione della Legge 4 del 9 gennaio 2004, per favorire l’accesso dei soggetti disabili agli strumenti informatici) aggiornato con • D.M. del 20 marzo 2013. • Decreto Legislativo 82/2005 (Codice dell'Amministrazione Digitale); • Decreto del Presidente della Repubblica 75/2005 Regolamento di attuazione della Legge 4/2004, per favorire l'accesso dei soggetti disabili agli strumenti informatici. • Decreto del Ministro per l'Innovazione e le Tecnologie 8 luglio 2005 recante "Requisiti tecnici e diversi livelli per l’accessibilità agli strumenti informatici". • Direttiva 27 luglio 2005 della Presidenza del Consiglio dei Ministri - Dipartimento per l’Innovazione e le Tecnologie Qualità dei servizi Online e misurazione della soddisfazione degli utenti. • Direttiva n. 8/2009 - Ministro per la pubblica amministrazione e l'innovazione relativa alla riduzione dei siti web delle P.A. e per il miglioramento della qualità dei servizi e delle informazioni on line al cittadino. • Linee Guida per i siti web delle P.A. (previste dalla Direttiva • n. 8/09 - Ministro per la pubblica amministrazione e l'innovazione). • Decreto Legislativo 33/2013 Riordino della disciplina riguardante gli obblighi di pubblicità, trasparenza e diffusione di informazioni da parte delle pubbliche amministrazioni (pubblicato sulla Gazzetta Ufficiale della Repubblica Italiana • n. 80 del 5 aprile 2013) e s.m.i. • Decreto Legislativo recante revisione e semplificazione delle disposizioni in materia di prevenzione della corruzione pubblicità e trasparenza, correttivo della Legge 6 novembre 2012, n. 190 e del decreto legislativo 14 marzo 2013, n. 33, ai sensi dell'articolo 7 della legge 7 agosto 2015, n. 124, in materia di riorganizzazione delle amministrazioni pubbliche. |
• Circolare n. 61/2013 del 29 marzo 2013 dell'Agenzia per l'Italia Digitale in materia di accessibilità dei siti web delle pubbliche amministrazioni; • Delibera CIVIT N. 50 del 4 luglio 2013, “Linee guida per l'aggiornamento del Programma triennale per la trasparenza e l'integrità 2014-2016”. | |
Data Center e cloud | Indicazioni di AgID: Circolare n. 2 del 24/06/2016, “Piano triennale per l’informatica nella pubblica amministrazione” previsto dalle disposizioni della legge n. 208 del 28/12/2015 - Legge di stabilità 2016. Circolare n.5 del 30 novembre 2017 relativa agli obiettivi e alle linee guida per la PA rispetto al risparmio di spesa ICT e al consolidamento dei data center. Regolamento per i servizi cloud, pubblicato da AgID a dicembre 2021 con determinazione 628/2021. Indicazioni di ACN: Decreto direttoriale prot. N. 29 del 02/01/2023 dell’Agenzia per la Cybersicurezza Nazionale. Determine 306 e 307 di gennaio 2022 pubblicate dalla Agenzia per la Cybersicurezza Nazionale e relativi allegati. |
Privacy e Security | D.Lgs. 196/2003 (“Codice in materia di protezione dei dati personali”) Misure di sicurezza e modalità di scambio dei dati personali tra amministrazioni pubbliche - 2 luglio 2015 GDPR (General Data Protection Regulation), Regolamento UE 2016/679 Linee guida AgID in merito alla misure minime di sicurezza ICT per la PA (Circolare n. 1 del 17.3.2017 pubblicata in GU del 4.4.2017) Misure Minime di Sicurezza AgID (circolare n. 2 del 18/4/2017) Indicazioni di ACN: Decreto direttoriale prot. N. 29 del 02/01/2023 dell’Agenzia per la Cybersicurezza Nazionale. Determine 306 e 307 di gennaio 2022 pubblicate dalla Agenzia per la Cybersicurezza Nazionale e relativi allegati. Fare riferimento a best practices e standard proposti nell’ambito del progetto OWASP (Open Web Application Security Project) e consultabili al seguente link: |
Proprietà intellettuale | L. 633/41 (“Protezione del diritto d'autore e di altri diritti connessi al suo esercizio”). |