CAPITOLATO TECNICO

ATS	ATS Milano Città Metropolitana, Ente appaltante e Cliente per il contratto.
Concorrente	Qualsiasi operatore economico partecipante alla gara di appalto.
Aggiudicatario	Il concorrente scelto dalla stazione appaltante per erogare le forniture ed i servizi coperti dal contratto.
OE	Operatore economico concorrente.
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 la storia. 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 dall’aggiudicatario 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 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 del Cliente.
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 Definizioni specifiche relative al Data Warehouse

DWH	Data Warehouse. Un Sistema di Controllo Direzionale caratterizzato dalla presenza di specifici strumenti di ETL, Reportistica e di Business Intelligence dedicati all’analisi dei dati di ATS.
ETL	Extract, Transform, Load. Software per estrazione, trasformazione e caricamento dei dati in un DWH.
BI	Business Intelligence.
OCI	Oracle Cloud Infrastructure.
BDA	Banca Dati Assistiti.
ACN	Agenzia per la Cybersicurezza Nazionale

1.3 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.
SIA	Sistema Informativo Aziendale.

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 è un'unità di misura utilizzata per esprimere la dimensione delle funzionalità fornite da un prodotto software (secondo la metodologia IFPUG 4.3 ed eventuali versioni successive).
CSP	Cloud Service Provider.

Il Data Warehouse di ATS (d’ora in avanti, DWH) è un sistema di supporto alle decisioni in ambito sanitario, sociosanitario e sociale che attraverso una collezione di metodi, tecnologie e strumenti di ausilio al cosiddetto “lavoratore della conoscenza” (dirigenti, analisti, amministratori, etc.) è utilizzato per condurre analisi dei dati finalizzate all’attuazione di processi decisionali e al miglioramento del patrimonio informativo aziendale. Considerata la mole di dati gestiti, tale sistema deve essere caratterizzato da livelli di performance adeguati (in termini di tempi di elaborazione e di risposta) e di adeguatezza delle funzionalità implementate per garantire le seguenti finalità:

• adempimento dei debiti informativi verso ATS, RL, Ministeri e altri Enti;

• conformità con i tracciati regionali;

• integrazione dei dati sulla base di un modello standard definito da ATS;

• flessibilità di interrogazione per trarre il massimo vantaggio del patrimonio informativo esistente anche per utenti con conoscenze limitate della base dati;

• sintesi di analisi mirate ed efficaci anche per utenti con conoscenze limitate di basi dati;

• rappresentazioni multidimensionali;

• correttezza e completezza dei dati integrati;

• reportistica di controllo e gestionale.

Il DWH di ATS è attualmente erogato in cloud attraverso infrastruttura OCI nella sottoscrizione di ATS e comprende, in estrema sintesi, le seguenti componenti:

• base dati Oracle (versione 19 e successive release), comprendente i data mart, le fact table, le dimension table che compongono il DWH stesso, oltre alle stored procedure che contengono le logiche di popolamento delle stesse basi dati;

• procedure ETL basate sul software open source Talend Open Studio (TOS, versione 7.1 e successive release) che, invocate periodicamente in modalità batch schedulata, gestiscono i processi di caricamento dei dati sul DWH in modo automatizzato; alcuni job TOS richiamano procedure Oracle il cui codice sorgente non è di proprietà di ATS;

• moduli di integrazione con applicativi gestionali esterni dedicati all’alimentazione del DWH (es. dati sanitari e sociosanitari, dati dipartimento prevenzione, dati risorse umane, etc.);

• portale di Business Intelligence (BI), basato su tecnologia QLIK Sense, la cui assistenza e manutenzione non sono oggetto del presente capitolato;

• portale di Business Intelligence (BI) basato sul prodotto open source Pentaho in cloud Microsoft Azure connesso a OCI, dedicato a specifici servizi di ATS (Farmaceutica, Controllo di Gestione, ...) la cui assistenza e manutenzione è oggetto del presente capitolato;

• applicativo web di cui ATS possiede una licenza d’uso illimitata ma non il codice sorgente e la cui assistenza e manutenzione non sono oggetto del presente capitolato, utilizzato per il caricamento dei flussi sul DWH tramite l’upload di file in formato testo e l’accodamento dei processi gestiti dagli ETL sopra citati;

• applicativo web di cui ATS possiede una licenza d’uso illimitata ma non il codice sorgente e la cui assistenza e manutenzione non sono oggetto del presente capitolato, che implementa un portale dedicato all’analisi delle prestazioni sanitarie e sociosanitarie del singolo Cittadino.

2.2 Scopo del documento

ATS ha l’esigenza di individuare l’operatore economico al quale affidare l’attività di assistenza e manutenzione, ordinaria e straordinaria, del DWH aziendale comprendente tutte le componenti indicate al paragrafo precedente.

L’aggiudicatario dovrà prevedere la messa a disposizione e la cessione perpetua ad ATS da parte dell’aggiudicatario di tutte le componenti software realizzate nel corso del contratto, comprensive del relativo codice sorgente.

Come indicato nel resto del documento (requisito COM1 – “Integrazione con applicativi, scalabilità e estendibilità”), il sistema è integrato con alcuni applicativi in uso presso ATS dai quali vengono importati i dati. Il servizio di assistenza e manutenzione dell’aggiudicatario deve comprendere in generale anche queste integrazioni e quelle che verranno introdotte nel corso del periodo contrattuale.

Il presente documento descrive le attività ed i servizi connessi alla gestione ed alla assistenza e manutenzione del sistema DWH nella sua globalità.

2.3 Contesto tecnologico ed operativo

Collocato su un’infrastruttura Oracle Cloud Infrastructure (OCI) nella sottoscrizione di ATS, il DWH ha la sua componente principale in un database Oracle, attualmente indicativamente delle dimensioni di 4 TB ma in progressivo aumento, che contiene i dati provenienti da varie fonti, con una profondità storica risalente, in alcuni casi, al 2010. Tali dati, attraverso specifici progetti TOS che lanciano all’occorrenza procedure Oracle, sono caricati in fact table dopo essere stati normalizzati e verificati, e successivamente vengono usati per il popolamento dei data mart che nel tempo sono stati implementati per rispondere alle esigenze di analisi e/o informative di ATS.

Come detto, il DWH è attualmente ospitato su infrastruttura OCI conforme alla normativa vigente (GDPR) in tema di privacy e sicurezza informatica, la gestione della profilazione e delle credenziali di accesso al DWH è garantita attraverso strumenti e tecnologie native Oracle OCI.

Il caricamento dei dati sul DWH avviene secondo diverse modalità:

1. import manuale di dati da parte del personale addetto del SIA di ATS: si tratta di caricamenti estemporanei che non ricadono nel perimetro delle attività di assistenza e manutenzione oggetto del presente capitolato;

2. import da database di applicativi gestionali sanitari e sociosanitari e amministrativi: si tratta di caricamenti regolarmente effettuati attraverso attività schedulate di dati presenti su database (tecnologie: Oracle, SQL Server, etc.) appartenenti alla rete di ATS; l’assistenza e la manutenzione di questi processi di import sono ricomprese nelle attività oggetto del presente capitolato;

3. import da file di testo: attraverso una web application dedicata già citata nei paragrafi precedenti, gli utenti opportunamente abilitati possono caricare dei file di testo corredandoli dei necessari metadati (tipo di flusso, periodo di riferimento, eventuali note). Ogni notte attraverso un task schedulato vengono lanciati dei processi TOS che, nel caso siano presenti nuovi txt da caricare, effettuano le operazioni di ETL e successivamente lanciano le procedure per il popolamento dei data mart interessati.

La consultazione dei dati presenti nel DWH, in forma di fact table o di data mart, avviene secondo diverse modalità e previa positiva autenticazione:

a) attraverso una web application, già citata nei paragrafi precedenti, dedicata all’analisi puntuale della

storia sanitaria e sociosanitaria di un singolo assistito;

b) attraverso app QLIK Sense pubblicate ed in uso presso ATS;

c) attraverso app Pentaho pubblicate ed in uso presso ATS;

d) attraverso l’interrogazione di viste e tabelle direttamente su Oracle utilizzando strumenti e tecnologie dedicate (SQL developer, Quest TOAD, SAS, script PHP, etc.).

L’abilitazione all’accesso alle tabelle/viste Oracle avviene attraverso gli strumenti nativi OCI, l’accesso attraverso le app citate e quelle di BI (QLIK Sense, QLIK Data Transfert, Pentaho) avviene operando direttamente sui rispettivi contesti applicativi.

A titolo puramente indicativo, di seguito sono riassunti alcuni dati numerici che descrivono le dimensioni attuali del DWH di ATS. Durante l’esecuzione del contratto, tali dimensioni potranno variare senza alcuna limitazione, senza che questo aspetto possa essere considerato influente rispetto agli obblighi verso l’aggiudicatario.

	SCHEMI	VISTE	TABELLE	Stored Procedure
TOTALE	20	1.200	2.200	520

• Oracle: numerosità indicativa

complessiva circa 4 (quattro) TB in progressivo aumento

• Oracle: dimensione

• Numero Progetti TOS (ETL): 40 (per maggiori dettagli fare riferimento all’Appendice A al presente capitolato)

• App QLIK Sense:

o numero indicativo di report alimentati: 10

o numero indicativo di cubi: 10

• App Pentaho:

o numero indicativo di report: 40

o numero indicativo di cubi: 55

2.4 Oggetto del servizio

L’aggiudicatario è tenuto a garantire il servizio di assistenza e manutenzione del database Oracle su OCI contenente i dati del DWH, comprensivo di tutti gli oggetti (tabelle, viste, stored procedure, stored function, etc.) già presenti e di tutti quelli che verranno creati durante il periodo contrattuale. A questo proposito l’aggiudicatario dovrà assicurare ad ATS i seguenti servizi:

• servizio di assistenza e manutenzione, correttiva ed evolutiva, delle componenti database in modo da garantire il relativo funzionamento di tutte le viste, stored procedure e stored function presenti sul database Oracle del DWH aziendale;

• adeguato supporto ad ATS nel monitoraggio del sistema e nell’analisi delle performance del sistema (tabelle, viste, stored procedure, indici, etc.) utilizzando gli strumenti nativi OCI (Enterprise Manager, log, etc.) ed effettuando autonomamente gli interventi di adeguamento necessari oltre a realizzare quelli richiesti da ATS che a sua volta ha facoltà di avvalersi della consulenza offerta dai servizi professionali Oracle e/o terze parti e con cui l’aggiudicatario è tenuto a collaborare in sinergia per l’espletamento degli specifici interventi;

• adeguato supporto ad ATS nella creazione e modifica delle strutture dati (tabelle, viste, etc.) necessarie ad accogliere nuovi flussi e/o nuove annate dei flussi esistenti;

• eventuale supporto a fornitori terzi di ATS, laddove richiesto in relazione alle attività di integrazione al DWH;

• presenza presso la sede di ATS, se richiesto dal DEC, nell’ambito dello svolgimento delle previste giornate evolutive a consumo.

Relativamente alle componenti TOS su OCI, l’aggiudicatario dovrà assicurare ad ATS:

• il servizio di assistenza e manutenzione correttiva ed evolutiva dei pacchetti TOS pubblicati al momento della sottoscrizione del contratto e per tutta la durata dello stesso;

• il servizio di manutenzione evolutiva attraverso la creazione dei nuovi pacchetti TOS che dovessero rendersi necessari nel corso della validità del contratto.

In generale, per quanto riguarda il database Oracle ed il server TOS, l’aggiudicatario dovrà garantire ad ATS un adeguato servizio di assistenza e manutenzione correttiva ed evolutiva, prendendo in carico i componenti esistenti al momento della sottoscrizione del contratto e garantendo il medesimo servizio su tutte le modifiche che interverranno nel corso della validità del contratto stesso.

ATS considera necessario garantire il servizio di assistenza e manutenzione preservando l’architettura attuale del DWH in modo da escludere potenziali impatti sulle applicazioni attualmente integrate col sistema e la necessità di migrazione dei dati.

Il presente capitolato include inoltre, opportunamente ricompresa nella base d’asta di gara, l’attività di conversione degli attuali cruscotti e report Pentaho in nuovi cruscotti di BI con tecnologia QLIK Sense. Tale attività dovrà essere svolta dall’aggiudicatario nel corso del periodo contrattuale, previo accordo con il DEC. Si sottolinea che le licenze QLIK Sense necessarie per completare tali sviluppi non sono comprese nella fornitura, ovvero l’aggiudicatario è tenuto a disporre di proprie specifiche licenze di prodotto.

2.5 Contesto normativo, tecnologico ed operativo

Il DWH di ATS è collocato ed erogato in ambiente cloud, conformemente alla normativa vigente a cui si rimanda per completezza con particolare riferimento ai criteri per la qualificazione dei servizi cloud per la PA.

Il gestore dei servizi cloud (CSP) scelto da ATS garantisce una infrastruttura qualificata almeno QI1 secondo quanto previsto da ACN. A maggior tutela dei dati personali trattati, ATS richiede inoltre che il CSP garantisca la conservazione dei dati e/o delle relative chiavi di cifratura esclusivamente in data center collocati (region) nel territorio italiano.

Con riferimento al Decreto direttoriale prot. N. 29 del 02/01/2023 dell’Agenzia per la Cybersicurezza Nazionale (ACN) è disponibile la procedura di qualificazione dei servizi cloud per la PA. In relazione alla natura dei dati trattati e del servizio digitale gestito, l’Aggiudicatario dovrà garantire un servizio qualificato almeno QC1 secondo quanto previsto da ACN.

ATS richiede 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 un servizio che garantisca il rispetto dei previsti obiettivi di sicurezza, dal punto di vista della confidenzialità, integrità e disponibilità dei dati trattati.

È compito di ATS verificare l’effettivo rispetto delle dichiarazioni prodotte in sede di qualificazione dall’aggiudicatario. In caso di servizi non conformi a quanto dichiarato dall’aggiudicatario, ATS è tenuta a segnalare la circostanza ad XxXX e ACN proponendo, in caso di esito confermativo dell’apposita verifica, la revoca della qualificazione.

L’aggiudicatario dovrà essere in possesso delle polizze assicurative di cui all’art. 15 del Capitolato Speciale d’Appalto.

Si ricorda che nella nomina dell’aggiudicatario a Responsabile al Trattamento Esterno dei dati (Regolamento UE 2016/679) saranno indicati i compiti, gli obblighi e le responsabilità contrattuali dell’aggiudicatario previsti da ATS.

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

2.6 Durata del contratto

La durata del contratto è stabilita in 36 mesi, decorrenti dalla data di sottoscrizione del contratto.

L’aggiudicatario è tenuto a consegnare la soluzione collaudata e completa di tutte le parti specificate nel presente Capitolato Tecnico (cruscotti BI realizzati in tecnologia QLIK) e/o proposte dall’offerente in sede di gare entro un massimo di 35 giorni solari dalla data di sottoscrizione del contratto.

A seguito della firma del contratto decorrerà il servizio di assistenza e manutenzione.

La non osservanza di tale pianificazione da parte dell’aggiudicatario è soggetta all’applicazione di penali e può determinare l’eventuale risoluzione del contratto.

Alla conclusione naturale del contratto l’aggiudicatario è tenuto a garantire ad ATS un adeguato passaggio di consegne. Le stesse modalità devono essere assicurate dall’aggiudicatario in caso di eventuale conclusione anticipata del contratto.

Per ogni progetto che verrà assegnato, l’aggiudicatario è tenuto a garantire ad ATS un adeguato passaggio di consegne alla conclusione del progetto stesso o comunque entro il termine naturale del contratto. Le stesse modalità dovranno essere assicurate dall’aggiudicatario in caso di eventuale conclusione anticipata del contratto.

2.7 Proprietà intellettuale

Tutto il software relativo alla presente fornitura, unitamente a tutte le successive modifiche (correttive e/o evolutive e/o migliorative) che verranno introdotte dall’aggiudicatario nel corso del contratto, unitamente a tutta la documentazione tecnica e di esercizio prodotta, sono da intendersi di proprietà intellettuale di ATS.

3 Requisiti funzionali

I paragrafi seguenti descrivono le funzionalità implementate dal sistema DWH, oggetto del presente Capitolato.

Il sistema DWH è costruito secondo uno schema classico multidimensionale per gestire informazioni di tipo

“Fatti” e di tipo “Dimensioni”. In estrema sintesi, il DWH di ATS consente:

• la registrazione dei fatti al livello di massimo dettaglio consentito dalle caratteristiche dei flussi di origine;

• la storicizzazione e aggiornamento di tutte le dimensioni, tabelle che gestiscono l’insieme degli

attributi descrittivi dei vari oggetti del DWH (comprese le tabelle di decodifiche).

Per completezza, sono da considerarsi parti integranti della presente specifica funzionale tutti i riferimenti bibliografici, documentali e normativi referenziati all’interno del presente documento.

3.1 Gestione flussi di produzione e consumo sanitari e sociosanitari

ORA1

Funzionalità implementate dagli oggetti Oracle

Il sistema deve consentire il caricamento, il trattamento e la gestione dei flussi di produzione e consumo (Anagrafiche Assistiti, Esenzioni, Ambulatoriale, SDO, Farmaceutica, File F, Psichiatria, Screening, Pronto Soccorso, Laboratorio Sanità, Vaccinazioni, Protesica Maggiore Minore, Dipendenze, Consultori Familiari, ADI, Istituti di Riabilitazione Territoriale, RSA, etc.) e dei flussi denominati Famiglia (Misura RSA Aperta, Misura Residenzialità per Minori Gravissimi Disabili, etc.). Si sottolinea che l’elenco suddetto è puramente indicativo, si considerano ricompresi tutti i flussi istituzionali e di rilevanza strategica gestiti da ATS.

Ogni flusso è caratterizzato da un proprio tracciato record (secondo gli standard definiti da RL e/o concordati con ATS) e prevede parametri e codici di controllo specifici.

I dati sono organizzati in fact table, dimension table e datamart, consultabili ed esportabili (in formati standard) sia con accesso diretto al DWH che attraverso strumenti di BI.

Più nel dettaglio, il sistema consente di acquisire e gestire i tracciati relativi ad almeno i seguenti flussi di attività:

• Ambulatoriale: Flussi informativi delle prestazioni ambulatoriali e di diagnostica strumentale;

• SDO: flussi informativi delle Schede di dimissione ospedaliere;

• Anagrafiche degli Assistiti e Residenti;

• Anagrafe Esenzioni: flussi esenzioni relativi agli Assistiti di ATS;

• Ricette FUR relativo alla farmaceutica convenzionata

• Ricette DPC relativo ai farmaci distribuiti direttamente da ATS

• File F: Farmaci a somministrazione diretta a pazienti non ricoverati;

• Psichiatria 46/san: Rilevazione delle prestazioni erogate dalle strutture psichiatriche pubbliche e private accreditate;

• Flussi relativi ad attività di particolare impegno professionale erogata dai PLS e MMG;

• Screening;

• Pronto Soccorso;

• Laboratorio Sanità Pubblica;

• Vaccinazioni ATS;

• Fatturazione Passiva;

• Dipendenze;

• Protesica Maggiore e Minore;

• CON: flusso relativo alle attività erogate dai consultori pubblici e privati per prestazioni ambulatoriali e sociosanitarie;

• SDOFAM: flusso informativo per la rilevazione delle informazioni dei ricoveri riabilitativi;

• RIAFAM: prestazioni di riabilitazione ambulatoriale, diurno continuo e domiciliare;

• SIAD: flusso informativo per la rilevazione delle prestazioni di assistenza domiciliare;

• SIDI: debito informativo relativi alle prestazioni offerte agli assistiti che accedono alle strutture d’offerta per disabili (RSD, CDD, CSS);

• SOSIA: rilevazione delle prestazioni erogate dalle RSA;

• Misura RSA Aperta: informazioni analitiche dei dati riferiti agli assistiti a cui è stato erogato un Voucher come previsto dalla ex DGR 2942/2014 per l’erogazione della Misura RSA Aperta;

• Misura Residenzialità Assistita/Religiosi: informazioni analitiche dei dati riferiti agli assistiti a cui è stato erogato un Voucher come previsto dalla ex DGR 2942/2014 per l’erogazione della Misura di Residenzialità Leggera/Assistita e dalla DGR 4086/2015 per le Comunità Religiose;

• Misura Residenzialità Gravissimi Disabili: informazioni analitiche dei dati riferiti agli assistiti a cui è stato erogato un Voucher come previsto dalla ex DGR 2942/2014 per l’erogazione della Misura di Residenzialità per minori con gravissima disabilità;

• Comunità per Minori: flusso delle Comunità per Minori sottratti alla famiglia

(Comune);

• rete UDO Misure: anagrafica delle reti delle Unità d’offerta usate da ATS per le

Misure;

• flusso FE1: rendicontazione economica per strutture d’offerta (CDD, XXX, XXX, XXX,

XXX, XXX, XXX, XXX, XXX);

• flusso FE2: flusso economico relativo alle prestazioni sociosanitarie fuori regione (RIA, RSA, RSD, TOX, HOSPICE, ADI, UCPDOM); tale flusso è gestito in modalità assistita da personale ATS;

• flusso FE4: flusso economico per la rilevazione della produzione di ADI;

• flusso B1: flusso economico riguardante il fondo nazionale Non Auto Sufficienza (Misura B1), gestito da ATS;

• flusso B2: flusso economico riguardante il fondo nazionale Non Auto Sufficienza (Misura B2), gestito e compilato in modalità assistita da Ambiti/Comuni;

• flusso Dopo di Noi: flusso economico relativo alle risorse ministeriali per progettualità specifiche delle persone disabili, compilato in modalità assistita da Ambiti/Comuni.

• Flussi giornalieri inviati da ARIA/RL (tempi di attesa, tamponi, vaccinazioni Covid, etc).

• Flussi giornalieri inviati dal Comune di Milano e di Sesto San Xxxxxxxx (variazioni dati anagrafici e demografici).

• Flussi giornalieri inviati dal Comune di Milano (decessi).

• Altro.

• Altri flussi attualmente in via di definizione.

Si sottolinea che l’aggiudicatario è tenuto a farsi carico del servizio di assistenza e manutenzione del database Oracle che contiene i dati del DWH, comprensivo di tutti gli oggetti (tabelle, viste, stored procedure, stored function, etc.) già presenti e di tutti quelli che verranno creati nel corso del contratto.

Rientrano tra i compiti dell’Aggiudicatario le seguenti attività:

• analisi di performance su tabelle, viste, stored procedure, indici, ivi compresi gli interventi necessari per garantire la migliore efficienza del sistema anche attraverso gli strumenti nativi di OCI;

• supporto ai referenti di ATS nella creazione e modifica delle strutture dati necessarie ad accogliere nuovi flussi e/o nuove annate dei flussi esistenti;

• garantire il corretto funzionamento di tutte le viste, stored procedure e stored

function presenti sul database Oracle.

3.2 ETL

TOS1	Funzionalità implementate tramite TOS

Il sistema DWH comprende lo strumento di ETL open source TOS (Talend Open Studio). Il ruolo di TOS è quello di alimentare una sorgente dati singola, dettagliata, esauriente di alta qualità che possa a sua volta alimentare il DWH. In caso di architettura a tre livelli di fatto questi strumenti alimentano il livello dei dati riconciliati; le operazioni da essi svolte vengono quindi spesso globalmente designate con il termine riconciliazione e sono tra le diverse fasi del processo di warehousing più complesse. Il processo di riconciliazione avviene in due occasioni: quando il DWH viene popolato per la prima volta e, periodicamente, quando il DWH viene aggiornato. Essa consiste in quattro distinti processi: estrazione, pulitura, trasformazione e caricamento.

Parte dei flussi descritti dal requisito ORA1 devono essere utilizzati dal sistema per generare, tramite processi TOS, un datamart che risponda ai criteri di cronicità dell’assistito previsti dalle specifiche relative alla Banca Dati Assistiti (BDA) versione 2010 o successive, comprensive di alcune specificità introdotte da ATS.

Si sottolinea che le attuali funzionalità TOS consentono il trattamento di dati provenienti da fonti eterogenee (es. DB esterni, container condivisi, etc.).

Si sottolinea che l’aggiudicatario è tenuto a farsi carico delle attività sistemistiche di TOS facente parte del sistema DWH, comprensiva di tutti i progetti in produzione e dei job che li avviano in maniera schedulata. Sono ricompresi nel servizio di assistenza anche tutti i progetti TOS che saranno creati durante la validità del contratto.

Nel corso del contratto, secondo tempi e modalità da concordare con ATS, l’aggiudicatario è tenuto ad effettuare l’aggiornamento di TOS all’ultima versione disponibile, o comunque a quella concordata con ATS, nonché di tutte le componenti impattate dall’aggiornamento di TOS.

Per i progetti TOS in ambito al progetto, la proprietà intellettuale e la relativa complessità fare riferimento alla Appendice A del presente documento.

3.3 Caricamento dati

WEB1

Funzionalità di caricamento dati (web app dedicata al caricamento flussi dati)

Tale requisito funzionale è inserito per completezza, la relativa web app non è in ambito alla presente fornitura.

Il sistema attualmente prevede un cruscotto per la gestione ed il monitoraggio dei caricamenti. Tale cruscotto è incluso nella web application indicata in precedenza.

Tale cruscotto consente di mostrare, per ciascun caricamento, lo stato e l’esito dello stesso (in caricamento, caricato, fallito, etc.) ed i metadati principali (data invio, ambito, periodo). Il

cruscotto mostra anche i dati dei caricamenti effettuati da ATS prima della sottoscrizione contrattuale.

La maschera di caricamento di un nuovo flusso deve prevedere almeno i seguenti dati:

• inizio periodo di riferimento dati (mese-anno);

• fine periodo di riferimento dati (mese-anno);

• tipologia flusso, organizzato con due menu a tendina gerarchici di tipo “Ambito” e “Sotto-Ambito” (ad esempio: per i dati di attività ambulatoriale, l’Ambito potrebbe essere Ambulatoriale e i Sotto-Ambiti potrebbero essere Ambulatoriale ATS, Ambulatoriale Fuori Regione, Ambulatoriale Anagrafica Strutture);

• testo libero di descrizione dell’invio;

• testo libero opzionale per eventuali note.

Il sistema deve permettere l’upload del file contenente i dati (formato zip, txt, csv, etc.) depositando tale file in una cartella predefinita, dalla quale i processi TOS schedulati potranno prelevarlo, inserendo nelle tabelle i dettagli dell’invio appena effettuato.

Il sistema deve prevedere un’adeguata reportistica che fornisca giornalmente il resoconto (esito e/o eventuali problematiche riscontrate) via mail dei flussi caricati attraverso la web application.

3.4 Analisi di dettaglio prestazioni

WEB2

Funzionalità per analisi prestazioni (web app dedicata alla ricerca delle prestazioni

dell’assistito)

Tale requisito funzionale è inserito per completezza, la relativa web app non è in ambito alla presente fornitura.

Il sistema deve permettere ad utenti opportunamente profilati di accedere ad una maschera riassuntiva contenente il dettaglio delle prestazioni sanitarie e sociali e sociosanitarie di un singolo cittadino, derivate dall’incrocio di tutti i dati presenti sul DWH (fare riferimento ai flussi sanitari, sociosanitari e sociali indicati al requisito ORA1). Tale maschera è inclusa nella web application indicata in precedenza.

Il sistema deve comprendere un data mart dedicato ed ottimizzato ai fini specifici del portale, le procedure per l’alimentazione del data mart stesso ed un progetto TOS che orchestri il lancio delle procedure e la predisposizione del data mart.

Il sistema deve permettere la ricerca dell’assistito attraverso un unico campo che effettui la ricerca della stringa inserita dall’utente nei campi nome, cognome, codice fiscale e tessera

sanitaria degli assistiti. La funzionalità consente di auto-proteggersi da comportamenti poco accorti o fraudolenti degli utenti, quali stringhe di ricerca troppo brevi o SQL injection.

Prima di mostrare i dati di dettaglio di un singolo cittadino, il sistema deve raccogliere e memorizzare una dichiarazione da parte dell’utente relativa alle finalità con le quali sta utilizzando il portale.

Una volta selezionato il cittadino, il portale permette di mostrare le prestazioni inerenti almeno i seguenti ambiti:

• Ambulatoriale

• Degenze

• Laboratorio analisi

• Pronto soccorso

• Day Hospital

• Doppio Canale

• Farmaceutica

• File F

• Sociali e sociosanitarie (es. Residenze Anziani, Cure Intermedie, RSA Aperta, Comunità Disabili, etc.)

• Esenzioni (solo per soggetti afferenti alla ATS)

permettendo quindi all’utente di scegliere quali di essi visualizzare ed un intervallo di date su cui filtrare le prestazioni. Deve essere possibile memorizzare la combinazione di questi filtri e poterla richiamare in seguito per applicarla anche ad altri cittadini.

Per ciascuna prestazione rispondente ai filtri impostati dall’utente, il portale permette di mostrare:

• Data

• Tipologia (Ambulatoriale, Degenze, etc.)

• Dettaglio attività

• Quantità

• Luogo di erogazione

• Descrizione

• Medico prescrittore

• Numero di ricetta

Deve essere possibile esportare in formato Excel o CSV i dettagli mostrati a video.

L’accesso alla web application avviene attraverso Azure AD.

Il sistema deve effettuare il tracciamento (codici fiscali, prestazioni, etc.) di tutte le attività di ricerca effettuate dagli utenti autorizzati opportunamente profilati su DWH tramite gli strumenti nativi di Oracle OCI.

3.5 Storicizzazione

STO1

Storicizzazione dati

Il sistema deve garantire, a valle dei caricamenti effettuati (via web, import da gestionali esterni, import estemporanei), la corretta storicizzazione dei dati associati ai vari flussi indicati in ORA1.

La storicizzazione è già garantita intrinsecamente per tutti i caricamenti con frequenza giornaliera, settimanale, mensile, trimestrale, quadrimestrale e annuale, indipendentemente dalla modalità di aggiornamento (incrementale o integrale).

L’eccezione è rappresentata da quei flussi (in particolare: Assistiti, Xxxxxx, Esenzioni) che riflettono una specifica situazione (assistito in carico al medico, esenzione in carico all’assistito) in un preciso momento temporale. In tali casi è necessario dare evidenza della effettiva variazione avvenuta alimentando e storicizzando data mart dedicati che stratificheranno nel tempo variabili essenziali e selezionate dalla ATS (es. medico di base, residenza, stato assistito, iscrizione a termine, calcolo del carico assistiti effettivi, etc.).

Si evidenzia in particolare che, per il contesto dell’epidemiologia, la storicizzazione dei dati riguarda i flussi provenienti dal NAR relativamente agli assistiti di tutta RL.

3.6 Georeferenziazione

GEO1

Georeferenziazione indirizzi presenti nel DWH ATS: Latitudine e Longitudine

All’interno del sistema DWH sono presenti fact table e data mart contenenti informazioni relative ad indirizzi fisici (quali ad esempio: l’anagrafica dei cittadini, delle strutture, delle farmacie, etc.).

In tutte le tabelle in cui tali informazioni sono presenti (solitamente sotto forma di Città – via, piazza … – numero civico), ATS ha predisposto dei campi “Latitudine” e “Longitudine” nei quali sono memorizzate le coordinate piane UTM32N riferite al sistema geodetico di riferimento WGS84.

Durante tutto l’arco di validità del contratto, l’aggiudicatario deve garantire la manutenzione di tali tabelle, inserendo nei nuovi indirizzi che dovessero comparirvi le relative coordinate in accordo con le specifiche sopra riportate. Il meccanismo di ricerca di tali coordinate deve

attivare la normalizzazione degli indirizzi e l’aggiornamento dei rispettivi record con

l’informazione corretta. L’aggiornamento deve poter essere schedulato con una cadenza concordata con ATS (settimanale o mensile, a seconda del carico che potrà produrre sul DWH e delle finestre temporali disponibili).

L’algoritmo di normalizzazione degli indirizzi deve essere in grado di recepire tutti gli eventuali aggiornamenti degli stradari del territorio afferente alla ATS.

GEO2

Georeferenziazione indirizzi presenti nel DWH ATS: CAP

Analogamente al requisito GEO1, il sistema dispone ove necessario di un campo CAP che l’aggiudicatario deve garantire opportunamente compilato sulla base dell’indirizzo normalizzato.

L’algoritmo di normalizzazione degli indirizzi deve essere in grado di recepire tutti gli eventuali aggiornamenti degli stradari del territorio afferente alla ATS.

3.7 Gestione log

LOG1

Log applicativi

Tutte le attività svolte, anche in modalità automatica e massiva, devono essere registrate in appositi file applicativi e/o tabelle.

Il sistema deve tracciare nei file di log anche tutte le operazioni di comunicazione di dati da e verso applicativi esterni, eventualmente utilizzando gli strumenti nativi OCI.

Tali file e/o tabelle devono essere consultabili da parte del personale ATS autorizzato.

3.8 Gestione alert

ALM1

Mail di alert

Il sistema deve garantire una messaggistica dedicata che dia evidenza agli amministratori del sistema degli esiti delle attività pianificate:

• caricamenti flussi da TOS (es. record caricati con successo, fallimenti, scarti, etc.);

• caricamenti dati da fonti esterne non gestiti attraverso TOS ma tramite integrazioni applicative.

3.9 Strumenti di analisi e reporting (Business Intelligence)

PEN1

Pentaho

Il sistema deve garantire la corretta integrazione con gli strumenti di BI utilizzati da ATS (QLIK Sense, Pentaho) per l’analisi delle informazioni di supporto alle attività decisionali.

A questo proposito si sottolinea che l’aggiudicatario è tenuto a garantire le attività sistemistiche relative a Pentaho e l’assistenza e manutenzione di tutti gli oggetti di BI (report e cubi) presenti alla partenza del contratto nonché di quelli che saranno creati durante tutto il periodo contrattuale.

Si sottolinea che nel corso del contratto, secondo tempi e modalità da concordare con ATS, l’Aggiudicatario è tenuto ad effettuare l’aggiornamento di Pentaho all’ultima versione disponibile, o comunque a quella concordata con ATS, nonché di tutte le componenti impattate dall’aggiornamento di Pentaho.

Si sottolinea inoltre che nel corso del contratto, secondo tempi e modalità da concordare con ATS, l’aggiudicatario è tenuto ad effettuare la conversione degli attuali cruscotti e report Pentaho in nuovi cruscotti di BI con tecnologia QLIK Sense. Tale attività deve essere svolta dall’aggiudicatario nel corso del periodo contrattuale previo accordo con i referenti DWH di ATS. Si sottolinea che le licenze QLIK Sense necessarie per completare tali sviluppi non sono comprese nella fornitura ovvero l’aggiudicatario è tenuto a disporre di proprie specifiche licenze di prodotto.

I report e/o cubi attualmente realizzati attraverso Pentaho si basano sui seguenti flussi dati:

28/SAN - FARMACEUTICA - FILEF - PS- SDO - ADI-ADP XXXX XXXX (report) - FE1 - FE2 - FE4 -

DIPENDENZE - LAB SANITA’ - SIAD - Residenti Assistiti - Doppio Canale - Analisi Covid 28/SAN e SDO - NPIA - BDA

4 Requisiti non funzionali

Le attività di assistenza e manutenzione richieste nella fornitura, devono essere previste e condotte dall’aggiudicatario anche nel rispetto di vincoli e requisiti non funzionali, tecnologici e procedurali riguardanti in generale la qualità e l’operatività del sistema.

4.1 Requisiti organizzativi

ORG1

SPOC (Single Point of Contact)

Al fine di rendere più efficaci le comunicazioni tra ATS e aggiudicatario, quest’ultimo dovrà individuare e comunicare ad ATS, fin dalle prime fasi del servizio, un referente unico di contatto (SPOC) per tutta la durata del contratto.

Tra SPOC e referenti di progetto ATS dovranno essere condivisi e concordati tutti gli interventi applicativi, sistemistici e manutentivi, sia in fase di sviluppo che di esercizio.

Lo SPOC individua la responsabilità per l’accesso, lato aggiudicatario, alle informazioni sensibili trattate dal sistema, nel rispetto integrale di tutti i vincoli di sicurezza e qualità definiti nel presente documento.

ORG2	Assistenza tecnica qualificata
	A seconda della tipologia di intervento richiesto, l’aggiudicatario metterà a disposizione di ATS un proprio servizio di assistenza tecnica 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 l’elevato grado di confidenzialità e sensibilità delle informazioni gestite, l’aggiudicatario dovrà garantire tutte le misure di sicurezza logica (riservatezza, integrità, disponibilità dei dati) ed organizzativa per garantire il rispetto della normativa vigente, tenendo conto delle best practices di sicurezza informatica.

SEC2

Privacy

Fare riferimento alla normativa sulla privacy secondo quanto riportato al capitolo “Riferimenti documentali e normativi” del presente documento.

L’aggiudicatario sarà designato Responsabile Esterno al trattamento dei dati.

SEC3	GDPR (General Data Protection Regulation) – Regolamento UE 2016/679
	Le prestazioni oggetto del presente capitolato tecnico devono essere conformi al nuovo Regolamento Generale sulla Protezione dei Dati (GDPR, General Data Protection Regulation – Regolamento UE 2016/679).

SEC4	Accordi di Non Divulgazione (NDA) e di Trattamento dei Dati (DPA)
	L’aggiudicatario dovrà garantire la non divulgazione delle informazioni sensibili trattate dal sistema a cui avrà accesso nel corso delle fasi di progettazione, sviluppo e manutenzione del sistema. Tali accordi (Non Disclosure Agreement, NDA) dovranno valere anche dopo la conclusione del contratto.

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

SEC5

Audit e Monitoraggio

ATS si riserva la facoltà di sottoporre ad audit e monitoraggio tutte le attività del servizio e in particolare relative al trattamento delle informazioni sensibili effettuate dall’aggiudicatario e dal personale di cui esso vorrà avvalersi, per tutta la durata del contratto.

Le attività di audit e monitoraggio potranno riguardare i seguenti processi:

• qualità e prestazioni dei servizi erogati dal sistema;

• conformità dei servizi erogati dal sistema alle policy di ATS, riferite nel presente documento;

• vulnerabilità assessment (e relativi penetration test) del sistema per validare la corretta configurazione dei componenti nativi OCI preposti alla sicurezza del DWH (ad esempio: accesso non autorizzato alle risorse, …).

ATS informerà lo SPOC dell’aggiudicatario, con preavviso di almeno 30 giorni, della pianificazione, dei tempi e delle modalità delle sessioni di audit previste.

4.3 Requisiti e vincoli tecnologici e infrastrutturali

TEC1

Accesso web

Il presente requisito non funzionale è inserito per completezza non essendo le due web app incluse nella presente fornitura.

Le funzionalità relative alle due web application devono poter essere raggiungibili dagli utenti autorizzati attraverso l’accesso alla rete Internet, col solo utilizzo di un browser, senza limitazioni di accessi concorrenti.

Lato client, il sistema deve essere conforme alle normative nazionali in tema di accessibilità dei sistemi informatici.

TEC2	Interfaccia web
	Il presente requisito non funzionale è inserito per completezza non essendo le due web app incluse nella presente fornitura.

Le funzionalità relative alle due web application dovranno 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;

• Edge, Mozilla Firefox, Chrome;

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.

La presentazione delle pagine web dovrà essere realizzata in HTML5.

TEC3	Formati e software di appoggio
	Si deve tenere presente che tutti i file di produzione ‘esterna’ del software (ad esempio: report, tabelle, fogli di calcolo,etc.) dovranno essere compatibili con i software di produttività personale, sia open source che commerciali, più in uso (ad esempio Microsoft Office ed Open Office) nella versione più aggiornata disponibile.

TEC4

Evoluzioni tecnologiche

Il presente requisito non funzionale è inserito per completezza non essendo le due web app incluse nella presente fornitura.

In merito alle due web application, si dovrà garantire il loro eventuale adeguamento rispetto a nuove versioni ed aggiornamenti di browser, sistemi operativi, software di base, middleware che i vari vendor dovessero rilasciare per tutto il periodo di validità contrattuale.

Tali aggiornamenti dovranno essere garantiti entro:

• un mese per quanto riguarda il rilascio di patch;

• tre mesi per quanto riguarda il rilascio di nuove release.

TEC5	Identificazione & Autenticazione degli utenti
	L’accesso al sistema dovrà utilizzare Microsoft Azure Active Directory (conforme alla normativa di sicurezza GDPR) per gli utenti interni di ATS e per gli utenti amministratori (sia essi interni ad ATS che dell’aggiudicatario).

TEC6

Gestione utenti e Azure Active Directory (AD)

L’accesso al sistema dovrà avvenire mediante autenticazione Microsoft Azure AD.

Le utenze del sistema dovranno essere create in Azure AD ed opportunamente profilate (ruoli

utente) all’interno del sistema stesso attraverso gli strumenti nativi OCI.

Il sistema dovrà disporre di tutte le informazioni (certificati e metadati) e funzionalità per la convalida dei token di autenticazione restituiti da Azure AD: a valle della convalida dei token verranno avviate le sessioni utente.

Le policy di validità temporale delle sessioni utente implementate tra Azure AD e OCI dovranno impedire la potenziale perdita dei dati alla scadenza dei token di sicurezza.

4.4 Requisiti di integrazione

COM1

Integrazione con applicativi, scalabilità e estendibilità

Il sistema è integrato con alcuni applicativi in uso presso ATS dai quali vengono importati i dati. Il servizio di assistenza e manutenzione dell’aggiudicatario comprende in generale anche queste integrazioni e quelle che verranno introdotte nel corso del periodo contrattuale.

Il sistema è attualmente integrato con una replica della base dati delle anagrafiche degli assistiti di ATS (MPI, Master Patient Index) alimentata a sua volta dai flussi NAR. Alcune informazioni non alimentate da NAR sono integrate su tale replica da altre fonti (es. Comuni, etc.) per arricchire il patrimonio informativo del sistema e consentire analisi più mirate.

Si sottolinea che la struttura del sistema DWH deve essere scalabile ovvero facilmente ridimensionata a fronte della crescita nel tempo dei volumi di dati da gestire ed elaborare e del numero di utenti da soddisfare.

Deve essere possibile accogliere nuove applicazioni e tecnologie (estendibilità) senza la necessità di riprogettare il sistema stesso.

4.5 Requisiti di usabilità

USA1

Facilità d’Uso

Il presente requisito non funzionale è inserito per completezza non essendo le due web app incluse nella presente fornitura.

Le due web application dovranno agevolare ogni categoria di utenza prevista durante le

relative fasi operative. L’interfaccia grafica dovrà essere implementata in italiano.

USA2

Interfacce Help-On-Line

Il presente requisito non funzionale è inserito per completezza non essendo le due web app incluse nella presente fornitura.

Le due web application dovranno disporre di una guida in linea delle funzionalità, ad integrazione della documentazione utente e operativa. La guida in linea dovrà essere implementata in italiano.

USA3

Inserimento dati

Il presente requisito non funzionale è inserito per completezza non essendo le due web app incluse nella presente fornitura.

Le maschere di inserimento delle due web application dispongono di opportuni controlli per evitare l’inserimento di informazioni errate e/o incomplete, garantendo controlli di congruenza dei dati inseriti dall’utente.

Le due web app consentono inoltre di fornire avvisi, eventualmente non bloccanti, qualora le maschere di inserimento dati non risultino integralmente compilate. La messaggistica utente (avvisi, alert) deve essere configurabile in funzione delle diverse tipologie di utenza.

Le due web app consentono di massimizzare l’utilizzo di menu a tendina e dizionari, limitando

ai soli campi di annotazione l’inserimento del testo libero.

5 Avvio e gestione del servizio

In merito alla fase di avvio del servizio di assistenza e manutenzione del sistema oggetto del presente capitolato, l’aggiudicatario dovrà garantire la continuità del servizio erogato. A questo proposito sono definiti i seguenti vincoli temporali.

Tutte le attività realizzative che verranno concordate durante il periodo contrattuale sono vincolate al superamento di una opportuna procedura di collaudo, condivisa con ATS, prima dell’effettiva accettazione e quindi del rilascio in produzione.

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.

Ogni eventuale futura modifica deve garantire la non regressione delle funzionalità applicative preesistenti.

Prima di eventuali sessioni di precollaudo e delle effettive sessioni di collaudo, l’aggiudicatario è tenuto a presentare un’opportuna documentazione (check list di collaudo) soggetta ad eventuali integrazioni ed alla accettazione finale da parte di ATS.

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, ATS si riserva la facoltà di valutare l’applicazione di penali ed eventualmente la risoluzione del contratto d’appalto.

Ad integrazione di quanto indicato, l’aggiudicatario è tenuto a consegnare ad ATS, preventivamente alle procedure di collaudo, una specifica documentazione (test list e test report funzionali) che dia evidenza dell’adeguata copertura delle funzionalità e del buon esito delle verifiche funzionali effettuate internamente durante lo sviluppo del sistema. Dalle verifiche funzionali previste verranno selezionati gli scenari di collaudo.

Durante il collaudo e/o gli eventuali precollaudi saranno verificate punto per punto tutte le funzionalità indicate nelle procedure stesse (check list collaudo) condivise con ATS. Al termine delle fasi di collaudo sarà redatto un verbale corredato da un opportuno documento (test report di collaudo) attestante l'esito delle verifiche effettuate.

Nel caso in cui una o più specifiche funzionali, non funzionali e tecniche o altri aspetti rilevanti della fornitura inclusi nel presente capitolato 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 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 e rilascerà l’elenco dei problemi da risolvere con un piano temporale di risoluzione concordato con ATS. La verifica della risoluzione dei problemi sarà oggetto di un ulteriore collaudo da parte di ATS.

6 Servizi di assistenza e manutenzione

L’aggiudicatario è tenuto a garantire, per tutta la durata contrattuale, la manutenzione (correttiva,

preventiva programmata, evolutiva, normativa) e l’assistenza tecnica al sistema DWH in esercizio.

Il servizio di assistenza e manutenzione delle componenti Oracle, TOS e Pentaho/QLIK, così come descritte nei punti specifici del presente documento, dovrà iniziare immediatamente alla firma del contratto.

6.1 Manutenzione correttiva, preventiva programmata e assistenza

Il servizio di manutenzione correttiva e preventiva programmata deve includere:

• interventi periodici da parte dell’aggiudicatario finalizzati alla verifica del sistema sia dal punto di vista funzionale che prestazionale, in funzione dei livelli transazionali e di carico del sistema in esercizio;

• la correzione dei difetti emersi a seguito di malfunzionamenti rilevati durante l'esercizio o individuati anche autonomamente dall’aggiudicatario, anche durante le attività di manutenzione programmata.

Le attività di individuazione e correzione di eventuali anomalie dovranno essere estese anche alle successive modifiche correttive, evolutive e normative che si rendessero necessarie per tutta la durata del contratto, in modo da escludere potenziali regressioni, funzionali e no, che possano impattare le funzionalità e le performance del sistema in esercizio. La manutenzione correttiva e l’assistenza tecnica si applica negli stessi termini anche alle integrazioni con gli altri sistemi del previsto perimetro operativo.

Tutte le attività suddette dovranno essere preventivamente programmate, condivise / concordate con ATS ed opportunamente pianificate e gestite in modo coordinato secondo le regole definite nel capitolo relativo ai collaudi, al fine di minimizzare i disagi alle attività operative e blocchi temporanei nel rispetto dei vincoli organizzativi e infrastrutturali di ATS. L’aggiudicatario è tenuto a dare evidenza ad ATS, attraverso il buon esito delle procedure di collaudo, di ogni modifica correttiva apportata al sistema. Si ribadisce che le procedure di collaudo dovranno essere sempre preventivamente condivise e approvate da ATS.

Il servizio di assistenza dell’aggiudicatario deve includere un servizio di help-desk attivabile dal servizio di help-desk di ATS. Il servizio potrà essere richiesto sia a seguito di malfunzionamenti sia per attività di supporto all'operatività del sistema. Il servizio di help-desk dell’aggiudicatario deve essere garantito nei giorni feriali da lunedì a venerdì, dalle ore 09:00 alle 18:00.

L’aggiudicatario è tenuto a fornire ad ATS idonee e chiare istruzioni operative per l'attivazione e la gestione del servizio di help-desk. Gli interventi di assistenza potranno effettuarsi sia in loco che a distanza, anche in teleassistenza.

L’aggiudicatario è tenuto a dare riscontro ad ATS di tutte le fasi di gestione di una richiesta di assistenza (presa in carico, risoluzione, chiusura), garantendo un sistema di gestione dei ticket.

La fornitura di manutenzione correttiva, preventiva programmata e assistenza deve comprendere:

• la mano d’opera (illimitata);

• l'assistenza telefonica (illimitata);

• la teleassistenza (illimitata);

• costi di trasferta del personale dell’aggiudicatario o del personale esterno di cui vorrà avvalersi.

L’aggiudicatario è tenuto a produrre, almeno trimestralmente, specifica reportistica relativa alle attività di assistenza svolte nel rispetto degli SLA contrattuali.

6.2 Manutenzione normativa

Il servizio di manutenzione normativa ha come obiettivo quello di assicurare l’eventuale aggiornamento delle

funzionalità erogate dal sistema in relazione a variazioni delle normative regionali o nazionali.

La manutenzione normativa include in particolare ogni adeguamento legato ai temi in ambito al presente capitolato, oltre a quelli relativi a privacy e sicurezza informatica, nel rispetto delle normative e delle disposizioni europee, nazionali e regionali.

L’aggiudicatario s'impegna a fornire, nel periodo contrattuale e senza oneri aggiuntivi per ATS, gli adeguamenti del software applicativo alle intervenute disposizioni legislative, regolamentari, dispositive provenienti a vario titolo dalle Pubbliche Amministrazioni competenti nelle materie riguardanti le informazioni gestite dal sistema oggetto dell’appalto.

Le attività di adeguamento del sistema ricomprese nel presente paragrafo riguardano le modifiche e/o gli aggiornamenti e/o evoluzioni di funzionalità presenti, anche solo parzialmente, e gestite nel sistema in uso. Le eventuali attività necessarie all’adeguamento normativo che richiedessero la realizzazione di funzionalità totalmente assenti, dunque funzionalità completamente nuove saranno considerate ambito della manutenzione evolutiva e regolate secondo quanto indicato nel successivo paragrafo “Manutenzione evolutiva”.

Tutte le attività relative ad aggiornamenti, modifiche, rilascio di nuove release di componenti del sistema dovranno essere opportunamente pianificate con ATS e l’avvio in produzione dovrà essere preventivamente autorizzato mediante apposito collaudo funzionale al fine di minimizzare i disagi alle attività operative e/o blocchi temporanei alle procedure di lavoro.

Le tempistiche di intervento saranno di volta in volta concordate con l’aggiudicatario e comunque non dovranno eccedere il limite di cinque giorni lavorativi dalla richiesta o 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 del sistema e ad essa si applica quanto definito nelle restanti parti del capitolato (in particolare riguardanti la manutenzione correttiva).

La manutenzione normativa del sistema in ambito alla presente procedura si applica negli stessi termini anche alle integrazioni realizzate con altri sistemi.

Le attività ricomprese nella manutenzione normativa includono da parte dell’aggiudicatario l’aggiornamento della documentazione, tecnica e di esercizio, oltre all’eventuale formazione dell’utenza.

6.3 Manutenzione evolutiva

Non essendo identificabili a priori gli interventi evolutivi determinati da necessità non comprese nelle specifiche iniziali di capitolato, la realizzazione di tali attività presuppone la preventiva analisi dei bisogni, la quotazione delle attività, la pianificazione degli interventi, la realizzazione ed il relativo collaudo. Tutte le fasi del processo sopra descritto sono da concordarsi con ATS.

Per lo svolgimento di tali attività, è previsto un “pacchetto” di giornate/uomo, da utilizzarsi “a consumo”

ovvero l’utilizzo di giornate o anche di mezze giornate di attività per lo sviluppo di tali interventi evolutivi.

Il pacchetto di giornate-uomo richiesto è stimato fino ad un massimo di 70 (settanta) giornate/uomo

all’anno eventualmente fruibili anche in 140 (centoquaranta) mezze giornate/uomo.

Tali giornate potranno anche essere utilizzate solo in parte da ATS; in tal caso ATS corrisponderà all’aggiudicatario il costo delle giornate/mezze giornate effettivamente erogate e preventivamente concordate con ATS sulla base di un documento tecnico, redatto dall’aggiudicatario, che dia evidenza delle attività effettivamente previste. Le eventuali giornate a consumo residue di un certo anno devono poter essere trasferite all’annualità successiva (tranne che ovviamente per l’ultima annualità di contratto).

Il prezzo del “pacchetto” deve comprendere:

• le attività di analisi, progettazione e sviluppo degli interventi richiesti con la fornitura delle risorse professionali necessarie;

• la documentazione tecnica e operativa, eventualmente attraverso l’integrazione della

documentazione già rilasciata dall’aggiudicatario;

• gli eventuali costi di trasferta del personale dell’aggiudicatario da garantire in caso di esplicita richiesta da parte di ATS.

Lo sviluppo delle modifiche dovrà essere validato sulla base di specifiche di collaudo concordate con ATS. Si ribadisce che ogni intervento evolutivo deve essere sempre preventivamente approvato da ATS sulla base di un documento tecnico di dettaglio dell’aggiudicatario, comprendente la valutazione dell’impegno richiesto secondo la metrica dei Function Point (FP). In base alla documentazione prodotta, ATS effettuerà una valutazione indipendente dell’impegno richiesto per confermare l’adeguatezza dell’impegno economico.

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. La manutenzione ordinaria di ogni intervento di adeguamento del sistema ottenuto tramite manutenzione evolutiva (attraverso giornate a consumo) si intende ricompresa negli accordi contrattuali.

7 SLA richiesti e criteri di misura

La gestione della fornitura, dei servizi realizzativi, della manutenzione correttiva e del servizio di assistenza è disciplinata nel documento “Capitolato Speciale di Appalto” in cui vengono illustrati gli indicatori di qualità e gli SLA della fornitura come parte integrante del presente Capitolato Tecnico: fare quindi riferimento a tale documento per la descrizione esaustiva degli obiettivi e delle azioni contrattuali previsti.

L’aggiudicatario è tenuto a garantire il servizio di manutenzione ed assistenza 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.

8 Riferimenti documentali e normativi

Privacy e Security

GDPR (General Data Protection Regulation), Regolamento UE 2016/679.

D.Lgs. 101/2018 (“Disposizioni per l’adeguamento della normativa nazionale alle disposizioni del regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati”).

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.

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

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.

Indicazioni di ACN:

Decreto direttoriale prot. N. 29 del 02/01/2023 dell’Agenzia per la

Cybersicurezza Nazionale.

Determine 306 e 307 di gennaio 2022 pubblicate dalla Agenzia per la Cybersicurezza Nazionale.

Linee Guida AgID

Linee Guida su acquisizione e riuso di software per le Pubbliche Amministrazioni. Release Finale, 9 maggio 2019, e s.m.i.

Allegato A delle suddette Linee Guida: Guida alla pubblicazione di software come open source.

Proprietà intellettuale

L. 633/41 (“Protezione del diritto d'autore e di altri diritti connessi al suo esercizio”).

Appendice A

Al fine di consentire una adeguata valutazione dei progetti TOS inclusi nella presente fornitura, si riportano di seguito delle informazioni di sintesi relativamente alla numerosità degli oggetti (job, componenti, procedure/funzioni/package Oracle) richiamati nei vari ambiti TOS.

ASSISTITI_TOS

Procedura di caricamento Assistiti da NAR.

Importazione_Deceduti_Milano

Procedura di caricamento Deceduti Comune di Milano.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Deceduti_Milano	1	0	0
Import_Deceduti_Milano	26	0	0

Prenotazioni_Vaccinazioni_COVID19

Procedura di caricamento prenotazioni vaccinazioni Covid, Xxxxxxx, Tamponi positivi.

JOB	COMPONENTI	NPROC_NON_VIS NPRO
Prenotaz_Vaccinazioni_Covid19		7
Import_Prenotazioni_Covid19
Import_Vaccinazioni_Covid19_2 Import_Tamponi_Covid19 Import_Tamponi_Co Impor
Vaccinazioni
Procedura di caricamento Vaccinazioni.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Vaccinazioni	22	0	0
Import_Vaccinazioni_SIAVR	39	0	0

PRESC_GG_AMB_FARM

Procedura di caricamento Prescrizioni Giornaliere di farmaceutica e specialistica.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Prescr_gg_Far_Amb	2	0	0
Import_Prescr_gg_Amb	33	0	0
Import_Prescr_gg_Far	33	0	0

P4P_Verifica_Aggiornamento

Procedura di verifica del corretto aggiornamento dati del P4P.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
P4P_Verifica_Aggiornamento_import	7	0	0

MEDICI_TOS

Procedura di caricamento Medici da NAR.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Anagrafica_Medici	23	0	0
Import_Anagrafica_Medici	25	0	1
Import_Anagrafica_Medici	0	1	0

Importazione_Anagrafiche_Comuni

Procedura di caricamento Variazioni Anagrafiche del Comune di Milano e invio nella Banca e codifiche Anagrafe ATS Milano (BAC).

Ambulatoriale_TOS

Procedura Caricamento ambulatoriale 28/SAN.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Ambulatoriale_new	23	0	0
Import_Ambulatoriale_new	58	21	0
Import_Ambulatoriale_new_NPIA	25	0	0

VariazioniAssistiti

Procedura di Caricamento variazioni NAR.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
caricamento_variazioni_azure	24	0	1

Screening

Procedura di caricamento dati Screening.

Psichiatria

Procedura di caricamento dati Psichiatria 46/SAN.

ANAG_PERSONALE_DIPENDENTE

Procedura caricamento anagrafe del personale dipendente ATS.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Import_Anag_Personale_Dipendente	31	0	0

Ambulatoriale_FR_TOS

Procedura di caricamento Ambulatoriale Fuori Regione.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Ambulatoriale_FR	23	0	0
Import_Ambulatoriale_FR	40	0	0

Anagrafiche_Strutture_TOS

Procedura caricamento anagrafe Presidi 28/SAN e Ospedali.

Controlli_Impresa_TOS

Procedura caricamento Controlli Impresa.

Controlli_Veterinaria_TOS

Procedura caricamento Controlli VETERINARIA.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Controlli_Veterinari	27	0	0

Cure_Palliative_DSPFLUX

Procedura Caricamento Cure Palliative.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Cure_Palliative	15	0	0
Import_Cure_Palliative	167	5	0

Dipendenze_AMB_TOS

Procedura di caricamento delle Dipendenze.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Dipendenze_AMB	22	0	0
Import_Dipendenze_AMB_NEW	52	0	0

DIT_Promag_TOS

Procedura di caricamento della Protesica Maggiore.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Import_DIT_PROMAG	33	0	0

Import_WebCare_DIABET_Invio_Reg Procedura di caricamento della Diabetica.

Import_WebCare_DIETET_Invio_Reg Procedura di caricamento della Dietetica.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Import_WebCare_DIETET_Invio_RegioneNew	34	0	0

Import_WebCare_PROMAG_Invio_Reg

Procedura di caricamento della Protesica Maggiore Farmaceutica.

JOB	COMPONENTI	NPR

Import_WebCare_PR

Import_WebCare_PROMIN_Invio_Reg

Procedura di caricamento della Protesica Minore Farmaceutica.

Esenzioni_TOS

Procedura di caricamento delle Esenzioni NAR.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Esenzioni	25	0	0
Import_Esenzioni	17	4	0

Import_Excel_Tempi_Attesa

Procedura caricamento giornaliero Tempi d'Attesa.

NPROC_

TA_Import_CSV_TA_ATS321_parte2

TA_Import_CSV_TA_ATS321_parte3

TA_Exp_Imp_TA

Export_TA TA_i

TA_Import_CSV_TA_ATS321_parte1

TA_Import_Azure

TA_ATS321_CSV

NPROC_NON_VIS

COMPONENTI

JOB

Import_BAC_SQLSERVER

Procedura di caricamento delle Variazioni BAC in SQL/Server.

ImportaComune_SESTO

Procedura di caricamento variazioni anagrafiche del Comune di Sesto San Xxxxxxxx.

SDO

Procedura di caricamento Ricoveri (SDO).

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
SDO	23	0	0
	85	13

SDO_FR

Procedura di caricamento Ricoveri Fuori Regione.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
SDO_FR	23	0	0
Import_SDO_FR	38	0	0

PROMAG_Report_Prescrizioni

Procedura di caricamento Prescrizioni di Protesica Maggiore.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Promag_Report_Ricette	22	0	0
Import_Promag_Report_Ricette	33	0	0

PRONTO_SOCCORSO

Procedura di caricamento del Flusso di Pronto Soccorso.

Import_P

Pronto_Soccorso

NPROC_NON_VIS

COMPONENTI

JOB

Farmaceutica_DPC

Procedura di caricamento del Doppio Canale (Farmaceutica).

JOB

COMPONE

NPROC_NON_VIS

NPROC_VIS

Farmacia_DPC

Import_Farmacia_DPC

Farmaceutica_EXPC

Procedura di caricamento farmaceutica convenzionata (EXPC).

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Farmacia_EXPC	23	0	0
Import_Farmacia_EXPC	103	14	0

Farmaceutica_FR_TOS

Procedura di caricamento Farmaceutica Fuori Regione.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Ambulatoriale_FR	23	0	0
Import_Ambulatoriale_FR	41	0	0

Farmaceutica_FUR

Procedura di caricamento farmaceutica FUR.

JOB

COMPONENTI

NPROC_NON_VIS

NPROC_VIS

Farmacia_FUR

Import_Farmacia_FUR

Farmaceutica_FILEF

Procedura di Caricamento File F.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
FILE_F	24	0	0
Import_FILE_F_Prod	52	0	0
Import_FILE_F	53	8	0

Farmaceutica_FILEF_FUORIREGIONE Procedura di caricamento File F Fuori Regione.

IMPORT_PLSFLUSSI

Procedura di caricamento prestazioni di follow up dei Pediatri.

JOB	COMPONENTI	NPROC_NON_VIS	NPROC_VIS
Import_plsFlussi	63	0	0

Document Metadata

Table of Contents

CAPITOLATO TECNICO

Document Metadata