CAPITOLATO TECNICO LOTTO 1

Aggiudicatario	Il Concorrente scelto dalla Stazione appaltante per erogare i servizi previsti nel contratto sottoscritto con l’ATS della Città Metropolitana di Milano
Stazione Appaltante	ATS Milano Città Metropolitana
XX.XX.XX. o ATS aggregate	Amministrazioni in unione d’acquisito alla presente procedura, ATS della Città Metropolitana di Milano e ATS di Bergamo.
Concorrente	Qualsiasi partecipante alla gara di appalto.
Software di base	Per software di base si intende l’insieme dei programmi che consentono ad un utente di eseguire operazioni base come costruire e mandare in esecuzione un programma o gestire una base dati. Tipici esempi di software di base sono il sistema operativo, gli editor, i compilatori ed i sistemi di gestione di basi di dati.
Software d’ambiente	Il software d’ambiente rappresenta l’insieme di programmi specializzati che facilitano la scrittura/gestione di applicazioni. Tipici esempi di software d’ambiente sono gli Application Server.
Software di rete	Il software di rete è inteso come l’insieme di programmi specialistici per la gestione delle comunicazioni. Tipici esempi di software di rete sono i gestori di posta ed i prodotti di gestione e condivisione di risorse distribuite.
Software applicativo	Programma che utilizza il software di base, d’ambiente e di rete per realizzare funzionalità legate agli scopi dell’ATS che lo utilizza.
Service Level Agreement (SLA)	Sono i Livelli di Servizio minimi contrattualmente richiesti. Definizione ed associato criterio di misura per la valutazione della qualità dei servizi che saranno erogati dall’Aggiudicatario.
Malfunzionamento bloccante	Malfunzionamento (difetto, errore, anomalia) che rende totalmente o parzialmente non utilizzabili ad un utente una o più funzionalità del sistema.
Malfunzionamento non bloccante	Malfunzionamento (difetto, errore, anomalia) che non inibisce l’operatività di un utente del sistema; l’utente può ugualmente pervenire ai risultati attesi mediante l’utilizzo di altre funzionalità offerte dal sistema e senza eccessivo aggravio sulla sua operatività.
Sistema di gestione dei ticket e Ticket	Un ticket contiene una richiesta di assistenza o di manutenzione attraverso una delle modalità di accesso al servizio e ne traccia l’evoluzione. Il sistema di gestione dei ticket è un tool software che permette di gestire la base dati dei ticket, il flusso di ogni ticket e l'estrazione di misure per la verifica degli SLA.

Manutenzione software correttiva	Rimozione di eventuali malfunzionamenti delle procedure applicative segnalati dal Cliente o dal Fornitore e verificatisi nell’ambito del corretto utilizzo dei programmi. Per malfunzionamento si intende una non conformità con quanto specificato nei manuali operativi o nelle specifiche tecniche / funzionali consegnate al Cliente.
Manutenzione software normativa	Comprende attività da svolgere per l’adeguamento del software applicativo al fine di adempiere ad obblighi di legge o a fronte di requisiti tecnici, informativi, funzionali e organizzativi che siano definiti da organismi normativi esterni alla struttura del Cliente (Stato, Ministeri, Regioni, etc.).
Manutenzione software evolutiva	Comprende la modifica / aggiunta di funzioni o la parametrizzazione del software applicativo sulla base di specifici requisiti dell’amministrazione.
Manutenzione preventiva programmata	Comprende interventi periodici e/o programmati per garantire il mantenimento del buon funzionamento del sistema informativo, attraverso il costante aggiornamento del software applicativo e di base.

1.2 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 procedura.
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.
Software “orizzontale”	Applicazioni software di uso generalizzato (general-purpose) adattabili alle esigenze di diversi settori commerciali. Si tratta di software commerciali con funzioni di utilità standard quali ad esempio: ERP, CRM, Knowledge and Content Management, Business Intelligence, sistemi di gestione documentale.
Software “verticale”	Applicazioni software con funzionalità specifiche di un determinato settore commerciale.
Software proprietario	Software privato, non libero di cui è possibile al beneficiario l’utilizzo sotto particolari condizioni (in relazione alla licenza) ma non ne è permessa la modifica, la condivisione, lo studio, la ridistribuzione o il reverse engineering.
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.
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.
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.

1.3 Definizioni, abbreviazioni e sigle specifiche del progetto

NOC

Nucleo Operativo di Controllo.

SDO

Schede di Dimissione Ospedaliera.

DRG

Diagnosis Related Groups.

I Raggruppamenti Omogenei di Diagnosi permettono di classificare i pazienti dimessi da un ospedale in gruppi omogenei al fine di quantificare economicamente le risorse impegnate e quindi remunerare ciascun episodio di ricovero.

2 Premessa

2.1 Scopo del documento

L’ATS Città Metropolitana di Milano (capofila) e l’ATS di Bergamo (mandante) hanno l’esigenza di individuare, tramite apposita gara di appalto, un operatore economico (OE) a cui affidare i servizi realizzativi e di personalizzazione e quelli aggiuntivi e complementari, nel seguito meglio dettagliati, di un applicativo software web- destinato ai servizi aziendali competenti del controllo delle prestazioni sanitarie di ricovero per la gestione informatizzata delle attività di controllo delle prestazioni sanitarie di ricovero.

Essendo titolare dei controlli di congruenza ed appropriatezza generica delle prestazioni sanitarie di ricovero a carico del SSL, le ATS devono garantire, come da regole di esercizio, almeno il 12,5% di verifiche sulla produzione del territorio di competenza. Il volume di prestazioni in questione impone una programmazione dettagliata delle attività ed una definizione puntuale del piano dei controlli definito in base a specifiche analisi di rischio così da favorire una valutazione di merito in ordine ai criteri di campionamento nonché all’analisi critica degli esiti ottenuti. In questo contesto assume particolare rilevanza la tracciabilità dei processi in capo al NOC di ATS della Città Metropolitana di Milano e la trasparenza dei criteri decisionali adottati al fine di favorire da una parte le verifiche interne ed esterne riferite alla Legge 190/2012 anticorruzione e al D.L. 33/2013 sulla trasparenza e dall’altra di attuare un monitoraggio puntuale dell’efficacia dei criteri di campionamento utilizzati.

La presente procedura ha ad oggetto le attività di predisposizione di una soluzione applicativa web, disponibile in cloud in modalità SaaS, comprensiva delle personalizzazioni dedicate all’ATS della Città Metropolitana di Milano e dei relativi servizi aggiuntivi di formazione, assistenza tecnica, manutenzione (ordinaria e straordinaria), hosting ed erogazione dell’applicazione web in cloud in modalità SaaS.

2.2 Finalità

La soluzione applicativa, comprensiva dei servizi realizzativi e aggiuntivi descritti nel presente documento, deve essere garantita dall’aggiudicatario attraverso le seguenti modalità:

• realizzazione di personalizzazioni di una soluzione applicativa esistente sul mercato, eventualmente offerta in

licenza d’uso ed i cui costi siano necessariamente inclusi nel contratto;

• erogazione di servizi aggiuntivi relativi a: formazione utenti interni, assistenza tecnica e manutenzione correttiva, preventiva programmata, normativa ed evolutiva, hosting ed erogazione dell’applicazione web in cloud in modalità SaaS.

2.3 Ambito della fornitura

L’aggiudicatario si impegna ad assicurare all’Amministrazione:

• la predisposizione di una soluzione applicativa eventualmente offerta dal mercato in licenza d’uso, senza ulteriori costi a carico dell’Amministrazione – e quindi ricompresa nell’importo contrattuale del lotto n. 1 e senza vincoli legati al numero di utenti; il contratto deve includere in particolare tutti i costi relativi all’integrazione del software GROUPER dedicato all’assegnazione e l’elaborazione dei DRG;

• la copertura di tutti i requisiti funzionali, non funzionali, tecnici, tecnologici ed operativi espressi nel presente documento;

• l’attività di formazione relativa all’utilizzo del sistema da parte delle diverse tipologie di utenza interna previste, sia presso la sede dell’Amministrazione che eventualmente in teleconferenza;

• l’attività di assistenza tecnica e manutenzione correttiva, preventiva programmata, normativa ed evolutiva per garantire la continuità operativa a tutti gli utilizzatori del sistema a partire dal rilascio in produzione fino alla scadenza prevista dal contratto;

• a partire dalla data di sottoscrizione del contratto e per tutta la durata dello stesso, la produzione di tutti i certificati digitali necessari per la gestione del sistema informativo e validi per tutti gli ambienti operativi messi a disposizione dall’ATS. Tali certificati digitali dovranno essere intestati all’ATS della Città Metropolitana di Milano ed emessi da una Certification Authority (CA) italiana pubblicamente riconosciuta;

• a partire dalla data di sottoscrizione del contratto e per tutta la durata dello stesso 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 sottoscrizione di una adeguata polizza assicurativa, meglio precisata nel Capitolato Speciale di Appalto, correlata ai rischi sul trattamento dei dati personali e sensibili (ovvero i dati “particolari” definiti dal GDPR) nell’ambito del contratto;

• l’attività di migrazione nel sistema in cloud dei dati storici dell’attuale soluzione di gestione del NOC

dell’ATS, secondo quanto indicato al requisito MIG1 – “Migrazione dati storici”;

• il supporto all’ATS e ai propri fornitori terzi per la messa a punto delle eventuali integrazioni applicative richieste;

• l’attività di predisposizione, nella sottoscrizione Microsoft Azure DevOps dell’ATS, del repository del codice sorgente relativo a tutte le personalizzazioni e integrazioni realizzate e dedicate all’ATS e relativo caricamento di tutta la documentazione di progetto e di esercizio realizzata specificatamente per l’ATS;

• l’attività connesse alla eventuale messa in riuso del codice sorgente realizzato relativo a tutte le personalizzazioni e integrazioni dedicate all’ATS, secondo quanto previsto dalle Linee Guida AgID e dai relativi allegati tecnici;

• la cessione perpetua del codice sorgente relativo a tutte le componenti funzionali sviluppate per l’ATS, delle personalizzazioni, delle configurazioni sistemistiche, della base dati integrale nonché della documentazione tecnica e di esercizio prodotta specificatamente per l’ATS;

• un adeguato periodo di garanzia, proporzionato alla durata contrattuale, relativo al servizio di manutenzione correttiva per tutte le componenti funzionali realizzate specificatamente per l’ATS, valido a partire dalla relativa data di messa in produzione a valle di un positivo collaudo;

• l’export dell’intera base dati, in un formato standard, aperto e documentato (attraverso metadati), senza oneri e possibile in ogni momento su richiesta dell’ATS e/o al termine del contratto.

2.4 Contesto normativo, tecnologico e operativo

Il sistema informativo richiesto dall’ATS prevede che tutte le componenti applicative e i dati siano erogati in ambiente cloud, conformemente alla normativa vigente ed alle Linee Guida di AgID per la PA. Si fa presente che per quanto non espressamente richiamato nel presente documento, si rimanda alla normativa vigente relativa alla qualificazione dei servizi cloud per la PA.

La soluzione applicativa proposta per l’Amministrazione dovrà essere basata su tecnologie di cloud computing secondo il paradigma SaaS (Software as a Service). Si precisa che, a partire dalla sua decorrenza, il contratto dovrà contemplare il servizio di hosting di una infrastruttura in linea con la normativa vigente ovverosia, in considerazione delle caratteristiche tecnologiche richieste, la soluzione progettuale dovrà richiedere la disponibilità di risorse o infrastrutture

integralmente a carico dell’aggiudicatario. L’aggiudicatario dovrà garantire la produzione di tutti i certificati digitali

necessari per la gestione sicura dell’applicazione web erogata.

Con riferimento alle due circolari AgID n. 2 e n. 3 del 9 aprile 2018, l’acquisizione dei servizi in hosting dovrà soddisfare quanto indicato: “A decorrere dal 1° aprile 2019, le Amministrazioni Pubbliche potranno acquisire esclusivamente servizi IaaS, PaaS e SaaS qualificati da AgID e pubblicati nel Cloud Marketplace”.

A questo proposito, l’ATS richiede che il servizio SaaS erogato dall’aggiudicatario venga “qualificato” da XxXX e pubblicato nel proprio Cloud Marketplace. Tale attività potrà essere svolta anche successivamente all’aggiudicazione della gara. Come indicato al link seguente:

xxxxx://xxxxx-xxxxxx.xxxxxxxxxxx.xx/xxxxxxxx/xxxxx-xxxxxx- circolari/it/latest/circolari/SaaS/allegato_a_qualificazione_SaaS_v6.html

“Requisiti per la qualificazione di servizi SaaS per il Cloud della PA”, la procedura di qualificazione AgID prevede che l’aggiudicatario dichiari esplicitamente la rispondenza del servizio erogato a tutti i requisiti indicati nella circolare sulla qualificazione dei servizi SaaS. La compilazione della auto-dichiarazione (self-assessment) dovrà essere effettuata sul portale dedicato di XxXX.

Alternativamente, è richiesto che l’aggiudicatario 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 l’aggiudicatario 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. L’aggiudicatario 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.

L’aggiudicatario dovrà dare evidenza all’ATS di eventuali altri soggetti o subfornitori che concorrano all’erogazione del servizio di cloud hosting e quindi al trattamento dei dati. In particolare, il gestore dei servizi cloud (CSP, Cloud Service Provider) scelto dall’aggiudicatario dovrà essere “qualificato” secondo quanto previsto da XxXX. Il CSP dovrà garantire la tutela dei dati personali trattati e la loro conservazione su data center collocati esclusivamente nel territorio italiano.

Considerando la natura critica dei dati oggetto della presente procedura, trattandosi di dati sanitari e quindi per definizione sensibili, il CSP scelto dall’aggiudicatario dovrà essere aderente ai requisiti espressi dal Regolamento per i servizi cloud, pubblicato da AgID a dicembre 2021 con determinazione 628/2021, che definisce i requisiti minimi per le infrastrutture digitali, le caratteristiche e le modalità di qualificazione e migrazione dei servizi cloud in relazione alla classificazione dei dati trattati.

I criteri per la qualificazione dei servizi cloud delle PA previsti da AgID devono essere integrati da quelli ulteriori previsti dall’Agenzia per la Cybersicurezza Nazionale (ACN) nell’Allegato 1 della determina 307 del 18/01/2022, con particolare riferimento all’allegato C “Requisiti per la qualificazione dei servizi Cloud per la Pubblica Amministrazione”.

È compito dell’ATS verificare l’effettivo rispetto delle dichiarazioni prodotte in sede di qualificazione dall’aggiudicatario, che ne risponde penalmente. In caso di servizi non conformi a quanto dichiarato dall’aggiudicatario, l’ATS è tenuta a segnalare la circostanza ad AgID che, in caso di esito confermativo dell’apposita verifica, procederà alla revoca della qualificazione.

In relazione agli obblighi e alle responsabilità dell’aggiudicatario relativamente al trattamento dei dati, con particolare riferimento a quelli personali e particolari, l’aggiudicario dovrà sottoscrivere 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 dalle 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 dell’aggiudicatario in relazione alla eventuale perdita, all’illecita diffusione dei dati trattati e gestiti nel cloud ed all’interruzione del servizio erogato. Si ricorda, pertanto, che nella nomina dell’aggiudicatario a Responsabile al Trattamento Esterno dei dati (Regolamento UE 679/2016) sono già indicati i compiti, gli obblighi e le responsabilità contrattuali previsti dall’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 5 “Progettazione, realizzazione e delivery”.

Al fine di permettere all’ATS di valutare l’efficacia del servizio SaaS erogato, l’aggiudicatario dovrà rendere disponibile a ciascuna 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 dall’aggiudicatario e di ogni personalizzazione dedicata ad ATS, dovrà essere necessariamente condiviso e concordato con i referenti di progetto dell’Amministrazione.

L’utilizzo delle funzionalità del sistema informativo dovrà essere possibile attraverso i più diffusi browser Internet,

l’accesso alle funzionalità ed ai dati sarà possibile solo agli utenti abilitati in base ai previsti livelli e profili di accesso.

La UOC Controllo Prestazioni Sanitarie di Ricovero dell’ATS della Città Metropolitana di Milano opera all’interno di ATS avendo come focus il controllo delle prestazioni sanitarie di ricovero. Ai fini del corretto dimensionamento del sistema in ambito al presente Capitolato Tecnico, di seguito sono forniti alcuni dati relativi agli utilizzatori ed ai volumi dati previsti:

• numero di operatori di backoffice della UOC NOC: indicativamente 30 unità;

• numero di record correnti e storici: indicativamente 600.000 record all’anno e storicizzati.

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. L’applicazione 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 Titolarità del codice sorgente

Tutto il software sviluppato ad hoc per l’ATS e le personalizzazioni realizzate dall’aggiudicatario, unitamente a tutte le relative successive modifiche e a tutta la documentazione tecnica e di esercizio prodotta specificatamente per l’Amministrazione, dovranno intendersi di proprietà intellettuale della stessa con la facoltà dell’Agenzia di poter cedere in riuso tali componenti funzionali ad altre amministrazioni pubbliche che ne dovessero fare richiesta.

Nella messa in riuso del codice sorgente sviluppato specificatamente per conto dell’ATS dovranno essere indicate tutte le dipendenze dal software proprietario offerto eventualmente in licenza d’uso.

3 Requisiti Funzionali

Il sistema oggetto del presente Capitolato Tecnico (d’ora in avanti, sistema) 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.

I requisiti funzionali sono tutti da considerarsi “obbligatori” (ovvero, l’ATS li ritiene indispensabili per l’avvio del sistema in produzione). I requisiti funzionali e/o non funzionali "secondari” (ovvero, che potranno essere rilasciati dall’aggiudicatario in tempi successivi, previo accordo con ATS) sono opportunamente evidenziati nel documento col testo “requisito opzionale”.

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;

• consultazione dei log applicativi. Si sottolinea che il sistema deve garantire l’integrità e quindi la non modificabilità dei log applicativi per finalità di controllo da parte dell’ATS con particolare riferimento agli aspetti di performance dell’applicativo.

GEN2

I&A utenti

Il sistema deve consentire l’identificazione e l’autenticazione (I&A) di utenti interni all’ATS.

Gli utenti interni di ATS devono poter accedere al sistema tramite le credenziali del dominio Azure Active Directory (AD) di ATS.

Il sistema deve gestire ruoli e gruppi di utenti, per poter configurare i corretti privilegi di accesso alle funzionalità ed ai dati ovvero garantire:

• la suddivisione degli operatori per profili di accesso e abilitazione alle funzioni del servizio in base ai ruoli ad essi associati;

• la possibilità di circoscrivere la visibilità e la modificabilità sui dati per singoli utenti o gruppi di utenti.

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 dall’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 TEC5 “Identificazione & Autenticazione degli utenti”.

GEN4

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 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.

Il sistema deve permettere la generazione di reportistica dedicata al supporto del processo di campionamento e dell’attività ispettiva (es. liste di cartelle da predisporre per l’ispezione, brogliaccio di lavoro, verbale di ispezione, etc.).

Il sistema deve consentire la generazione e l’export di report dedicati. I report devono poter essere

estratti in formato standard e aperto (CSV, ODS, PDF elaborabile, etc).

GEN5

Univocità, disponibilità e storicizzazione dei dati

Il sistema deve poter conservare dati afferenti ad annualità differenti e reportistica dedicata al confronto dei contenuti tra di esse.

Il sistema deve garantire l'univocità di qualsiasi informazione all'interno della base dati. Le informazioni rilevanti devono essere storicizzate, per ciascuna registrazione deve essere rilevabile la data di validità.

Il sistema deve mantenere in linea due annualità oltre alla base dati completa dello storico dei controlli

relativo all’esercizio precedente.

GEN6

Migrazioni dati storici

Il sistema deve consentire l’importazione dei dati storici provenienti dall’attuale sistema informativo di gestione del NOC dell’ATS della Città Metropolitana di Milano (fare riferimento a MIG1 “Migrazione dati storici”).

Il sistema deve garantire che tali dati storici siano perfettamente allineati ai nuovi dati e, come per questi, essere elaborabili attraverso gli strumenti ed i moduli messi a disposizione dal sistema.

GEN7	Tracciamento delle attività
	Il sistema deve garantire il completo tracciamento (log applicativi) per almeno sei mesi di tutte le operazioni effettuate e dei dati modificati dagli utenti.

3.2 Requisiti specifici del servizio

NOC1

Requisiti specifici del servizio

Il sistema deve permettere le seguenti attività:

• caricamento dei flussi previsti dalle normative regionali secondo i tracciati vigenti;

• realizzazione, aggiornamento e temporizzazione in considerazione della data di dimissione

presente sulla SDO, delle seguenti tabelle, consultabili tramite l’interfaccia utente:

1) tabelle di decodifica dei codici presenti sui tracciati importati;

2) tabelle di configurazione temporizzate (es. anagrafica strutture, comuni, regioni, tariffari, DRG, Diagnosi, Procedure etc.);

• archiviazione delle versioni SDO generate nel corso del processo di gestione ed in particolare del dettaglio dell’eventuale cronologia delle diverse versioni inviate dall’erogatore alla DG Welfare di RL, della versione eventualmente generata dall'erogatore a seguito di modifiche in fase di Autocontrollo, della versione generata dal NOC nel corso delle verifiche ispettive;

• gestione in blocco delle schede SDO in tutte le fasi di controllo (selezione, campionamento, inserimento degli esiti di default, verbalizzazione, etc.)

• creazione di contenitori (cartelle-folder) per l’inserimento e la gestione delle schede SDO, secondo specifiche definite dal tipo di ispezione (Mirato di Congruenza, Autocontrollo di Congruenza e Autocontrollo di Qualità documentale).

Il sistema deve, altresì, garantire la presenza di strumenti:

• per la ricerca dinamica e la selezione che riguardino tutti i campi presenti delle schede SDO, tramite una semplice e intuitiva interfaccia utente;

• per l’inserimento o rimozione delle schede SDO nel/dal contenitore, sia in blocco che per singola scheda. L'inserimento deve comportare l’applicazione sulla scheda SDO del criterio per cui è stata selezionata, il quale deve essere unico per le schede del campione Mirato di

Congruenza e doppio per le schede degli Autocontrolli appartenenti al minicampione del NOC;

• per la selezione delle schede SDO campionate/non campionate dal NOC o dall’erogatore e presenti/non presenti nell’elenco delle pratiche campionate dall’erogatore per l’Autocontrollo di Congruenza;

• per la selezione delle schede SDO rispetto a tutte le versioni esistenti (NOC, erogatore, stratificate);

• di simulazione che permettano di visualizzare le possibili variazioni di DRG e il relativo rimborso, in base alle diverse combinazioni dei codici di diagnosi e/o procedure esposte nella scheda SDO.

3.3 Caricamento flusso SDO

NOC2

Caricamento e trattamento flussi dati

Il sistema deve consentire le seguenti attività:

• caricamento flusso SDO (file L1/P1, L2/P2, L3/P3, L4/P4) di ritorno regionale, aggiornato alle

nuove specifiche dell’Esercizio in corso;

• per i file L4/P4:

o gestione delle SDO, con data di dimissione compresa tra 01.01.2019 e 31.12.2021, secondo quanto disposto dalla DGR n. XI/1046/2018 del 17/12/2018, dalla nota operativa prot. n. G1.2019.0009622 del 28/02/2019, dai chiarimenti prot. n. G1.2019.0012240 del 21/03/2019 e dalla DGR n. XI/3245 del 16/07/2020;

o gestione delle SDO, con data di dimissione a partire dal 01.01.2022, secondo quanto disposto dalla DGR n. XI/5924/2022 del 07/02/2022 e/o successive modificazioni ed integrazioni disposte da RL;

o caricamento e conservazione di tutti i campi. Quelli da visualizzare sulla scheda SDO sono i seguenti:

▪ Protesi/Componente, non editabile;

▪ Lotto di produzione, non editabile;

▪ Rimborso Regionale per ogni singolo componente della protesi, non editabile;

▪ Progressivo protesi, non editabile;

A questi si aggiunge la descrizione del Tipo Protesi/Componente elaborato dal sistema (es. “Tipo Protesi/Componente” = 01A corrisponde alla descrizione: Protesi d’anca - componente acetabolare, coppa).

Il sistema deve, altresì, garantire:

• l’indicazione del Totale Rimborso Protesi come importato regionale dal file L2/P2;

• la presenza di un campo Rimborso Complessivo che sia calcolato come somma del Rimborso SDO e del Rimborso Protesi dove presente;

• la presenza di una libreria storica di tracciati, che consenta anche il caricamento di dati di annualità precedenti, secondo le specifiche storicamente valide;

• la presenza nel database di tutte le SDO ricevute con il flusso SDO regionale;

• la presenza nel data base di due aree distinte e separate per la gestione delle schede SDO. In un’area deve essere gestita la produzione finanziata degli erogatori di pertinenza dell’ATS di Milano (di seguito chiamato “gruppo 1”), nell’altra la produzione non finanziata degli erogatori di pertinenza dell’ATS di Milano unitamente alla produzione finanziata e non finanziata fruita da residenti dell’ATS Milano presso erogatori di altre ATS (di seguito chiamato “gruppo 2”). Le SDO di entrambe le aree devono essere gestite con le stesse modalità;

• l’individuazione e la segnalazione di eventuali record anomali presenti nei file L1/P1, L2/P2,

L3/P3 e L4/P4 che impediscano il corretto caricamento del flusso SDO;

• la marcatura e stratificazione delle schede SDO importate con il caricamento del flusso, secondo le seguenti condizioni:

1. se la SDO non è presente nel database, deve essere generata la scheda SDO che assume il marcatore del mese che si sta importando;

2. se la SDO è già presente nel database e con il nuovo flusso non ci sono modifiche in nessun campo, la scheda SDO deve rimanere invariata e assumere il marcatore del mese che si sta importando;

3. se la SDO è già presente nel database e non figura nel nuovo flusso, la scheda SDO deve rimanere invariata e mantenere il marcatore del mese precedente;

4. se la SDO è già presente nel database e con il nuovo flusso vengono modificati uno o più campi della stessa, la scheda SDO deve essere stratificata e caratterizzata: da uno strato attivo che deve riportare i dati dell’ultima SDO importata e da uno strato sottostante che deve riportare i dati non modificabili della SDO precedentemente importata. Tutti gli strati che si creano devono essere visibili ed accessibili attraverso un comando presente sulla scheda SDO attiva. La quantità di strati non deve essere numericamente predefinita;

5. se la SDO è già presente nel database, in un campione non ancora verbalizzato e con il nuovo flusso viene modificato anche un solo campo della stessa, la scheda SDO deve essere stratificata; in uno strato la scheda SDO dell’importazione precedente deve rimanere invariata e non più modificabile, mentre un ulteriore strato, che sarà quello attivo, deve riportare i dati dell’ultima SDO importata. Tutti gli strati che si creano devono essere visibili ed accessibili attraverso un comando presente sulla scheda SDO attiva. La quantità di strati non deve essere numericamente predefinita. Sulla scheda SDO attiva deve essere riportato lo stesso criterio di campionamento presente sullo strato della scheda SDO precedente. Se presente la scheda NOC, quest’ultima deve essere accessibile dalla scheda SDO attiva che deve riportare anche gli esiti dell’ispezione. Il sistema deve individuare e segnalare se i campi modificati risultano essere quelli del DRG e/o del rimborso DRG e/o del rimborso protesi;

6. se la SDO è già presente nel database, in un campione già verbalizzato e con il nuovo flusso viene modificato anche un solo campo della stessa, deve essere creato uno strato in cui la SDO importata precedentemente, già bloccata perché verbalizzata, deve rimanere invariata e sarà lo strato attivo, mentre l’ultimo strato aggiornato deve avere solo una funzione informativa e non sarà mai lo strato attivo. Gli strati devono essere visibili ed accessibili attraverso un comando presente sulla scheda che in questo caso sarà su quella non attiva;

7. se la SDO è già presente nel database come SDO del “gruppo 2” e con l’importazione

del nuovo flusso risulta invece appartenere al “gruppo 1”, la stessa deve essere

inserita nel “gruppo 1” delle SDO e deve essere stratificata secondo le stesse modalità

di cui al punto 4.

• la collocazione in modo automatico delle schede SDO appartenenti al gruppo 1 o 2, generate

con l’importazione del flusso, nella corretta area di pertinenza;

• la visualizzazione, durante la procedura di importazione, di un’anteprima del risultato, estraibile in un file, che consenta una valutazione di eventuali situazioni inattese per una gestione preventiva di potenziali errori nei dati. Tale anteprima deve contenere i seguenti campi, per le SDO di entrambi i gruppi 1 e 2: numero di nuove SDO importate, sovrascritte, stratificate, scartate, totale;

• il controllo formale e specifico della congruenza fra il rimborso totale delle protesi (file L2/P2) e la somma del valore unitario delle singole componenti delle protesi (file L4/P4);

• l’attribuzione alle SDO del DRG e delle informazioni ad esso correlate in modo autonomo con

algoritmo di calcolo proprio;

• il calcolo delle tariffe dei DRG e delle protesi conformi alle regole vigenti, che devono essere assegnate in maniera assolutamente puntuale, tenendo conto di tutte le variabili espresse a livello normativo (acuti e post-acuti, regime ordinario o DH, giornate soglia e tariffe ‘in’ e ‘oltre’ soglia, BIC, reingressi nei ricoveri per acuti e in quelli riabilitativi, soglie minime previste per l’attribuzione della tariffa del DRG complicato, incrementi e riduzioni legati alla presenza di pronto soccorso, maggiorazione tariffaria alle strutture qualora prevista, incremento delle tariffe relative alle diagnosi urgenti, arrotondamenti e valutazione delle differenziazioni DRG procedura-dipendenti, allineamento delle procedure OR a quelle regionali e qualsiasi regola definita dalla normativa legata a particolari eccezioni o casistiche), comprensive delle specificità per anno di competenza nonché mantenimento della cronologia dei tariffari regionali che vengono automaticamente applicati alle schede in base alla data di dimissione;

• l’individuazione e segnalazione delle schede SDO che presentano DRG, rimborso DRG e

rimborso protesi calcolati dal software, diversi da quelli importati dalla Regione;

• l’impedimento di sovrascrittura, nella fase del caricamento del flusso SDO, delle schede SDO appartenenti ai campioni verbalizzati (vedi punto 6 sopra);

• l’individuazione, al termine del caricamento del flusso SDO, delle schede SDO campionate e non ancora verbalizzate in cui ci sono state variazioni nei campi del DRG, rimborso e rimborso protesi (vedi punto 5 sopra);

• l’identificazione e l’etichettatura delle schede SDO generate con l’importazione del flusso SDO, con i criteri del piano di controllo relativo all’esercizio in corso. Tali criteri devono essere transcodificati con i codici che identificano le tipologie di controllo previste dalle note di RL prot. n. H1.2012.0003657 del 02.02.2012, n. H1.2012.0036178 del 17.12.2021 e n. G1.2019.0009622 del 28.02.2019, con procedure automatizzabili;

• la visualizzazione dei dati importati e calcolati dal software secondo due modalità:

o Elenco di Record con scelta dei campi da visualizzare;

o Maschera a campi prestabiliti.

3.4 Caricamento elenco SDO e tracciato esiti degli Autocontrolli: erogatore – ATS

NOC3

Caricamento e trattamento flussi dati

Il sistema deve consentire le seguenti attività:

• caricamento liste delle pratiche campionate dall’erogatore per l’Autocontrollo di Congruenza, tracciato esiti di Autocontrollo di Congruenza e di Qualità documentale e relative SDO di cui alla DGR n. IX/4334 del 26.10.2012 e relativa Circolare attuativa prot. n. H1.2012.0036178 del 17.12.2012 nonché in riferimento alle Regole annuali di sistema;

• individuazione e segnalazione di eventuali record anomali bloccanti il caricamento dei flussi.

A) Liste delle pratiche campionate dall’erogatore per l’Autocontrollo di Congruenza

• con il caricamento mensile, la lista precedentemente importata deve essere sovrascritta o

sostituita dall’ultima lista importata;

• il sistema deve individuare e segnalare le schede SDO già campionate coincidenti con le liste importate;

• il sistema deve permettere l’eliminazione in blocco delle liste importate;

B) Tracciato esiti e relative SDO di Autocontrollo di Congruenza

• con il tracciato esiti il sistema deve individuare e inserire nel campione le schede SDO ed etichettarle con il criterio specifico del controllo. Inoltre i dati delle schede SDO dovranno essere integrati con i dati del tracciato esiti;

• con i file contenenti i dati delle SDO (SDO 1, 2, 3), il sistema deve creare una ulteriore versione sulla scheda SDO (versione erogatore) qualora l’esito assegnato dalla struttura sia diverso da “A”, ossia contenga modifiche rispetto alla versione originale. Tale versione deve essere visibile e accessibile attraverso un comando e distinta da una eventuale scheda NOC.

C) Tracciato esiti di Autocontrollo di Qualità documentale

• integrazione delle schede SDO, già presenti nel campione specifico, con i dati del tracciato esiti.

3.5 Campionamento Mirato di Congruenza e Appropriatezza Generica e controllo dati

NOC4

Campionamento Mirato di Congruenza e Appropriatezza Generica

Il sistema deve consentire la definizione di un Piano sistematizzato di Controlli di Appropriatezza organizzativa e di Congruenza, che possa essere pensato, organizzato e manutenuto in modo dinamico ed in totale autonomia, mediante una semplice e intuitiva interfaccia grafica.

L’esecuzione del Piano Controlli sopra richiamato deve consentire l’individuazione, l’analisi, l’etichettatura delle schede SDO in base ai criteri stabiliti dallo stesso ed essere gestito attraverso gli strumenti di campionamento, sia per la selezione in blocco che sulla singola scheda.

Il sistema deve garantire e supportare l’oggettività, la tracciabilità e la riproducibilità dei processi di campionamento e controllo.

3.6 Campionamento Autocontrollo e controllo dei dati

NOC5	Campionamento di Autocontrollo di Congruenza e Qualità Documentale
	Il sistema deve consentire controlli di correttezza formale e sostanziale del tracciato esiti inviati dagli erogatori nonché garantire e supportare l’oggettività, la tracciabilità e la riproducibilità dei processi di campionamento e controllo.

3.7 Gestione dell’attività ispettiva

NOC6

Attività ispettiva

A) Il sistema deve prevedere la realizzazione della scheda di lavoro NOC, distinta per le tre tipologie di controlli, riportante i campi di seguito elencati, suddivisi in sezioni:

1) Brogliaccio per controllo congruenza e appropriatezza generica

Prima sezione: Azienda; Presidio; Numero scheda; Età; Sesso;

Seconda sezione: Regime di ricovero; Tipo ricovero; Modalità dimissione; Data ricovero; Data dimissione; Reparto ammissione; Reparto dimissione; Onere degenza; Regione di residenza;

Terza sezione: Diagnosi principale; Diagnosi secondarie (indicando per ognuna la relativa influenza sul DRG, ad esempio “Non influenza il DRG”, “Complica il DRG”); Sesta diagnosi; Procedura principale (indicando la relativa influenza sul DRG, ad esempio: “E’ un OR”, “OR che influenza il DRG”, “Non influenza il DRG”); Procedure (indicando per ognuna la relativa influenza sul DRG, ad esempio: “E’ un OR”, “OR che influenza il DRG”, “Non influenza il DRG”); Sesta procedura; DRG; Giornate di degenza; Giornate di degenza nette; Giornate non a carico SSN; MDC; Tipo DRG; Xxxxxxxx; Rimborso endoprotesi; Soglia DRG; Xxxxxx CC; Xxxxxx All. F (vedi allegato F alla DGR n. IX/2057 del 28.07.2011); Tipo tariffa;

Quarta sezione: Numero endoprotesi; Codice regionale endoprotesi; Descrizione endoprotesi; Lotto endoprotesi; Rimborso singola endoprotesi;

Quinta sezione: Criteri di selezione; Controllore; Destinazione; Note complessive;

Sesta sezione denominata “Esito del controllo” riportante la legenda degli esiti relativi al controllo di congruenza e appropriatezza generica e degli esiti del controllo endoprotesi secondo nota DG Welfare prot. n. G1.2019.0009622 del 28.02.2019;

2) Brogliaccio per autocontrollo di qualità documentale

Prima sezione: Azienda; Presidio; Numero scheda; Età; Sesso;

Seconda sezione: Regime di ricovero; Tipo ricovero; Modalità dimissione; Data ricovero; Data dimissione; Reparto ammissione; Reparto dimissione; Onere degenza; Regione di residenza;

Quarta sezione: Controllore; Discussa da; Criteri di selezione; Destinazione; Esito NIC; Percentuale abbattimento NIC; Rimborso NIC; Esito NOC (riportante la legenda degli esiti relativi all’autocontrollo di qualità documentale secondo nota DG Welfare prot. n. G1.2010.0036718 del 05.11.2010); Percentuale abbattimento NOC; Rimborso NOC; Note complessive;

Quinta sezione denominata “Controllo documentale”: Numero cartella clinica; Generalità assistito; Struttura di ricovero; Date ingresso/uscita; DH: orari e posto letto; SDO: Firma del medico; Motivo del ricovero; Anamnesi patologica; Esame obiettivo ingresso; Firma esame obiettivo; Data esame obiettivo; Diario medico quotidiano; Firme diario medico; Diario infermieristico quotidiano; Firme diario infermieristico; PRI firmato; Referti diagnostici; Data consenso informato; Firma consenso informato; Cartella anestesiologica; Verbale operatorio; Lettera di dimissione. Accanto ad ogni item il sistema deve prevedere la presenza di una casella di spunta;

3) Brogliaccio per autocontrollo di congruenza e appropriatezza generica

Prima sezione: Azienda; Presidio; Numero scheda; Età; Sesso;

Seconda sezione: Tipo ricovero; Modalità dimissione; Data ricovero; Data dimissione; Reparto ammissione; Reparto dimissione; Onere degenza; Regione di residenza; Regime di ricovero

Terza sezione: Diagnosi principale; Diagnosi secondarie (indicando per ognuna la relativa influenza sul DRG, ad esempio “Non influenza il DRG”, “Complica il DRG”); Sesta diagnosi; Procedura principale (indicando la relativa influenza sul DRG, ad esempio: “E’ un OR”, “OR che influenza il DRG”, “Non influenza il DRG”); Procedure (indicando per ognuna la relativa influenza sul DRG, ad esempio: “E’ un OR”, “OR che influenza il DRG”, “Non influenza il DRG”); Sesta procedura; DRG; Giornate di degenza; Giornate di degenza nette; Giornate non a carico SSN; MDC; Tipo DRG; Rimborso; Tipo tariffa; Soglia DRG; Soglia CC; Soglia All. F (vedi allegato F alla DGR n. IX/2057 del 28.07.2011);

Quarta sezione: Controllore; Discussa da; Criteri di selezione; Destinazione; note complessive;

Quinta sezione denominata “Esito del controllo” riportante la legenda degli esiti relativi all’autocontrollo di congruenza e appropriatezza generica secondo nota DG Welfare prot. n. G1.2019.0009622 del 28.02.2019;

In caso di presenza della versione NIC nella scheda SDO originale, il sistema deve permettere di generare automaticamente i brogliacci delle due versioni e riportare sulla versione NIC la dicitura “VERSIONE NIC”.

* * * * * * *

B) Scheda NOC

Il sistema deve prevedere le seguenti attività:

• creazione di una seconda versione della scheda SDO (di seguito denominata scheda NOC), per i controlli Mirati di Congruenza e per gli Autocontrolli di Congruenza. La scheda NOC deve riportare le correzioni effettuate dal NOC e deve essere creata nel caso in cui anche uno solo dei campi “Esito DRG” ed “Esito Endoprotesi” sia diverso da “A”. Inoltre il sistema deve assegnare in modo automatico i valori dei campi Esito in base alle modifiche effettuate sulla scheda SDO;

• assegnazione del DRG, del rimborso DRG e del rimborso protesi (dove previsto), che devono essere conformi alle regole vigenti e assegnati in maniera assolutamente puntuale, tenendo conto di tutte le variabili espresse a livello normativo. Il campo totale rimborso protesi non deve essere modificabile direttamente, ma solo come conseguenza di modifiche effettuate sui valori addendi (rimborso regionale protesi unitario)

• creazione di uno strumento per la forzatura del valore dei campi rimborso DRG e rimborso regionale protesi (valore unitario delle protesi), che può agire sia contemporaneamente su entrambi i campi che singolarmente. Lo stesso deve presentare i seguenti campi: “valore” all’interno del quale è possibile inserire l’importo che si desidera; “percentuale” all’interno del quale è possibile inserire la percentuale che modificherà l’importo; percentuale di abbattimento per i ricoveri ripetuti (pari a - 20%). Il sistema deve garantire l’arrotondamento di tutti gli importi forzati nonché l’inserimento della tariffa importata dalla Regione;

• eliminazione della scheda NOC sia in blocco che su singola scheda e aggiornamento automatico del campo “esito DRG” e “esito Endoprotesi” riportando ad esito “A”. La visibilità e l’uso della funzione in blocco deve essere circoscritta ai soli utenti autorizzati;

* * * * * * *

C) Assegnazione esiti

Il sistema deve prevedere le seguenti attività:

• assegnazione del valore nei campi “esito DRG”, “esito Endoprotesi” dove previsto, “Destinazione”, “Esito altro”, sia in blocco che su singola scheda;

• prevedere l’esistenza di un campo libero editabile in cui inserire le note;

• inserimento del valore nel campo “controllore” sia in blocco che su singola scheda e segnalazione se lo stesso risulta già compilato;

• segnalazione di ipervalorizzazione del campo rimborso DRG e rimborso protesi in fase di generazione della scheda NOC, rispetto alla scheda originale;

• la visibilità della sezione “esiti” con i campi “esito DRG”, “esito Endoprotesi”, “Destinazione”, “Esito altro”, “Controllore” e campo note su entrambe le versioni delle schede SDO e NOC;

• per l’Autocontrollo di Qualità documentale, presenza anche di una sezione “esiti” sulla scheda SDO per l’inserimento degli esiti e per il calcolo dell’abbattimento in percentuale, sia per la parte relativa all'erogatore che per quella del NOC;

• allineamento automatico degli esiti NOC con gli esiti degli Autocontrolli inviati dall'erogatore;

• controlli di correttezza sostanziale relativi agli esiti assegnati alle schede SDO, che dovranno essere effettuati in tutte le tipologie di campioni previste e segnalazione dell’eventuale tipo di errore (es. congruenza tra esiti assegnati e contenuto delle modifiche effettuate);

* * * * * * *

D) Reportistica

Il sistema deve prevedere la generazione di reportistica di confronto basata sulle diverse versioni delle schede SDO (strati, versione della Struttura e versione NOC).

Il sistema deve permettere la distribuzione della reportistica, in grado di suddividere automaticamente i report in base ad una configurazione predisposta ed inviarli via e-mail ai referenti stabiliti.

* * * * * * *

E) Verbali di accertamento

Il sistema deve garantire la generazione dei seguenti verbali in base al diverso tipo di ispezione: controllo Mirato di Congruenza, Autocontrollo di Qualità documentale e Autocontrollo di Congruenza. I verbali devono contenere i seguenti elementi:

• intestazione della prima pagina riportante i dati dell’ATS di Milano o dell’ATS di Bergamo, del Dipartimento e UOC che effettua l’ispezione. A seguire l’indicazione della tipologia di ispezione;

• piè di pagina contente numero delle pagine (ad es. Pag 1 di 15) e la denominazione sociale della ATS di Milano – Dipartimento – UOC;

• il numero (cardinale) di verbale di accertamento che deve essere assegnato secondo un ordine crescente e in modo automatico. La numerazione deve essere progressiva con azzeramento alla fine dell’anno solare. Inoltre il sistema deve segnalare la presenza di numeri verbali duplicati o che non rispettino la numerazione progressiva;

• la data del verbale automatica, ma con la possibilità di modifica;

• elenco dei nomi degli operatori che hanno partecipato al controllo. L’inserimento deve

avvenire in modo automatico e comparire anche nei campi firma verbale;

• la data e l’ora di inizio e fine controlli;

• la denominazione sociale dell’erogatore oggetto del controllo, da inserire attraverso un menù

a tendina;

• i dati del Legale Rappresentante della Struttura (nome, cognome);

• i dati del delegato alla discussione della Struttura (nome, cognome, data di nascita, residenza)

• un campo note libero

• un campo dove segnalare la presenza di un eventuale allegato al verbale

• frasi indicate dall’ATS (frasi standard)

• la firma olografa o eventualmente digitale del verbale

• la data di stampa del verbale

E.1) Il verbale del Mirato di Congruenza ed Appropriatezza Generica

Il sistema deve prevedere la generazione di un verbale del Mirato di Congruenza contenente tre prospetti.

Il primo prospetto deve riportare l’elenco iniziale di tutte le SDO sottoposte a ispezione. Deve

contenere i seguenti campi:

1. “codice ospedale”, che indica il numero della Regione e del presidio ospedaliero (es. 030074 Presidio Magenta 030 = regione, 074 = presidio)

2. “pratica”, numero della SDO

3. “reparto”, il codice del reparto di dimissione

4. “esito del controllo”, che corrisponde all’esito DRG

5. “esito Endoprotesi”,

6. “il Legale rappresentante”, che deve riportare la dicitura “concorda” o “non concorda”

Il secondo prospetto deve essere intestato con la dicitura “ATS della Città Metropolitana di Milano – SDO modificate - le SDO modificate durante il controllo sono riportate nelle tabelle sottostanti.” e riportare le SDO modificate. Deve essere suddiviso in tre sezioni all’interno delle quali le SDO vengono rappresentate in base alla presenza o meno dell’esito corrispondente (Esito NOC e/o Esito Endoprotesi), di seguito descritte:

La prima sezione deve essere intestata con la dicitura “Dettaglio pratiche modificate – congruenza e appropriatezza generica” e contenere le SDO con “esito DRG” diverso da “A”. Deve contenere i seguenti campi:

1. “Numero scheda”, numero della SDO

2. “Esito NOC”, che corrisponde all’”Esito DRG”

3. “Versione Erogatore” che deve contenere i dati della SDO inviata dalla Struttura, come di

seguito riportati:

- “DRG”, codice del DRG

- “Rimborso”, rimborso del DRG

- “Diagnosi”, il codice delle diagnosi

- “Procedure”, il codice delle procedure

4. “Versione NOC” che deve contenere i dati della scheda NOC e riportare i campi di cui al punto

5. “Variazione rimborso” che è la differenza tra il campo rimborso della versione Erogatore e

quello della versione NOC

Deve essere presente, al termine della sezione, uno specchietto riassuntivo riportante il totale delle schede, del rimborso erogatore, del rimborso NOC e della variazione rimborso.

La seconda sezione deve essere intestata con la dicitura “Dettaglio pratiche modificate – endoprotesi” e contiene le SDO con “Esito Endoprotesi” diverso da “A”. Deve contenere i seguenti campi:

1. “Numero scheda”, numero della SDO

2. “Esito Endoprotesi”

3. “Versione Erogatore” che deve contenere i dati della SDO inviata dalla Struttura, come di

seguito riportati:

- “DRG”, codice del DRG

- “Rimborso”, rimborso delle Endoprotesi

- “Endoprotesi”, i codici regionali identificativi delle Endoprotesi (Tipo

Protesi/Componente)

- “Procedure”, il codice delle procedure

4. Versione NOC che deve contenere i dati della scheda NOC e riportare i campi di cui al punto 3.

5. “Variazione rimborso” che è la differenza tra il campo rimborso della versione erogatore e quello della versione NOC

Deve essere presente al termine della sezione uno specchietto riassuntivo riportante il totale delle schede, del rimborso erogatore, del rimborso NOC e della variazione rimborso.

La terza sezione deve essere intestata con la dicitura “Dettaglio totale pratiche modificate” e contiene le SDO presenti in entrambe le sezioni precedenti e rappresenta le variazioni economiche complessive mettendo a confronto la versione erogatore e NOC. Deve contenere i seguenti campi:

1. “Numero scheda”, numero della SDO

2. “Esito NOC”, esito DRG

3. “Esito Endoprotesi”

4. “Versione Erogatore” che deve contenere i dati della SDO inviata dalla Struttura, come di seguito riportati:

- “Rimborso DRG”,

- “Rimborso Endoprotesi”,

- “Rimborso Totale”, somma del rimborso DRG e del rimborso Endoprotesi

5. “Versione NOC” che deve contenere i dati della scheda NOC e riportare i campi di cui al punto 4

6. “Differenza rimborso totale” è la differenza tra il rimborso totale della versione dell’Erogatore e quello della versione NOC

Il terzo prospetto deve contenere i totali finali con i seguenti campi:

1. Schede esaminate: numero totale delle schede presenti nel campione;

2. Schede variate: numero totale delle schede modificate dal NOC;

3. Rimborso esaminate: il valore dato dalla somma del rimborso DRG di tutte le SDO inviate dall’erogatore e presenti nel campione, più la somma del rimborso Endoprotesi solo per le schede che presentano esito endoprotesi valorizzato;

4. Rimborso variate: il valore dato dalla somma del rimborso DRG di tutte le schede NOC presenti nel campione, più la somma del rimborso Endoprotesi solo per le schede che presentano esito endoprotesi valorizzato;

5. Variazione: il valore dato dalla differenza tra il rimborso delle schede esaminate e il rimborso delle schede variate;

6. Variazione percentuale: il valore dato dalla differenza percentuale tra il rimborso delle schede esaminate e il rimborso delle schede variate.

E.2) Il verbale di Autocontrollo di Congruenza ed Appropriatezza Generica

Il sistema deve prevedere la generazione di un verbale di Autocontrollo di Congruenza contenente tre prospetti.

Il primo prospetto deve essere intestato con la dicitura “Le pratiche i cui esiti sono stati trasmessi da parte della Struttura all’ATS e che vengono ammesse e validate come autocontrollo, in numero di (…), sono riportate di seguito:” e riportare l’elenco iniziale di tutte le SDO sottoposte a ispezione. Deve contenere i seguenti campi:

1. “Numero scheda”: numero della SDO

2. “Esito Struttura”: esito DRG

Il secondo prospetto deve essere intestato con la dicitura “Le pratiche sottoposte a verifica del NOC sono riportate di seguito con relativo esito:” e riportare l’identificazione dell’Erogatore. Deve contenere i seguenti campi:

1. “Numero scheda”: numero della SDO

2. “Esito NIC”, esito DRG assegnato dall’Erogatore

3. “Esito NOC”, esito DRG assegnato dal NOC

4. “Esito Altro”

5. Versione Erogatore che deve contenere i dati della SDO inviata dalla Struttura, come di seguito riportati:

- DRG: codice del DRG

- Rimborso: rimborso del DRG

- Diagnosi: il codice delle diagnosi

- Procedure: il codice delle procedure

6. “Versione NOC” che deve contenere i dati della scheda NOC e riportare i campi di cui al punto 5

Al termine di questi campi devono essere riportati il numero di schede NOC “discordanti” e l’indicazione

del superamento o meno della soglia di estensione.

In caso di superamento della soglia di estensione, deve essere riportato un ulteriore prospetto (secondo bis) riferito alle pratiche oggetto di estensione, contenente i medesimi campi del secondo prospetto.

Il terzo prospetto deve essere intestato con la dicitura “Gli effetti economici del controllo sono qui di

seguito riportati:”. Deve riportare i seguenti campi:

1. Xxxxxx campione complessivo

2. Schede esaminate dal NOC

3. Xxxxxxxx campione complessivo

4. Rimborso dopo modifiche NOC

5. Variazione

6. Variazione percentuale

Al termine di questi campi deve essere riportato se l’Erogatore concorda o non concorda con l’esito

NOC del controllo.

E.3) Il verbale di Autocontrollo di Qualità documentale

Il sistema deve prevedere la generazione di un verbale di Autocontrollo di Qualità documentale contenente tre prospetti.

Il primo prospetto deve essere intestato con la dicitura “Le pratiche i cui esiti sono stati trasmessi da parte della Struttura alla ATS e che vengono ammesse e validate come autocontrollo, in numero di (…), sono riportate di seguito:” e riportare l’elenco iniziale di tutte le SDO sottoposte a ispezione. Deve contenere i seguenti campi:

1. “Numero scheda": numero della SDO

2. “Esito Struttura” che deve contenere i dati dell’esito e la percentuale di decurtazione

economica;

Il secondo prospetto deve essere intestato con la dicitura “Le pratiche sottoposte a verifica da parte del NOC sono riportate di seguito con relativo esito” e riportare le pratiche oggetto di verifica del NOC. Deve contenere i seguenti campi:

1. “Numero scheda": numero della SDO

2. “Esito Struttura” che deve contenere i dati dell’esito, della percentuale di decurtazione

economica e del rimborso relativi ai controlli effettuati dall’erogatore

3. “Esito NOC” che deve contenere i dati dell’esito, della percentuale di decurtazione economica

e del rimborso relativi ai controlli effettuati dal NOC

Al termine di questi campi devono essere riportati il numero di schede NOC “discordanti” e l’indicazione

del superamento o meno della soglia di estensione.

Il terzo prospetto deve essere intestato con la dicitura “Gli effetti economici del controllo, sono qui di

seguito riportati:”. Deve riportare i seguenti campi:

1. Xxxxxx campione complessivo

2. Schede esaminate dal NOC

3. Xxxxxxxx campione complessivo

4. Rimborso dopo modifiche NOC

5. Variazione

6. Variazione percentuale

Al termine di questi campi deve essere riportato se l’Erogatore concorda o non concorda con l’esito

NOC del controllo.

3.8 Rendicontazione esiti

NOC7

Rendicontazione esiti verso la Regione Lombardia

Il sistema deve permettere la produzione del tracciato esiti per la rendicontazione del processo di controllo verso la DG Welfare della Regione Lombardia, nelle diverse modalità previste dalla normativa vigente in base alle tipologie di campioni (Mirato di Congruenza, Autocontrollo di Congruenza, Autocontrollo di Qualità documentale).

Il sistema deve garantire la verifica di correttezza formale dei campi del tracciato esiti nonché la possibilità di introdurre gradualmente nel tempo anche la verifica di correttezza sostanziale dello stesso.

3.9 Requisiti specifici per il monitoraggio interno ed esterno

NOC8	Monitoraggio interno ed esterno
	Il sistema deve consentire la costruzione di indicatori ad hoc e possibilità di generare report per il loro monitoraggio e stima di proiezione. A questo proposito il sistema deve disporre di un’ampia libreria di report di analisi, integrabile su richiesta di personalizzazioni, con contenuti esportabili nei formati più comuni di presentazione (es. Excel, CSV, PDF, ACCDB).

4 Requisiti non funzionali

Si elencano di seguito i requisiti non funzionali, tecnici e tecnologici richiesti al sistema informativo oggetto della presente fornitura.

4.1 Requisiti organizzativi

ORG1	SPOC (Single Point of Contact)
	Al fine di rendere più efficaci le comunicazioni tra le ATS e operatore economico, quest’ultimo dovrà individuare e comunicare all’ATS contraente, 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.

4.2 Requisiti di security

SEC1

Sicurezza logica, fisica e organizzativa

Dato il grado di confidenzialità delle informazioni gestite dal sistema, l’aggiudicatario 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 delle Agenzie e della continuità del servizio, l’aggiudicatario 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’aggiudicatario sarà designato come Responsabile Esterno al trattamento dei dati e conseguentemente assoggettato a tutti gli obblighi previsti dalla normativa di riferimento.

SEC3	GDPR (General Data Protection Regulation) – Regolamento UE 2016/679

Le prestazioni oggetto della presente procedura 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).

SEC4

Protocollo HTTPS

Il software applicativo, oggetto della procedura, dovrà essere fruibile dai client esclusivamente mediante protocollo HTTPS.

L’aggiudicatario 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 pubblicamente riconosciuta ed intestato all’ATS contraente.

SEC5

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, avviamento e manutenzione del sistema. Tali accordi (Non Disclosure Agreement, 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à.

SEC6	Audit e Monitoraggio
	Ciascuna ATS contraente 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.

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.

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 dall’ATS contraente 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, etc.) né si devono rendere necessarie configurazioni particolari sulle impostazioni dei browser o dei sistemi operativi dei client.

L’applicazione deve poter essere utilizzata anche in mobilità, attraverso tablet e smartphone delle

piattaforme più comuni (ad esempio, iOS, Android, …).

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 la corretta rappresentazione dei contenuti da parte dei motori di rendering utilizzati.

Più nel dettaglio, a seconda del dispositivo operativo utilizzato dall’utente, dovrà essere garantita la compatibilità con i seguenti sistemi operativi e browser:

• piattaforma desktop: Windows, OS X, Linux;

• piattaforma mobile: IOS e Android (per le funzionalità dedicate al Cittadino);

• Microsoft Edge, Chrome, Mozilla Firefox;

nelle versioni che i rispettivi vendor garantiranno dal punto di vista del supporto per tutto il periodo della validità contrattuale del presente capitolato.

Per una rapida visualizzazione delle pagine web, il sistema dovrà garantire un peso pagina web ottimizzato dal punto di vista della dimensione.

Le interfacce grafiche esposte dal servizio dovranno 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à
	L’aggiudicatario 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.

Il sistema dovrà essere realizzato con tecnologie a logica micro-servizi, con un sistema di orchestrazione open source e gestione di container (preferibilmente Kubernetes o equivalente).

TEC4	Evoluzioni tecnologiche
	L’aggiudicatario 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.

TEC5

Identificazione & Autenticazione degli utenti

Il sistema dovrà utilizzare la seguente soluzione tecnologica di I&A:

• Microsoft Azure Active Directory (conforme alla normativa di sicurezzaGDPR).

TEC6

Performance

Il sistema dovrà nel suo complesso (application server, database server, backup server, file server, etc.) 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 l’ATS. L’incremento delle risorse dovrà essere garantito “a caldo”, senza interruzioni di servizio.

Il servizio di hosting in modalità cloud SaaS dovrà 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.

Si richiede 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. L’ATS richiede che, sia in condizioni nominali che di picco di traffico, una generica pagina web del sito sia caricata entro un tempo massimo di 1 secondo (1.000 msec), sia in accesso da desktop che da mobile. Si richiede inoltre che:

• le transazioni sincrone devono avere un tempo di risposta minore o uguale a 500 msec;

• le transazioni asincrone devono avere un tempo di risposta proporzionale al numero di record da elaborare ovvero 50 msec per ciascun record (es. se il file SDO da elaborare comprende

10.000 record, il tempo di elaborazione atteso dovrà essere minore o uguale a 8 minuti).

Dovrà 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) all’ATS contraente in caso di eventuali disservizi. Il sistema dovrà prevedere la disponibilità di pagine di cortesia o “Landing Page” a cui indirizzare gli utenti dei Portali dell’ATS in caso di sua indisponibilità per potenziali disservizi o per attività di manutenzione programmata. La manutenzione programmata dovrà essere sempre condivisa e autorizzata dall’ATS contraente.

Al fine di favorire la governance del servizio da parte dell’ATS, il sistema dovrà preferibilmente prevedere tecnologie (“agent” Azure Arc o equivalenti) che consentano il monitoraggio e la corretta applicazione delle policy di sicurezza e infrastrutturali adottate dall’aggiudicatario sulla propria sottoscrizione cloud.

4.4 Requisiti normativi

REG1

Hosting dei servizi cloud

Il CSP scelto dall’aggiudicatario dovrà essere aderente ai requisiti espressi dal Regolamento per i servizi cloud, pubblicato da AgID a dicembre 2021 con determinazione 628/2021, che definisce i requisiti minimi per le infrastrutture digitali, le caratteristiche e le modalità di qualificazione e migrazione dei servizi cloud in relazione alla classificazione dei dati trattati.

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	Interfacce Help-On-Line (HOL)
	Il sistema dovrà disporre di una guida in linea delle funzionalità, ad integrazione della documentazione utente e operativa. La guida in linea dovrà 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.

USA3	Inserimento dati
	Il sistema dovrà disporre di opportuni controlli per evitare l’inserimento di informazioni errate e/o incomplete, garantendo controlli di congruenza dei dati inseriti dall’utente.

4.6 Requisiti di migrazione

MIG1

Migrazione dati storici

La fornitura dovrà prevedere la predisposizione dei database interni del sistema (import: anagrafiche, etc.) e garantire il porting dei dati storici dell’attuale gestionale del NOC di ATS (es. dati, campioni, schede NOC, verbali, etc.) verso la sottoscrizione cloud dell’aggiudicatario, secondo le tempistiche stabilite dall’ATS.

Tali attività saranno propedeutiche al collaudo, alla formazione ed all’avviamento del sistema in

produzione.

Sarà cura, pertanto, dell’aggiudicatario 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 all’aggiudicatario di fornire all’impresa 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 dell’aggiudicatario favorire la portabilità e la interoperabilità dei dati trattati in modo garantire, in ogni momento e su necessità dell’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 prevedrà dovranno essere sviluppati usando formati xml e protocolli basati su web services, offrendo integrazioni sia sincrone che asincrone.

L’aggiudicatario dovrà 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.

INT2	Integrazione SISS e firma digitale remota - requisito opzionale
	Il sistema dovrà integrarsi con il SISS secondo i vincoli e le modalità stabiliti dai diversi scenari di integrazione e secondo le modalità e le tempistiche che saranno concordate con ATS.

5 Progettazione, realizzazione e delivery

5.1 Responsabilità

L’aggiudicatario è responsabile di tutte le attività di progettazione, realizzazione, personalizzazione e messa in esercizio delle componenti software e personalizzazioni previste dal presente Capitolato Tecnico. Sono comprese nel contratto tutte le attività di predisposizione e caricamento sulla sottoscrizione Microsoft Azure DevOps di ATS del codice sorgente sviluppato per conto dell’ATS e delle personalizzazioni dedicate all’ATS. Il deployment del software già esistente e degli sviluppi e personalizzazioni dedicate all’ATS deve essere previsto negli ambienti operativi (collaudo, produzione) in cloud in modalità SaaS, servizio gestito in hosting dall’aggiudicatario.

L’aggiudicatario è 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 all’ATS la supervisione e governance del progetto in tutte le sue fasi, l’aggiudicatario è 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

L’aggiudicatario è 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.

5.3 Collaudo ed avvio in produzione

Il sistema oggetto del presente Capitolato Tecnico è vincolato al superamento di un’opportuna procedura di collaudo, condivisa con l’ATS, prima dell’effettiva accettazione del sistema e quindi del relativo rilascio in produzione.

Il collaudo dovrà essere effettuato in un ambiente di test dedicato, messo a disposizione in hosting dall’aggiudicatario, il più simile possibile, in termini di risorse cloud, a quello di produzione. In collaudo verranno utilizzate postazioni client coerenti con quanto previsto dal contratto d’Appalto.

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, l’ATS richiede che ogni eventuale modifica all’ambiente di utilizzo (software d’ambiente, patch, upgrade, etc.) sia soggetta a specifiche procedure di verifica da parte dell’aggiudicatario per garantire la non regressione delle funzionalità applicative, dandone evidenza all’ATS.

Prima di eventuali sessioni di precollaudo e delle effettive sessioni di collaudo, l’aggiudicatario è tenuto a presentare un’opportuna documentazione (test list di collaudo) soggetta ad eventuali integrazioni ed alla accettazione finale da parte del Direttore dell’Esecuzione del contratto nominato dall’Amministrazione.

In caso di inadempimenti dell’aggiudicatario legati al rilascio in produzione di funzionalità o modifiche non condivise o che non abbiano positivamente superato le procedure di collaudo, l’ATS si riserva la facoltà di valutare l’applicazione di penali secondo quanto previsto dal contratto.Nel caso in cui una o più specifiche funzionali, non funzionali e tecniche o altri aspetti rilevanti, inclusi nel presente Capitolato Tecnico e/o eventualmente forniti come requisiti migliorativi dall’aggiudicatario, 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). L’aggiudicatario rilascerà l’elenco dei problemi da risolvere con un piano temporale di risoluzione concordato con l’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, l’ATS si riserva la facoltà di monitorare il corretto andamento del funzionamento del sistema in produzione per periodo di due mesi (fase di avvio) per valutare l’affidabilità del software rilasciato dall’aggiudicatario.

5.4 Servizi cloud

L’aggiudicatario 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:

• Nell’individuazione del CSP, l’aggiudicatario dovrà prendere in considerazione solo fornitori conformi al Regolamento AgID già citato ed alla normativa nazionale ed europea sulla protezione dei dati personali.

• Nell’individuazione del CSP l’aggiudicatario dovrà prendere in considerazione solo fornitori conformi alle linee guida in materia emanate da AgID in tema di interoperabilità dei sistemi.

• Nell’individuazione del CSP l’aggiudicatario 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.

• L’aggiudicatario ed il relativo CSP non dovranno utilizzare i dati di ATS per qualsiasi altro scopo secondario non autorizzato.

• L’aggiudicatario dovrà informare tempestivamente l’ATS contraente di qualsiasi violazione ai propri servizi e/o dati che possa avere un impatto diretto o indiretto su ATS stessa.

• L’aggiudicatario 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 dell’aggiudicatario, rilevate nel corso delle sessioni di audit periodiche da parte di una commissione nominata dall’Amministrazione, l’Agenzia si riserva la facoltà di valutare l’applicazione di penali secondo quanto previsto dal Contratto d’Appalto.

Fare riferimento a quanto indicato nel requisito SEC6 – “Audit e Monitoraggio”.

6 Durata del contratto e modalità di conclusione

La durata del contratto previsto dalla presente fornitura è di 60 mesi (5 anni) a partire dalla data di sottoscrizione del contratto, con possibilità di rinnovo per altri 60 mesi (5 anni).

L’aggiudicatario è tenuto a consegnare la soluzione completa di tutte le parti specificate nel presente Capitolato Tecnico entro un massimo di 30 (trenta) giorni solari dalla data di sottoscrizione del contratto.

Le attività di collaudo, formazione ed avviamento del sistema in produzione dovranno completarsi entro un periodo di 30 (trenta) giorni solari dal termine delle attività di sviluppo e di predisposizione del sistema.

A partire dalla data di sottoscrizione del contratto, l’aggiudicatario dovrà provvedere alla fornitura dei certificati digitali relativi a tutti gli ambienti operativi dedicati a ciascuna ATS (collaudo, produzione) ed erogare i relativi servizi di cloud hosting attraverso una infrastruttura SaaS che garantisca all’ATS la disponibilità, di due ambienti operativi indipendenti (collaudo, produzione).

In esito al collaudo positivo, decorrerà il servizio di assistenza tecnica e manutenzione che l'aggiudicatario dovrà garantire sino alla scadenza naturale del contratto.

Alla conclusione naturale del contratto è prevista la possibilità di rinnovare i servizi di assistenza tecnica, di manutenzione correttiva, normativa ed evolutiva (ipotizzando il medesimo numero di giornate uomo a consumo) e di cloud hosting.

Alla conclusione naturale del contratto l’aggiudicatario è tenuto a garantire all’Amministrazione il trasferimento integrale della base dati, opportunamente documentata attraverso metadati ed in un formato aperto e non proprietario; per lo svolgimento di queste attività l’aggiudicatario non potrà imputare alcun costo all’ATS contraente, in quanto già e ricompresi nel contratto.

In generale, in linea con quanto previsto dalla normativa e dalle Linee Guida AgID, l’aggiudicatario è 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).

In linea con la normativa vigente, con particolare riferimento alle circolari AgID n. 2 e n. 3 del 9 aprile 2018 e relativi allegati (fare riferimento al capitolo “Riferimenti documentali e normativi” del presente documento), al termine del contratto l’aggiudicatario deve consentire la migrazione dei dati del servizio verso un altro gestore SaaS, con conseguente eliminazione permanente dai propri archivi dei dati di proprietà dell’ATS.

Al termine del contratto o in qualsiasi momento solo dopo esplicita richiesta del titolare, i dati in possesso

dell’aggiudicatario e/o di eventuali suoi subfornitori dovranno essere cancellati, in qualsiasi forma essi siano detenuti.

7 Formazione utenti

Il presente Capitolato Tecnico comprende il servizio formativo relativo all’utilizzo del sistema dedicato agli utenti dell’ATS, sia in presenza che eventualmente in modalità a distanza.

La formazione dovrà consistere in almeno 15 (quindici) giornate da garantire all’ATS per tutta la durata contrattuale, di cui 10 (dieci) a consumo. La formazione potrà essere fruita anche tramite mezze giornate. L’eventuale attività d’aula sarà effettuata presso la sede che verrà indicata dall’ ATS. Tale sede si troverà sul territorio di competenza dell’ATS. Se concordato con ATS, alcune fasi dell’attività di formazione potranno essere effettuate in teleconferenza.

A supporto degli utenti del sistema, l’aggiudicatario 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 ciascuna 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.

8 Servizi di assistenza e manutenzione

L’aggiudicatario è 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 dell’aggiudicatario dovranno essere preventivamente comunicate ad ATS e comunque non dovranno inficiare la normale attività lavorativa (neppure per i mesi di agosto e di dicembre).

8.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 dall’operatore economico;

• 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 l’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 dell’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”.

Il servizio di manutenzione correttiva e assistenza tecnica comprende:

• mano d’opera (illimitata);

• assistenza telefonica (illimitata);

• teleassistenza (illimitata);

• eventuali costi di trasferta del personale dell’aggiudicatario o dei consulenti di cui vorrà avvalersi (illimitati).

L’aggiudicatario dovrà fornire all’ATS idonee e chiare istruzioni operative per l'attivazione del servizio.

Gli interventi dovranno potersi effettuare sia in loco che a distanza, anche in teleassistenza.

L’aggiudicatario dovrà impegnarsi, nel caso di attivazione del servizio di secondo livello, a dare riscontro all’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.

8.2 Manutenzione normativa

L’aggiudicatario s'impegna a fornire, nel periodo contrattuale e senza oneri aggiuntivi per l’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 punto 8.3.

Tutte le attività relative ad aggiornamenti, modifiche, rilascio di nuove release dell'applicazione software dovranno essere opportunamente pianificate con l’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 l’aggiudicatario 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 (es: manutenzione correttiva).

La manutenzione normativa dell'applicazione software si applica negli stessi termini anche alle integrazioni realizzate con altri sistemi.

8.3 Manutenzione evolutiva

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 l’ATS contraente.

Per lo svolgimento di tali attività, ATS richiede all’Aggiudicatario 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 è stimato, per ciascuna Amministrazione, fino ad un massimo di 120 (centoventi) giornate/uomo per tutta la durata contrattuale eventualmente fruibili anche in 240 (duecentoquaranta) mezze giornate/uomo. Tali giornate potranno anche essere utilizzate solo in parte dalle Agenzie; in tal caso verrà corrisponderà all’aggiudicatario solo il costo delle giornate/mezze giornate effettivamente erogate e preventivamente concordate con l’ATS sulla base di un documento tecnico, redatto dall’aggiudicatario che dia evidenza delle attività effettivamente previste.

L’aggiudicatario è 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 Capitolato 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, ciascuna 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.

9 SLA richiesti e criteri di misura

La gestione della fornitura è disciplinata all’interno nel documento “Capitolato Speciale di Appalto” in cui vengono illustrati gli indicatori di qualità e gli SLA della fornitura stessa come parte integrante del presente Capitolato Tecnico: occorre fare pertanto riferimento a tale documento per la descrizione esaustiva degli obiettivi e delle azioni contrattuali previsti.

Dato il rilevante impatto che tale applicativo ha sulla immagine e operatività delle Agenzie, 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.

L’aggiudicatario è 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 dall’aggiudicatario 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.

10 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.

• 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 e loro successive modificazioni e integrazioni.

• 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. Circolare AgID n. 2 del 9 aprile 2018, “Criteri per la qualificazione dei Cloud Service Provider per la PA”. Circolare AgID n. 3 del 9 aprile 2018, “Criteri per la qualificazione di servizi SaaS per il Cloud della PA”. Regolamento per i servizi cloud, pubblicato da AgID a dicembre 2021 con determinazione 628/2021. Determine 306 e 307 di gennaio 2022 pubblicate dalla Agenzia per la Cybersicurezza Nazionale (ACN).
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 alle 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) Fare riferimento a best practices e standard proposti nell’ambito del progetto OWASP (Open Web Application Security Project) e consultabili al seguente link: xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxx_Xxxx
Proprietà intellettuale	L. 633/41 (“Protezione del diritto d'autore e di altri diritti connessi al suo esercizio”).

Document Metadata

Table of Contents

CAPITOLATO TECNICO LOTTO 1

Document Metadata