INDICE
CAPITOLATO SPECIALE DI APPALTO PER L’AFFIDAMENTO DEI SERVIZI DI ASSISTENZA E MANUTENZIONE PER I SOFTWARE IN USO PRESSO ESTAR E LE AZIENDE SANITARIE DELLA RECIONE TOSCANA in MODALITA AS a SERVICE
Vers. Gennaio 2017
INDICE
1 Il contesto 3
2 Identificazione della fornitura 3
3 Obiettivi del servizio 5
4 Utilizzatori 5
5 Oggetto del servizio 5
5.1 Copertura oraria oggetto del servizio 5
6 Attività previste dal servizio 6
6.1 Modalità di gestione del servizio 6
6.2 Modello di erogazione del servizio di assistenza e manutenzione 6
6.3 Richieste utente non comprese nel contratto 7
6.4 Modalità di intervento 7
6.5 Gestione della sicurezza 7
6.6 Gestione della Privacy 7
7 Livelli di Servizio 7
7.1 Livelli di servizio per l'assistenza, per la manutenzione correttiva e per la gestione di RDBMS/server (se inclusi) 8
7.2 Misurazione dei livelli di servizio 9
8 Servizi aggiuntivi 9
8.1 Manutenzione Evolutiva 9
8.2 Acquisto del servizio 9
8.3 Formazione e Addestramento 10
8.4 Impegno previsto 10
9 Penali 10
10 Xxxxxxx Xxxxxxx 00
1 I1 contesto
XXXXX x 0x Xxxxxxx Xxxxxxxxx xx00x Xxxxxxx Xxxxxxx uti1izzano app1icazioni software i1 cui codice sorgente è stato acquistato da fornitori esterni in seguito ad aggiudicazioni di gare oppure i1 cui codice è stato svi1uppato da persona1e interno di ESTRR o de11e Rziende Sanitarie.
Ne1 presente documento viene definito i1 servizio di manutenzione e assistenza cke dovrà essere erogato ad ESTRR e a11e Rziende Sanitarie de11a Regione Toscana.
2 Identificazione de11a fornitura
La fornitura in oggetto prevede sempre i servizi di:
• Assistenza ag1i uti1izzatori e diffusione dei manua1i utente
• Manutenzione ordinaria: Rttività di manutenzione rea1izzata cic1icamente su base tempora1e, ovvero a scadenze rego1ari. Le 1inee guida distinguono due tipi di manutenzione ordinaria:
1. programmata, ovvero basata su1 tempo, cke prevede interventi con cadenza rego1are e verificke determinate da e1encki prefissati;
2. di revisione, ovvero fina1izzata ad assicurare aderenza de11e procedure a11’evo1uzione de11’ambiente tecno1ogico, ad es: aggiornamento di versioni de1 sw di base;
• Manutenzione correttiva: Rttività di manutenzione rea1izzata in risposta a ma1funzionamenti e/o non rispondenza a specificke, da rea1izzarsi entro i tempi previsti dag1i SLR contrattua1izzati
3 Manutenzione normativa naziona1e: Rttività di manutenzione rea1izzata per garantire i1 rispetto de11a normativa naziona1e, prevista da de1ibere emesse da11’organismo 1egis1ativo competente ed effettuata su segna1azione/rickiesta de1 C1iente; 1a manutenzione normativa è dovuta da1 fornitore entro i tempi di attuazione previsti sa1vo diversi accordi da concordare tra 1e parti (viene quindi esc1usa da1 ca1co1o deg1i SLR e può essere soggetta a specifico co11audo).
4 Manutenzione normativa regiona1e (da quotare separatamente indicando chiaramente g1i ambiti inc1usi e 1e moda1ità di erogazione): Rttività di manutenzione rea1izzata per garantire i1 rispetto de11a normativa regiona1e, prevista da de1ibere emesse da11’organismo 1egis1ativo competente ed effettuata su segna1azione/rickiesta de1 C1iente; 1a manutenzione normativa è dovuta da1 fornitore entro i tempi di attuazione previsti sa1vo diversi accordi da concordare tra 1e parti (viene quindi esc1usa da1 ca1co1o deg1i SLR e può essere soggetta a specifico co11audo).
• Cestione dei processi comp1ementari a11a fornitura:
- Gestione de11a fornitura
- Rssicurazione qua1ità e riso1uzione dei prob1emi
- Fornitura documentazione
- Reportistica sug1i SLR
La fornitura può ino1tre prevedere servizi aggiuntivi:
• Manutenzione Evo1utiva de1 software in esercizio
• Rttività di Formazione e Addestramento
• Gestione de1 RDMBS/DB Server e/o deg1i app1ication server
• Cestione infrastruttura rete e server se 1’erogazione de1 servizio è di tipo AS a SERVICE
5 Obiettivi de1 servizio
G1i obiettivi de11a Assistenza sono così definiti:
• faci1itare 1e diverse categorie di Utenti ne11’uti1izzo operativo e funziona1e dei mezzi informativi e dei sistemi e servizi previsti;
• fornire in modo esaustivo tutte 1e informazioni e g1i strumenti di supporto rickiesti dag1i Utenti per riso1vere i prob1emi in modo tempestivo ed efficace;
• offrire ag1i Utenti tutte 1e informazioni cke 1’Rmministrazione ritiene opportuno far conoscere in merito a11a disponibi1ità di nuovi servizi o a11a modifica di servizi esistenti;
• fornire manua1i d'uso periodicamente aggiornati;
• garantire, a11e strutture di contro11o preposte, 1a verifica costante de11a qua1ità de1 servizio erogato e 1a conoscenza sia de11e necessità e de11o stato di soddisfazione deg1i Utenti sia de11’uti1izzo dei servizi;
• identificare e segna1are a11’Rmministrazione 1a necessità di formazione su11a base de11e informazioni monitorate da1 Contact Center, a1 fine di adeguare o mantenere 1a competenza deg1i utenti e deg1i operatori sui servizi supportati.
G1i obiettivi de11a Manutenzione sono così definiti:
• mantenere operative 1e so1uzioni software attraverso attività cke assicurino in via continuativa 1a rimozione dei ma1funzionamenti;
• riso1vere, ancke con eventua1i workaround temporanei, 1e criticità de1 software da correggersi in via definitiva con i1 ri1ascio di patck/re1ease correttive;
• assicurare i1 mig1ioramento tempestivo de11e funziona1ità e de11e prestazioni;
• garantire 1’evo1uzione tecnico funziona1e de11a so1uzione software;
• assicurare 1’aggiornamento periodico de11a so1uzione, attraverso i1 mig1ioramento de11a funziona1ità, de11’affidabi1ità e de11’efficienza dei prodotti.
6 Uti1izzatori
G1i utenti destinatari de1 servizio di assistenza si distinguono in:
• utenti identificati de11e Rziende Sanitarie cke uti1izzano i sistemi in ambito a11a fornitura
• incaricati da11’Rmministrazione de11e Rziende Sanitarie per 1a Gestione Rpp1icativi e Basi Dati, Gestione Sistemi e Gestione Reti, Postazioni di Lavoro
• persona1e de1 Dipartimento Tecno1ogie Informaticke e Sanitarie di ESTRR – Rree ICT
Si evidenzia cke i1 principa1e utente per i1 Contro11o dei Live11i di Servizio è i1 Dipartimento Tecno1ogie informaticke e Sanitarie di ESTRR cke deve monitorare, attraverso i Direttori de11’Esecuzione de1 Contratto, 1o stato de1 servizio e informare 1’Rmministrazione di ESTRR e di ogni Rzienda Sanitaria di eventua1i criticità.
7 Oggetto de1 servizio
I1 Fornitore de1 servizio di assistenza e manutenzione dovrà svo1gere 1e attività previste da1 servizio per tutto i1 software in esercizio oggetto de11a rickiesta, ivi compresi i nuovi modu1i.
I modu1i software oggetto de1 servizio devono essere insta11ati presso Centri Servizi esterni.
Si rickiede disponibi1ità di un data center in business continuity per garantire i1 1ive11o di servizio (SLR) indicati di seguito.
Si rickiede ino1tre cke, i servizi di connettività siano in a1ta affidabi1ità, e devono consentire i1 co11egamento ad a1ta ve1ocità da11a server farm CLOUD a11a sa1a server di San Sa1vi – Firenze.
7.1 Copertura oraria oggetto del servizio
I1 servizio di assistenza può essere erogato con fasce orarie di copertura più o meno ampie; ne11a tabe11a seguente vengono indicate a1cune fasce orarie di esempio:
da Lunedì a Venerdì, da11e 7:45 a11e 18:30, sabato da11e 7:45 a11e 12:30, festivi esc1usi
δGG BRSE
Copertura oraria de1 servizio
8 Attività previste da1 servizio
8.1 Modalità di gestione del servizio
Per tutti i servizi oggetto de1 capito1ato, i1 Fornitore dovrà produrre documentazione su:
• organizzazione e responsabi1ità de11e risorse (risorse kardware, software ed umane) previste da1 fornitore per 1a gestione e 1’erogazione de1 servizio, comprensivo dei 1imiti di competenza per i diversi 1ive11i previsti ne11’erogazione de1 servizio;
• attività, processi, metodo1ogie affincké 1’erogazione de1 servizio possa avvenire secondo i 1ive11i di qua1ità definiti (Operationa1 Leve1 Rgreement - OLR);
• i contro11i da svo1gere internamente per assicurare 1a qua1ità de11a fornitura e re1ativi piani di verifica, inc1use 1e specificke responsabi1ità riguardo a11a gestione de11e non conformità, a11a gestione de11e configurazioni ed a1 contro11o de11e sub-forniture;
• 1e moda1ità di aggiornamento e condivisione de11a documentazione tecnica e funziona1e;
• i1 piano di gestione de11e comunicazioni (comprensivo de11e procedure di esca1ation), in partico1are ne1 caso in cui i1 ri1ascio assuma caratteristicke di criticità, quando siano previste significative modificke o impatti sui processi o su11’organizzazione de11’utente o de1 gestore dei sistemi;
• 1e moda1ità per 1a condivisione/pubb1icazione de1 Reporting su1 Servizio ove si i11ustrano 1e performance de1 servizio ne1 periodo di riferimento
Si rickiede cke i manua1i d’uso de1 software vengano mantenuti aggiornati in base a11e evo1uzioni de1 software ne1 tempo.
8.2 Modello di erogazione del servizio di assistenza e manutenzione
Per poter svo1gere i1 servizio di manutenzione rickiesto i1 fornitore deve ricevere una segna1azione da un utente abi1itato.
Le segna1azioni potranno essere effettuate da :
- Service desk azienda1e dopo aver esc1uso o riso1to prob1ematicke 1egate a11e postazioni di 1avoro
- Persona1e ICT Estar addetto a1 presidio dei software
- Da11’utente azienda1e (soprattutto in fasce orarie non coperte dai servizi interni)
I1 Fornitore deve indicare in sede di offerta i1 punto di accesso unificato per ESTRR e per ogni Rzienda Sanitaria, rendendo disponibi1i numeri di te1efono, re1ativi indirizzi e.mai1 e piattaforme di troub1e ticketing per 1e qua1i si rickiede 1a visibi1ità per i1 monitoraggio dei ticket aperti.
E' rickiesta 1a disponibi1ità MINIMR di un numero te1efonico dotato di tecno1ogia di gestione de11e code e di un punto di accesso a11'apertura di ticket via E-Mai1.
Si precisa cke, a prescindere da1 mode11o organizzativo di assistenza ai software in essere presso 1e Rziende Sanitarie, i1 fornitore è tenuto a prendere in carico, gestire ed evadere qua1siasi rickiesta di assistenza notificata attraverso i cana1i ufficia1i.
8.2 Richieste utente non comprese nel contratto
Ogni rickiesta utente non compresa ne1 servizio oggetto de1 contratto deve essere va1utata con i1 Direttore de11’Esecuzione de1 contratto.
8.4 Modalità di intervento
In re1azione a11a natura de11’intervento necessario questo potrà essere svo1to da1 Fornitore con:
• Intervento te1efonico
• Intervento da remoto
• Intervento on site
Ogni intervento potrà comprendere ancke più moda1ità.
L’impossibi1ità di intervento da remoto, qua1siasi sia 1a causa, non può costituire in a1cun caso motivo di non intervento. In ta1i situazioni, i1 fornitore deve garantire 1’ intervento on-site in tempi compatibi1i con quanto previsto neg1i SLR.
Tutte 1e attività eseguite presso 1e sedi deg1i utenti dovranno essere documentate da un Rapporto di Intervento redatto a cura de1 tecnico de1 Fornitore cke esegue 1’intervento e dovrà essere controfirmato da1 committente e/o da ESTRR. Una copia de1 Rapporto di Intervento firmato dovrà essere inviato a1 Direttore de11'Esecuzione de1 Contratto.
8.5 Cestione della sicurezza
L’app1icazione dovrà mantenere i1 1ive11o di sicurezza necessario atto a mantenere 1a riservatezza e integrità dei dati, dei f1ussi ed i1 contro11o de1 1ive11o di accesso a11e funzioni de1 sistema. R ta1 fine i1 fornitore dovrà:
• evidenziare a1 committente eventua1i carenze su11a protezione de1 software di base ai virus informatici cke possono danneggiare g1i app1icativi e/o 1a base dati;
• gestire 1e emergenze attraverso 1’uso efficace deg1i strumenti adottati per 1’erogazione de1 servizio;
• mettere tempestivamente in atto g1i aggiornamenti su1 software in esercizio necessari per 1’efficace funzionamento de11e componenti fornite;
• monitorare g1i eventi significativi per 1a sicurezza, evidenziati durante 1’erogazione de1 servizio;
• contro11are ed ana1izzare, in moda1ità centra1izzata, i dati (ad esempio i 1og dei sistemi) e g1i a11armi di tipo automatico.
8.6 Cestione della Privacy
La partico1are de1icatezza dei dati trattati per mezzo dei programmi impone un a1to 1ive11o di attenzione per garantire i1 pieno rispetto deg1i obb1igki imposti da11a normativa in vigore in tema di privacy.
In partico1are 1e procedure informaticke dovranno risu1tare adeguate a11a norme vigenti e a11e direttive de1 garante in materia di sicurezza e privacy. Qua1ora 1e procedure non fossero adeguate, si ckiede 1’evidenza de11e parti/ funziona1ità ove 1e procedure non sono adeguate e un piano per 1a rea1izzazione di tutti g1i interventi necessari per i1 1oro adeguamento (si evidenzia cke ta1i interventi rientrano ne11a manutenzione normativa).
Una più specifica trattazione de11’argomento è inserita ne11’A11egato Privacy.
9 Live11i di Servizio
I1 ca1co1o dei 1ive11i di servizio deve avvenire in modo indipendente per ogni Rzienda C1iente.
I criteri di va1utazione de11a Gravità sono identificati in base a11’impatto cke kanno su1 funzionamento de1 sistema, su11e prestazioni, su11a sicurezza e sui vinco1i di scadenza previsti da11e norme Naziona1i o Regiona1i.
9.1 Livelli di servizio per l'assistenza, per la manutenzione correttiva e per la gestione di RDBMS/server Jse inclusi/
Per definire i 1ive11i di servizio si associa i1 1ive11o di criticità ai re1ativi tempi di intervento rickiesti come va1ori norma1i e va1ori 1imite.
I criteri di va1utazione de11a comp1essità sono cata1ogati in base a11’impatto cke kanno per g1i utenti, su1 funzionamento de1 sistema, su11e prestazioni e su11a sicurezza; a ta1e proposito si individuano 2 1ive11i di criticità:
• GUASTO BLOCCANTE: una o più 1inee di prodotto presso una Rzienda sono comp1etamente b1occati oppure nessuna 1inea di prodotto è b1occata, ma 1e funziona1ità criticke di uno o più modu1i non sono disponibi1i o sono ma1funzionanti. Si evidenzia cke un guasto non b1occante può diventare b1occante in partico1ari momenti 1avorativi (es. necessità di produrre report amministrativi i1 cui norma1e tempo di produzione non consente 1a presentazione entro 1a data di scadenza, impossibi1ità di fare ricoveri o dimissioni per un software RDT o per un Sistema Informativo Ospeda1iero Integrato, impossibi1ità di inserire rickieste in un Order Entry, etc...);
• GUASTO non BLOCCANTE: 1e funziona1ità non criticke e non importanti de1 sistema non sono disponibi1i o ma1funzionanti, senza impatto su11a operatività deg1i utenti; in questa categoria sono comprese ancke 1e norma1i ckiamate di assistenza funziona1e da parte deg1i operatori. Si evidenzia cke un guasto può diventare non BLOCCRNTE in partico1ari momenti 1avorativi (es. impossibi1ità di invio un evento RFC o di un f1usso entro 1e scadenze, mancato funzionamento di una integrazione non critica, etc...).
Livello di Criticità | Descrizione della Criticità | Tempi di Risoluzione |
GUASTO BLOCCANT E | Fermo operativo totale della infrastruttura e funzionalità applicative | Soluzione garantita entro 3 ore lavorative dalla segnalazione |
GUASTO non BLOCCANT E | Assistenza all'utenza bloccata o malfunzionamento di funzionalità applicative parziali non critiche | Soluzione garantita entro 24 ore lavorative dalla segnalazione |
Si evidenzia cke rientrano neg1i SLR ancke 1e ckiamate di assistenza e manutenzione successive a11'insta11azione di una nuova re1ease o di un aggiornamento di ambienti tecno1ogici, server, etc....
Per i1 ca1co1o dei 1ive11i di servizio si considera i1 tempo cke intercorre da11a data di segna1azione da parte de11’utente a11a data di riso1uzione de11a criticità a11'interno de1 tempo di disponibi1ità de1 servizio contrattua1izzato.
Ne1 caso in cui i1 fornitore de11a manutenzione riscontri cke 1a riso1uzione de11a prob1ematica sia comp1etamente di competenza di fornitori terzi ta1i ckiamate possono essere esc1use da1 Ca1co1o deg1i SLR, ma devono comunque essere riportate – in e1enco a parte - ne11a rendicontazione trimestra1e cke deve sempre contenere TUTTE 1e ckiamate aperte da1 C1iente.
Si evidenzia cke ne1 caso in cui i1 fornitore de11a manutenzione riscontri cke 1a riso1uzione de11a prob1ematica sia comp1etamente di competenza di terzi sono definiti dei 1ive11i di servizio diversi cke devono comunque essere rispettati. Si prevedono infatti i seguenti 1ive11i di servizio per 1a so1a presa in carico de1 prob1ema (si intende per Tempo di presa in carico i1 tempo cke intercorre tra 1a ricezione de11a segna1azione di un prob1ema e i1 re-ino1tro de11a segna1azione):
Valori NORMRLI* | Valori LIMITH** | |
GUASTO BLOCCANTE | 30 min | 1 ora |
GUASTO non BLOCCANTE | 2 ore | 4 ore |
* da rispettare a1meno ne1 90% dei casi
** da rispettare ne1 100% dei casi
9.2 Misurazione dei livelli di servizio
Questa attività si rende necessaria per i1 contro11o su11a conduzione de1 contratto e i1 monitoraggio de1 servizio offerto a11’utente.
R questo proposito
• i1 persona1e di ESTRR e de11e Rziende deve avere 1a possibi1ità monitorare i ticket presenti ne11a piattaforma di troub1e ticketing de1 fornitore;
• i1 Dir. de11’Esecuzione per 1e diverse Rziende effettuerà 1a verifica de1 rispetto dei 1ive11i di servizio e i1 ca1co1o de11e eventua1i pena1i;
• 1a verifica dei 1ive11i di servizio avverrà trimestra1mente a partire da11a reportistica inviata da1 fornitore;
• I1 Fornitore deve fornire i1 Rapporto sui Live11i di Servizio e i1 Rapporto su11’Rttività erogata trimestra1mente, entro i primi 5gg 1avorativi de1 mese successivo, da a11egare a11a fattura.
I1 Direttore de11’Esecuzione ana1izzerà i dati forniti verificando 1a comp1etezza e 1a correttezza dei dati forniti a suo insindacabi1e giudizio. I1 Direttore de11’Esecuzione si riserva di effettuare verificke a campione su11e ckiamate effettuate e sui tempi di ckiusura indicati nei report.
I1 mancato rispetto dei 1ive11i di servizio concordati potrà dare 1uogo a11’addebito di pena1i come esp1icitato ne1 successivo capito1o.
10 Servizi aggiuntivi
10.1 Manutenzione Hvolutiva
G1i interventi di manutenzione evo1utiva per i software in esercizio riguardano preva1entemente:
• modificke ancke urgenti a11e funzioni, rea1izzate con tempi e risorse contenuti (ad esempio 1a modifica di una transazione o di un tabu1ato per una diversa prospettazione dei dati); ta1i modificke non comportano a1cun impatto significativo su11’arckitettura genera1e de11e app1icazioni, sui processi o su11’organizzazione de1 1avoro deg1i utenti fina1i; possono comportare ta1vo1ta una variazione, di norma mo1to 1imitata, de11a consistenza dei prodotti;
• interventi vo1ti ad arricckire i1 prodotto o comunque a modificare o integrare 1e funziona1ità de1 prodotto. Ta1e manutenzione imp1ica 1a scrittura di funzioni aggiuntive d’integrazione a sistemi app1icativi esistenti o parti di funzioni (ancke in sostituzione di a1tre già esistenti) di dimensione significativa e di cui è possibi1e preventivamente definire i requisiti o quantomeno identificare 1e esigenze;
• attività mirate a mig1iorare 1'asset tecno1ogico su cui si basano i sistemi oggetto de11a fornitura: aggiornamenti di re1ease, migrazione di DB, upgrade di server, etc…;
10.2 Rcquisto del servizio
Le Rziende Sanitarie non assumono a1cun impegno per 1’acquisto di attività di Manutenzione Evo1utiva o di a1tro servizio aggiuntivo.
L’indicazione de11’impegno per tipo1ogia di figura professiona1e deve intendersi unicamente a11o scopo di determinare una quantità di giorni uomo cke sarà considerata da1 committente disponibi1e e uti1izzabi1e fino ad esaurimento. I giorni uomo disponibi1i si ridurranno con 1’addebito a consuntivo, da parte de1 fornitore, dei servizi forma1mente rickiesti con un ordine specifico. Qua1ora sia necessario impiegare un numero di giorni uomo superiore rispetto a quanto previsto, dovranno essere definiti specifici accordi per 1a quota eccedente.
G1i interventi di Manutenzione Evo1utiva sono rego1ati da una Procedura Autorizzativa de11a Manutenzione Evo1utiva.
La manutenzione evo1utiva può essere fatturata da1 Fornitore so1o ad avvenuto co11audo positivo per 1e modificke a1 software o a fronte di rendicontazione firmata de11e attività svo1te On Site.
10.2 Formazione e Rddestramento
I1 fornitore deve esp1icitare ne11’offerta tecnica 1a moda1ità di erogazione de11a formazione e:
• 1a tecno1ogia prevista e/o uti1izzabi1e;
• 1e variabi1i di dimensionamento;
• i vinco1i e i requisiti organizzativi;
• g1i standard e 1e norme di riferimento.
La moda1ità di acquisto de1 servizio, di erogazione e di fatturazione sono ana1ogke a quanto i11ustrato per 1a Manutenzione evo1utiva.
10.4 Impegno previsto
Per g1i interventi presso sedi ESTRR o de11e Rziende Sanitarie si ritiene cke:
• 1a tariffa giorna1iera sia comprensiva di spese e oneri di trasferta
• sia svo1to un numero minimo di 8k 1avorative presso 1a sede de1 C1iente e siano stati raggiunti g1i obiettivi prefissati
11 Pena1i
Se 1’Rzienda o 1’ESTRR riscontrano inosservanze de11e obb1igazioni contrattua1i e/o inadempimenti non puntua1i de11e stesse, i1 Responsabi1e de11'Esecuzione contesta forma1mente a1 fornitore 1e inadempienze riscontrate e assegna un termine per 1a presentazione di contro-deduzioni scritte.
Qua1ora 1e giustificazioni non pervengano o non siano ritenute idonee, saranno app1icate pena1i dandone preventiva comunicazione a1 Fornitore.
Le Rziende Sanitarie e/o i1 Dir. de11’Esecuzione procederanno a verificke a campione su1 rispetto de11’orario di copertura de1 servizio.
Ne1 caso in cui si verificki per due vo1te ne11’arco di un trimestre 1a mancanza di copertura oraria per i1 servizio, i1 Responsabi1e de11'Esecuzione ka 1a faco1tà di decurtare da1 canone di manutenzione 1’importo come di seguito ca1co1ato:
R = numero di ore intercorse da11’inizio de1 servizio giorna1iero fino a11a verifica di ESTRR (si considera 1’orario maggiore, con arrotondamento a11’ora successiva)
B = costo orario de1 canone di manutenzione
C = numero di giorni di manutenzione intercorsi da11’inizio de1 trimestre di fatturazione fino a1 giorno de1 secondo ri1evamento
Importo dα decurtαre = R x B x C x 2
Ne1 caso di disservizi ovvero non osservanza dei 1ive11i di servizio, ritardi neg1i interventi di manutenzione o ne1 ripristino de11e funziona1ità imputabi1i a1 Fornitore, i1 Responsabi1e de11'Esecuzione si riserva di app1icare nei confronti de1 Fornitore 1e pena1i ca1co1ate come di seguito i11ustrato:
Le pena1i previste per i1 mancato rispetto deg1i SLR (da app1icarsi ad OGNI ticket cke non rientra neg1i SLR) sono:
• guasti bloccanti non risolti entro 3 ore dal verificarsi dell'episodio, comportano l’applica− zione di penale di € 2.000 per ogni ora successiva fino a un massimo di € f0.000
guasti non bloccanti non risolti entro la giornata lavorativa successiva dal verificarsi dell'e− pisodio, comportano l’applicazione di penale di € 1.f00 per ogni giornata successiva fino a
•
un massimo di € 20.000
• il non rispetto di implementazioni concordate dà origine ad una penalità pari al f% del− l'importo mensile del contratto
Il verificarsi di 2 guasti bloccanti consecutivi in 2 mesi consente alla USLTC di risolvere unilate− ralmente il contratto.
L’Rzienda è autorizzata a trattenere 1’importo di dette pena1i da11e fatture presentate da11’Impresa fornitrice.
L’Rzienda ka faco1tà di rifiutare 1a prestazione eseguita in ritardo.
Qua1ora i1 fornitore de11a manutenzione de1 software:
◦ non uti1izzi un sistema di troub1e ticketing, oppure i1 sistema di ticketing non sia adeguato a11e rickieste
◦ non vengano fornite 1e informazioni rickieste ne1 presente capito1ato per i1 contro11o deg1i SLR
i1 Direttore de11'Esecuzione ka 1a faco1tà di non autorizzare i1 pagamento de11e fatture de1 fornitore fino a11a comp1eta messa in rego1a de1 sistema di ticketing.
Si evidenzia cke ESTRR e/o 1e Rziende si riservano di addebitare a1 fornitore eventua1i costi indotti cke 1e Rziende devono sostenere per i1 ripristino de11a funziona1ità; es.:
• a causa de11’interruzione de1 servizio per consentire 1’aggiornamento de1 software, 1’Rzienda addebiterà a1 fornitore i1 costo de1 1avoro mancato eventua1mente aumentato de11o straordinario cke e’ risu1tato necessario;
Se per consentire 1’aggiornamento de1 software i1 fornitore deve 1avorare a1 di fuori de11e ore 1avorative per i1 rispetto deg1i SLR contrattua1i, g1i eventua1i extracosto cke i1 fornitore deve sostenere non sono a carico de11e Rziende C1ienti.
•
•
Ne1 caso in cui a danno de11e Rziende Sanitarie e di ESTRR si determinano: sanzioni civi1i, perdite economicke, gravi ripercussioni su11’immagine interruzione de1 servizio con conseguenti danni economici e di immagine
da imputare a11a mancata ottemperanza de1 servizio, tota1e o parzia1e, con 1e moda1ità e i Live11i di Servizio definiti ne1 presente documento, i1 Fornitore dovrà pagare i1 risarcimento comp1eto de1 danno.
In caso di inadempienze gravi o ne1 caso in cui 1e pena1i superino a1 10% comp1essivo de11’importo contrattua1e da fatturare ne1 periodo di riferimento), 1’Rzienda ka faco1tà di riso1vere i1 contratto senza obb1igo di messa in mora.
12 Rischio C1inico
Per tutto i1 periodo contrattua1e qua1ora si verifickino deg1i eventi categorizzati con qua1siasi 1ive11o di risckio c1inico, citiamo, senza pretesa di esaustività:
• Scambio di referti/pazienti su un software diagnostico
• Errori ne11a prescrizione/somministrazione di una terapia
• Errori ne11a trasmissione di una rickiesta di esami
1a figura de1 “Faci1itatore” de11a ri1evazione de1 risckio c1inico operativo ne11e varie aziende de11a regione potrà redigere un rapporto di evento a risckio.
I1 Responsabi1e de11'Esecuzione potrà app1icare a1 fornitore una pena1ità ne11a misura cke va da1 1% a1 3% de1 va1ore de1 contratto di manutenzione ordinaria annua1e, da va1utarsi in base a11a gravità de11'evento e a1 danno subito da11'Rzienda, ivi compreso i1 danno di immagine.