PRESIDÈNTZIA PRESIDENZA Direzione generale della Centrale regionale di committenza Servizio forniture e servizi Capitolato speciale, descrittivo e prestazionale Pagina 1 di 135 Procedura ristretta informatizzata per l’affidamento dei servizi di gestione, manutenzione e reingegnerizzazione dell’architettura del Sistema Informativo Sanitario Integrato Regionale (SISaR) e acquisizione dell’infrastruttura di integrazione SISaR 2.0. CIG: 7686214073 - CUP: E77H18001780002 Allegato 1.A Capitolato speciale, descrittivo e prestazionale
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 1 di 135
Procedura ristretta informatizzata per l’affidamento dei servizi di gestione,manutenzione e reingegnerizzazione dell’architettura del Sistema Informativo
Sanitario Integrato Regionale (SISaR) e acquisizione dell’infrastruttura diintegrazione
SISaR 2.0.
CIG: 7686214073 - CUP: E77H18001780002
Allegato 1.A
Capitolato speciale, descrittivo e prestazionale
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 1 di 135
1. PREMESSA .............................................................................................................................. 31.1. Il sistema SISaR........................................................................................................................ 41.2. ACRONIMI .............................................................................................................................. 17
2. OGGETTO DELLA PROCEDURA......................................................................................... 192.1. Fasi del progetto e durata ....................................................................................................... 202.2. Precisazioni in merito alla possibilità di sostituzione degli applicativi ..................................... 222.3. Linee guida Usabilità............................................................................................................... 232.4. Metodologie di sviluppo software e gestione di progetto ........................................................ 25
2.4.1 Aspetti metodologici specifici relativi alla protezione dei dati personali........................ 262.5. Open Data e formato dei dati .................................................................................................. 27
2.5.1 Formato dei dati .............................................................................................................. 28
3. AREA 1 – SERVIZI DI GESTIONE E MANUTENZIONE....................................................... 283.1. Servizio A1.1: Manutenzione Preventiva, Adeguativa, Correttiva, Perfettiva......................... 29
3.2. Servizio A1.2: Miglioramento delle performance e dell’usabilità ............................................ 393.3. Servizio A1.3: Manutenzione Evolutiva .................................................................................. 413.4. Servizio A1.4: Servizi Specialistico-Applicativi ....................................................................... 463.5. Servizio A1.5: Gestione degli ambienti applicativi di test e di produzione.............................. 493.6. Servizio A1.6: Gestione sistemistico-applicativa .................................................................... 523.7. Servizio A1.7: Servizio di Help Desk....................................................................................... 563.8. Servizio A1.8: Reperibilità H24 mission critical....................................................................... 58
4. AREA 2 – REALIZZAZIONE NUOVA ARCHITETTURA....................................................... 594.1. Servizio A2.1: Sistema Enterprise Service Bus ...................................................................... 60
4.1.1 Descrizione della infrastruttura richiesta / servizio......................................................... 614.1.2 Caratteristiche specifiche della componente ESB ........................................................... 624.1.3 Caratteristiche specifiche della componente API Gateway ............................................ 644.1.4 Requisiti generici comuni per ESB/API ............................................................................ 654.1.5 Requisiti di sicurezza comuni per ESB/API....................................................................... 66
4.2. Servizio A2.2: Evoluzione e migrazione su nuova infrastruttura e disaccoppiamentofunzionale........................................................................................................................................... 66
4.2.1 Migrazione delle attuali integrazioni sul nuovo ESB/API ................................................ 674.2.2 Disaccoppiamento delle macrocomponenti del SISaR.................................................... 67
5. AREA 3 – SERVIZI DI TRANSIZIONE................................................................................... 755.1. Servizio A3.1: Transizione verso il fornitore/i subentrante/i.................................................... 76
6. AREA 4. SERVIZI TRASVERSALI......................................................................................... 796.1. Servizio A4.1: Program, Project e Service Management ....................................................... 806.2. Servizio A4.2: Formazione e Affiancamento........................................................................... 82
7. PASSAGGIO DI CONSEGNE “IN INGRESSO” E PRESA IN CARICO DALL’ATTUALEGESTORE DEL SISTEMA............................................................................................................. 848. ASPETTI RELATIVI AL GDPR E TRATTAMENTO DEI DATI PERSONALI ....................... 889. ORGANIZZAZIONE DI PROGETTO...................................................................................... 8910. Strumenti di supporto ....................................................................................................... 9411. DELIVERABLES ................................................................................................................. 97
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 2 di 135
12. MODALITÀ DI ESECUZIONE........................................................................................... 10013. SLA – LIVELLI DI SERVIZIO E OBBLIGHI DELL’AGGIUDICATARIO.......................... 101
13.1. Metodo di calcolo degli SLA.............................................................................................. 10213.2. Manutenzione Correttiva ................................................................................................... 10313.3. Manutenzione Preventiva, Adeguativa, Perfettiva ............................................................ 10413.4. Manutenzione per adeguamenti normativi ordinari ........................................................... 10513.5. Servizi per il miglioramento delle performance e dell’usabilità ......................................... 10613.6. Servizi di Manutenzione Evolutiva..................................................................................... 10613.7. Servizi Specialistico-Applicativi ......................................................................................... 10813.8. Gestione ambiente applicativo di test ............................................................................... 10813.9. Gestione ambiente applicativo di produzione ................................................................... 10913.10. Gestione sistemistico-applicativa ...................................................................................... 11013.11. Help Desk .......................................................................................................................... 11013.12. Reperibilità H24 mission critical ........................................................................................ 11213.13. Realizzazione nuova infrastruttura interoperabilità ........................................................... 11313.14. Evoluzione e migrazione su nuova infrastruttura e disaccoppiamento funzionale ........... 11313.15. Transizione verso il fornitore subentrante ......................................................................... 11413.16. Program/Project/Service Management ............................................................................. 11413.17. Formazione e affiancamento............................................................................................. 11713.18. Livelli di servizio Sicurezza/GDPR .................................................................................... 117
14. PENALI .............................................................................................................................. 11914.1. Penali per mancato rispetto degli SLA .............................................................................. 12014.2. Penali per mancato rispetto degli SLA relativi a cronoprogrammi .................................... 12014.3. Tabella sinottica SLA – Penali........................................................................................... 121
15. PROPRIETÀ DEL SOFTWARE ........................................................................................ 13116. SPESE, OBBLIGHI, ONERI, RISCHI E RESPONSABILITÀ........................................... 13117. VERIFICA DI CONFORMITÀ - COLLAUDO FUNZIONALE E ACCETTAZIONE........... 13318. VARIAZIONI IN CORSO D’OPERA.................................................................................. 134
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 3 di 135
1. PREMESSA
Il sistema informativo sanitario regionale della Regione Sardegna è costituito da un insieme di sistemi
informativi integrati acquisiti e gestiti dall’Amministrazione regionale a beneficio delle Aziende
Sanitarie e dell’Assessorato dell’Igiene e Sanità e dell’Assistenza Sociale, tra cui si citano, in
particolare, i sistemi SISaR (sistema informativo sanitario integrato regionale), MEDIR (sistema Medici
in Rete e Fascicolo Sanitario Elettronico), ANAGS (Anagrafe Sanitaria), SILUS (Sistema Informativo
dipendenze). Il sistema informativo sanitario regionale rappresenta uno strumento essenziale per il
governo clinico ed economico del servizio sanitario regionale nel suo complesso.
L’estensione del grado di copertura delle funzionalità del sistema informativo sanitario integrato
regionale rispetto alla totalità dei processi gestiti dalle Aziende Sanitarie è in costante evoluzione,
essendo necessariamente, in virtù dell’estrema complessità del Servizio Sanitario Regionale, un
percorso da condurre progressivamente in ragione dell’avanzamento delle tecnologie e in funzione
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 4 di 135
delle esigenze di budget, sostenibilità e change management, nell’arco di programmazioni pluriennali.
Il grado di maturità di tale percorso, considerate anche le priorità strategiche determinate dagli
orientamenti regionali e nazionali in materia sanitaria, consente e impone oggi di focalizzare
l’attenzione sulla gestione dei percorsi clinico assistenziali, sia intra-ospedalieri sia di continuità
ospedale-territorio e di cure primarie.
Allo stato attuale, nelle Aziende Sanitarie della Regione, accanto ai singoli sistemi appartenenti al
perimetro del sistema informativo sanitario integrato regionale, convivono un gran numero di altri
sistemi informativi di natura prevalentemente clinica, aventi generalmente funzioni di carattere
“verticale”, parzialmente integrati con i sistemi regionali. In alcuni ambiti, che non permettono flussi di
lavoro interamente digitali, persiste ancora la gestione di funzioni in modalità cartacea.
Nell’ambito dell’Agenda Digitale della Sardegna, in coerenza con le politiche nazionali in materia, con
riferimento alle azioni di informatizzazione del Servizio Sanitario Regionale, l’articolazione delle
strategie individuate include lo sviluppo di servizi relativi all’e-health, orientati al miglioramento dei
processi sanitari, facendo leva sull’accentuazione del grado di interoperabilità tra i sistemi. Inoltre il
Servizio Sanitario Regionale deve continuare a supportare le riforme intraprese dalla Regione e dallo
Stato nell’ambito di un percorso normativo ed attuativo pluriennale mirato alla modernizzazione ed
all’efficientamento dell’organizzazione secondo criteri di razionalizzazione e valorizzazione delle
competenze specifiche, ed alla riforma delle Cure Primarie in coerenza con la Legge n. 189 del
08.11.2012 che ha stabilito all’art. 1 il riordino dell’assistenza territoriale, dando mandato alle Regioni
per la definizione dell’organizzazione dei servizi territoriali di assistenza primaria, promuovendo
l’integrazione con l’area del sociale, anche con riferimento all’assistenza domiciliare ed ai servizi
ospedalieri.
Ciò che, in ogni caso, emerge fortemente è l’evidenza che qualunque evoluzione del Servizio
Sanitario Regionale non possa prescindere dall’esistenza di un’architettura a rete diffusa, che non può
essere implementata senza il parallelo e coerente sviluppo dell’informatizzazione secondo i medesimi
principi, per consentire l’interrelazione tra professionisti e tra questi ed i nodi della rete integrata dei
servizi sociosanitari del distretto e dei servizi sanitari ospedalieri, così da favorire il massimo livello di
integrazione e condivisione delle informazioni. Per queste ragioni, il tema dell’interoperabilità risulta
pertanto strategia cardine anche del presente appalto, come meglio illustrato nel seguito.
1.1. Il sistema SISaR
Il Sistema Informativo Sanitario Integrato Regionale (SISaR) rappresenta il nucleo centrale del
sistema informativo sanitario regionale. Esso è stato realizzato attraverso una specifica gara d’appalto
pubblicata nel 2006, con avvio dell’esecuzione nel 2008. Dal 2008 al 2019 il sistema SISaR è stato
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 5 di 135
sottoposto ad una costante manutenzione ed a numerose evoluzioni. Attualmente, il SISaR è un
sistema integrato di sistemi e moduli software gestionali a carattere sia amministrativo che clinico,
omogeneo su tutto il territorio regionale e presso tutte le Aziende Sanitarie, le cui funzionalità
assicurano la copertura della maggioranza dei processi essenziali al funzionamento della sanità
regionale. In particolare, il sistema SISaR è costituito dai seguenti principali moduli che sono
maggiormente dettagliati nei documenti tecnici allegati:
SISTEMI\ModuliAMC
Contabilità GeneraleContabilità AnaliticaControllo di GestioneApprovvigionamenti: Acquisiti e ContrattiLogistica: Magazzini/Farmaci, Richieste Approvvigionamento, Armadietto di RepartoGestione Attrezzature e Manutenzioni
HRTrattamento GiuridicoGestione Dotazione OrganicaGestione Economica e ContributivaGestione Presenze e Assenze (Rilevazione Presenze)Gestione PensioniGestione Concorsi e SelezioniGestione FondiDichiarazioni 770Portale del Dipendente (Intranet del Personale SSR)
SIO (Ospedaliero)AnagrafeADT e Liste di AttesaPronto Soccorso + OBI + Monitor Pronto SoccorsoOrder Entry di PrestazioniSale OperatorieTrasfusionaleSRC (ex CRCC) + componente Broker EsamiEMR – Cartella Clinica (offerta migliorativa su ASL 8)Prescrizione e Somministrazione dei Farmaci (offerta migliorativa su ASL 8)Identificazione Certa del Paziente - RFID (offerta migliorativa su ASL 8)
AAP (Territoriale)ConsultorioCSS Cartella Socio-SanitariaPUA-Punto Unico di AccessoADI-Assistenza Domiciliare IntegrataMedicina dello SportMedicina LegaleSPRESAL-Servizio Prevenzione e Sicurezza negli ambienti di vita e di LavoroSISP-Servizio Igiene e Sanità Pubblica
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 6 di 135
SIAN-Servizio Igiene degli Alimenti e della NutrizioneRSA-Gestione attività residenziali e semi-residenzialiProtesicaPortale Prevenzione: Portale Notifica Preliminare dei Cantieri e Portale Amianto
DIRStrumento ETL: Talend Open StudioFlussi ETLDatawarehouseStrumento di BI: SpagoBIReport ed Indicatori
EPI (Epidemiologico)CEDAP-Certificato di Assistenza al PartoRENCAM-Registro Nominativo elle Cause di Morte
SIDISistema Integrato Debito Informativo
Accesso al Sistema e CDASistema di accesso SSO, tramite CNS, produzione dei documenti sanitari firmabili digitalmente
IntegrazioniIntegrazioni con Sistemi Terzi Non SISaR (Fascicolo Sanitario Elettronico, SILUS, etc.)Integrazioni intra-SISaRMiddleware di Integrazione: Spagic
L’ambito del presente appalto concerne l’intero parco sistemi sopra descritto.
La descrizione di dettaglio dei sistemi di cui è composto il SISaR è riportata nei documenti allegati al
presente capitolato, elencati nella tabella sottostante. Tali documenti sono articolati secondo il
seguente schema:
- Documenti di descrizione generale dei sistemi: forniscono informazioni generali sui sistemi e
sul grado del loro utilizzo in Regione Sardegna.
- Documenti funzionali, specifiche tecniche e reportistica: forniscono informazioni di maggior
dettaglio sui moduli, sulle funzionalità, sull’architettura e sul dimensionamento.
DOCUMENTI DI DESCRIZIONE GENERALE
Sistema Nome file
Sistema Territoriale edEpidemiologico Allegato 1.B - Descrizione sistema territoriale – AAP
Sistema InformativoOspedaliero Allegato 1.C - Descrizione sistema ospedaliero – SIO
Sistema Amministrativo Allegato 1.D - Descrizione sistema amministrativo - AMC-HR-PROT
CUP e CCA Allegato 1.E - Descrizione sistema CUP-AMB-EPRE
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 7 di 135
Sistema Direzionale Allegato 1.F - Descrizione sistema direzionale
Sistema Integrato DebitiInformativi Allegato 1.G - Descrizione sistema debito informativo
Infrastruttura HW eSOFTWARE di base Allegato 1.H - Descrizione infrastruttura
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 18 di 135
ANFFASS Associazione Nazionale di Famiglie con Persone con DisabilitàIntellettiva e/o Relazionale
AO Azienda OspedalieraAOU Azienda Ospedaliera UniversitariaAPI Application Programming Interface
AREUS Azienda Regionale dell'Emergenza e Urgenza della SardegnaASL Azienda Sanitaria LocaleASSL Area Socio Sanitaria LocaleATS Azienda per la Tutela della SaluteBMI Body Mass IndexBPMN Business Process Model and NotationCCA Cartella Clinica AmbulatorialeCDI Centri Diurni IntegratiCDI Cure Domiciliari Integrate (vedere ADI)CML Commissione Medico Locale (INPS)CMS Commissione Medico Superiore (INPS)CR Change RequestCRESSAN Centro regionale servizi sanitari (area del CSR dedicata alla sanità)CSR Centro Servizi RegionaleCUP Centro Unico di PrenotazioneDBA Database AdministratorDB DatabaseDEC Direzione dell’esecuzione del contrattoDL Direzione lavoriDNS Domain name systemDPO Data Protection OfficerEA Enterprise ArchitectureEMR Electronic Medical RecordENS Ente Nazionale SordiESB Enterprise Service BusETL Extract, Transform, LoadFAD Formazione a distanzaFSE Fascicolo Sanitario ElettronicoFTE Full Time EquivalentGCC Gruppo di coordinamento CUPGDPR General Data Protection RegulationGLU Gruppo di Lavoro per l'Usabilità - Funzione PubblicaH-Cloud Infrastruttura cloud regionale dedicata alla sanitàHL7 Health level 7HR Human ResourcesHW HardwareINPS Istituto Nazionale Previdenza Sociale
Medir Medici in rete (sistema informativo che realizza l’infrastrutturatecnologica del Fascicolo Sanitario Elettronico)
MMG Medico di Medicina GeneraleMNA Mini Nutritional AssessmentOE Order EntryOSA Operatore Settore AlimentarePA Pubblica AmministrazionePLS Pediatra di Libera Scelta
PL/SQL Procedural Language/Structured Query Language (linguaggio diprogrammazione per database Oracle)
PRCIF Piano regionale di controllo ufficiale sulle matrici alimentari, sulcommercio e sull’impiego dei prodotti fitosanitari
PRGLA Programma per la riduzione delle Liste d’attesa
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 19 di 135
PS-EDS Patient Summary-Emergency Data SetPRIC Piano regionale dei controlli ufficialiPS Pronto SoccorsoRAS Regione Autonoma della SardegnaRDP Remote Desktop ProtocolRSA Residenze sanitarie assistenzialiRTI Raggruppamento temporaneo di impreseRTR Rete Telematica RegionaleSA Stazione AppaltanteSAL Stato Avanzamento LavoriSIA Sistema Informativo AmministrativoSIAD Sistema Informativo Nazionale Assistenza DomiciliareSIAN Servizio Igiene degli Alimenti e della NutrizioneSIDI Sistema Integrato Debito InformativoSIO Sistema Informativo OspedalieroSISP Sistema Informativo Igiene e Sanità PubblicaSLA Service Level Agreement – Livelli di servizioSOA Service Oriented ArchitectureSPRESAL Servizio Prevenzione e Sicurezza negli Ambienti di Vita e di LavoroSRC Struttura Regionale di CoordinamentoSSN Servizio Sanitario NazionaleSSR Servizio Sanitario RegionaleSUS System Usability ScaleSW SoftwareTOJ Training on the jobTSO Team di Supporto OperativoTT Trouble TicketingUCI Unione Italiana dei Ciechi e degli IpovedentiUML Unified Modeling LanguageUVI Unità Valutazione InternaUX User ExperienceVAT Verbale AttivitàVPN Virtual Private Network – rete privata virtualeXML eXtensible Markup LanguageXSD XML Schema definition
2. OGGETTO DELLA PROCEDURA
Oggetto della procedura è l’affidamento dei servizi di gestione, manutenzione e reingegnerizzazione
dell’architettura del SISaR e l’acquisizione dell’infrastruttura di integrazione, come meglio descritto nei
capitoli seguenti.
Tutto il codice sorgente del software e tutta la documentazione tecnica, funzionale e la manualistica di
cui è composto il SISaR sono e resteranno di proprietà della Regione Autonoma della Sardegna.
Tutta la documentazione ed i sorgenti software sono disponibili per essere valutati dai concorrenti alla
presente procedura con l’obiettivo di poter proporre una offerta avendo a disposizione le informazioni
necessarie.
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 20 di 135
Tutti questi oggetti saranno consegnati all’aggiudicatario della presente gara per la presa in carico del
sistema. L’aggiudicatario potrà e dovrà modificare il software e la documentazione, che, aggiornata,
resterà comunque integralmente di proprietà della Regione Autonoma della Sardegna.
Si deve inoltre tenere conto che il sistema SISaR, per ovvie ragioni, è in continua manutenzione
normativa ed evolutiva e, pertanto, i sorgenti software e la documentazione tecnica che saranno
consegnati all’aggiudicatario ai fini della presa in carico potranno essere differenti (presumibilmente in
misura estremamente ridotta) rispetto alle versioni allo stato dell’arte attualmente disponibili per i
concorrenti della presente gara.
Alla conclusione del contratto oggetto del presente appalto, i documenti tecnici e funzionali,
unitamente al codice sorgente, dovranno essere riconsegnati attentamente aggiornati allo stato
dell’arte finale, in modo che siano disponibili per i concorrenti della/e prossima/e procedura/e per la
gestione e manutenzione del SISaR.
Le prestazioni oggetto del presente appalto riguardano tutto il parco applicativi SISaR come descritto
in premessa. Si precisa inoltre che non sono oggetto della presente procedura i servizi di Call Center
per il CUP.
Il concorrente dovrà descrivere come intende affrontare complessivamente quanto richiesto dalla
presente procedura dettagliando l’organizzazione, il team di progetto, le procedure e i processi che
applicherà, per ogni servizio, prestazione e fornitura richiesta, come meglio precisato nei capitoli
seguenti e nello schema di offerta tecnica. È richiesto che il concorrente illustri precisamente come
intende assicurare i livelli di servizio richiesti\offerti e gli obiettivi prefissati dal presente capitolato.
2.1. Fasi del progetto e durata
L’esecuzione del contratto sarà suddivisa in due fasi temporali consecutive:
1. Fase 1 - Presa in carico del sistema (durata 3 mesi). Questa fase preparatoria è finalizzata
a consentire all’aggiudicatario di predisporsi all’erogazione delle prestazioni e acquisire le
competenze operative per la presa in carico effettiva del sistema SISaR. In questa fase non è
pertanto prevista alcuna produzione di servizi da parte dell’aggiudicatario e
conseguentemente la stessa non presenta oneri per l’Amministrazione Aggiudicatrice.
Durante questo periodo, infatti, continuerà, in parallelo al nuovo contratto, ad essere vigente
l’attuale contratto di gestione e manutenzione; il precedente gestore erogherà la formazione e
il supporto on the job all’aggiudicatario, secondo le modalità precisate nel capitolo 7, e
continuerà ad erogare i servizi di gestione e manutenzione del sistema nell’ambito del
precedente contratto. L’aggiudicatario della presente procedura avrà l’obbligo di assicurare la
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 21 di 135
presa in carico dell’intero sistema a partire dal primo giorno successivo al termine di questa
Fase.
2. Fase 2 – Erogazione dei servizi (durata 24 mesi, dal mese 4 al mese 27): in questa fase è in
capo all’aggiudicatario della presente procedura l’erogazione di tutti i servizi oggetto del
contratto.
Relativamente alle attività della Fase 2, è prevista l’opzione di cui all'art. art. 63, comma 5, D.Lgs. n.
50/2016, per la ripetizione, totale o parziale, alla conclusione dei 24 mesi della Fase 2, di servizi
analoghi a quelli già aggiudicati, per un massimo di ulteriori 24 mesi.
È altresì prevista l’opzione di proroga tecnica dell’appalto fino a un termine massimo stimabile in 12
mesi, al fine di assicurare la continuità dei servizi indispensabili in pendenza di una nuova gara e per il
tempo strettamente necessario alla conclusione della stessa, ex art. 106 c. 11 D.Lgs. n. 50/2016.
AREA 1 Gestione e Manutenzione Durata del servizio (mesi)
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 62 di 135
Deployment distribuito: singole installazioni ESB/API aziendali (una per ciascun nodo
aziendale SISaR) e una centrale: strumenti di sviluppo, monitoraggio e componenti runtime
sono indipendenti le une dalle altre.
Deployment in cloud:
o I flussi di integrazione sono deployabili in un ambiente gestito dal provider cloud,
oppure come componenti di runtime su infrastruttura locale, comunque collegati alla
piattaforma cloud.
o Gli strumenti di gestione, sviluppo e monitoraggio sono centralizzati, mentre le
componenti runtime possono essere sia centralizzate che locali.
Nell’offerta tecnica, il concorrente dovrà presentare una descrizione tecnica completa delle forniture
proposte e delle modalità di installazione, deployment e configurazione. Dovrà in particolare attestare
le caratteristiche dell’ESB/API secondo l’apposita griglia allegata al modello di offerta tecnica.
4.1.2 Caratteristiche specifiche della componente ESB
L’ESB dovrà supportare le seguenti caratteristiche funzionali:
Routing: fornire la possibilità di smistare una richiesta verso un particolare service provider
basandosi sia sugli standard di instradamento (ws:addressing e simili) sia sul contenuto dei
messaggi.
Filtering: possibilità di bloccare messaggi in base al loro contenuti.
Message transformation: essere in grado di convertire la struttura e il formato del payload
della richiesta effettuata dal consumer nel formato effettivamente gestibile dal service
provider, e viceversa per la risposta.
Message enhancement: aggiungere, modificare o eliminare un’informazione contenuta in un
messaggio in modo da renderlo compatibile col service provider (ad esempio, convertendo il
formato delle data o aggiungendo informazioni non presenti originariamente).
Message Delivering: assicurare il delivery dei messaggi di richiesta e di risposta.
Protocol transformation: consentire di inviare lo stesso payload utilizzando un differente
protocollo. Ad esempio, accettare un tipo di protocollo nei confronti del consumer (p.es.
SOAP, JMS) e comunicare al service provider attraverso un altro protocollo (p.es. REST).
Service orchestration: fungere da coordinatore che controlla i servizi coinvolti e coordina
l’esecuzione delle differenti operazioni. Per questa funzionalità devono essere supportati
linguaggi standard quali BPEL (Business Process Execution Language) o BPMN (Business
Process Modeling Notation).
Ulteriori requisiti funzionali dell’ESB:
La messaggistica deve supportare i principali standard di comunicazione: SOAP 1.1, SOAP
1.2, POX, HTML, Plain text, Binary, JSON.
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 63 di 135
La messaggistica deve supportare i principali protocolli di comunicazione, tra cui: HTTP/S,
POP/IMAP, SMTP, JMS, File transport (FTP/SFTP/CIFS).
Supporto degli standard: WS-Addressing, WS-Security, WS-Reliable Messaging, WS-Policy,
WS-Discovery.
Deve garantire l’interoperabilità tra sistemi a prescindere dalle tipologie del sistema operativo
(windows, unix, linux, etc.) e dei linguaggi di programmazione (JAVA, .NET, etc.).
Deve processare, consentire o rifiutare gli allegati alla messaggistica (MIME, DIME, MTOM).
Deve supportare i formati di messaggistica standard in sanità, tra cui HL7, DICOM, etc.. In
particolare, per la messaggistica HL7 deve essere previsto il supporto nativo per le versioni
2.x e 3.
Deve supportare i profili di integrazione IHE.
Deve supportare le integrazioni verso il data layer. e in particolare tutte le versioni dei
principali RDBMS (Oracle, Microsoft SQL Server, Postgres; MySQL, DB2, etc.).
Deve supportare i paradigmi publish&subscribe ed event driven.
Deve supportare i diversi Message Exchange Patterns: richiesta-risposta sincrona o
asincrona.
Deve essere integrato in un ambiente di sviluppo.
Deve offrire i servizi di test per validare le diverse componenti delle interfacce.
Deve essere gestito il versioning per i servizi ed i processi resi disponibili.
Deve fornire la persistenza di tutti i messaggi e dei processi attraverso il DBMS di appoggio.
Deve mettere in coda o bloccare i messaggi se alcune applicazioni collegate al bus non sono
momentaneamente disponibili.
Deve gestire un motore di regole (Business Rules Engine, BRE) estensibile ed utilizzabile in
modo efficace anche da non programmatori.
Deve garantire il log e la tracciabilità di tutte le operazioni e messaggi gestiti; in particolare,
deve disporre di una console grafica per il log, il monitoraggio la tracciabilità dei messaggi
(Business Activity Monitoring, BAM), il loro recupero, la loro visualizzazione, l’eventuale
modifica e re-inoltro. Inoltre, deve essere possibile monitorare i livelli di servizio (Service Level
Monitoring, SLM) e gli indicatori chiave di performance per ogni servizio/metodo esposto.
Possibilità di scrivere log su file dedicati o syslog.
Deve avere un motore per la gestione di Business Process (Business Process Management,
BMP) che supporti:
o l’orchestrazione dei processi di business;
o la possibilità per gli sviluppatori di definire la logica di business attraverso la
modellazione grafica o attraverso linguaggi quali BPEL e BPMN;
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 64 di 135
o l’integrazione con il BRE in modo da poter modificare il comportamento dei processi
gestiti lavorando sulle regole e non sul codice;
o la separazione delle regole dalla logica di business in modo da poterle riutilizzare
facilmente;
o l’integrazione con il BAM ai fini di monitorare l'attività e lo stato dei singoli processi
aziendali e dell'intero sistema.
Deve supportare l’esecuzione di task, anche periodici.
4.1.3 Caratteristiche specifiche della componente API Gateway
La componente API Gateway dovrà supportare i requisiti funzionali seguenti:
Deve fornire un’interfaccia grafica che renda disponibili tutte le funzionalità necessarie agli
amministratori del sistema.
API Store GUI: deve fornire un’interfaccia grafica che metta a disposizione tutte le funzionalità
necessarie ai consumer delle API per fare discovery, enrollment e sottoscrizione alle API in
modalità user friendly. L'interfaccia include anche un ambiente di test.
Publisher GUI: deve fornire un’interfaccia grafica che metta a disposizione tutte le funzionalità
necessarie alla pubblicazione delle API.
Deve supportare pienamente lo standard Swagger:
- possibilità di esportare le API in file di formato standard Swagger
- possibilità di creare API a partire da file in formato standard Swagger
- possibilità di creare API da endpoint Swagger.
Possibilità di configurare distintamente un endpoint per l'ambiente di sviluppo e un endpoint di
produzione.
Possibilità di storicizzare in modo permanente e consultabile tutti gli scambi di messaggi che
avvengono tramite API.
Possibilità di correlare i messaggi storicizzati afferenti allo stesso flusso logico.
Gestione del ciclo di vita delle API.
Possibilità di versionare differenti rilasci dell'API.
Throttling: limitare l’utilizzo delle API in base al tipo di sottoscrizione.
Possibilità di adottare policy bloccanti basate su:
- IP o range di IP preconfigurati
- campi specifici dell'header della request
- campi specifici del token JWT veicolato nella request
- campi specifici della URL della request
Possibilità di accettare un numero limitato di richieste per API in un intervallo di tempo
configurabile.
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 65 di 135
Possibilità di scrivere log su file dedicati o syslog.
Integrazione col sistema di pagamenti elettronici verso la Pubblica Amministrazione
(PagoPA).
Possibilità di esporre un API unica che integri diversi servizi di backend al fine di esporre una
singola funzionalità in modalità semplificata.
Supporto ad interfacce di backend di tipo REST, SOAP e Websocket.
Possibilità di trasformare il messaggio in ingresso al gateway prima che venga inoltrato al
backend, e, viceversa, possibilità di trasformare il messaggio di risposta al gateway prima che
venga inoltrato al client.
Possibilità di integrare sistemi di backend protetti con: user/pwd, protocollo OAuth2.
Strumenti di monitoraggio e analisi sull’utilizzo delle API sul carico a cui sono sottoposte
(numero di chiamate ricevute, numero di chiamate completate con successo, tempo medio,
minimo e massimo di risposta, risorse utilizzate, etc.).
4.1.4 Requisiti generici comuni per ESB/API
L’infrastruttura ESB/API complessiva deve inoltre garantire i seguenti requisiti:
Deve assicurare elevate performance e garantire la scalabilità orizzontale e verticale dellapiattaforma.
Deve essere configurabile per operare in alta affidabilità mediante l’installazione e la
configurazione di un cluster di almeno due nodi. Devono essere supportate le comuni
modalità di configurazione del cluster:
o Attivo/Passivo: in questa configurazione, composta tipicamente da 2 nodi, un nodo è
attivo, mentre l’altro, in riserva calda, subentra in caso di crash del nodo attivo.
o Attivo/Attivo: in questa configurazione l’ESB/API è installato su N nodi e il carico è
bilanciato su tutti i nodi. In caso di crash di un nodo, il carico viene automaticamente
ripartito sui rimanenti.
Gli strumenti di monitoraggio resi disponibili devono rilevare in anticipo le criticità che
potrebbero portare alla non disponibilità di uno o più nodi.
I requisiti di scalabilità e alta affidabilità devono intendersi estesi a tutte le componenti
dell’infrastruttura ESB/API.
Deve rendere disponibile un’interfaccia grafica che metta a disposizione tutte le funzionalità
necessarie agli amministratori del sistema.
Possibilità di effettuare operazioni di tuning per garantire un livello di servizio conforme alle
attese.
Deve permettere di gestire gli errori e definire le azioni da eseguirsi nel caso di un’eccezione.
Deve consentire di configurare alert basati su eventi.
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 66 di 135
Possibilità di creare report, generare statistiche e grafici.
Deploy in business continuity: il rilascio di nuove funzionalità, processi, metodi e operazioni
deve avvenire con rilasci a caldo senza dover gestire tempi di down del sistema.
4.1.5 Requisiti di sicurezza comuni per ESB/API
L’infrastruttura ESB/API complessiva deve soddisfare i seguenti requisiti di sicurezza:
Deve proteggere i servizi da accessi non autorizzati, gestendo: l’autenticazione,
l’autorizzazione e l’auditing.
Deve gestire la profilazione di utenti e gruppi di utenti per ruoli e attributi (RBAC, ABAC).
Integrazione con il Sistema Pubblico di Identità Digitale (SPID).
Transport Level Security: possibilità di configurare il protocollo SSL/TLS.
Deve supportate l'autenticazione SSL reciproca attraverso la verifica dei rispettivi certificati
digitali.
Possibilità di applicare il protocollo autorizzativo OAuth2 come controllo degli accessi ai
servizi.
Protezione da attacchi DOS.
Possibilità di applicare il protocollo autorizzativo SAML come controllo degli accessi utente.
Deve supportare obbligatoriamente i seguenti standard specifici di settore: WS Security 1.1,
WS Policy, WS Addressing, SAML 2, LDAP, X.509, XML Signature, XML Encryption.
sono inoltre considerati ulteriori standard rilevanti al fine della valutazione: WS Trust, XACML,
PKI, WS Reliability, WS ReliableMessaging.
4.2. Servizio A2.2: Evoluzione e migrazione su nuova infrastruttura e disaccoppiamentofunzionale
Il servizio in oggetto comprende l’attuazione degli interventi di evoluzione e manutenzione necessari
per l’implementazione, la migrazione e conduzione a regime del SISaR al nuovo modello di
interoperabilità su ESB:
Migrazione delle attuali integrazioni sul nuovo ESB/API
Disaccoppiamento delle macrocomponenti del SISaR
Obiettivo del servizio è condurre e migrare il sistema, entro la conclusione del contratto, in uno stato di
funzionamento ottimale consolidato e a regime sulla nuova architettura di integrazione basata su
ESB/API fornita nell’ambito dell’appalto stesso.
Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità
di erogazione del servizio. Il concorrente dovrà descrivere l’organizzazione del servizio, dettagliando il
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 67 di 135
dimensionamento e la composizione dei profili del team coinvolto e dimostrandone la coerenza e
congruità rispetto alle modalità di erogazione proposte per il servizio. Dovrà inoltre giustificare come
riuscirà a garantire gli SLA richiesti e dichiarare eventuali SLA migliorativi (cfr. capitolo 13).
4.2.1 Migrazione delle attuali integrazioni sul nuovo ESB/API
Si richiede che tutte le integrazioni esistenti all’atto dell’avvio del contratto, tra cui quelle che
attualmente insistono sul middleware di integrazione SpagiC, realizzate con sistemi terze parti o tra
moduli SISaR, siano trasferite sulla nuova infrastruttura ESB/API proposta dall’Aggiudicatario (rif. cap.
4.1). Più in generale, per quanto concerne le integrazioni esistenti tra moduli SISaR, è richiesto che:
Le integrazioni tra due o più moduli distinti realizzate tramite accesso diretto ai dati devono
essere disaccoppiate tramite l’ESB/API, che esporrà una specifica API che accederà in lettura
ai dati del sistema provider e un’altra da invocare su richiesta dal sistema consumer, o
comunque secondo uno scheduling prestabilito definito nell’ESB.
Nell’ESB dovranno essere ricostruite le code applicative per la trasmissione asincrona di dati
ad altri sistemi. Ad esempio, ricadono in questa fattispecie le code di invio dei CDA al
FSE/Medir.
Tutte le integrazioni, flussi di dati (anche ETL) attualmente comandati da cron job devono
essere messi sotto il controllo dell’ESB che si occuperà dello scheduling e del monitoraggio.
Il concorrente dovrà descrivere come intende procedere per il servizio di Migrazione delle attuali
integrazioni sul nuovo ESB/API secondo le indicazioni riportate nel presente paragrafo e presentare il
piano temporale di realizzazione. Dato atto che è interesse dell’Amministrazione disporre quanto
prima del sistema in esercizio migrato sulla nuova infrastruttura, saranno infatti oggetto di valutazione
anche le tempistiche proposte.
4.2.2 Disaccoppiamento delle macrocomponenti del SISaR
Il termine macrocomponente indica un raggruppamento di uno o più componenti applicative distinte
tra le quali non è richiesta come obbligatoria la realizzazione di un disaccoppiamento tramite
l’ESB/API. Viceversa, qualunque accoppiamento tra componenti applicative appartenenti a
macrocomponenti differenti dovrà essere disaccoppiata per tramite dell’ESB/API.
Il servizio consiste nella realizzazione di manutenzione evolutiva necessaria affinché le principali
macrocomponenti funzionali di cui è composto il SISaR dialoghino esclusivamente tramite l’ESB/API
oggetto di fornitura nella presente procedura di gara (Cap. 4.2.1). Le macrocomponenti
(raggruppamenti composti da uno o più componenti applicative distinte) da disaccoppiare tramite
l’ESB/API sono individuate di seguito (le macrocomponenti sono indicate come elenco di componenti
racchiuse tra [..]):
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 68 di 135
Per il Sistema Informativo Amministrativo si individuano le seguenti macrocomponenti:
o [AMC]
o [Controllo di Gestione]
o [HR]
o [Ripresa]
o [Protocollo]
o [Atti e delibere]
o [Documentale]
Per il Sistema Informativo Ospedaliero si individuano le seguenti macrocomponenti:
o [XMPI, LA, ADTWEB, PSWEB, OEPR, EMR]
o [SOWEB]
o [ELIOT]
o [Repository Documentale]
Per il Sistema Gestore Risorse (CUPWEB) e Cartella Clinica Ambulatoriale (CCA) si
individuano le seguenti macrocomponenti:
o [CUPWEB]
o [ePrescription]
o [CCA]
Per il Sistema Informativo Territoriale si individuano le seguenti macrocomponenti:
o [PUA]
o [CSS]
o [ADI]
o [Medicina Legale]
o [Cartella Consultori]
o [SPRESAL]
o [Protesica]
o [RSA]
o [SIAN]
o [Amianto]
o [Notifica Preliminare Cantieri]
Per il Sistema Integrato Debito Informativo (SIDI) si individuano le seguenti macrocomponenti:
o [SIDI]
Per il Sistema Informativo Direzionale si individuano le seguenti macrocomponenti:
o [Direzionale]
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 69 di 135
Le integrazioni esistenti, o da realizzarsi, tra macrocomponenti distinte del SISaR, dovranno migrare
sul nuovo ESB/API, secondo le seguenti linee guida:
Le integrazioni tra due o più moduli appartenenti a macrocomponenti distinti realizzate tramite
accesso diretto ai dati devono essere disaccoppiate tramite l’ESB/API, che esporrà specifiche
API, una che accederà in lettura ai dati del sistema provider e una da invocare su richiesta dal
sistema consumer, o comunque secondo uno scheduling prestabilito definito nell’ESB/API.
Nell’ESB dovranno essere ricostruite le code applicative per la trasmissione asincrona di dati
ad altri sistemi.
Tutte le integrazioni e i flussi di dati (anche ETL) attualmente comandati da cron job devono
essere messi sotto il controllo dell’ESB che si occuperà dello scheduling e del monitoraggio.
Il disaccoppiamento effettivo tra macrocomponenti distinte dovrà consentire la sostituzione di singoli
macrocomponenti senza rinunciare ad alcuna funzionalità del sistema preesistente, senza apportare
altre modifiche ad alcun componente del sistema SISaR, e senza che il macrocomponente sostitutivo
debba conoscere dettagli implementativi del macrocomponente SISaR preesistente.
La figura seguente riassume lo scenario di integrazione complessivo; in particolare, evidenzia la
modalità di integrazione tra i livelli SISaR centralizzato e aziendali, da realizzarsi tramite i rispettivi
ESB/API o comunque sotto il loro stretto controllo e continuo monitoraggio.
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 70 di 135
Figura 1 Panoramica di alto livello sulle integrazioni
SISaR - Nodo Regionale
Enterprise Serv ice Bus (ESB) [Regionale]
Enterprise Serv ice Bus (ESB) [Aziendale]
Livello Regionale
Livello Aziendale
SISaR - Nodo Aziendale
Sistema Terze Parti
Sistema Terze Parti
Sistema Terze PartiModulicentralizzati
Modulicentralizzati
Modulicentralizzati
Sistema Terze Parti
Sistema Terze Parti
Sistema Terze PartiModuli
dipartimentale
Modulidipartimentale
Modulidipartimentali
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 71 di 135
La figura seguente riassume lo scenario di integrazione interne ai moduli SISaR centralizzati, e tra
questi e i sistemi terze parti.
Figura 2 Panoramica integrazioni regionali centralizzate
La figura seguente riassume lo scenario di integrazione interna ai moduli SISaR aziendali, e tra questi
e i sistemi terze parti.
Figura 3 Panoramica integrazioni aziendali e dipartimentali
Le integrazioni da realizzarsi tramite intermediazione del nuovo ESB/API sono individuate sulla base
del singolo applicativo specifico e sono individuate ai paragrafi che seguono.
Portali
SISaR - Nodo Regionale
SIDI
Direzionale
HR DocumentaleModulo SRC AMC
Atti e DelibereProtocollo RENCAM CUP/WBS
XMPI
Enterprise Serv ice Bus (ESB) [Regionale]
Livello Regionale
PortaleDipendente
Monitor PS Portale Amianto NPCWEB
ETL Flussi
CUPWEB
ePrescription
Sistema TerzeParti
Sistema TerzeParti
Sistema TerzeParti
ADI PUA
ProtesicaMedicina Legale
SPRESAL CartellaConsultori
RSA/Hospice
Livello Aziendale
SIANCEDAP Medicina delloSport
Enterprise Serv ice Bus (ESB) [Aziendale]
SISaR - Nodo Aziendale
ADTWEB PSWEB SOWEBXMPI OEPRLista Attesa
RepositoryDocumentale
ETL FlussiEMRCCAELIOT
SISP
Sistemi DipartimentaliTerze Parti
Sistemi DipartimentaliTerze Parti
LIS
RIS/PACS
AP
Altri sistemi
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 72 di 135
L’importo contrattuale per tutto l’insieme dei servizi sopra descritti verrà riconosciuto con valore a
corpo unitario ed erogato per Stati di Avanzamento Lavori.
Il concorrente dovrà descrivere come intende procedere per l’evoluzione delle integrazioni come
richiesto nel presente paragrafo e fornire il piano temporale di realizzazione. Il concorrente dovrà
descrivere la proposta progettuale e tecnica, relativamente al servizio in oggetto, incluso il passaggio
in produzione della versione del SISaR con la nuova release del SISaR, le tempistiche di
realizzazione con gli annessi eventuali rischi e disservizi eventualmente necessari per il passaggio in
produzione e le misure previste per l’attenuazione e il contenimento degli stessi.
4.2.2.1 Integrazioni da migrare o realizzare su ESB/API
Nei paragrafi seguenti vengono indicate le integrazioni tra i moduli SISaR e altre componenti afferenti
a macrocomponenti distinti o sistemi terze parti, per le quali è richiesta la realizzazione per mezzo
della nuova infrastruttura ESB/API.
4.2.2.1.1 Integrazioni in ambito Sistema Informativo Amministrativo
Per quanto riguarda le integrazioni inerenti il sistema informativo amministrativo, si richiede che tutte
le integrazioni fra i macrocomponenti ad esso afferenti siano realizzate per tramite della nuova
infrastruttura ESB/API e poste sotto controllo e monitoraggio dell’ESB.
4.2.2.1.2 Integrazioni del modulo XMPI
Per quanto riguarda le integrazioni tra XMPI e i sistemi di terze parti, i messaggi HL7 per l’inserimento
e le variazioni anagrafiche dovranno essere trasmessi tramite l’ESB: XMPI dovrà notificare l’evento
all’ESB il quale a sua volta si occuperà di trasmetterlo a tutti i sistemi sottoscrittori.
Per quanto attiene i flussi di interoperabilità anagrafica tra le installazioni XMPI dipartimentali (più il
CUP) e l’installazione XMPI centrale è richiesto che siano messe sotto il controllo dell’ESB.
Per quanto riguarda l’integrazione tra ANAGS e l’installazione XMPI centrale per lo scarico delle
variazioni anagrafiche, già attiva, questa dovrà essere messa sotto controllo e monitoraggio dal ESB.
4.2.2.1.3 Integrazioni del modulo ADTWEB
È richiesto che tutti gli eventi di prericovero, accettazione, trasferimento e dimissione, nonché
annullamento e aggiornamento delle relative informazioni, trasmessi con messaggistica HL7 da
ADTWEB ai sistemi terzi integrati, siano implementati tramite l’ESB: ADTWEB dovrà notificare
l’evento all’ESB che si occuperà di trasmetterlo a tutti i sistemi sottoscrittori.
Per quanto riguarda le code applicative di invio al FSE/Medir dei CDA prodotti da ADTWEB è richiesto
che siano implementate sull’ESB, che si dovrà occupare della trasmissione al FSE.
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 73 di 135
Si richiede che le seguenti integrazioni di ADTWEB con gli altri moduli SISaR siano messe sotto
controllo e monitoraggio dell’ESB:
- Repository Documentale. Gli eventi di salvataggio e recupero della documentazione dal
repository dovranno essere implementati tramite l’ESB.
- SOWEB. L’acquisizione nella SDO delle informazioni su interventi gestite da SOWEB dovrà
transitare da ESB con l’implementazione di un servizio provider che acquisisca i dati richiesti
da SOWEB e di un consumer da invocare da ADTWEB o comunque schedulato.
- ETL Flussi. Le estrazioni massive di dati da altri sistemi dovranno essere messe sotto il
controllo e monitoraggio dell’ESB
4.2.2.1.4 Integrazioni del modulo PSWEB
Si richiede che le seguenti integrazioni di PSWEB con gli altri moduli SISaR siano messe sotto
controllo e monitoraggio dell’ESB:
- Repository Documentale. Gli eventi di salvataggio e recupero della documentazione dal
repository dovranno essere implementati tramite l’ESB.
- ETL Flussi. Le estrazioni massive di dati da altri sistemi dovranno essere messe sotto il
controllo e monitoraggio dell’ESB
- SPRESAL. Tale integrazione è necessaria per la notifica degli infortuni sul lavoro.
- CUPWEB. La trasmissione bidirezionale di dati tra PSWEB e CUPWEB per le informazioni di
pagamento, per i ticket di Pronto Soccorso e le prestazioni erogate per pazienti solventi, e le
informazioni di avvenuto pagamento dovrà transitare tramite ESB
È richiesto che tutti gli eventi di accettazione e dimissione trasmessi con messaggistica HL7 da
PSWEB ai sistemi terzi integrati siano implementati tramite l’ESB: il PSWEB dovrà notificare l’evento
all’ESB che si occuperà di trasmetterlo a tutti i sistemi sottoscrittori.
Per quanto riguarda le code applicative di invio al FSE/Medir dei CDA prodotti da ADTWEB è richiesto
che siano implementate sull’ESB, che si dovrà occupare della trasmissione al FSE.
Il PSWEB dovrà verificare lo stato di attivazione del FSE e la presenza del documento PS-EDS
tramite l’ESB.
È richiesto che le integrazioni bidirezionali tra PSWEB e le Centrali Operative 118 avvengano tramite
ESB.
È richiesto che anche la trasmissione all’INAIL delle certificazioni di infortunio sia governata da ESB.
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 74 di 135
4.2.2.1.5 Integrazioni del Monitor Pronto Soccorso
È richiesto che i flussi di dati sugli accessi di PS e sui posti letto nei reparti di degenza acquisiti dal
Monitor di Pronto Soccorso con strumenti ETL siano schedulati e monitorati dall’ESB.
4.2.2.1.6 Integrazioni modulo OEPR
Tutti i messaggi HL7 bidirezionali tra OEPR e i sistemi dipartimentali LIS, RIS/PACS, AP,
Trasfusionale e CCA è richiesto che transitino sull’ESB.
È richiesto che tutti gli eventi di salvataggio e recupero della documentazione dal Repository
Documentale siano messi sotto controllo e monitoraggio dell’ESB.
4.2.2.1.7 Integrazioni modulo SOWEB
È richiesto che le informazioni su interventi chirurgici ai fini della condivisione con ADTWEB transitino
tramite ESB con l’implementazione di un servizio provider per l’accesso ai dati SOWEB e uno
consumer da invocare da ADTWEB o comunque schedulato.
Analogamente, le informazioni sul consumo dei medicinali da trasmettere al sistema AMC dovranno
transitare sull’ESB, sotto il controllo e monitoraggio dello stesso.
È richiesto che gli eventi di salvataggio e recupero della documentazione dal Repository Documentale
siano messi sotto controllo e monitoraggio dell’ESB.
4.2.2.1.8 Integrazioni del modulo ELIOT
Per quanto riguarda le integrazioni del modulo ELIOT si richiede:
- che i messaggi HL7 bidirezionali tra ELIOT e OEPR per le richieste informatizzate di
emocomponenti ed esami e dello stato di esecuzione transitino tramite l’ESB;
- che gli eventi di salvataggio e recupero della documentazione dal Repository Documentale
siano messi sotto controllo e monitoraggio dell’ESB;
- che l’interscambio bidirezionale dei dati di richiesta ed esito tra ELIOT e il LIS/Galileo sia
realizzato tramite ESB;
- che i flussi massivi di dati da ELIOT a SRC siano governati da ESB;
- che l’interscambio di dati tra ELIOT e il Broker Esami avvenga sotto controllo e monitoraggio
dell’ESB.
4.2.2.1.9 Integrazioni del modulo EMR
Per quanto riguarda le integrazioni del modulo EMR si richiede:
- che gli eventi di salvataggio e recupero della documentazione dal Repository Documentale
siano messi sotto controllo e monitoraggio dell’ESB;
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 75 di 135
- che la trasmissione ad AMC delle informazioni sui medicinali somministrati sia messa sotto
controllo e monitoraggio dell’ESB.
4.2.2.1.10 Integrazioni in ambito CUPWEB e CCA
Per quanto riguarda le integrazioni fra CUPWEB e Cartella Clinica Ambulatoriale è richiesto:
- che i messaggi bidirezionali tra CUPWEB e la CCA per le richieste di prestazioni e la notifica
dello stato di esecuzione transitino tramite gli ESB/API centrale e aziendale;
- che i messaggi HL7 bidirezionali tra CUPWEB e i sistemi dipartimentali LIS e RIS (e altri
eventuali sistemi terze parti) per le richieste di prestazioni e la notifica dello stato di
esecuzione transitino tramite gli ESB centrale e aziendale;
- che i messaggi HL7 bidirezionali tra OEPR e CCA per le richieste di prestazioni, notifica dello
stato di esecuzione e invio del referto finale transitino tramite l’ESB aziendale.
4.2.2.1.11 Integrazioni in ambito Sistema Informativo Territoriale
Per quanto riguarda il sistema informativo territoriale si richiede che tutte le integrazioni fra i
macrocomponenti ad esso afferenti siano realizzate per il tramite della nuova infrastruttura ESB/API e
poste sotto controllo e monitoraggio dell’ESB.
4.2.2.1.12 Integrazioni in ambito SIDI
Per quanto riguarda il sistema integrato debito informativo non sono previste integrazioni da mettere
sotto il controllo e monitoraggio dell’ESB.
4.2.2.1.13 Integrazioni in ambito Sistema Informativo Direzionale
Per quanto riguarda il Sistema Informativo Direzionale è richiesto che la schedulazione delle attività
eseguite dal Direzionale per l’estrazione dei dati che alimentano il DWH transitino sotto il controllo e
monitoraggio dell’ESB centrale.
5. AREA 3 – SERVIZI DI TRANSIZIONE
I servizi della presente area hanno per oggetto il passaggio di consegne “in uscita” dal contratto,
consistente nelle attività finalizzate a consentire il pieno subentro di uno o più nuovi fornitori nelle
attività di gestione e manutenzione del sistema. Tali servizi saranno erogati negli ultimi 3 mesi della
durata contrattuale (compreso l’eventuale ricorso alle opzioni di rinnovo e/o proroga) come riportato
anche nel Capitolo 2.1.
Durante il periodo di transizione non saranno più consentiti interventi di manutenzione evolutiva “a
consumo\misura” quali quelli descritti nel capitolo 3.3. Prima dell’avvio dei servizi di transizione gli
interventi di manutenzione evolutiva “a consumo” dovranno essere quindi consolidati e stabili. Nello
stesso periodo di transizione dovranno essere invece assicurati tutti i servizi di gestione e
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 76 di 135
manutenzione a canone di Area 1 previsti nel Cap. 3, e i servizi di Area 4 previsti nel cap. 6. I servizi di
Area 2 previsti nel cap. 4 dovranno essere, invece, già completati, rilasciati in ambiente di produzione
e consolidati.
5.1. Servizio A3.1: Transizione verso il fornitore/i subentrante/i
I servizi dovranno prevedere sia la casistica in cui, alla conclusione del contratto oggetto della
presente procedura, il soggetto aggiudicatario (o i soggetti aggiudicatari) del/i futuro/i contratto/i, per
ciascun modulo applicativo, gestirà e manuterrà direttamente i sistemi SISaR, sia quella in cui opererà
una sostituzione parziale o totale degli applicativi esistenti con nuovi applicativi. Dovranno pertanto
essere offerti sia servizi di trasferimento di knowledge / competenze sul sistema oggetto del presente
contratto, sia servizi di supporto alla migrazione su nuovi sistemi e recupero dati, con possibilità di
combinare in modo flessibile gli stessi in modo da ottimizzare l’efficacia e massimizzare il risultato in
caso di mix tra le casistiche.
Infatti, dato atto che non è possibile alla data della presente procedura prevedere le modalità con cui
avverrà il subentro dei nuovi fornitori a fine contratto, la presente Area dovrà avere carattere
altamente flessibile, in modo da consentire all’Amministrazione di configurare il servizio nella maniera
più opportuna in funzione delle esigenze che si definiranno in corso di esecuzione del contratto e a
seguito dell’aggiudicazione della/e futura/e procedura/e. L’offerta tecnica dovrà dunque descrivere le
opzioni tra cui l’Amministrazione potrà scegliere, indicando e segmentando il relativo
dimensionamento per singola sotto-attività e singolo sistema, così da permettere in fase esecutiva la
costruzione di un mix chiaro e non ambiguo di servizi e costi, entro il budget fissato, quando saranno
consolidate le condizioni e il quadro attuativo della transizione. Il servizio include la predisposizione
del progetto di migrazione, da avviarsi non appena le suddette condizioni saranno conosciute, che
sarà sottoposto all’approvazione dell’Amministrazione Aggiudicatrice.
Entro le scadenze previste nel cap. 12, l’Aggiudicatario dovrà consegnare un piano per la transizione,
da sottoporre all’approvazione della DEC.
L’impegno dell’aggiudicatario nella fase di transizione sarà variabile in funzione del tipo di subentro
richiesto (con o senza sostituzione del sistema). Nella tabella sottostante sono indicati il numero di
giorni persona che al minimo l’aggiudicatario dovrà erogare per ciascun sistema nel caso in cui tale
sistema sia sostituito (in tal caso l’attività da erogare consisterà nel supporto alla migrazione del
sistema), oppure nel caso in cui il sistema sia mantenuto (in tal caso l’attività da erogare consisterà
nel passaggio delle competenze).
Il totale delle giornate persona che al minimo l’aggiudicatario dovrà quindi erogare è compreso fra 890
(nessun sistema migrato, solo passaggio di competenze sui sistemi esistenti) e 1176 giornate (tutti i
sistemi migrati, nessun passaggio di competenze sui sistemi esistenti).
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 77 di 135
Sistema Moduli Applicativi
Effort minimi inGG/U per Sistema
per l’attività disupporto alla
Migrazione Dati nelcaso di sostituzione
del Sistema
Effort minimi inGG/U per l’attività diTrasferimento delle
Competenze perciascun sistema in
caso dimantenimento dello
stesso
AMC – Amministrazione eControllo
Contabilità, Acquisti e Contratti, Logistica(Magazzini, Richieste di Approvvigionamento,Armadietto di Reparto), Gestione Attrezzature eManutenzioni / Cespiti
FOR Grado di soddisfazione A conclusione di ciascunasessione di formazione viene
Aggiornato con verifica trimestrale
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 83 di 135
medio degli utenti rilevato il grado di soddisfazionemedio dei partecipanti.
Liv. 1 – Scarso
Liv. 2 – Insufficiente
Liv. 3 - Sufficiente
Liv. 4 - Buono
Liv. 5 - Ottimo
AFF Grado di soddisfazionemedio degli utenti
A conclusione di ciascunasessione di affiancamento,viene rilevato il grado disoddisfazione medio degli utentirispetto alla totalità diaffiancamento nel trimestre.
Liv. 1 – Scarso
Liv. 2 – Insufficiente
Liv. 3 - Sufficiente
Liv. 4 - Buono
Liv. 5 - Ottimo
Aggiornato con verifica trimestrale
Detta rilevazione del livello di soddisfazione degli utenti non avrà effetto ai fini della determinazione di
eventuali penali per tale servizio.
Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità
di erogazione del servizio. Il concorrente dovrà descrivere l’organizzazione del servizio, dettagliando il
dimensionamento e la composizione dei profili del team coinvolto e dimostrandone la coerenza e
congruità rispetto alle modalità di erogazione proposte per il servizio. Dovrà inoltre giustificare come
riuscirà a garantire gli SLA richiesti e dichiarare eventuali SLA migliorativi (cfr. capitolo 13). Il
concorrente dovrà specificare il numero massimo di giornate persona che potranno essere erogate
mediamente in una stessa giornata lavorativa, per tutto il periodo di durata del contratto.
L’effettivo numero di giornate da erogare sarà determinato dalla tariffa offerta per ciascun profilo
professionale richiesto, fino al tetto massimo costituito dal budget contrattuale disponibile per il
servizio.
Considerata la natura flessibile e il contenuto non stimabile a priori delle attività ricadenti nel presente
servizio e degli obiettivi che questo intende perseguire, esso è da intendersi integralmente “a
consumo”, ovvero remunerato a misura sulla base dell’effort approvato dalla Direzione
dell’Esecuzione del Contratto su proposta dell’aggiudicatario ed effettivamente erogato giustificato con
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 84 di 135
report attività firmato dall’utente, basato sulle tariffe per figura professionale offerte per le giornate
erogate, fino al raggiungimento del budget massimo di risorse disponibili per il servizio medesimo.
Il servizio dovrà essere garantito nei giorni lavorativi dal Lunedì al Venerdì nella fascia oraria 09:00 –
18:00.
7. PASSAGGIO DI CONSEGNE “IN INGRESSO” E PRESA IN CARICO DALL’ATTUALEGESTORE DEL SISTEMA
Per quanto concerne il passaggio di consegne “in ingresso” all’avvio del contratto, l’aggiudicatario
potrà fruire di un mese di durata di formazione in aula più due mesi di passaggio di consegne\training
on the job, su tutti i sistemi costituenti il SISaR, da parte dell’attuale fornitore del servizio di gestione e
manutenzione di SISaR (Fase 1). Gli oneri del passaggio di consegne lato fornitore uscente sono a
carico dell’Amministrazione Aggiudicatrice nell’ambito del contratto cessante, mentre, lato
aggiudicatario della presente procedura, che riceve ed è beneficiario dei suddetti servizi, non sono
previste remunerazioni, come da cap. 2.1, in quanto non sussiste produzione né erogazione di servizi.
Riassumendo, la pianificazione di massima per il periodo di presa in carico “in entrata” del sistema
prevede:
1 mese di elapsed per la fruizione di formazione in aula
2 mesi di training on the job
Sarà inoltre possibile per l'aggiudicatario avvalersi del supporto del fornitore uscente per rispondere a
dubbi o richieste atte a chiarire e colmare eventuali carenze associate al passaggio di consegne
svolto, che si dovessero manifestare entro 6 mesi dal completamento delle attività di formazione e
training on the job e in ogni caso prima che vengano rilasciate in produzione sul modulo contestato
nuove evoluzioni e modifiche da parte dell'aggiudicatario.
Al fine di coordinare l’attività del passaggio di consegne l’aggiudicatario dovrà concordare con la
Direzione dell’Esecuzione del Contratto la formazione e il training attraverso la redazione della
seguente documentazione, con il dettaglio del personale che parteciperà alle sessioni di formazione:
Piano della presa in carico
Di seguito si riporta, per ciascun Applicativo, il numero di giornate che il fornitore uscente è tenuto ad
erogare all’aggiudicatario nei primi 3 mesi di transizione.
Area Tematica/Sistema ModuliEffort in GG/U x
Trasferimento delleCompetenze
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 85 di 135
AMC – Amministrazione e Controllo
Contabilità, Acquisti e Contratti, Logistica (Magazzini,Richieste di Approvvigionamento, Armadietto diReparto), Gestione Attrezzature e Manutenzioni /Cespiti
• Tempo intercorrente fra la data effettiva di rilascio in produzione e la data prevista di rilascio in
produzione (calcolato automaticamente)
L’aggiudicatario è tenuto a prendere in carico e gestire correttamente gli strumenti di cui sopra. Tutti
gli utenti e operatori abilitati del sistema SISaR, afferenti sia al SSR che alla Regione, sono in
possesso di una utenza per la segnalazione delle anomalie del software o per richieste di assistenza.
Il fornitore dovrà gestire correttamente gli account di tutti gli utenti che possono accedere ai sistemi di
supporto.
Come già rappresentato, l’aggiudicatario potrà eventualmente proporre la sostituzione degli strumenti
con altri o l’aggiunta di nuovi strumenti, ed in tal caso eventuali costi di licenza e di formazione o
manualistica, nonché l’obbligatoria migrazione di tutto il dato storico e del pregresso, saranno a carico
dell’aggiudicatario stesso. Tale opzione, risultando indifferente dal punto di vista dei servizi oggetto del
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 97 di 135
contratto e del valore aggiunto per l’Amministrazione, non costituisce oggetto di punteggio in sede di
valutazione dell’offerta ai fini dell’aggiudicazione della presente procedura di gara.
11. DELIVERABLES
I deliverable minimi da produrre nell’esecuzione del contratto sono elencati, per ciascun servizio, nella
seguente tabella. L’elenco è indicativo e non esaustivo, e potrà subire variazioni in corso di
esecuzione sulla base delle esigenze dell’Amministrazione.
Servizio DeliverableAREA 1 - Gestione
Manutenzione correttiva
Registro Manutenzione CorrettivaDocumentazione tecnica di analisi e design, note Operative e manuali utenteaggiornatiCheck List e Verbale di Installazione Ambiente di Test
Check List e Verbale di Installazione Ambiente di Produzione
Piano dei Test/Rapporto Esecuzione Test
No-regression Test
Manutenzione preventiva
Piano della manutenzione preventiva e aggiornamento trimestrale dello stesso
Piano dei Test/Rapporto Esecuzione Test
Note Operative e manuali utente aggiornati
Check List e Verbale di Installazione Ambiente di Test
Check List e Verbale di Installazione Ambiente di ProduzioneDocumentazione tecnica (sia funzionale che architetturale), manualistica, diagrammiUML, User Exeperience Design
Manutenzione adeguativa e adattativa
Piano della manutenzione adeguativa e adattativa con paragrafo distinto dedicatoalla manutenzione ordinaria per adeguamenti normativi e aggiornamento trimestraledello stessoPiano dei Test/Rapporto Esecuzione Test
Note Operative e manuali utente aggiornati
Check List e Verbale di Installazione Ambiente di Test
Check List e Verbale di Installazione Ambiente di ProduzioneDocumentazione tecnica (sia funzionale che architetturale), manualistica, diagrammiUML, User Exeperience DesignIn particolare, per gli adeguamenti normativi ordinari:- Registrazione dell’esigenza sul sistema di tracciamento sul sistema di TT.- Documento di analisi.- Applicazione delle linee guida usabilità.- Valutazione economica.- Aggiornamento della documentazione tecnica di analisi e progettazione e dei
relativi elaborati UML, BPMN, etc- Pianificazione attività.- Eventuale aggiornamento del piano di lavoro- Produzione piano dei Test, unit testing, integration testing, system testing,
regression testing- Tracciamento dei test effettuati- Test in ambiente di test SISaR, regression testing- Rilascio della patch in produzione- Verifiche di funzionamento in ambiente di produzione- Registrazione dei documenti attestanti l’attività sul portale documentazione
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 98 di 135
Manutenzione perfettiva
Piano della manutenzione perfettiva e aggiornamento trimestrale dello stesso
Piano dei Test/Rapporto Esecuzione Test/Risultati code inspection
Note Operative e manuali utente aggiornati
Check List e Verbale di Installazione Ambiente di Test
Check List e Verbale di Installazione Ambiente di ProduzioneDocumentazione tecnica (sia funzionale che architetturale), manualistica, diagrammiUML, User Exeperience Design
Manutenzione evolutiva
Piano della manutenzione evolutiva e aggiornamento mensile dello stessoPer ciascuna CR:- Documento d’analisi- Piano di sviluppo con descrizione delle iterazioni, cronoprogramma equantificazione economica- Software sviluppato- Piano dei test\No regression test\Test di integrazione\Risultato dei test- Rilascio- Documentazione tecnica a corredo del software: design del software(UML), user experience design, manualistica utente, piano dei test, report dei testeffettuatiCheck List e Verbale di Installazione Ambiente di Test
Check List e Verbale di Installazione Ambiente di Produzione
Note Operative e manuali utente aggiornati
Miglioramento delle performance edell’usabilità
Piano per il miglioramento delle performance e della user experience eaggiornamento trimestrale dello stessoGantt complessivo con mappatura delle risorse impiegate per profilo professionaleutilizzato aggiornatoCheck List e Verbale di Installazione Ambiente di Test
Check List e Verbale di Installazione Ambiente di Produzione
Piano dei Test/No regression Test/Rapporto Esecuzione Test
Note Operative e manuali utente aggiornatiAnalisi Funzionale/Analisi dei requisiti/Specifica architetturale delle soluzionisw/Diagrammi UML, User Experience Design
Servizi Specialistico-Applicativi Report segnalazioni registrate su JIRA> Relazione sullo Stato Avanzamento Lavori
Gestione dell’Ambiente Applicativo diTest
Check List e Verbale di Installazione Ambiente di Test
Piano dei Test/Rapporto Esecuzione Test
No-regression Test
Gestione dell’Ambiente Applicativo diProduzione
Check List e Verbale di Installazione Ambiente di Produzione
Note Operative e manuali utente (applicativi e amministrazione) aggiornati
Verbale verifiche effettuate in ambiente di produzione
Gestione Sistemistico-Applicativa
Produzione mensile dei report di dettaglio (da definirsi con l’AmministrazioneAggiudicatrice) su tutte le integrazioni che insistono sull’integratore SpagiC\nuovointegratore ESB: Conteggio dei messaggi, per tipologia e destinatario, trasmessi con esito
positivo (ACK OK), senza ACK e in errore (ACK KO) Conteggio dei messaggi, per tipologia e sistema sorgente, ricevuti con esito
positivo (ACK OK) e in errore (ACK KO)Individuazione dei sistemi sorgente per i quali i messaggi ricevuti risultano in numeroinferiore a quanto atteso (soglia da definirsi in base alla media)Relazioni mensili sulle verifiche di qualità eseguite su moduli, integrazioni eaggiornamento dei dati del Direzionale.
Servizio di Help Desk Report segnalazioni registrate sul sistema di trouble ticketing, all’interno dei rapportibimestrali sui servizi erogati
Servizio di Reperibilità H24 Mission-Critical
Report segnalazioni registrate sul sistema di trouble ticketing, all’interno dei rapportibimestrali sui servizi erogati
AREA 2 - Infrastruttura di interoperabilità ESB/API
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 99 di 135
Fornitura infrastruttura di interoperabilitàESB/API
Piano per la fornitura, installazione e configurazione della nuova infrastruttura diintegrazione e per la migrazione e disaccoppiamento dei macrocomponenti delSISaRLicenze di utilizzo e/o canone di manutenzione per 3 anni a partire dalla data diinstallazione/attivazioneReport di Installazione e attivazione
Manuali di utilizzo
Report e statistiche periodiche di utilizzo e funzionamento
Piano di migrazione delle integrazioni esistenti
Evoluzione e migrazione su nuovainfrastruttura e disaccoppiamentofunzionale
Piano per la fornitura, installazione e configurazione della nuova infrastruttura diintegrazione e per la migrazione e disaccoppiamento dei macrocomponenti delSISaRDocumentazione tecnica sulle integrazioni
Check List e Verbali di Installazione
Piano dei Test/Rapporto Esecuzione Test
Note Operative
Check List e Verbale di Installazione Ambiente di Test
Check List e Verbale di Installazione Ambiente di Test
AREA 3 -Transizione
Transizione verso il fornitore\isubentrante\i
Piano di transizione
Verbali Attività
Relazione sullo Stato Avanzamento Lavori
Sorgenti SOFTWARE allineati all’ultima versione in produzioneDocumentazione funzionale, tecnica, manuali utenti, Manuali configurazioni,diagrammi UML etc. allineati ai sorgenti aggiornati
AREA 4 –Servizi Trasversali
Program, Project e ServiceManagement
Piano di progetto generale complessivo
Piano di Qualità e Matrice dei Rischi
Documento della Configurazione e Standard di Progetto
Rapporto trimestrale di Stato Avanzamento Lavori
Rapporto bimestrale sui servizi a canone
Rapporto sui Livelli di Servizio
Report stato Change Request
Piano di presa in carico
Verbali attivitàAggiornamento di tutti i documenti Tecnico\Funzionali del SISaR allegati allapresente garaReport audit interni ed esterni
Formazione e Affiancamento
Registri Presenze Formazione
Rapporto giornate pianificate ed erogate per Formazione e AffiancamentoFogli con la rilevazione del livello di soddisfazione degli utenti e statistiche sul livellodi soddisfazione degli utentiVerbali Attività
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 100 di 135
12. MODALITÀ DI ESECUZIONE
Come specificato nel paragrafo 2.1 Fasi del progetto e durata, durante la Fase 1 l’aggiudicatario dovrà
predisporsi all’erogazione delle prestazioni e acquisire le competenze operative per la presa in carico
effettiva del sistema SISaR. In questa fase dovrà predisporre, entro 10 giorni lavorativi dalla data di
stipula del contratto, la seguente documentazione:
o Piano di presa in carico (da concordare con la DEC)
La presa in carico dell’intero sistema e la formazione dovranno concludersi entro 3 mesi dalla data
della stipula del contratto.
La Fase 2 - Erogazione dei servizi inizierà a partire dal primo giorno successivo al termine di questa
Fase.
A decorrere dalla data di avvio della Fase 2, l’aggiudicatario dovrà:
1. presentare, entro 1 mese, la seguente documentazione:
o piano di progetto generale;
o piano di qualità e matrice dei rischi;
o documento della configurazione e standard di progetto;
o modello e prima versione di piano per la manutenzione preventiva;
o modello e prima versione di piano per la manutenzione adeguativa e adattativa;
o modello e prima versione di piano per la manutenzione perfettiva;
o modello e prima versione di piano per il miglioramento delle performance e della user
experience;
o piano per la fornitura, installazione e configurazione della nuova infrastruttura di
integrazione e per la migrazione e disaccoppiamento dei macrocomponenti del
SISaR;
o modello e prima versione del piano della manutenzione evolutiva;
2. produrre, con cadenza mensile:
o aggiornamento del piano della manutenzione evolutiva;
o rapporto giornate pianificate ed erogate per Formazione e Affiancamento;
o report di dettaglio (da definirsi con l’Amministrazione Aggiudicatrice) sullo stato di
tutte le integrazioni che insistono sull’integratore SpagiC e sul nuovo integratore;
3. produrre, con cadenza bimestrale:
o rapporto dei servizi erogati contenente la descrizione dettagliata delle attività
riguardanti i servizi a corpo con rendicontazione a canone svolte nel periodo di
riferimento, con i relativi deliverable (verbali, documentazione, etc.) e il relativo
rendiconto economico;
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 101 di 135
4. produrre, con cadenza trimestrale:
o rapporto di Stato di avanzamento lavori per i servizi a corpo e a misura per cui è
prevista la rendicontazione a SAL;
o aggiornamento del Piano di progetto, del piano della qualità e gestione dei rischi, del
documento della configurazione e standard di progetto;
o aggiornamento del piano per la manutenzione preventiva;
o aggiornamento del piano per la manutenzione adeguativa e adattativa;
o aggiornamento del piano per la manutenzione perfettiva;
o aggiornamento del piano per il miglioramento delle performance e della user
experience;
o aggiornamento del piano per la fornitura, installazione e configurazione della nuova
infrastruttura di integrazione e per la migrazione e disaccoppiamento dei
macrocomponenti del SISaR;
o calcolo dei livelli di servizio – SLA - per ciascun indicatore effettuato sui dati
riscontrabili dai tool di trouble ticketing, JIRA o ricavabili da sistemi di monitoraggio;
5. presentare, prima di 6 mesi dalla data di conclusione del contratto:
o piano di transizione.
Nell’erogazione dei servizi oggetto del presente appalto, l’aggiudicatario è tenuto ad adempiere agli
obblighi inerenti all’utilizzo dei sistemi di supporto per ciascuno specifico servizio, come da indicazioni
di dettaglio contenute nella descrizione dei servizi di cui al presente Capitolato.
13. SLA – LIVELLI DI SERVIZIO E OBBLIGHI DELL’AGGIUDICATARIO
Con decorrenza dalla data di avvio della Fase 2 (cap. 2.1), l’aggiudicatario è tenuto a garantire il
rispetto dei livelli di servizio (SLA) e delle modalità di esecuzione indicati nel seguito del presente
capitolo.
Il periodo di osservazione per il calcolo degli SLA è trimestrale, intendendosi con ciò che la
misurazione degli SLA sarà effettuata ogni 3 mesi a partire dall’avvio della Fase 2. L’aggiudicatario
entro il 20 del mese successivo al trimestre, a partire dal primo trimestre di erogazione dei servizi,
dovrà presentare regolarmente il report completo di tutti gli SLA. Più precisamente, il periodo
contrattuale della Fase 2 risulta diviso in 6 trimestri di rilevazione al fine del controllo degli SLA, che
sono pertanto così individuati:
1. dal mese 4 al mese 7,
2. dal mese 8 al mese 11,
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 102 di 135
3. dal mese 12 al mese 15,
4. dal mese 16 al mese 19,
5. dal mese 20 al mese 23,
6. dal mese 24 al mese 27.
13.1. Metodo di calcolo degli SLA
Per gli indicatori con valori di soglia del tipo “<soglia 1> nel X% dei casi; <soglia 2> nel restante Y%
dei casi”, il metodo di calcolo degli SLA è il seguente:
1. Si ordinano i casi rientranti nel periodo di riferimento per valore di interesse crescente.
2. Si considera il sottoinsieme costituito dal primo X% dell’insieme ordinato di cui al punto
precedente e si contano i casi che superano la soglia 1.
3. Analogamente, si considera il sottoinsieme costituito dal restante Y% dell’insieme ordinato di
cui al punto precedente e si contano i casi che superano la soglia 2.
4. Il totale dei casi che superano i valori di soglia per i due sottoinsiemi, rapportato al numero
totale (100%) dei casi, rappresenta la violazione dello SLA ed è la percentuale da utilizzare ai
fini della determinazione delle penali di cui al cap. 14.1.
5. Se entrambi i valori di cui ai punti precedenti 2 e 3 sono minori o uguali alle rispettive soglie, lo
SLA è rispettato.
Come caso particolare del precedente, se l’indicatore è del tipo valor medio, il metodo di calcolo di cui
sopra è il seguente:
1. Si ordinano i casi rientranti nel periodo di riferimento per valore di interesse crescente.
2. Si considera il sottoinsieme costituito dal primo X% dell’insieme ordinato di cui al punto
precedente e si calcola l’indicatore (media). Se l’indicatore (media) risulta superiore alla soglia
1, si conta il numero minimo di casi del sottoinsieme che portano la media sopra la soglia 1.
3. Analogamente, si considera il sottoinsieme costituito dal restante Y% dell’insieme ordinato di
cui al punto precedente e si calcola l’indicatore (media). Se l’indicatore (media) risulta
superiore alla soglia 2, si conta il numero minimo di casi del sottoinsieme che portano la
media sopra la soglia 2.
4. Il totale dei casi di cui ai punti 2 e 3, che portano l’indicatore a superare i valori di soglia per i
due sottoinsiemi, rapportato al numero totale (100%) dei casi, rappresenta la violazione dello
SLA ed è la percentuale da utilizzare ai fini della determinazione delle penali di cui al cap.
14.1.
5. Se entrambi i valori di cui ai punti precedenti 2 e 3 sono minori o uguali alle rispettive soglie, lo
SLA è rispettato.
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 103 di 135
Per tutti gli altri indicatori, ogni caso superiore al valore di soglia determina la violazione dello SLA e il
totale dei casi fuori SLA, rapportato al numero totale (100%) dei casi, rappresenta la percentuale da
utilizzare ai fini della determinazione delle penali di cui al cap. 14.1.
Si consideri comunque che il calcolo degli SLA deve consentire di valutare tutti gli eventi accaduti nel
periodo. In particolare, oltre a prendere in considerazione le segnalazioni registrate nel periodo per il
quale si stanno calcolando gli SLA, è necessario anche prendere in considerazione le segnalazioni
registrate in periodi precedenti a quello in esame ma prese in carico, chiuse o elaborate nel periodo in
esame.
13.2. Manutenzione Correttiva
La manutenzione correttiva fa parte del Servizio A1.1: Manutenzione Preventiva, Adeguativa,
Correttiva, Perfettiva (Cap. 3.1.3).
Codice SLA Indicatore Valore di soglia Descrizione
A1.1-1Tempo medio dirimozione di guasti oerrori bloccanti
Entro 8 ore consecutive di coperturadel servizio nel 90% dei casi
Entro 16 ore consecutive nelrestante 10% dei casi
In caso di guasti o errori bloccanti vienemisurato il tempo medio necessario perla individuazione, risoluzionedell’inconveniente e ripristino delsoftware applicativo dalla rispettiva presain carico durante le ore di copertura delservizio di manutenzione correttiva
A1.1-2Tempo medio dirimozione di guasti oerrori non bloccanti
Entro 24 ore consecutive dicopertura del servizio nel 90% deicasi
Entro 36 ore consecutive nelrestante 10% dei casi
In caso di guasti o errori non bloccantiviene misurato il tempo medionecessario per la individuazione erisoluzione dell’inconveniente e ripristinodel software applicativo dalla rispettivapresa in carico durante le ore dicopertura del servizio di manutenzionecorrettiva
A1.1-3Tempo massimo dirisoluzione dei guasti oerrori bloccanti
30 ore consecutive
Per guasti o errori bloccanti di severità 1il tempo impiegato per la individuazionee risoluzione dell’inconveniente eripristino del software applicativo inproduzione, anche medianteapplicazione di work-around, dallarispettiva presa in carico durante le ore dicopertura del servizio di manutenzionecorrettiva, non deve superare in nessuncaso la soglia massima indicata.
A1.1-4Tempo massimo dirisoluzione dei guasti oerrori non bloccanti
130 ore consecutive
Per guasti o errori non bloccanti il tempoimpiegato per la individuazione erisoluzione dell’inconveniente e ripristinodel servizio in produzione, anchemediante applicazione di work-around,dalla rispettiva presa in carico durante leore di copertura del servizio dimanutenzione correttiva, non devesuperare in nessun caso la sogliamassima indicata.
A1.1-5Numero interventi di Casi rilevati < 3 Numero di interventi che hanno
comportato la riapertura su stesso
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 104 di 135
manutenzione recidivi malfunzionamento di casi di guasti oerrori che risultavano già risolti sulsistema di TT
La classificazione del livello di gravità dell’errore è la seguente:
Severità 1 (A1.1-1, A1.1-3) Anomalia bloccante L’intero sistema\modulo è indisponibile agli utenti o gravemente
degradato.
Severità 2 (A1.1-1, A1.1-3) Anomalia grave Funzioni critiche del sistema\modulo sono indisponibili agli utenti o
gravemente degradate.
Severità 3 (A1.1-2, A1.1-4) Anomalia media
Funzioni non critiche del sistema\modulo sono indisponibili agliutenti o gravemente degradate, oppure funzioni critiche sonolievemente degradate.
Severità 4 (A1.1-2, A1.1-4) Anomalia lieve Funzioni non critiche del sistema\modulo sono lievemente
degradate.
Ai fini del calcolo degli SLA, per l’applicazione di eventuali penali, come tempo di risoluzione del
singolo ticket si considera il tempo netto di risoluzione registrato dall’aggiudicatario nello strumento di
Trouble Ticketing.
Le tipologie di ticket registrate nello strumento di TT gestito dall’aggiudicatario prese in considerazione
per il calcolo degli SLA relativi alla manutenzione correttiva sono almeno le seguenti:
Il presente SLA si applica alla manutenzione Preventiva, Adeguativa e Perfettiva.
Queste manutenzioni fanno parte del Servizio A1.1: Manutenzione Preventiva, Adeguativa, Correttiva,
Perfettiva (Cap. 3.1.1, Cap. 3.1.2, Cap. 3.1.4). Il servizio viene attivato aprendo un ticket sul sistema
Jira\Sistema di TT. La segnalazione può essere fatta da utenti della Direzione Generale della Sanità,
dagli utenti delle Aziende Sanitarie, dalla Direzione dell’esecuzione del contratto o dall’Aggiudicatario
stesso.
I livelli di servizio minimi che devono essere garantiti sono i seguenti:
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
A1.1-6Intervallo medio di presain carico della richiesta dimanutenzione
<5 giorni lavorativi nel90% dei casi
<10 giorni lavorativi nel
A fronte della richiesta di manutenzione vienemisurato il tempo medio per la presa in caricodella richiesta stessa da parte del ServiceManager
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 105 di 135
restante 10% dei casi
A1.1-7
Intervallo medio diemanazione delladocumentazione diprogettazione per larichiesta di manutenzioneprevista al cap. 3.1.2
<20 giorni lavorativi nel90% dei casi
<25 giorni lavorativi nelrestante 10% dei casi
A fronte della presa in carico e dell’analisi dellamanutenzione richiesta viene misurato il tempomedio per la produzione della progettualitàrichiesta
Tutto il processo di manutenzione Preventiva, Adeguativa e Perfettiva dovrà essere tracciato
attraverso il sistema Jira / sistema di TT. L'aggiudicatario è tenuto (con decorrenza dalla data di avvio
della Fase 2 di cui al cap. 2.1) a garantire che all’interno del sistema di Jira \Sistema di TT,
contestualmente alla conferma della presa in carico, sia espressamente indicato il tempo entro cui
sarà consegnato il piano delle attività.
L'aggiudicatario è tenuto a consegnare la pianificazione e le note di rilascio delle manutenzioni, in
coerenza con gli SLA previsti per la messa in produzione delle release/add.
13.4. Manutenzione per adeguamenti normativi ordinari
La manutenzione normativa ordinaria fa parte del Servizio A1.1: Manutenzione Preventiva,
Adeguativa, Correttiva, Perfettiva (Cap. 3.1.2), ed è un caso particolare della manutenzione
adeguativa.
Il servizio, per quanto attiene gli adeguamenti normativi ordinari derivanti da norme di livello regionale
o nazionale, viene attivato aprendo una segnalazione sul sistema Jira \Sistema di TT. La
segnalazione può essere fatta da utenti della Direzione Generale della Sanità, dagli utenti delle
Aziende Sanitarie, dalla Direzione dell’esecuzione del contratto o dall’Aggiudicatario stesso.
I livelli di servizio minimi che devono essere garantiti per gli adeguamenti normativi ordinari sono i
seguenti:
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
A1.1-8Intervallo medio di presain carico della richiesta divariazione normativa
<5 giorni lavorativi nel 90%dei casi
<10 giorni lavorativi nelrestante 10% dei casi
A fronte della richiesta di variazionenormativa viene misurato il tempo medioper la presa in carico della richiestastessa da parte dell’Aggiudicatario
A1.1-9
Intervallo medio diemanazione delladocumentazione diprogettazione per larichiesta di manutenzioneprevista al cap. 3.1.2
<20 giorni lavorativi nel90% dei casi
<25 giorni lavorativi nelrestante 10% dei casi
A fronte della presa in carico e dell’analisidella variazione normativa richiesta vienemisurato il tempo medio per laproduzione della documentazione diprogettazione richiesta
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 106 di 135
Tutto il processo di adeguamento normativo ordinario dovrà essere tracciato attraverso il sistema Jira.
L'aggiudicatario è tenuto (con decorrenza dalla data di avvio della Fase 2 di cui al cap. 2.1) a garantire
per gli adeguamenti normativi ordinari che all’interno del sistema di Jira \Sistema di TT,
contestualmente alla conferma della presa in carico, sia espressamente indicato il tempo entro cui
sarà consegnato il rispettivo documento di progettazione.
L'aggiudicatario è tenuto a consegnare la pianificazione e le note di rilascio delle evoluzioni normative
in coerenza con gli SLA previsti per la messa in produzione delle release / add.
13.5. Servizi per il miglioramento delle performance e dell’usabilità
Per i servizi in oggetto (Cap. 3.2), i livelli di servizio minimi che devono essere garantiti sono i
seguenti:
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
A1.2-1
Rispetto dei tempi diconsegna dei diversiaggiornamenti del sistemasecondo il piano
100% del rispetto dei tempiprevisti nei piani rilasciatidall’aggiudicatario
L’aggiudicatario dovrà rispettare ilpiano dei rilasci riportato nel piano peril miglioramento delle performance edella user experience
Casi rilevati < 4Casi rilevati di intervento chepeggiorano le performance e l'usabilitàsegnalati dall'amministrazione/DEC
Per quanto riguarda il calcolo dello SLA A1.2-1, si dovrà verificare se “il pronti al rilascio in
produzione” rispetta le date previste nel piano di progetto aggiornato trimestralmente.
L’aggiornamento del piano di progetto per il miglioramento delle performance e della user experience
non potrà prevedere ritardi del rilascio in produzione delle integrazioni, salvo cause non imputabili
all’aggiudicatario, pena l’applicazione delle penali previste nell’apposita sezione.
Tutto il processo di interventi per il miglioramento delle performance dovrà essere tracciato attraverso
il sistema Jira / sistema di TT. L'aggiudicatario è tenuto (con decorrenza dalla data di avvio della Fase
2 di cui al cap. 2.1) a garantire la registrazione dei dati degli interventi sul sistema Jira \Sistema di TT,
analogamente a quanto specificato per gli altri interventi di manutenzione.
13.6. Servizi di Manutenzione Evolutiva
I servizi (cap. 3.3) vengono attivati aprendo un ticket sul sistema Jira\Sistema di TT. La segnalazione
può essere fatta da utenti della Direzione Generale della Sanità o dalla Direzione dell’esecuzione del
contratto.
I livelli di servizio minimi che devono essere garantiti sono i seguenti:
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 107 di 135
A1.3-1Tempo di presa in caricodella richiesta di evoluzionedel software applicativo
<5 giorni lavorativi dallarichiesta nel 90% dei casi
<10 giorni lavorativi dallarichiesta nel restante 10%dei casi
A partire dalla data di richiesta dievoluzione del software applicativoviene misurato il tempo per la presain carico della richiesta stessa daparte dell’Aggiudicatario SISaR
A1.3-2Tempo di presentazione deldocumento di analisifunzionale relativo alla CR
<20 giorni lavorativi dallapresa in carico nel 90% deicasi
<30 giorni lavorativi dallapresa in carico nel restante10% dei casi
A partire dalla data di presa in caricodella richiesta di evoluzione delsoftware applicativo viene misurato iltempo per il rilascio della versionedel documento di analisi funzionale.Nel periodo dalla presa in carico alrilascio del documentol’Aggiudicatario potrà eventualmentechiedere approfondimenti necessariall’AmministrazioneAggiudicatrice\DEC\Utente
A1.3-3
Tempo di presentazione delpiano di sviluppo della CRcon descrizione delleiterazioni, cronoprogramma equantificazione economica
<10 giorni lavoratividall’approvazionedell’analisi funzionale nel90% dei casi
<15 giorni lavoratividall’approvazionedell’analisi funzionale nelrestante 10% dei casi
A partire dalla data di approvazionedel documento di analisi funzionaleviene misurato il tempo per il rilasciodel piano di sviluppo della CR condescrizione delle iterazioni,cronoprogramma e quantificazioneeconomica
A1.3-4
Avvio dell’esecuzione delpiano di sviluppo della CR aseguito dell’approvazionedella DEC
100% del rispetto delladata di avvio prevista perl’avvio dell’esecuzione
L’aggiudicatario dovrà rispettare ladata di avvio dell’esecuzione delleattività concordata in sede diapprovazione del piano di sviluppo.
A1.3-5
Rispetto delle milestone delpiano di sviluppo della CR edei tempi di rilascio dellesingole funzionalità resedisponibili per ogni iterazione
100% del rispetto dei tempiprevisti nei piani rilasciatidall’aggiudicatario
L’aggiudicatario dovrà rispettare lapianificazione approvata e dovràriportare nel piano per lamanutenzione evolutiva le milestoneseffettive di rilascio intermedie e inproduzione (pronti al rilascio inproduzione)
A1.3-6 Casi di test falliti nel collaudopreliminare
Percentuale di test falliti sutest effettuati <= 10%
Casi di test falliti durante la fase dicollaudo preliminare al rilascio dellefunzionalità, rispetto al numero di testeffettuati secondo il piano di test
Tutto il processo del singolo intervento di evoluzione, dalla richiesta fino alla effettiva messa in
produzione, dovrà essere tracciato attraverso il sistema Jira\Sistema di TT. L'aggiudicatario è tenuto
(con decorrenza dalla data di avvio della Fase 2 di cui al cap. 2.1) a garantire la registrazione dei dati
all’interno del sistema di ALM Jira, come specificato nel cap. 10 Strumenti di supporto.
Si consideri che il periodo di osservazione deve consentire di valutare gli SLA degli eventi accaduti
nel periodo. In particolare, oltre a prendere in considerazione le CR registrate nel periodo per il quale
si stanno calcolando gli SLA, è necessario anche prendere in considerazione le CR registrate in
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 108 di 135
periodi precedenti a quello in esame ma analizzate, valutate, prese in carico, chiuse, etc., nel periodo
in esame.
13.7. Servizi Specialistico-Applicativi
Il servizio (Cap. 3.4) viene attivato aprendo un ticket sul sistema Jira\Sistema di TT, attraverso una
chiamata ad un numero di telefono dedicato o attraverso invio mail ad indirizzo dedicato. La richiesta
dovrà essere comunque tracciata sul sistema Jira \Sistema di TT. La segnalazione può pervenire da
utenti della Direzione Generale della Sanità, dagli utenti delle Aziende Sanitarie, dalla Direzione
dell’esecuzione del contratto\SardegnaIT o dall’Aggiudicatario stesso.
I livelli di servizio minimi che devono essere garantiti sono i seguenti:
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
A1.4-1
Intervallo medio di presa incarico della richiesta disupporto specialistico-applicativo remoto
<8 ore lavorative nel90% dei casi
<16 ore lavorative nelrestante 10% dei casi
A fronte della richiesta di supportospecialistico - applicativo remoto vienemisurato il tempo medio per la presa incarico della richiesta stessa da partedell’Aggiudicatario SISaR
A1.4-2 Sostituzione del personale <2 risorse
Numero di sostituzioni unilateraliingiustificate dal punto di vistadell'esecuzione del contratto diSpecialisti di prodotto. Eventualisostituzioni finalizzate ad un migliorefunzionamento dei servizi/attività,purché preventivamente condivise eapprovate dai referentidell’Amministrazione, noncontribuiscono al conteggio. Eventualisostituzioni operate a fronte didimissioni / licenziamento di risorseimpegnate nell’erogazione dei servizinon contribuiscono al conteggio purchéopportunamente documentate.
Tutto il processo di supporto specialistico-applicativo remoto dovrà essere tracciato attraverso il
sistema Jira. L'aggiudicatario è tenuto (con decorrenza dalla data di avvio della Fase 2 di cui al cap.
2.1) a garantire che all’interno del sistema di ALM Jira, contestualmente alla conferma della presa in
carico, sia espressamente indicato il tempo entro cui sarà effettuata la
parametrizzazione/configurazione della soluzione applicativa.
13.8. Gestione ambiente applicativo di test
Il servizio (Cap. 3.5) viene attivato allorquando viene pubblicata la disponibilità di una nuova release /
patch / add. Non si applica per gli interventi correttivi.
I livelli di servizio minimi che devono essere garantiti sono i seguenti:
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 109 di 135
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
A1.5-1
Intervallo medio per la messa inesercizio in ambiente di test diuna nuova Patch/Add/NuovaRelease rilasciata
<10 giorni lavorativi nel90% dei casi
<20 giorni lavorativi nelrestante 10% dei casi
A fronte della comunicazione delladisponibilità di una patch/Add/nuovarelease viene misurato il tempomedio entro il quale il Team diApplication Operation la installa inambiente di test
I livelli di servizio devono essere calcolati dall’Aggiudicatario ed esposti alla DEC su tracciato a scelta
dell’Aggiudicatario dove compaiono le date di disponibilità della nuova patch/add/release ricavabili
nello strumento di pubblicazione della patch e la data di messa in esercizio nell’ambiente di test.
Il tracciamento degli interventi mediante il quale verranno calcolati gli SLA dovrà essere effettuato
attraverso il sistema Jira / Sistema di TT.
13.9. Gestione ambiente applicativo di produzione
Il servizio (Cap. 3.5) viene attivato allorquando la DEC, o l’aggiudicatario autonomamente, decide di
mettere in produzione una nuova release / add che ha superato i test nell’ambiente applicativo di test.
Non si applica per gli interventi correttivi.
I livelli di servizio minimi che devono essere garantiti sono i seguenti:
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
A1.5-2Rispetto dei tempi di preavvisorichiesti per interventi cheimplicano disservizi
=100% Questo SLA deve essere semprerispettato salvo diversaautorizzazione della DEC
A1.5-3
Intervallo medio per la messa inesercizio in ambiente diproduzione di una nuovaPatch/Add/Nuova Releaserilasciata
<20 giorni lavorativi nel90% dei casi
<25 giorni lavorativi nelrestante 10% dei casi
A fronte della verifica in test di unaNuova Release, ADD o di una Patchviene misurato il tempo medio entro ilquale il Team di ApplicationOperation la installa in ambiente diproduzione
A1.5-4
Tempo di disservizio per la messain esercizio di una nuovaPatch/Add/Nuova Release
<30 ore solari
Tempo complessivo di disserviziocausato da tutti i casi in cui èpossibile mettere in esercizio lanuova Patch/Add/Nuova Releaseutilizzando la modalità hot-deploy mail fornitore ha scelto una modalitàdifferente.
I livelli di servizio devono essere calcolati dall’Aggiudicatario ed esposti alla DEC su tracciato a scelta
dell’Aggiudicatario dove compaiono le date di decisione della messa in produzione / data di verifica
positiva in test e data di condivisione del piano operativo di rilascio.
Il servizio dovrà essere erogato nel rispetto dei vincoli e delle cautele sugli orari e sulla pianificazione
degli interventi già descritti nel Cap. 3.5.
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 110 di 135
Il tracciamento degli interventi mediante il quale verranno calcolati gli SLA dovrà essere effettuato
attraverso il sistema Jira / Sistema di TT.
13.10.Gestione sistemistico-applicativa
Per questo servizio (cap. 3.6), i livelli di servizio minimi rientrano nella casistica censita nella
manutenzione correttiva cioè i blocchi segnalati che saranno originati da non corretta gestione
sistemistico-applicativa saranno censiti come anomalia e saranno ricompresi nel calcolo di A1.1-1,
A1.1-2, A1.1-3, A.1.1-4.
Per quanto riguarda la componente di integrazione si riportano i livelli di servizio richiesti:
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
A1.6-1Tempo di risoluzionedall’insorgenza del blocco dellaintegrazione al suo riavvio
< 4 ore Questo SLA deve essere semprerispettato
A1.6-2
Disponibilità in produzione delmodulo per la compilazione delmodello 770 per l’annualità diriferimento
Numero massimo di errori sulDirezionale inerenti mancatocaricamento dei dati o erratocaricamento dei dati
< 5
Questo SLA deve essere semprerispettato. Gli utenti che utilizzano ildirezionale devono avere sempredisponibili i dati sul direzionalecaricati in maniera corretta. Lafrequenza minima di aggiornamentodegli indicatori di utilizzo è giornalieramentre quella dei vari data mart saràvariabile e stabilita dalla stazioneappaltante all’avvio del contratto.
Il tracciamento degli errori, mediante il quale verranno calcolati gli SLA, dovrà essere effettuato
attraverso il sistema di TT.
13.11.Help Desk
Il servizio (cap. 3.7) viene attivato mediante segnalazione telefonica all’operatore di help desk, il quale
prende in carico la richiesta provvedendo ad aprire un ticket sul sistema di Trouble Ticketing ed a
comunicare il numero di Ticket all’utente richiedente. La segnalazione può essere fatta da utenti della
Direzione Generale della Sanità, dagli utenti delle Aziende Sanitarie, dalla Direzione dell’esecuzione
del contratto o dall’Aggiudicatario stesso.
I livelli di servizio minimi che devono essere garantiti per quanto concerne l’efficienza di presa in
carico telefonica della richiesta sono i seguenti:
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 111 di 135
A1.7-1 Tempo di attesa netto
Il tempo diconnessione conl’operatore non devesuperare i 30secondi.
TT1 ≥ 90%.
Misura del tempo che intercorre tra larichiesta di contatto con l’operatore(ingresso della chiamata in assenza di IVR,oppure la digitazione della richiestanell’ambito della struttura dell’IVR),espressa secondo la formula_
TT1 = (CRO/CROT)*100
Dove CRO è il numero totale di chiamateche hanno richiesto un contatto conl’operatore e sono state connesse conl’operatore entro i tempi definiti, CROT è ilnumero totale di chiamate che hannorichiesto di essere connesse conl’operatore.
A1.7-2 Tempo di presa in carico dellarichiesta
< 10 min nel 95% deicasi
Viene misurato il tempo che intercorre dallaricezione della richiesta multicanale(telefono, mail, ecc.) alla presa in caricodella segnalazione
A1.7-3 Numero richieste riaperte < 5%Percentuale di richieste riaperte per casiimputabili all'aggiudicatario sul totale dellerichieste chiuse
I livelli di servizio minimi che devono essere garantiti per quanto concerne la risoluzione del problema
segnalato dall’Utente sono i seguenti:
Codice SLA DescrizioneIndicatore Valore soglia Descrizione
A1.7-4Tempo medio dirisoluzione dallapresa in carico
Entro 1 giorno lavorativo nel 70% dei casi
Entro 2 giorni lavorativi nel restante 30% dei casiErrori con livello di gravitàCNIPA 1
A1.7-5Tempo medio dirisoluzione dallapresa in carico
Entro 2 giorni lavorativi nel 70% dei casi
Entro 4 giorni lavorativi nel restante 30% dei casiErrori con livello di gravitàCNIPA 2
A1.7-6Tempo medio dirisoluzione dallapresa in carico
Entro 3 giorni lavorativi nel 70% dei casi
Entro 8 giorni lavorativi nel restante 30% dei casiErrori con livello di gravitàCNIPA 3
A1.7-7Tempo medio dirisoluzione dallapresa in carico
Entro 6 giorni lavorativi nel 70% dei casi
Entro 16 giorni lavorativi nel restante 30% dei casiErrori con livello di gravitàCNIPA 4
I livelli di servizio devono essere calcolabili autonomamente da parte della Direzione dell’Esecuzione a
partire dai dati riportati sul sistema di Trouble Ticketing (si veda cap. 10 Strumenti di supporto). Nel
sistema di Trouble Ticketing devono essere presenti gli eventuali tempi di ritardo causati dai tempi di
risposta degli utenti.
Tutte le attività di assistenza help desk, dalla segnalazione e apertura del ticket a seguito di
segnalazione telefonica fino alla risoluzione, dovranno essere tracciate attraverso lo strumento di
Trouble Ticketing che, in particolare, dovrà consentire la tracciabilità sia dei tempi complessivi che
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 112 di 135
vanno dalla segnalazione all’intervento risolutivo, sia anche di eventuali sospensioni dei termini in
attesa di riscontro alle richieste di chiarimenti/integrazioni effettuate verso l’utente.
Le tipologie di ticket registrate nello strumento di TT gestito dall’aggiudicatario prese in considerazione
per il calcolo degli SLA relativi alla manutenzione correttiva sono almeno le seguenti:
• Formazione Applicativa
• Richieste Evolutive
• In fase di analisi
• Assistenza Generica
• Supporto Tecnico Normativo
• Verifica su dati del DB.
13.12.Reperibilità H24 mission critical
Il servizio di reperibilità H24 (cap. 3.8) prevede che le segnalazioni di malfunzionamenti/guasti
relativamente ai sistemi coperti da tale servizio vengano avanzate direttamente dagli utenti ai numeri
telefonici di reperibilità specifici. Il tecnico reperibile di turno, cui viene indirizzata la singola
segnalazione telefonica di malfunzionamento/guasto, alla risposta sottopone all’utente chiamante le
richieste di informazioni utili a definire la problematica e attivare la gestione dell’intervento risolutivo e
dunque provvede alla conferma della rispettiva presa in carico.
Compiuto l’intervento, il tecnico reperibile provvede a confermare la chiusura del medesimo all’utente,
nonché a registrare successivamente sul sistema di trouble ticketing i dati dell’attività operata allo
scopo.
I livelli di servizio minimi che devono essere garantiti sono i seguenti:
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
A1.8-1
Tempo medio di intervento daremoto dalla presa in carico dellasegnalazione di malfunzionamentosu Infrastruttura Tecnologica e/oPronto Soccorso e/o TrasfusionaleSISaR nella fascia oraria direperibilità H24
<= 1 ora dalla presa incarico della segnalazionenel 90% dei casi
<= 4 ore dalla presa incarico della segnalazionenel restante 10% dei casi
A fronte della segnalazione dimalfunzionamento, nella fascia oraria direperibilità H24, su infrastrutturatecnologica e/o pronto soccorso e/otrasfusionale SISaR, viene misurato iltempo medio intercorrente tra la presa incarico della segnalazione medesima el’inizio delle attività di intervento daremoto
A1.8-2
Tempo medio di intervento in locodalla presa in carico dellasegnalazione di malfunzionamentosu Infrastruttura TecnologicaSISaR nella fascia oraria direperibilità H24
<= 4 ore dalla presa incarico della segnalazionenel 90% dei casi
<= 6 ore dalla presa incarico della segnalazionenel restante 10% dei casi
A fronte della segnalazione dimalfunzionamento, nella fascia oraria direperibilità H24, su infrastrutturatecnologica SISaR, viene misurato iltempo medio intercorrente tra la presa incarico della segnalazione medesima el’inizio delle attività di intervento in loco
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 113 di 135
I livelli di servizio devono essere calcolabili dalla DEC a partire dai dati riportati sul sistema di Trouble
Ticketing o su altro strumento. Considerato che in genere la segnalazione viene condivisa tramite
chiamata al numero telefonico di reperibilità, è onere e obbligo dell’aggiudicatario tracciare la
segnalazione sul sistema di Trouble Ticketing o altro strumento.
13.13.Realizzazione nuova infrastruttura interoperabilità
Il servizio (cap. 4.1) viene attivato a partire dal piano di progetto che l’aggiudicatario dovrà predisporre
coerentemente all’offerta tecnica presentata in sede di gara.
I livelli di servizio minimi che devono essere garantiti sono i seguenti:
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
A2.1-1
Rispetto dei tempi diinstallazione e attivazionedell’infrastruttura ESB/APIsecondo piano di progetto
100% del rispetto deitempi previsti nei pianirilasciatidall’aggiudicatario
L’aggiudicatario trimestralmente dovràaggiornare un piano delle attività in cuisono specificate le milestones di rilascio inproduzione (pronti al rilascio inproduzione)
Per quanto il calcolo dello SLA A2.1-1 si dovrà verificare se “il pronti al rilascio in produzione” rispetta
le date previste nel piano di progetto. L’aggiornamento del piano di progetto non potrà prevedere
ritardi del rilascio in produzione dell’infrastruttura, salvo cause non imputabili all’aggiudicatario, pena
l’applicazione delle penali previste.
13.14.Evoluzione e migrazione su nuova infrastruttura e disaccoppiamento funzionale
Il servizio (cap. 4.2) viene attivato a partire dal piano di progetto che l’aggiudicatario dovrà predisporre
coerentemente all’offerta tecnica presentata in sede di gara.
I livelli di servizio minimi che devono essere garantiti sono i seguenti (si veda anche SLA A.4.1-13 dei
servizi trasversali):
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
A2.2-1
Rispetto dei tempi dimigrazione delle integrazioniesistenti secondo piano diprogetto
100% del rispetto dei tempiprevisti nei piani rilasciatidall’aggiudicatario
L’aggiudicatario trimestralmente dovràaggiornare un piano della Evoluzione emigrazione su nuova infrastruttura edisaccoppiamento funzionale a corpoin cui sono specificate le milestones dirilascio in produzione (pronti al rilascioin produzione)
A2.2-2
Rispetto dei tempi di rilasciodelle nuove integrazionipresentate nel piano diprogetto
100% del rispetto dei tempiprevisti nei piani rilasciatidall’aggiudicatario
L’aggiudicatario trimestralmente dovràaggiornare un piano della Evoluzione emigrazione su nuova infrastruttura edisaccoppiamento funzionale a corpoin cui sono specificate le milestones dirilascio in produzione (pronti al rilascioin produzione)
A2.2-3 Casi di test falliti nel Percentuale di test falliti su Casi di test falliti durante la fase di
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 114 di 135
collaudo preliminare test effettuati <= 10% collaudo preliminare al rilascio dellefunzionalità, rispetto al numero di testeffettuati secondo il piano di test
Per quanto il calcolo dello SLA A2.2-1 e A2.2-2 si dovrà verificare se “il pronti al rilascio in produzione”
rispetta le date previste nel piano di progetto della manutenzione evolutiva per le integrazioni a corpo
aggiornato trimestralmente. L’aggiornamento del piano di progetto non potrà prevedere ritardi del
rilascio in produzione delle integrazioni, salvo cause non imputabili all’aggiudicatario, pena
l’applicazione delle penali previste.
13.15. Transizione verso il fornitore subentrante
Per il servizio in oggetto (Cap. 5.1) l’aggiudicatario è tenuto al rispetto dei tempi di consegna del piano
di transizione e al rispetto del medesimo secondo le tempistiche definite dall’Amministrazione
Aggiudicatrice.
Tutta la documentazione tecnica e i sorgenti aggiornati dovranno essere resi disponibili al nuovo
fornitore secondo le tempistiche richieste dall’Amministrazione Aggiudicatrice e che saranno previste
nel piano di transizione.
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
A3.1-1Tempo massimo di rilascio deldocumento riguardante il piano ditransizione
Secondo le tempistiche dicui al cap. 12
A conclusione della procedura diaggiudicazione della nuova gara, in casodi aggiudicatario diverso dal fornitoreattuale, lo stesso dovrà produrre unpiano di lavoro dettagliato
A3.1-2Tempo massimo di rilascio di tuttala documentazione aggiornata perla pubblicazione della gara
100% dei casi: tutta ladocumentazione tecnicacompleta ed i sorgenti adhoc e personalizzazioniche sarà consideratanecessaria per lapubblicazione della garadovrà essere rilasciataentro tre mesi dalla data dirichiesta
Per rendere disponibili tutte leinformazioni tecniche che consentano aipartecipanti alla nuova gara di poterpresentare le offerte tecniche eeconomiche, è necessario chel’Aggiudicatario condivida tutte le versioniaggiornate dei documenti e del codicesorgente dei software sviluppati ad hoc etutte le configurazioni eparametrizzazioni
A3.1-3 Rispetto delle milestones del pianodi transizione
<10 giorni lavorativi nel100% dei casi
A fronte delle milestones definite nelpiano di transizione approvatodall’Amministrazione Aggiudicatrice,l’Aggiudicatario dovrà rispettare le datedelle milestones
13.16.Program/Project/Service Management
I livelli di servizio minimi che devono essere garantiti per questo servizio (Cap. 6.1) sono i seguenti:
CodiceSLA Descrizione Indicatore Valore Soglia Descrizione
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 115 di 135
A4.1-1Tempo massimo di rilasciodel documento riguardantegli SLA trimestrali
100% dei casi
Entro il 20 del mese successivo al trimestre dirilevazione (cap. 13) dovrà essere inviato ildocumento con il calcolo degli SLA per ciascunservizio
A4.1-2
Tempo massimo diaggiornamento del portaledocumentazione su richiestadel DEC\SA
100% dei casi: tutti ideliverable riportati nelRapporto dei ServiziErogati o nel documento diSAL dovranno essereregistrati sul portaledocumentazione nellacartella riferita al bimestredi riferimento (servizi acorpo rendicontati acanone) o nel SAL (servizia misura e a corporendicontata a SAL) entro5 giorni lavorativi dalladata di richiestaaggiornamento del Portaledocumentazione
A conclusione di ciascun bimestre contrattuale dovràessere inviato il documento di Rapporto dei ServiziErogati (corpo-canone) e i deliverable in essoriportati dovranno essere inseriti nel portaledocumentazione. In caso di mancato inserimento diun deliverable l’Aggiudicatario è tenuto adottemperare alla richiesta di aggiornamento delportale entro 5 giorni lavorativi dalla data disegnalazione della DEC\SA. Analogamente nel casodi SAL.
A4.1-3Intervallo medio di rispostaalla richiesta di chiarimentida parte della DEC\SA
<15 giorni lavorativi nel90% dei casi
<30 giorni lavorativi nelrestante 10% dei casi
A fronte della richiesta di chiarimento da parte dellaDEC\SA l’Aggiudicatario dovrà provvedere arispondere secondo la tempistica media minimadefinita come soglia
A4.1-4Partecipazione alla verificatrimestrale SLA e riesamedel contratto
100%
Il contract manager, ilprogram manager, tutti iservice manager,dovranno partecipareobbligatoriamente dipersona presso laDirezione Generale dellasanità o comunque pressoun’altra sede localizzata inCagliari
Riunione trimestrale sull’andamento del progetto
A4.1-5Partecipazione a riunioni dilavoro, verifiche, raccolta deirequisiti utente
100%
Il program manager e iservice manager dovrannopartecipareobbligatoriamente dipersona alle riunioniconvocate con almeno unagiornata di anticipo che sisvolgeranno presso laDirezione Generale dellaSanità o comunque pressoun’altra sede localizzata inCagliari. Non sarannoconsiderate le assenzedovute a contemporaneaattività presso altri utenti eriguardanti i servizi oggettodella presente procedura
Riunione su convocazione dell’AmministrazioneAggiudicatrice ovvero della DEC
A4.1-6Consegna e aggiornamentodel piano di progettocomplessivo generale delcontratto, secondo le
100%L’Aggiudicatario deve consegnare e aggiornare ilpiano di progetto complessivo per i servizi delcontratto secondo le tempistiche di cui al cap. 12
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 116 di 135
tempistiche di cui al cap. 12
A4.1-7
Consegna e aggiornamentodel piano di qualità, matricedei rischi e documento dellaconfigurazione e standard diprogetto, secondo letempistiche di cui al cap. 12
100%
L’Aggiudicatario deve consegnare e aggiornare ilpiano di qualità, matrice dei rischi e documento dellaconfigurazione e standard di progetto, secondo letempistiche di cui al cap. 12
A4.1-8
Consegna e aggiornamentodel piano dellamanutenzione preventiva,secondo le tempistiche di cuial cap. 12
100%L’Aggiudicatario deve consegnare e aggiornare ilpiano della manutenzione preventiva secondoquanto previsto nel cap. 3.3 e nel cap. 12.
A4.1-9
Consegna e aggiornamentodel piano dellamanutenzione adeguativa eadattativa, secondo letempistiche di cui al cap. 12
100%L’Aggiudicatario deve consegnare e aggiornare ilpiano della manutenzione adeguativa e adattativasecondo quanto previsto nel cap. 3.3 e nel cap. 12.
A4.1-10
Consegna e aggiornamentodel piano per lamanutenzione perfettiva,secondo le tempistiche di cuial cap. 12
100%L’Aggiudicatario deve consegnare e aggiornare ilpiano per la manutenzione perfettiva, secondo letempistiche di cui al cap. 12
A4.1-11
Consegna e aggiornamentodel piano dellamanutenzione evolutiva,secondo le tempistiche di cuial cap. 12
100%L’Aggiudicatario deve consegnare e aggiornare ilpiano della manutenzione evolutiva secondo quantoprevisto nel cap. 3.3 e nel cap. 12.
A4.1-12
Consegna e aggiornamentodel piano per ilmiglioramento delleperformance e della userexperience, secondo letempistiche di cui al cap. 12
100%
L’Aggiudicatario deve consegnare e aggiornare ilpiano per il miglioramento delle performance e dellauser experience, secondo le tempistiche di cui alcap. 12
A4.1-13
Consegna e aggiornamentodel piano per la fornitura,installazione econfigurazione della nuovainfrastruttura di integrazionee per la migrazione edisaccoppiamento deimacrocomponenti delSISaR, secondo letempistiche di cui al cap. 12
100%
L’Aggiudicatario deve consegnare il piano per lafornitura, installazione e configurazione della nuovainfrastruttura di integrazione e per la migrazione edisaccoppiamento dei macrocomponenti del SISaR,secondo le tempistiche di cui al cap. 12
A4.1-14
Consegna dei risultati degliaudit dell’Ente Certificatore edel servizio interno perl’Assicurazione Qualità
100%
L’Aggiudicatario deve consegnare il risultato dei dueAudit annuali svolti dall’Ente Certificatore del sistemadi Qualità e interni del Servizio Aziendale perl’Assicurazione di qualità
A4.1-15 Rispetto scadenze temporalidei deliverable 0 giorni La data di consegna e la data prevista non devono
discostarsi
A4.1-16 Qualità delladocumentazione <2 documenti Numero di documenti rielaborati a seguito della
Numero di sostituzioni richieste dall'Amministrazioneper inadeguatezza secondo quanto specificato nelcap. 9
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 117 di 135
13.17.Formazione e affiancamento
Il servizio (Cap. 6.2) viene attivato a partire dal piano per la formazione proposto e accettato
dall’Amministrazione Aggiudicatrice.
I livelli di servizio minimi che devono essere garantiti sono i seguenti:
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
A4.2-1
Rilascio dei fogli dirilevazione soddisfazioneutente compilati e calcolodegli indici statistici
100% delle sessioni diformazione con ilrilascio dei foglicompilati disoddisfazione utente ecalcolo indici statistici
L’aggiudicatario dovrà proporre lacompilazione del foglio di feedback per larilevazione del grado di soddisfazionedell’utente e dovrà calcolare gli indicistatistici per ogni sessione di formazionesvolta. Si dovrà verificare se sono statirilasciati e ritirati i fogli di feedbackcompilati e se sono stati calcolati gli indicistatistici.
A4.2-2 Numero sessioni diformazioni erogate inparallelo
3 sessionicontemporanee
A richiesta dell'Amministrazione/DECdeve essere sostenibile avere un numerominimo di sessioni di formazionecontemporaneamente anche in sedidifferenti.
13.18.Livelli di servizio Sicurezza/GDPR
Per quanto concerne il rispetto della normativa sulla sicurezza e sulla protezione dei dati personali,
con particolare riferimento al GDPR, l’aggiudicatario dovrà rispettare i livelli di servizio minimi
rappresentati nella seguente tabella. È previsto che il sistema consegnato in fase di presa in carico
disponga delle funzionalità necessarie per assicurare il rispetto di questi SLA. In ogni caso,
l’aggiudicatario, nel periodo di acquisizione delle competenze (Fase 1), dovrà verificare la sussistenza
di questi requisiti e relazionare alla DEC. Nel caso si dovesse rilevare la necessità di adeguamento
del sistema, le relative modifiche potranno essere richieste ed effettuate attraverso il servizio di
manutenzione evolutiva a consumo. Naturalmente, anche tutte le variazioni dei sistemi sviluppate
dall’aggiudicatario nel corso dell’esecuzione del contratto dovranno rispettare gli stessi SLA.
Codice SLA Descrizione Indicatore Valore Soglia Descrizione
SICAPP1 Profilazione degli accessi inbase al ruolo 100% dei casi
Il sistema deve consentire di creare profili diautenticazione in base al ruolo rivestito(sistema di autorizzazione).
SICAPP2 Utilizzo di credenzialiuninominali 100% dei casi
L’aggiudicatario deve assicurarsi che ilsistema software consenta ad ogni operatoredi utilizzare credenziali uninominali (ossiadifferenti tra i singoli operatori).
SICAPP3 Autenticazione delle utenzetramite
100% casi Il sistema deve prevedere una autenticazionebasata su username e password, tramite
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 118 di 135
username/password, SPIDo CNS
SPID livello 2 o CNS\Tessera Sanitaria.
SICAPP4 Utilizzo di password sicure 100%
Il sistema deve prevedere i seguenti vincoliper la password:
Ha almeno 8 caratteri. Non è banale, ovvero non è soggetta ad
attacchi dizionario. Viene modificata dall’incaricato al primo
utilizzo. Viene modificata ogni 6 mesi o, in caso di
dati sensibili/giudiziari, ogni 3 mesi. Evita il riutilizzo di password
precedentemente utilizzate dallo stessoutente.
SICAPP5 Mascheratura della basedati 100%
Il sistema deve prevedere la possibilità dimodulare le informazioni alle quali si possaaccedere per singole attività.
SICAPP6 Encryption dei dati 100% Il sistema deve assicurare il corretto utilizzodel sistema di cifratura delle basi dati.
SICAPP7 Tracciatura degli accessi 100%
Il sistema deve memorizzare in un file di logtutti gli accessi degli operatori (sia gli accessiriusciti che quelli falliti). Dovrannomemorizzarsi, quindi, Data, ora, UID, esitologin (successo, fallito). I log devono essereconservati per almeno 6 mesi in manieracriptata.
SICAPP8 Tracciatura delle modifiche 100% Il sistema deve memorizzare in un file di logtutte le modifiche effettuate.
Il sistema deve garantire che nellecomunicazioni client/server siano utilizzatiprotocolli di comunicazione sicuri (es. SSH).
SICAPP10Archivi separati tra daticomuni e altre categorie didati
100%
Il sistema deve garantire la possibilità ditrattare in modo differente (anche con sistemidi mascheramento o cifratura differenziati) idati comuni e le altre categorie di dati.
L’aggiudicatario dovrà tempestivamenteinstallare le patch di sicurezza dei diversisoftware che utilizza quali DBMS, ESB, Java,SPAGIC, SPAGOBI, Sistema Operativo,etcove questo non abbia impatti sulla continuitàdel servizio o funzionamento dei sistemi.Dovrà procedere a condividere l’analisi degliimpatti e dei rischi sulla mancata installazionenel caso questa possa procurare deidisservizi.
SICAPP12 Programma di backup deidati 100%
L’aggiudicatario deve adempiere alle policy dibackup che verranno condivise all’avvio delcontratto.
SICAPP13 Programma di backup delleconfigurazioni 100%
L’aggiudicatario deve adempiere alle policy dibackup che verranno condivise all’avvio delcontratto.
SICAPP14 Protezione / cifratura dei 100% L’aggiudicatario dovrà assicurare che i
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 119 di 135
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A1.6-3
Numero massimo dierrori sul Direzionaleinerenti mancatocaricamento dei dati oerrato caricamento deidati
< 5
0,5 per milledell’importocontrattualeassociato allospecifico servizio perogni eventoeccedente la soglia
Nessuno
A1.7 - Servizio diHelp Desk
A1.7-1 Tempo di attesa netto
Il tempo di connessionecon l’operatore nondeve superare i 30secondi.
0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni puntopercentualeeccedente i valori disoglia
10
TT1 ≥ 90%.
A1.7-2 Tempo di presa in caricodella richiesta
< 10 min nel 95% deicasi
0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni puntopercentualeeccedente i valori disoglia
10
A1.7-3 Numero richieste riaperte < 5%
0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni puntopercentualeeccedente i valori disoglia
10
A1.7-4 Tempo di risoluzionedalla presa in carico
Entro 1 giorno lavorativonel 70% dei casi
0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni punto
10Entro 2 giorni lavorativinel restante 30% deicasi
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 125 di 135
percentualeeccedente i valori disoglia
A1.7-5 Tempo di risoluzionedalla presa in carico
Entro 2 giorni lavorativinel 70% dei casi
0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni puntopercentualeeccedente i valori disoglia
10Entro 4 giorni lavorativinel restante 30% deicasi
A1.7-6 Tempo di risoluzionedalla presa in carico
Entro 3 giorni lavorativinel 70% dei casi
0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni puntopercentualeeccedente i valori disoglia
10Entro 8 giorni lavorativinel restante 30% deicasi
A1.7-7 Tempo di risoluzionedalla presa in carico
Entro 6 giorni lavorativinel 70% dei casi
0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni puntopercentualeeccedente i valori disoglia
10Entro 16 giorni lavorativinel restante 30% deicasi
A1.8 - ReperibilitàH24 mission critical
A1.8-1
Tempo medio diintervento da remotodalla presa in carico dellasegnalazione dimalfunzionamento suInfrastruttura Tecnologicae/o Pronto Soccorso e/oTrasfusionale SISaRnella fascia oraria direperibilità H24
<= 1 ora dalla presa incarico dellasegnalazione nel 90%dei casi
0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni puntopercentualeeccedente i valori disoglia
5<= 4 ore dalla presa incarico dellasegnalazione nelrestante 10% dei casi
A1.8-2
Tempo medio diintervento in loco dallapresa in carico dellasegnalazione dimalfunzionamento suInfrastruttura TecnologicaSISaR nella fascia orariadi reperibilità H24
<= 4 ore dalla presa incarico dellasegnalazione nel 90%dei casi
0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni puntopercentualeeccedente i valori disoglia
5<= 6 ore dalla presa incarico dellasegnalazione nelrestante 10% dei casi
A2.1 - SistemaEnterprise ServiceBus
A2.1-1
Rispetto dei tempi diinstallazione e attivazionedell’infrastrutturaESB/API secondo pianodi progetto
100% del rispetto deitempi previsti nei pianirilasciatidall’aggiudicatario
Tra lo 0,3 e l'1 permille dell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Rispetto dei tempi dimigrazione delleintegrazioni esistentisecondo piano diprogetto
100% del rispetto deitempi previsti nei pianirilasciatidall’aggiudicatario
Tra lo 0,3 e l'1 permille dell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A2.2-2
Rispetto dei tempi dirilascio delle nuoveintegrazioni presentatenel piano di progetto
100% del rispetto deitempi previsti nei pianirilasciatidall’aggiudicatario
Tra lo 0,3 e l'1 permille dell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 126 di 135
A2.2-3 Casi di test falliti nelcollaudo preliminare
Percentuale di test fallitisu test effettuati <= 10%
0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni puntopercentualeeccedente i valori disoglia
10
A3.1 - Transizioneverso il fornitore/isubentrante/i
A3.1-1
Tempo massimo dirilascio del documentoriguardante il piano ditransizione
Secondo le tempistichedi cui al cap. 12
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A3.1-2
Tempo massimo dirilascio di tutta ladocumentazioneaggiornata per lapubblicazione della gara
100% dei casi: tutta ladocumentazione tecnicacompleta ed i sorgentiad hoc epersonalizzazioni chesarà consideratanecessaria per lapubblicazione della garadovrà essere rilasciataentro tre mesi dalla datadi richiesta
Tra lo 0,3 e l'1 permille dell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A3.1-3 Rispetto delle milestonesdel piano di transizione
<10 giorni lavorativi nel100% dei casi
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A4.1 - Program,Project e ServiceManagement
A4.1-1
Tempo massimo dirilascio del documentoriguardante gli SLAtrimestrali
100% dei casi
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A4.1-2
Tempo massimo diaggiornamento delportale documentazionesu richiesta del DEC\SA
100% dei casi: tutti ideliverable riportati nelRapporto dei ServiziErogati o nel documentodi SAL dovranno essereregistrati sul portaledocumentazione nellacartella riferita albimestre di riferimento(servizi a corporendicontati a canone) onel SAL (servizi amisura e a corporendicontata a SAL)entro 5 giorni lavoratividalla data di richiestaaggiornamento delPortale documentazione
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A4.1-3
Intervallo medio dirisposta alla richiesta dichiarimenti da parte dellaDEC\SA
<15 giorni lavorativi nel90% dei casi
0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni puntopercentualeeccedente i valori disoglia
Nessuno<30 giorni lavorativi nelrestante 10% dei casi
A4.1-4 Partecipazione alla 100% 0,5 per mille Nessuno
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 127 di 135
verifica trimestrale SLA eriesame del contratto
Il contract manager, ilprogram manager, tutti iservice manager,dovranno partecipareobbligatoriamente dipersona presso laDirezione Generaledella sanità o comunquepresso un’altra sedelocalizzata in Cagliari
dell’importocontrattualeassociato allospecifico servizio perogni eventoeccedente la soglia
A4.1-5
Partecipazione a riunionidi lavoro, verifiche,raccolta dei requisitiutente
100%
0,5 per milledell’importocontrattualeassociato allospecifico servizio perogni eventoeccedente la soglia
Nessuno
Il program manager e iservice managerdovranno partecipareobbligatoriamente dipersona alle riunioniconvocate con almenouna giornata di anticipoche si svolgerannopresso la DirezioneGenerale della Sanità ocomunque pressoun’altra sede localizzatain Cagliari. Non sarannoconsiderate le assenzedovute acontemporanea attivitàpresso altri utenti eriguardanti i servizioggetto della presenteprocedura
A4.1-6
Consegna eaggiornamento del pianodi progetto complessivogenerale del contratto,secondo le tempistiche dicui al cap. 12
100%
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A4.1-7
Consegna eaggiornamento del pianodi qualità, matrice deirischi e documento dellaconfigurazione estandard di progetto,secondo le tempistiche dicui al cap. 12
100%
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A4.1-8
Consegna eaggiornamento del pianodella manutenzionepreventiva, secondo letempistiche di cui al cap.12
100%
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A4.1-9
Consegna eaggiornamento del pianodella manutenzioneadeguativa e adattativa,secondo le tempistiche dicui al cap. 12
100%
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A4.1-10
Consegna eaggiornamento del pianoper la manutenzioneperfettiva, secondo letempistiche di cui al cap.12
100%
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A4.1-11
Consegna eaggiornamento del pianodella manutenzioneevolutiva, secondo letempistiche di cui al cap.
100%
0,3 per milledell’importocontrattualeassociato allaspecifica attività, per
Nessuno
PRESIDÈNTZIAPRESIDENZA
Direzione generale della Centrale regionale di committenzaServizio forniture e servizi
Capitolato speciale, descrittivo e prestazionalePagina 128 di 135
12 ogni giorno di ritardo
A4.1-12
Consegna eaggiornamento del pianoper il miglioramento delleperformance e della userexperience, secondo letempistiche di cui al cap.12
100%
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A4.1-13
Consegna eaggiornamento del pianoper la fornitura,installazione econfigurazione dellanuova infrastruttura diintegrazione e per lamigrazione edisaccoppiamento deimacrocomponenti delSISaR, secondo letempistiche di cui al cap.12
100%
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A4.1-14
Consegna dei risultatidegli audit dell’EnteCertificatore e delservizio interno perl’Assicurazione Qualità
100%
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A4.1-15 Rispetto scadenzetemporali dei deliverable 0 giorni
0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo
Nessuno
A4.1-16 Qualità delladocumentazione <2 documenti
0,5 per milledell’importocontrattualeassociato allospecifico servizio perogni eventoeccedente la soglia