SIO
ASL di Rieti PROGETTO DEI FABBISOGNI
“Servizi di interoperabilità per i dati e di cooperazione applicativa”
Sistema Pubblico di Connettività - Lotto 3
SIO
SOMMARIO
2 ORGANIZZAZIONE DEL CONTRATTO ESECUTIVO 5
3.2.1 Supporto memorizzazione Big Data 9
3.2.2 Supporto analisi Big Data 10
3.3 Quadro riassuntivo dei servizi 12
3.4 Impegno delle risorse professionali 13
3.5 Indirizzo di dispiegamento dei servizi 13
3.6 Modalità di esecuzione del collaudo dei servizi 14
4 MODALITÀ DI PRESENTAZIONE E APPROVAZIONE DEGLI STATI DI AVANZAMENTO MENSILI 15
4.1 Gestione dei SAL Mensili 15
4.2 Report di Stato di Avanzamento Mensile 15
5.2 Gestione della Sicurezza 17
1.1 PREMESSA
Il presente documento costituisce il Progetto dei Fabbisogni per i servizi richiesti da ASL Rieti. Esso riporta la proposta tecnico ed economica da implementare sulla base delle richieste contenute nel Piano dei Fabbisogni secondo le modalità tecniche ed i listini previsti nel Contratto Quadro.
Il processo di digitalizzazione e di informatizzazione alla base dell’erogazione delle prestazioni sanitarie appare irreversibile ed in crescita esponenziale; tale fenomeno è confermato da molteplici studi sia sulle scelte strategiche delle aziende che dei soggetti fruitori in termini di rapporto con le prime:
• le aziende migrano verso sistemi informativi integrati con una correlazione positiva fra l’integrazione dei processi clinici ed amministrativi e le performance aziendali con l’evidenza di un incremento complessivo dell’efficienza e dell’efficacia nel perseguimento della mission aziendale;
• il soggetto fruitore dei servizi sanitari, ove disponibile, è sempre più propenso all’utilizzo di sistemi di gestione della prestazione dematerializzati.
Tale processo è stato affiancato, se non addirittura anticipato ed alimentato dal passaggio verso un modello di sanità di tipo “quantitativo” che si identifica nei Livelli Essenziali di Assistenza (LEA) ovvero nell’elenco delle prestazioni e dei servizi essenziali che le Aziende sono tenute a fornire.
Sulla base di quanto sopra esposto e partendo dall’assunto di base della completa soddisfazione di tutti i requisiti richiesti dal Piano dei Fabbisogni, nel seguito del seguente Progetto dei Fabbisogni, saranno indicate nel dettaglio le soluzioni proposte, l’organizzazione del progetto ed i servizi necessari per garantire la migliore riuscita dello stesso, evidenziando allo stesso tempo punti di forza ed elementi migliorativi.
1.2 SCOPO
Scopo del documento è documentare e quantificare i servizi richiesti dall’Amministrazione. Si compone di:
◼ Organizzazione del Contratto
◼ Progetto di Attuazione
◼ Modalità di presentazione e approvazione degli stati di avanzamento mensili
◼ Piano di Attuazione
◼ Data di Attìvazione.
1.3 CAMPO DI APPLICAZIONE
Il documento si applica al progetto SPC lotto 3. In particolare, ai servizi:
◼ Big data – assessment (L3.S6.1)
◼ Big data - singola configurazione avanzata Cat A (L3.S6.5)
◼ Big data - singola configurazione avanzata Cat B (L3.S6.6)
◼ Big data - singola instanziazione sistema di gestione on premise (L3.S6.7)
◼ Big data - Formulazione del modello di analisi (L3.S7.4)
◼ Big data - Esercizio conduzione soluzione analisi (L3.S7.5)
1.4 ASSUNZIONI
Non applicabile.
1.5 RIFERIMENTI
Identificativo1 | Titolo/Descrizione |
Contratto Quadro del 31/03/2017 e relativi Allegati | Contratto Quadro del 31/03/2017 relativo all’Appalto dei servizi di interoperabilità per i dati e di cooperazione applicativa (lotto 3) in favore delle PA. |
Allegato 5A alla lettera d’invito | Capitolato Tecnico Parte Generale |
Allegato 5B alla lettera d’invito | Capitolato Tecnico Lotto 3 |
SPCL3 -PianoFabbisogni-ASL Xxxxx XXX 1.2(firmato) del 28/10/2020 | Piano dei Fabbisogni |
1.6 ACRONIMI E GLOSSARIO
Definizione / Acronimo | Descrizione |
AgID | Agenzia per l’Italia Digitale |
Consip | Consip S.p.a. |
RTI | Raggruppamento Temporaneo d’Impresa |
SPC | Sistema Pubblico di Connettività |
1 La sigla x.y identifica la versione del documento; tale sigla, presente nell’identificativo del documento stesso, sottintende la versione ultima dello stesso.
2 ORGANIZZAZIONE DEL CONTRATTO ESECUTIVO
Il RTI si avvale di un modello organizzativo di Cooperazione, che ha come obiettivo quello di soddisfare le richieste di Cooperazione delle Amministrazioni in maniera coordinata e integrata sia a livello di singolo Contratto Esecutivo sia a livello di Contratto Quadro.
Per il Contratto Esecutivo si identificano:
◼ il Responsabile del Contratto Esecutivo: Xxxxxx Xxxxxxxxxx (x.xxxxxxxxxx@xxxxxxxx.xx)
◼ il Responsabile delle funzioni di Project e Risk Management e di Quality Management specifiche per il CE: R. A. Xxxxxxxxx Xxxx (x.xxxx@xxxxxxxx.xx)
Centri Servizi
La figura seguente rappresenta l’organizzazione prevista per l’esecuzione del contratto.
Responsabile dei Centri Servizi
Supporto Analisi
Orchestrazione
Supporto Memorizzazione
Web services/Client
Responsabile Big Data
Responsabile Open Data
Responsabile Coop. App.
Qualità
Project e Risk
Management
Responsabile Contratto Es.
Piattaforme «a-a-s»
BIG Data «a-a-s»
SPAQRL end point
Porta di dominio
Responsabile C.Q.
Figura 1
La tabella seguente riporta i nominativi/ruoli dell’organizzazione previsti per i servizi contrattuali erogati.
Ruolo | Nome | Cognome | Riferimenti |
Responsabile Centro Servizi | Xxxxxxxx | Xxxxxx | |
Responsabile Cooperazione Applicativa | |||
Responsabile Open Data | |||
Responsabile Big Data | Xxxxxx | Xx Xxxxxxx |
I paragrafi che seguono riportano una breve sintesi delle iniziative descritte nel piano dei fabbisogni, e, per ognuna di esse, le stime dimensionali/economiche articolate secondo le modalità di erogazione dei servizi previste contrattualmente per il Lotto 3.
Il valore che la presente proposta progettuale vuole perseguire riguarda sia la sfera del governo clinico sia la sfera del governo gestionale. Tale valore, è stato declinato ed elaborato mediante un Technology Benefits Reference Model, che l’RTI ha sviluppato per trasporre il potenziale delle tecnologie ICT sugli aspetti più rilevanti per le aziende sanitarie.
Il progetto persegue benefici economici quali:
◼ riduzione dei costi indiretti dovuti ad una diagnosi non corretta
◼ riduzione costi di trasporto del materiale e spostamento del personale sanitario
◼ riduzione dei costi dovuti ad interventi tecnologici per garantire la scalabilità della soluzione su base regionale e locale;
◼ miglioramento della capacità di controllo e analisi della spesa relativa ai materiali di consumo, in funzione della domanda e della produzione svolta
Il presente documento ha come principali obiettivi quello di descrivere:
◼ Assessment e supporto all’Amministrazione sul parco applicativo richiesto, per tutta la durata del contratto, al fine di valutare eventuali ed opportuni interventi di configurazione
◼ La realizzazione di un sistema in grado di effettuare analisi predittive tramite modelli AI, con l’obbiettivo di fornire strumenti di supporto per la cura del paziente e per l’ottimizzazione dei processi logistici
3.1 SUPPORTO E ASSESSMENT
Come da richiesta, il servizio di supporto ed assessment sarà previsto per i seguenti processi:
• Anagrafe Assistiti LHA (MPI)
• Anagrafe Operatori X1V1 (SS0)
• Anagrafe Codifiche X1V1 (MCI)
• Dossier Sanitario X1V1
• ESB X1V1
• Arianna ADT
• Xxxxxxx Xxxxxxx (Gestione Reparto)
• Arianna MedOffice (Gestione Ambulatori)
• Arianna DSA (Gestione Day Service)
• Ormaweb (Gestione Blocco Operatorio)
• Sire 3 (Gestione Prescrizione elettronica)
• Arianna Order Management (Gestione Order Manager)
• Concerto (Gestione Lab. Analisi)
• Armonia (Gestione Anatomia Patologica)
• Dedalus BI (Controllo Direzionale, Flussi e debiti informativi)
• TCWA / P4C (Terapia Farmacologica)
• PCS (Casa della Salute)
• Sistema di Gastroenterologia
• Sistema Grouper
• Sistema Dialisi
Il servizio sarà svolto da 3 risorse specialiste di dominio e di dati. L’obiettivo, fra gli altri, è quello di valutare
eventuali interventi sullo scenario applicativo
Nella tabella seguente sono riportati i servizi SPC coinvolti con il corrispondente impegno economico:
Servizi | Cotrattualizzato | ||||||
Servizio | Nome Servizio | Prezzo unitario | Metrica di pricing | Modalità di consuntivazione | ID esigenza | Quantità | Importo |
536.987,50 € | |||||||
L3.S6.1 | Big data - assessment | € 267,50 | gg/pp | A corpo | 705,00 | 188.587,50 € | |
Assessment e supp. | 705,00 | 188.587,50 € | |||||
- | - | - € | |||||
L3.S6.5 | Big data - singola configurazione avanzata Cat A | € 1.100,00 | attività | A corpo | 200,00 | 220.000,00 € | |
Assessment e supp. | 200,00 | 220.000,00 € | |||||
- | - | - € | |||||
L3.S6.6 | Big data - singola configurazione avanzata Cat B | € 650,00 | attività | A corpo | 190,00 | 123.500,00 € | |
Assessment e supp. | 190,00 | 123.500,00 € | |||||
- | - | - € | |||||
L3.S6.7 | Big data - singola instanziazione sistema di gestione on premise | € 490,00 | istanziazione | A corpo | 10,00 | 4.900,00 € | |
Assessment e supp. | 10,00 | 4.900,00 € | |||||
- | - | - € | |||||
3.2 BIG DATA
L’obiettivo è predisporre un sistema in grado di acquisire dati - di tipo qualitativo e quantitativo - dall’infrastruttura ospedaliera, quindi trasferirli ad algoritmi di Machine Learning e Deep Learning capaci di effettuare le predizioni. I modelli AI, grazie alla capacità di gestire, analizzare ed elaborare moli di dati, si pongono come strumenti di supporto per la cura del paziente e per l’ottimizzazione dei processi logistici.
3.2.1 Supporto memorizzazione Big Data
La piattaforma che verrà sviluppata consentirà di acquisire ed elaborare dati provenienti da più fonti eterogenee in un unico bacino dati (Data Lake multi DB), per permettere poi la realizzazione dei servizi AI da mettere a disposizione degli utenti finali attraverso integrazione con applicativi esterni.
In linea con le specificità richieste, si descrivono a seguire le componenti logiche e tecnologiche dell’architettura
della soluzione proposta.
Figura 2- Architettura Piattaforma Big Data & AI
Ingestion Layer
I moduli presenti nell’Ingestion Layer sono delegati all’acquisizione dei dati sulla piattaforma, in particolare:
◼ abilitano l’acquisizione di dati da sorgenti eterogenee come file, database, servizi http, code di
messaggi, etc
◼ sono responsabili dell’acquisizione, trasformazione e persistenza dei dati su una moltitudine di tecnologie di storage differenti, tra cui file system (distribuito o meno), database relazionali, database non relazionali
Processing Layer
Il Processing Layer è deputato all’elaborazione dei dati, in modalità batch o real-time (stream), acquisiti
dall’Ingestion Layer e memorizzati sul Multi DB Layer.
La modalità di elaborazione batch ha la capacità di elaborare grandi quantità di dati in maniera temporizzata (es. ogni ora) per casi d’uso che non richiedono la disponibilità immediata delle elaborazioni effettuate. Le componenti presenti in questo layer sono in grado di elaborare dati presenti su una vasta gamma di sorgenti (tra cui anche quelle presenti nel Multi DB Layer) e i dati elaborati possono essere memorizzati a loro volta all’interno del Multi DB Layer.
La modalità di elaborazione real-time, detta anche streaming, prevede l’elaborazione immediata dei dati acquisiti. A differenza del modulo di elaborazione batch, questo layer acquisisce dati da sorgenti di tipo stream, come ad esempio code di messaggi o canali di rete. I dati elaborati, come nel caso batch potranno essere memorizzati all’interno del Multi DB Layer.
Tra le principali elaborazioni e manipolazione dei dati, il Processing Layer sarà in grado di:
◼ Analizzare e importare i Dataset
◼ Armonizzare e bonificare i dati
◼ Trasformare i dati al fine di renderli uniformi e coerenti per altre elaborazioni
◼ Aggregare i dati per renderli disponibili per essere consumati dalle Dashboard di Advanced Analytics.
Analytics & ML
Il Machine Learning Engine è il componente responsabile dell’addestramento e l’utilizzo di modelli di machine learning. Attraverso questo engine è possibile addestrare, in modo data driven, modelli di classificazione automatica, predizione ed anomaly detection. Il modulo è inoltre responsabile di fornire gli strumenti di
addestramento dei modelli sotto forma di Notebook, web application interattive che consentono l’esecuzione
di snippet di codice, unite alla visualizzazione di grafici e statistiche.
3.2.2 Supporto analisi Big Data
Come descritto nelle sezioni precedenti, l’analisi dei dati e l’addestramento dei modelli verrà effettuato con tecnologie quali TensorFlow e Keras. L’esperienza che AlmavivA ha sviluppato in questo settore ha portato a realizzare diversi algoritmi predittivi tra i quali quello per predire le complicanze del diabete. Questo algoritmo prende in input i parametri presenti nella seguente tabella e fornisce in output la probabilità che un paziente diabetico sviluppi nel futuro una o più tra le seguenti complicanze: Reni, Occhi, Vasi Periferici e Cuore.
Input algoritmo | o Sesso (donna=0/uomo=1) o Età (anni) o Altezza (cm) o BMI o Colesterolo HDL (mg/dL) o Colesterolo LDL calc. (mg/dL) o Colesterolo (mg/dL) o Creatinina (mg/dL) |
o Emoglobina Glicata HbA1c. (%)
o Emoglobina Glicata HbA1c. (mmol/mol) (solo nel Modello 1)
o GFR
o GPT (UI/L)
o Gamma GT (UI/L) (solo nel Modello 2)
o Glicemia a digiuno (mg/dL)
o Insuline..tutte (variabile binaria 0=assenza/1=presenza di farmacoterapia insulinica)
o Ipoglicemizzanti..tutti (variabile binaria 0=assenza/1=presenza di farmacoterapia ipoglicemizzante)
o Peso (kg)
o Pressione Diastolica (mmHg)
o Pressione Sistolica (mmHg)
o SGOT (UI/L)
o Trigliceridi (mg/dL)
o gg_da_diag_diabete (giorni tra la data diagnosi diabete e data esami)
o Vasi periferici (variabile binaria 0=assenza/1=presenza della complicanza in data precedente a data esami)
o Occhio (variabile binaria 0=assenza/1=presenza della complicanza in data precedente a data esami)
o Cuore (variabile binaria 0=assenza/1=presenza della complicanza in data precedente a data esami)
o Rene (variabile binaria 0=assenza/1=presenza della
complicanza in data precedente a data esami)
L’offerta, dunque, si articolerà in due modalità: fruizione del modello preesistenti di complicanze diabete “as a service” e prototipazione, sviluppo ed esposizione di un nuovo modello inerenti a una tematica concordata con il personale medico dell’ospedale.
Nella tabella seguente sono riportati i servizi SPC coinvolti con il corrispondente impegno economico:
Servizi | Cotrattualizzato | ||||||
Servizio | Nome Servizio | Prezzo unitario | Metrica di pricing | Modalità di consuntivazione | ID esigenza | Quantità | Importo |
199.382,00 € | |||||||
L3.S6.1 | Big data - assessment | € 267,50 | gg/pp | A corpo | 616,00 | 164.780,00 € | |
Alg. Predittivi | 616,00 | 164.780,00 € | |||||
- | - | - € | |||||
L3.S7.4 | Big data - Formulazione del modello di analisi | € 243,50 | gg/pp | A corpo | 120,00 | 29.220,00 € | |
Alg. Predittivi | 120,00 | 29.220,00 € | |||||
- | - | - € | |||||
L3.S7.5 | Big data - Esercizio conduzione soluzione analisi | € 234,00 | gg/pp | A canone | 23,00 | 5.382,00 € | |
Alg. Predittivi | 23,00 | 5.382,00 € | |||||
- | - | - € |
3.3 QUADRO RIASSUNTIVO DEI SERVIZI
Si riporta di seguito la tabella con il dettaglio dei servizi previsti con relativi importi (al netto di IVA):
Servizi | Cotrattualizzato | ||||||
Servizio | Nome Servizio | Prezzo unitario | Metrica di pricing | Modalità di consuntivazione | ID esigenza | Quantità | Importo |
736.369,50 € | |||||||
L3.S6.1 | Big data - assessment | € 267,50 | gg/pp | A corpo | 1.321,00 | 353.367,50 € | |
Assessment e supp. | 705,00 | 188.587,50 € | |||||
Alg. Predittivi | 616,00 | 164.780,00 € | |||||
L3.S6.5 | Big data - singola configurazione avanzata Cat A | € 1.100,00 | attività | A corpo | 200,00 | 220.000,00 € | |
Assessment e supp. | 200,00 | 220.000,00 € | |||||
- | - | - € | |||||
L3.S6.6 | Big data - singola configurazione avanzata Cat B | € 650,00 | attività | A corpo | 190,00 | 123.500,00 € | |
Assessment e supp. | 190,00 | 123.500,00 € | |||||
- | - | - € | |||||
L3.S6.7 | Big data - singola instanziazione sistema di gestione on premise | € 490,00 | istanziazione | A corpo | 10,00 | 4.900,00 € | |
Assessment e supp. | 10,00 | 4.900,00 € | |||||
- | - | - € | |||||
L3.S7.4 | Big data - Formulazione del modello di analisi | € 243,50 | gg/pp | A corpo | 120,00 | 29.220,00 € | |
Alg. Predittivi | 120,00 | 29.220,00 € | |||||
- | - | - € | |||||
L3.S7.5 | Big data - Esercizio conduzione soluzione analisi | € 234,00 | gg/pp | A canone | 23,00 | 5.382,00 € | |
Alg. Predittivi | 23,00 | 5.382,00 € | |||||
- | - | - € | |||||
L’importo complessivo dell’offerta, escluso IVA, è di 736.369,50 €.
3.4 IMPEGNO DELLE RISORSE PROFESSIONALI
Il mix delle risorse professionali impegnate nelle attività tiene conto delle necessita progettuali e delle scelte tecnologiche espresse dall’Amministrazione nel piano dei fabbisogni.
3.5 INDIRIZZO DI DISPIEGAMENTO DEI SERVIZI
Il Centro Servizi del RTI può essere considerato a tutti gli effetti un Data Center “virtuale” ed è costituito dalle sedi che le aziende del RTI hanno attivato per la erogazione di tutti i servizi previsti dall’Accordo quadro SPC.
Il Centro Servizi è organizzato su 4 sedi (cfr. tabella seguente) dislocate sul territorio italiano: tre della mandataria Almaviva che ospitano sia il personale sia l’infrastruttura dedicata alle Amministrazioni contraenti, una di Xxxxx che prevede la presenza del solo personale.
Sede | Azienda RTI | Data Center | Indirizzo | Mq totali |
Casal Boccone | Almaviva | √ | xxx xx Xxxxx Xxxxxxx 000/000 - Xxxx | 34.800 |
Scalo Prenestino | Almaviva | √ | xxx xxxxx Xxxxx Xxxxxxxxxx 00 - Xxxx | 11.200 |
Missaglia | Almaviva | √ | xxx Xxxxxxxxx 00 - Xxxxxx | 10.800 |
Xxxx | Xxxxx | xxx Xxxxxxx Xxxx 00 - Xxxx | 2.600 |
I servizi oggetto del presente Progetto saranno erogati secondo le modalità previste dal Contratto Quadro, mentre saranno erogati dal Centro Servizi i Servizi Trasversali a supporto, qui di seguito elencati:
◼ Sistema di Controllo dei livelli di Servizio (SLAM);
◼ Portale di Governo della Fornitura (PGF);
◼ Help Desk (HD).
In particolare, l’infrastruttura di Help Desk sarà ospitata nel Centro Servizi, mentre il personale di I livello opererà da postazioni presenti presso una sede del Gruppo AlmavivA e il personale di II livello opererà da postazioni presenti presso le sedi del RTI.
Vanno inoltre ricordati i Servizi di gestione necessari al buon funzionamento del Centro Servizi:
◼ Gestione della sicurezza dei Data Center, consiste messa in opera delle misure di tipo fisico, logico ed organizzativo atte ad assicurare in corso d’opera il mantenimento dei livelli di sicurezza coerenti con le politiche e con gli impegni assunti nei contratti e formalizzati nelle specifiche di servizio/configurazioni di servizio.
◼ Monitoraggio e controllo dei sistemi e della rete, consiste nell’utilizzo dell’infrastruttura hardware e software di base a supporto delle verifiche sulla disponibilità delle risorse dell’ambiente elaborativi e della rete e successivi controlli sui Log.
◼ Gestione dei Backup dei sistemi del Centro Servizi, consiste nell’utilizzo della infrastruttura a supporto
della applicazione delle politiche di backup e nel salvataggio in ambienti sicuri dei supporti utilizzati.
3.6 MODALITÀ DI ESECUZIONE DEL COLLAUDO DEI SERVIZI
I servizi oggetto del presente Progetto dei fabbisogni saranno sottoposti ad un collaudo “sul campo” da parte dell’Amministrazione, che eseguirà i test previsti dal RTI nelle Specifiche di collaudo ed ogni altro test che riterrà opportuno.
Al termine sarà redatto un Verbale di Xxxxxxxx con il dettaglio di quanto effettuato e gli esiti.
È responsabilità del RTI fornire personale e documentazione necessaria all’esecuzione del collaudo.
4 MODALITÀ DI PRESENTAZIONE E APPROVAZIONE DEGLI STATI DI AVANZAMENTO MENSILI
4.1 GESTIONE DEI SAL MENSILI
Gli stati di avanzamento mensili costituiscono lo strumento mediante il quale il RTI tiene informata
l’Amministrazione su tutte le attività che costituiscono il provisioning dei servizi da erogare (dal sopralluogo fino al collaudo finale e la relativa migrazione) e, successivamente, sullo stato di funzionamento e la qualità dei servizi stessi.
A tale scopo il Fornitore ed il RTI attivano un servizio di project management consistente nella pianificazione, gestione e verifica delle attività mirate al completamento del progetto.
Il project manager del Fornitore si confronterà con il responsabile di progetto nominato dall’Amministrazione
per la definizione ed esecuzione delle attività.
I report saranno prodotti con cadenza mensile e consegnati all’Amministrazione secondo una modalità di
comunicazione definita tra RTI ed Amministrazione.
4.2 REPORT DI STATO DI AVANZAMENTO MENSILE
Per quanto concerne le attività legate all'implementazione dei servizi, il flusso comunicativo può essere sintetizzato come segue:
◼ il project manager del RTI invia, mediante E-mail, il report SAL all’Amministrazione;
◼ l’Amministrazione, nella persona del suo responsabile di progetto, analizza, congiuntamente con il project manager del fornitore, la situazione di avanzamento, le eventuali modifiche rispetto al piano operativo previsto e le contromisure che il fornitore intende mettere in atto per recuperare gli eventuali ritardi verificatisi.
◼ Il responsabile dell’Amministrazione approva il report mediante comunicazione e-mail verso il fornitore.
Il report di Stato di Avanzamento Mensile contiene le seguenti informazioni:
◼ Avanzamento/Rispetto dei tempi previsti nel piano di attivazione;
◼ Eventuali ripianificazioni;
◼ Esito Tracking sui rischi;
◼ Esito dei test interni;
◼ Esito collaudi effettuati;
◼ Change emersi nel periodo;
◼ Azioni correttive/preventive applicate;
◼ Varie ed eventuali.
Tutti gli stati di avanzamento sono soggetti ad approvazione da parte dell’Amministrazione.
Nella fase di erogazione dei servizi il RTI manterrà la produzione mensile del SAL, orientati più a definire
l’andamento della erogazione, in termini di:
◼ Indicazioni su possibili problemi o anomalie eventualmente verificatisi;
◼ Proposte di modifiche/aggiornamenti da apportare;
◼ Proposte eventuali ottimizzazioni/migliorie da apportare all’organizzazione dei processi definiti;
◼ Varie ed eventuali.
Tali informazioni posso essere fornite utilizzando il template SPCL3-TMP-SALMensile-1.0.
5.1 PIANO DI LAVORO
Il piano di lavoro si sviluppa secondo quanto riportato nello schema seguente:
Piano di lavoro | 2020 | 2021 | ||||||||
M1 | M2 | M3 | M4 | M5 | M6 | M7 | M8 | M9 | M10 | |
Servizi di Assessment e supporto | √ | √ | √ | √ | √ | √ | √ | √ | √ | √ |
Big Data - algoritmi predittivi | √ | √ | √ | √ | √ | √ | √ | √ | ||
5.2 GESTIONE DELLA SICUREZZA
Il documento SPCL3-SEC-Documento Programmatico sulla Sicurezza (DPS)-2.1.docx è il riferimento alle politiche di sicurezza implementate dal RTI per SPC lotto 3.
Relativamente agli specifici progetti sviluppati nell’ambito dei servizi richiesti dall’Amministrazione, sarà implementato nel progetto il profilo di sicurezza per la riservatezza dei dati nonché le misure per soddisfarlo.
5.3 PIANO DI QUALITÀ
Il documento SPCL3-GEN-PianoQualitaGenerale-2.2.docx è il piano di qualità di riferimento per il presente progetto.
La data stimata di attivazione dei servizi contrattualizzati è il 02/11/2020.
Per la data effettiva si rimanda al relativo verbale di attivazione dei servizi firmato dall’Amministrazione e dal Fornitore.