INDICE
Capitolato Tecnico
SOFTWARE PER LA DIAGNOSI PRECOCE DELL’ ICTUS
Versione 07
INDICE
1 Introduzione 3
2 Oggetto della fornitura ed esclusioni 7
3 Contesto 12
4 Processi funzionali ed eventuali sistemi informatici correlati 13
5 Requisiti Funzionali e Tecnologici del sistema 15
6 Offerta Tecnica – Predisposizione e Vincoli 19
7 Allegati di Gara 23
8 Appendice A – Penali 25
1 Introduzione
1.1 Premessa
L’ictus cerebrale ischemico rappresenta la seconda causa di morte e la prima causa di grave disabilità nelle popolazioni del mondo occidentale. In particolare i dati statistici forniscono un indice d’incidenza di tale patologia nella popolazione italiana di circa 220 nuovi casi/100.000 abitanti per anno con tale dato di incidenza che si eleva a 250 nuovi casi/100.000 abitanti per la regione Toscana.
Ormai da circa 10 anni la Medicina, grazie all’introduzione di terapie farmacologiche fibrinolitiche prima e dopo poco a trattamenti terapeutici endovascolari loco-regionali, ha raccolto una sfida che ha cambiato favorevolmente il corso della precedente storia naturale di detta patologia.
Contemporaneamente al progresso dei presidi terapeutici si è assistito allo sviluppo di tecniche di “imaging” radiologico sempre più complesse e raffinate che consentono lo studio e l’identificazione “in vivo” dei complessi meccanismi fisiopatologici che nel cervello umano sono la conseguenza di un ictus ischemico. Il ruolo dell’imaging neuroradiologico pertanto diventa il cardine su cui si basa la selezione del paziente eventualmente da eleggere per il successivo trattamento terapeutico sia esso soltanto farmacologico, endovascolare o combinato (farmacologico / endovascolare). Poichè l’ictus ischemico cerebrale è una patologia tempo dipendente è necessario che l’enorme quantità di dati prodotta durante l’esame venga gestita ed interpretata, come peraltro l’insieme del “percorso ictus”, nel più breve tempo possibile.
Con tale obiettivo sono stati sviluppati SW dedicati che anche grazie allo sviluppo dell’intelligenza artificiale sono in grado di fornire al Medico Radiologo tutte le informazioni necessarie per la selezione del paziente fornendo quei dati essenziali (punteggio ASPECTS, sede dell’occlusione del vaso cerebrale, identificazione del “core ischemico e della relativa penombra), ed oggettivi, che quindi riducono la variabilità di interpretazione interoperatore, che è un’insidia dello studio radiologico, riproducibili e di immediata consultazione anche per colleghi che potrebbero prendere in carico il paziente per eventuali trattamenti di seconda istanza (endovascolari).
L’insieme delle motivazioni cliniche espresse, inserite in un contesto di Ospedali HUB e SPOKE, che coprono forse la gran parte della “rete ictus” della Regione Toscana, cui l’impiego di tale SW dovrebbe essere destinato, ne giustificano l’impiego sia in termini di appropriatezza diagnostica che di adeguamento delle conoscenze agli standard operativi validati dai trials clinici internazionali ed indicati nelle linee guida di trattamento sia nazionali che internazionali.
In tale contesto si inserisce il presente Capitolato Tecnico per la locazione operativa del software di diagnosi precoce dell’ictus per le Aziende Sanitarie della Regione Toscana con previsione di prima adesione per l’ Azienda USL Toscana Centro, AOU Senese, AOU Pisana e AOU Careggi con relativi servizi di assistenza e manutenzione, come da comunicazione di richiesta pervenuta dalle varie Aziende.
I moduli software oggetto del servizio saranno installati presso Centri Servizi esterni (ad esempio TIX di Regione Toscana), per tale motivo si evidenzia che le modalità di aggiornamento software per attività di manutenzione saranno regolate in maniera specifica.
1.2 Obiettivi
Da diversi anni assistiamo ad un notevole progresso ed al continuo miglioramento dell’approccio terapeutico nell’ictus ischemico acuto sia con la terapia trombolitica endovenosa che con il trattamento endovascolare. Anche la Diagnostica per Immagini si è adeguata a rispondere a ulteriori quesiti diagnostici per migliorare sempre di più il PDTA regionali e aziendali, suggeriti dai trials clinici internazionali e consigliati dalle linee guida nazionali e internazionali al fine di individuare rapidamente i pazienti candidati al trattamento trombolitico con RTPA e per selezionare i pazienti da inviare al centro Hub per eventuale trattamento endovascolare. I quesiti posti alla Diagnostica per Immagini nell’ictus acuto non si limitano più alla sola esclusione di emorragie intra ed extracerebrali e alla individuazione delle aree di ischemia precoce nell'esame TC dell'Encefalo ma richiedono ulteriori elementi come, nello stroke del circolo anteriore :
• la valutazione del punteggio ASPECTS (Alberta Stroke Program Early CT Score) e calcolo del volume dell’ipodensità acuta nel territorio di distribuzione della arteria cerebrale media;
• identificazione della sede dell'occlusione del vaso;
• valutazione dei circoli collaterale di compenso;
• riconoscimento del tessuto cerebrale potenzialmente salvabile (penombra) nonchè del tessuto ischemico (core).
L'identificazione di tali elementi costituisce importanti fattori prognostici di outcome del paziente e determinano il successivo iter terapeutico (medico; endovascolare o combinato). Pertanto è necessario che il protocollo diagnostico da utilizzare nello studio, in urgenza, di un paziente con sospetto di ictus ischemico, comprenda:
• TC Cranio basale senza mezzo di contrasto (MdC) con calcolo del punteggio ASPECTS;
• Angio-TC dei vasi arteriosi del collo e intracranici per l'identificazione della sede dell'occlusione;
• Angio-TC trifasica per la valutazione dei circoli collaterali di compenso leptomeningeo;
• studio della perfusione cerebrale per il riconoscimento del tessuto cerebrale potenzialmente salvabile e del "core” ischemico.
Per ottimizzare il percorso diagnostico nell’ictus cerebrale acuto è indispensabile introdurre protocolli TC standard “Codice Ictus” con rapida interpretazione delle immagini e refertazione quanto più possibile standardizzata ed omogenea. Per il calcolo del punteggio APSECT e per la valutazione dei circoli di compenso leptomeningei è indispensabile il training dei radiologi dei presidi ospedalieri autorizzati al trattamento con rTPA; ci vuole molta esperienza poichè anche in ambito specialistico neuroradiologico si riscontra notevole variabilità inter ed intraosservatore. Recentemente i risultati degli studi randomizzati multicentrici (DAWN e DEFUSE 3) basati sull'analisi dei risultati dello studio perfusionale hanno consentito di ampliare da 6 sino a 24 ore la finestra per il trattamento terapeutico endovascolare dello stroke ischemico del circolo anteriore,
risultati inseriti con grado di evidenza forte ed a favore nelle linee guida sia nazionali che internazionali e nel trial Extend rtPA 4,5 – 9ore.
Con questa procedura si intende acquisire un software dedicato all'interpretazione delle immagini TC che consenta l'analisi e l'interpretazione rapida dei dati generati dal complesso imaging neuroradiologico cui viene sottoposto il paziente con ictus ischemico acuto.
A tal proposito giova ricordare che le nuove linee guida ISO raccomandano con grado di evidenza forte, l'impiego di software dedicati di analisi volumetrica basati su soglie per il calcolo automatico del volume del "core", della penombra e del mismatch ratio.
1.3 Definizioni
Nel testo che segue, oltre che alle definizioni contenute nelle norme UNI 11063 (Tutte le definizioni delle norme di riferimento per la manutenzione), viene fatto riferimento alle seguenti denominazioni e definizioni:
Termine | Descrizionedel Termine |
Aggiudicatario, Xxxxx Xxxxxxxxxxxxxx, Xxxxx appaltatrice, Ditta contraente, Contraente, Fornitore, Assuntore | Il fornitore aggiudicatario, che ha sottoscritto il contratto obbligandosi a quanto nello stesso previsto nei confronti dell’Azienda. Esso può identificarsi anche con un raggruppamento temporaneo di imprese o con il suo capofila. |
Azienda Sanitaria, Azienda, Committente | Il complesso delle aziende sanitarie e gli enti del Servizio Sanitario della Regione Toscana che usufruiscono dei servizi oggetto dell’appalto. |
Ente Appaltante, Stazione Appaltante | Ente che assegna l’appalto |
Ditta concorrente, Ditta offerente | Impresa singola, raggruppamento temporaneo di imprese costituito o costituendo, consorzio o altro soggetto partecipante alla gara. Essa può identificarsi anche con il capofila di un raggruppamento temporaneo di imprese |
Help Desk | Struttura che ha il compito di dare il supporto di primo livello a fronte di una richiesta di assistenza; qualora non sia possibile trovare una soluzione al problema via assistenza di primo livello, l’Help Desk ha il compito scalare il problema sia verso il supporto tecnico avanzato o verso un eventuale fornitore terzo che eroga il supporto tecnico specifico |
Service Level Agreement (SLA) | in italiano: Accordo sul livello del servizio, in sigla SLA, è uno strumento contrattuale attraverso il quale si definiscono le metriche di servizio che devono essere rispettate da un fornitore di servizi. |
Sistemi Serventi o Server | sottosistemi più o meno complessi, in grado di fornire servizi di tipo infrastrutturale di base o applicativi. Essi sono generalmente costituiti da hardware, software di base (sistemi operativi, driver di periferiche) e sistemi di memorizzazione interni o esterni, esclusivi o condivisi. |
Unità Operativa (UO) | Struttura organizzativa professionale e/o funzionale dell’Azienda titolare di proprio budget assegnato |
1.4 Terminologia,abbreviazioni
Glossario dei termini e delle abbreviazioni
Acronimo | Definizione |
ESTAR | Ente di supporto tecnico-amministrativo regionale |
XX.XX. | Aziende Sanitarie. Si Tratta di USL Toscana Nord Ovest, USL Toscana Centro, USL Toscana Sud Est |
AA.OO.UU. | Aziende Ospedaliero Universitarie. Si Xxxxxx di AOU Pisana, AOU Careggi, AOU Meyer, AOU Senese |
ISPRO | Istituto per lo Studio, la Prevenzione e la Rete Oncologica |
FTGM | Fondazione Toscana Xxxxxxxx Xxxxxxxxxx |
CART | Cooperazione Applicativa Regione Toscana |
SLA | Service Level Agreement |
RUP | Responsabile unico del procedimento (art. 31 D.Lgs 50/2016) nella fase che si chiude con la stipula del contratto |
RES | Responsabile del procedimento per la fase di esecuzione del contratto (art. 2 comma 1.b DGRT 16/2014) |
DEC | Direttore dell'Esecuzione del Contratto (art. 101 D.Lgs 50/2016) |
ANAC | Autorità nazionale anticorruzione |
RT | Regione Toscana |
SSR | Servizio Sanitario Regionale |
SSRT | Servizio Sanitario Regionale Toscano |
SDA | Sistemi Dinamici di Acquisizione |
SW | Software |
RDA | Richiesta di Acquisto |
GDPR | General Data Protection Regulation, il Regolamento Ue 2016/679 relativo alla protezione delle persone fisiche con riguardo al trattamento e alla libera circolazione dei dati personali |
DURC | Documento Unico di Regolarità Contributiva |
PDI | Piano dettagliato di intervento |
TC | Tomografia Assiale Computerizzata |
PACS | Picture Archiving and Communication System |
DICOM | Digital Imaging and COmmunications in Medicine |
Tabella 2 - Glossario
2 Oggetto della fornitura ed esclusioni
2.1 Oggettodellafornitura
Con tale Bando di Gara si richiede la fornitura, in locazione operativa, di un software per la “Diagnosi precoce dell’ICTUS” per le Aziende Sanitarie della Regione Toscana, con previsione di prima adesione per l’ Azienda USL Toscana Centro, l’AOU Senese, l’AOU Pisana e l’AOU Careggi con relativi servizi di assistenza e manutenzione.
La fornitura deve essere composta da 2 (due) “moduli software” fra loro indipendenti ed allo stesso tempo complementari ed integrabili con la seguente suddivisione:
MODULO A:
1. riconoscimento delle aree di ipodensità acuta nel territorio della arteria cerebrale media con calcolo del punteggio ASPECT sulle scansioni TC senza MdC;
2. misurazione del volume delle aree di ipodensità acuta a livello di tutti i segmenti dell’ ASPECT sulle scansioni TC senza MdC;
3. riconoscimento dell’iperdensità intravascolare con misurazione delle dimensioni del trombo sulle scansioni TC senza MdC;
4. rilevazione della presenza e localizzazione di occlusione di grosso vaso sulle scansioni Angio-TC monofasica;
5. valutazione quantitativa dei circoli collaterali sulle scansioni Angio-TC monofasica e trifasica utilizzando un sistema di punteggio clinicamente validato;
6. visualizzazione delle localizzazioni del deficit dei circoli collaterali sulle scansioni An- gio-TC monofasica;
7. supporto delle scansioni Angio-TC multifasica equivalentemente alle scansioni Angio- TC monofasica;
8. visualizzazione del tempo relativo all’arrivo del bolo sulle scansioni angio-TC multifa- sica attraverso tutta la vascolarizzazione cerebrale;
9. condivisione in tempo reale fra gli utenti;
10. le misurazioni quantitative devono essere convalidate clinicamente per garantire presta- zioni equivalenti a quelle dei medici esperti in materia di ictus;
11. la generazione dei risultati non deve richiedere alcun intervento manuale.
MODULO B (perfusione):
1. generazione automatica delle mappe di perfusione cerebrale MTT, TCBV, CBF, TMAX con identificazione del core ischemico e calcolo dei volumi del core e penom- bra ischemici e relativo calcolo del mismatch core-penombra;
2. condivisione in tempo reale fra gli utenti;
3. le misurazioni quantitative devono essere convalidate clinicamente per garantire pre- stazioni equivalenti a quelle dei medici esperti in materia di ictus;
4. la generazione dei risultati non deve richiedere alcun intervento manuale.
La necessità di fornitura a 2 moduli indipendenti, nasce per le diverse esigenze delle Aziende sani- tarie dettate dalle differenti organizzazioni interne.
I moduli software oggetto del servizio, secondo l'attuale assetto normativo, sono qualificabili come dispositivi medici e come tali dovranno essere conformi alla legislazione vigente coerentemente con la destinazione d’uso prevista.
Nello specifico, ove applicabili, i Dispositivi Medici devono essere conformi al D.lgs 46/1997 e successive integrazioni o modifiche, attuazione della direttiva 93/42/CEE, concernente i dispositivi medici ovvero al Regolamento (UE) 2017/745 del Parlamento Europeo e del Consiglio del 5 aprile 2017 relativo ai dispositivi medici .
I moduli software oggetto del servizio dovranno essere installati presso Centri Servizi esterni (ad esempio TIX di Regione Toscana), per tale motivo si evidenzia che le modalità di aggiornamento software per attività di manutenzione saranno regolate in maniera specifica.
Gli applicativi in ambito al contratto di manutenzione devono includere le necessarie funzionalità, erogate mediante interfaccia client (o User Interface), a supporto degli amministratori di applicativo per l’esecuzione delle attività di amministrazione sul sistema (ad esempio Creazione e Profilazione utenti, definizioni profili, etc).
Per una più puntuale identificazione della fornitura si chiede che il Fornitore fornisca in sede di offerta tutti i dettagli necessari per identificare i moduli in ambito alla fornitura in modo non vago o ambiguo. In particolare il Fornitore deve esplicitare/fornire tutti i dettagli per identificare in modo chiaro i moduli e le funzionalità a disposizione delle Aziende, evidenziando le eventuali differenze per le eventuali diverse installazioni.
Le caratteristiche dei servizi richiesti per l’assistenza e la relativa manutenzione, inerenti ai moduli del software per la diagnosi precoce dell’ictus, possono essere riassunte nei seguenti punti:
1. Assistenza telefonica e on line agli utilizzatori e diffusione dei manuali utente:
comprende un servizio di helpdesk telefonico e/o telematico (via email o web form) dedicati, al fine di offrire supporto al per il corretto ed efficiente utilizzo del programma e la soluzione dei problemi operativi che possono emergere nel suo utilizzo. Rientrano in Assistenza tutte le richieste informative di carattere tecnico (funzionamento di script, estrazione flussi, estrazioni dati, viste, etc.) fatte esclusivamente da personale di ICT Estar, salvo che, quanto richiesto, non sia già presente nei manuali tecnici consegnati a ICT.
2. Manutenzione ordinaria:
comprende tutti gli interventi sul software volti a consentire il corretto funzionamento con altri software presenti sulla postazione e con i sistemi operativi aggiornati rispetto a quelli previsti dal contratto di licenze, anche sulla base di segnalazioni ricevute.
È realizzata ciclicamente su base temporale, ovvero a scadenze regolari. Le linee guida distinguono due tipi di manutenzione ordinaria:
a) programmata, ovvero basata sul tempo, che prevede interventi con cadenza regolare e verifiche determinate da elenchi prefissati;
b) di revisione, ovvero finalizzata ad assicurare aderenza delle procedure all’evoluzione dell’ambiente tecnologico, ad es: aggiornamento di versioni del software di base;
Rientra nella manutenzione ordinaria tutta l’attività di profilazione utenti e comunque di generica configurazione (parametri, dizionari) laddove il software non sia dotato di funzionalità applicativa o nel caso in cui i moduli da utilizzare risultino oggettivamente difficili da utilizzare in termini di rapporto tra il dato da immettere il numero di passaggi da fare nell’applicativo.
3. Manutenzione correttiva:
Attività di manutenzione realizzata in risposta a malfunzionamenti e/o non rispondenza a specifiche applicative o di flussi, sulla base dei test o delle segnalazioni fatte, da realizzarsi entro i tempi previsti dagli SLA contrattualizzati. Rientrano nella manutenzione correttiva tutti gli interventi necessari alla sistemazione dei dati sul database laddove la causa sia direttamente imputabile ad un malfunzionamento dell’applicativo o ad una integrazione con altri software.
4. Manutenzione normativa:
Attività di manutenzione realizzata per garantire il rispetto della normativa nazionale e/o regionale, prevista da delibere emesse dall’organismo legislativo ESTAR Linee Guida Manutenzione e Assistenza Software Pag. 4 di 17 competente ed effettuata su segnalazione/richiesta del Cliente. Rientrano nella manutenzione normativa anche gli aggiornamenti di tabelle di dizionari salvo che non siano già previsti tool per il caricamento massivo delle informazioni con i quali Estar può procedere in autonomia. Saranno da quotare separatamente le eventuali attività relative a manutenzione normativa regionale laddove l’intervento richiesto dia luogo alla modifica delle strutture della base dati, o, nel caso di flussi, al cambio di tecnologia usata (es. da flussi a eventi) o quando la variazione richieda l’integrazione con software di altre ditte. La manutenzione normativa è soggetta a specifico collaudo.
Il Fornitore del servizio di assistenza e manutenzione dovrà svolgere le attività previste dal servizio per tutto il software messo in esercizio e per tutto il tempo contrattualizzato.
Per l’approfondimento dei servizi di assistenza e la relativa manutenzione si chiede di fare riferimento allo specifico allegato.
2.2 Obiettivispecificidellafornitura
Il software oggetto di tale fornitura deve avere le seguenti caratteristiche oltre a quelle già evidenziate negli altri paragrafi :
1. Il sistema deve ricevere le scansioni TC direttamente dalle workstation, senza la necessità di passare dal PACS con un nodo DICOM di invio diretto;
2. Il sistema deve elaborare le scansioni in automatico;
3. Il sistema deve essere in grado di distribuire i risultati verso il PACS di competenza, coi necessari meccanismi di univocità e di sicurezza sui pazienti trattati e sui relativi episodi clinici;
4. I risultati devono essere consultabili tramite una interfaccia web del software tramite protocollo https, all’interno della rete dati delle Aziende Sanitarie, con possibilità di utilizzo sui principali browser, quali Mozilla Firefox, Google Chrome, Internet Explorer, Apple Safari, Edge.
5. I risultati devono essere consultabili anche su dispositivi mobili con opportuna anonimizzazione dei dati personali.
Gli obiettivi della Assistenza sono così definiti:
1. Facilitare le diverse categorie di Utenti nell’utilizzo operativo e funzionale dei mezzi informativi e dei sistemi e servizi previsti;
2. Fornire in modo esaustivo tutte le informazioni e gli strumenti di supporto richiesti dagli Utenti per risolvere i problemi in modo tempestivo ed efficace;
3. Offrire agli Utenti tutte le informazioni che l’Amministrazione ritiene opportuno far conoscere in merito alla disponibilità di nuovi servizi o alla modifica di servizi esistenti;
4. Fornire manuali d'uso periodicamente aggiornati;
5. Garantire, alle strutture di controllo preposte, la verifica costante della qualità del servizio erogato e la conoscenza sia delle necessità e dello stato di soddisfazione degli Utenti sia dell’utilizzo dei servizi;
6. Identificare e segnalare all’Amministrazione la necessità di formazione sulla base delle informazioni monitorate dal Contact Center, al fine di adeguare o mantenere la competenza degli utenti e degli operatori sui servizi supportati.
Gli obiettivi della Manutenzione sono così definiti:
1. Mantenere operative le soluzioni software attraverso attività che assicurino in via continuativa la rimozione dei malfunzionamenti;
2. Risolvere, anche con eventuali workaround temporanei, le criticità del software o dei flussi estratti da correggersi in via definitiva con il rilascio di patch/release correttive;
3. Assicurare il miglioramento tempestivo delle funzionalità e delle prestazioni;
4. Garantire l’evoluzione tecnico funzionale della soluzione software;
5. Assicurare l’aggiornamento periodico della soluzione, attraverso il miglioramento della funzionalità, dell’affidabilità e dell’efficienza dei prodotti.
La copertura oraria del servizio di assistenza e manutenzione dovrà garantire quanto esplicitato nello specifico allegato ed indicato con il nome di “STANDARD”, ”ESTESO” e “h24”.
Il fornitore nell’allegato economico dovrà valorizzare tutti e tre i tipi di copertura.
2.3 Elementinoncompresinellafornitura
Al fine di analizzare l’infrastruttura necessaria, non oggetto di questa fornitura, il fornitore nella proposta deve dettagliare le caratteristiche delle componenti hw e sw che sono necessarie per l’erogazione del servizio del sistema. A titolo esemplificativo, senza pretesa di esaustività, si riportano i dettagli HW / SW richiesti.
In ogni caso il fornitore deve fornire la garanzia di funzionalità con sistemi operativi client presenti sul parco macchine aziendale, compresi i nuovi sistemi operativi rilasciati durante il periodo di validità del contratto.
Si richiede altresì di identificare in maniera precisa la tipologia, marca e versione del database, se utilizzato ed esplicitare l’eventuale costo di licenza nella scheda di dettaglio economico.
3 Contesto
Il Servizio Sanitario Regionale Toscano, preso atto della necessità di aggiornare e migliorare l'efficienza e l'efficacia clinica dei sistemi informatici di gestione delle strutture di Diagnostica per Immagini operanti al suo interno (noti come RIS-PACS) e considerata la sempre crescente necessità di interscambio ed interoperabilità tra i sistemi informatici allo scopo di ottenere la condivisione dei dati finalizzata a migliorare i processi clinico-assistenziali, razionalizzare le risorse e favorire l'integrazione dei processi di prescrizione elettronica (e-prescription) e di fascicolo sanitario elettronico regionale, ha deciso di allinearsi con logiche di progettazione che seguano i dettami degli standard internazionali.
Ad oggi i sistemi RIS-PACS in uso sul territorio regionale sono i seguenti:
• Area Vasta Nord Ovest (compreso AOU Pisana)
◦ RIS Ebit SuitEstensa per la gestione dei flussi nei reparti di Radiologia, Cardiologia ed Endoscopia;
◦ PACS Fujifilm Synapse per la archiviazione e visualizzazione delle immagini radiologiche.
• Area Vasta Centro eccetto Zona Empolese (compreso AOU Careggi)
◦ RIS Agfa Gevaert Elefante per la gestione dei flussi nei reparti di Radiologia;
◦ PACS Siemens Syngo per la archiviazione e visualizzazione delle immagini radiologiche.
• Area Vasta Centro Zona Empolese:
◦ RIS Elco Polaris per la gestione dei flussi nei reparti di Radiologia;
◦ PACS Carestream Vue PACS per la archiviazione e visualizzazione delle immagini radiologiche.
• Area Vasta Sud Est eccetto Zona Aretina (compreso AOU Senese)
◦ RIS Gmed SilveRIS per la gestione dei flussi nei reparti di Radiologia;
◦ PACS Carestream Vue PACS per la archiviazione e visualizzazione delle immagini radiologiche.
• Area Vasta Sud Est Zona Aretina:
◦ RIS Gmed SilveRIS per la gestione dei flussi nei reparti di Radiologia,
◦ PACS General Electric per la archiviazione e visualizzazione delle immagini radiologiche.
Di seguito alcune informazioni analitiche che potranno essere utili per il dimensionamento dell’offerta :
Azienda | TC annue esaminate con SW | Numero apparecchiature TC |
AOU Careggi | 350 | 2 |
AOU Senese | 370 | 2 |
AOU Pisana | 300 | 2 |
AUSL Toscana Centro | 3600 | 14 |
4 Processi funzionali ed eventuali sistemi informatici correlati
4.1 ModelloApplicativo
Il Sistema, oggetto di tale bando di gara, deve ricevere le scansioni TC direttamente dalle workstation, senza la necessità di passare dal PACS con un nodo DICOM di invio diretto, il sistema proposto elaborerà le scansioni in modalità automatica. Le elaborazioni risultanti dovranno essere visionabili dagli specialisti ed inviate verso il PACS di competenza, con i necessari meccanismi di univocità e di sicurezza sui pazienti trattati e sui relativi episodi clinici.
I risultati devono essere consultabili tramite una interfaccia web del software tramite protocollo https, all’interno della rete dati delle Aziende Sanitarie, con possibilità di utilizzo sui principali browser, fra i quali Google Chrome, Apple Safari, Edge. Tale possibilità dovrà anche essere esposta su dispositivi mobili con opportuna anonimizzazione dei dati personali.
4.2 Descrizionedei Processi
Si riporta nella seguente tabella lo schema dei processi :
Step | Processo | Descrizione |
1 | Esecuzione TC | In questa fase viene prodotta la TC oggetto di analisi. |
2 | Acquisizione TC | In questa fase viene acquisita la TC, oggetto della analisi, direttamente dalla workstation attraverso un nodo DICOM di invio diretto. |
3 | Elaborazione | In questa fase, viene elaborata l’immagine e prodotto il risultato. Tale attività deve essere svolta senza l’intervento di uno specialist (elaborazione automatica). |
4 | Esposizione | Il software deve mostrare i risultati dell’elaborato allo specialist. Tali risultati, devono essere esposti tramite interfaccia web sia sulle postazioni in dotazione alla azienda sia su dispositivi mobili con opportuna anonimizzazione dei dati personali. |
5 | Invio sistema PACS | Il sistema dovrà inviare i risultati della elaborazione al PACS di riferimento. |
4.3 ContestoStrutturaleed Organizzativo
Il sistema oggetto del presente Capitolato dovrà essere compliant con le linee-guida e coi vincoli tecnologico-organizzativi richiesti dal settore Reti e Sistemi del Dipartimento ICT.
Il sistema dovrà altresì tenere conto di quanto previsto dalla progettualità regionale in materia di interoperabilità RIS PACS.
Per i dettagli sui sistemi PACS presenti nelle XX.XX e XX.XX del Servizio Sanitario Toscano si rimanda alla Determinazione del Direttore del Dipartimento Acquisizione Beni e Servizi ESTAR
n. 958 del 05/07/2019 pubblicata all’Albo Pretorio il 08/07/2019 avente ad oggetto:
“AGGIUDICAZIONE PROCEDURA NEGOZIATA PER L'AFFIDAMENTO DEGLI ADEGUAMENTI TECNOLOGICI E IL SERVIZIO DI MANUTENZIONE DEL SISTEMA RIS PACS DELLE XX.XX./OO./ENTI DEL SSRT (CUI 2018-021-0033) DAL 01/07/2019 AL
30/06/2024” consultabile sul sito di Estar (xxx.xxxxx.xxxxxxx.xx) menu “Albo Pretorio” sezione “Archivio”.
4.4 Integrazionicon sistemiinternied esterni
Come descritto precedentemente il software oggetto del presente capitolato deve poter dialogare tramite un nodo Dicom in maniera bidirezionale in modo da ricevere le immagini da elaborare direttamente dalla apparecchiatura TC e in seguito restituire l’elaborazione prodotta alla piattaforma PACS.
5 Requisiti Funzionali e Tecnologici del sistema
La fornitura deve includere le funzionalità che seguono, classificate secondo la tematica delle funzioni.
5.1RequisitiFunzionali
Si riportano nel seguito le caratteristiche generali che il sistema deve avere oltre ai requisiti espressi nei capitoli precedenti. Tali caratteristiche hanno carattere obbligatorio eccetto quelle espressamente indicate come migliorative e/o preferenziali:
ID | Requisito | Obbligatorio/ Migliorativo/ Preferenziale |
MA1 | Riconoscimento delle aree di ipodensità acuta nel territorio della arteria cerebrale media con calcolo del punteggio ASPECT sulle scansioni TC senza MdC | Obbligatorio |
MA2 | Misurazione del volume delle aree di ipodensità acuta a livello di tutti i segmenti dell’ ASPECT sulle scansioni TC senza MdC | Obbligatorio |
MA3 | Riconoscimento dell’iperdensità intravascolare con misurazione delle dimensioni del trombo sulle scansioni TC senza MdC | Obbligatorio |
MA4 | Rilevazione della presenza e localizzazione di occlusione di grosso vaso sulle scansioni Angio-TC monofasica | Obbligatorio |
MA5 | Valutazione quantitativa dei circoli collaterali sulle scansioni Angio- TC monofasica e trifasica utilizzando un sistema di punteggio clinicamente validato | Migliorativo |
MA6 | Visualizzazione delle localizzazioni del deficit dei circoli collaterali sulle scansioni Angio-TC monofasica | Obbligatorio |
MA7 | Supporto delle scansioni Angio-TC multifasica equivalentemente alle scansioni Angio-TC monofasica | Migliorativo |
MA8 | Visualizzazione del tempo relativo all’arrivo del bolo sulle scansioni angio-TC multifasica attraverso tutta la vascolarizzazione cerebrale | Obbligatorio |
MB1 | Generazione automatica delle mappe di perfusione cerebrale MTT, TCBV, CBF, TMAX con identificazione del core ischemico e calcolo dei volumi del core e penombra ischemici e relativo calcolo del mi- smatch core-penombra | Obbligatorio |
G01 | Il tempo di latenza intercorrente tra la fine dell’acquisizione dei dati e la fruizione da parte del radiologo deve essere il più' breve possibile (si richiede di esplicitare i tempi tipici di elaborazione di ciascun modulo) | Preferenziale |
G02 | Il sistema deve ricevere le scansioni TC direttamente dalle workstation, senza la necessità di passare dal PACS con un nodo DICOM di invio diretto | Obbligatorio |
G03 | Il sistema deve essere in grado di distribuire i risultati verso il PACS di competenza, coi necessari meccanismi di univocità e di sicurezza sui pazienti trattati e sui relativi episodi clinici | Obbligatorio |
G04 | I risultati devono essere consultabili tramite una interfaccia web del software tramite protocollo https, all’interno della rete dati delle Aziende Sanitarie, con possibilità di utilizzo sui principali browser, almeno Chrome, Safari, Edge. | Obbligatorio |
G05 | I risultati devono essere consultabili anche su dispositivi mobili con opportuna anonimizzazione dei dati personali | Obbligatorio |
G06 | Condivisione in tempo reale fra gli utenti | Obbligatorio |
G07 | Le misurazioni quantitative devono essere convalidate clinicamente per garantire prestazioni equivalenti a quelle dei medici esperti in ma- teria di ictus; | Obbligatorio |
G08 | La generazione dei risultati non deve richiedere alcun intervento ma- nuale | Obbligatorio |
Legenda:
Obbligatorio: requisito indispensabile pena l’esclusione
Preferenziale: requisito non indispensabile ma che qualifica positivamente una offerta rispetto ad un’altra
Migliorativo: requisito non indispensabile che la commissione si riserva di valutare come proposta migliorativa
MAxx : Requisiti modulo A MBxx : Requisiti modulo B
Gxx : Requisiti Generali (per entrambi i moduli)
5.2Requisititecnologici
Nel rispetto delle disposizioni espresse dal Dipartimento Tecnologie Informatiche di Estar in materia di caratteristiche tecnologiche dei software di nuova acquisizione, il sistema dovrà rispettare la tecnologia web “zero footprint” per essere fruibile via browser da tutte le postazioni di lavoro che saranno individuate sul territorio regionale e dovrà essere installato in modo centralizzato nei data-center indicati dal committente e nel rispetto delle linee guida tecnologiche allegate.
Il software deve poter essere utilizzato da qualsiasi pc con le seguenti caratteristiche:
● pc con Microsoft Office o Openoffice/Libreoffice;
● browser Safari release corrente e successive;
● browser Chrome release corrente e successive;
● browser Egde release corrente e successive.
La piattaforma dovrà altresì consentire una distinzione in ambienti software corrispondenti alle singole aziende sanitarie e ospedaliere in modo tale da garantire la gestione separata, a livello aziendale, delle attività delle Strutture organizzative delle aziende sanitarie locali e ospedaliere toscane e/o di Estar, ovvero di tutti gli Enti destinatari della fornitura.
Si riportano nel seguito le caratteristiche generali che il sistema deve avere oltre ai requisiti espressi nei capitoli precedenti. Tali caratteristiche hanno carattere obbligatorio eccetto quelle espressamente indicate come migliorative e/o preferenziali:
ID | Requisito | Obbligatorio/ Migliorativo/ Preferenziale |
T1 | Disponibilità di servizi on line a supporto dell’apprendimento e dell’uso del software. Esempio: O Video Tutorial in linea: ovvero piattaforme interattive e navigabili per imparare velocemente ad usare il software, con i problemi più frequenti risolti/descritti mediante appositi video; a tali piattaforme si deve poter accedere direttamente da menù dell’applicativo; O Forum: ovvero uno spazio virtuale dedicato agli operatori per lo scambio di esperienze, al confronto e alla discussione; O Help on line: ovvero un motore di ricerca per trovare le soluzioni nel Video Tutorial e nel Forum NB: Tutti questi strumenti devono essere mantenuti aggiornati alla versione corrente del software per tutta la durata dell’appalto con con periodicità di rilascio non superiore a 6 mesi. | Migliorativo |
T2 | Gestione strutturata delle utenze e dei profili: il software in acquisizione dovrà possedere al suo interno funzionalità, utilizzabili solo dai profili di amministrazione, dedicate alla generazione e manutenzione delle utenze e dei profili di accesso alla procedura. Il gestionale deve essere integrato/integrabile, senza oneri aggiuntivi, con gli eventuali sistemi aziendali di identity management. | Obbligatorio |
T3 | Sistema di messaggistica interna al software dedicata alla pubblicazione di news o alert redatti dall’amministratore dell’applicativo. Il meccanismo di messaggistica deve strutturarsi su due livelli gerarchici: • messaggi che richiedono la presa visione obbligatoria da parte dell’utente al momento dell’accesso (login) al gestionale; • messaggi che possono essere letti in differita e conservati in un’area apposita dell’applicativo e segnalati con un alert fino all’avvenuta lettura | Migliorativo |
T4 | Inoltro delle richieste di assistenza tecnica, da parte dell’operatore, mediante semplice selezione di un pulsante o di una voce di menù sempre disponibile nella barra dei pulsanti/menù a disposizione dell’utente. Una volta premuto il pulsante o selezionata la voce di menù, l’utente verrà invitato a compilare un form con le informazioni necessarie per inoltrare correttamente la segnalazione, che verrà trasmessa via mail all’HD. L’interfaccia utente dovrà anche consentire all’operatore di monitorare lo stato di avanzamento delle segnalazioni trasmesse. | Migliorativo |
Legenda:
Obbligatorio: requisito indispensabile pena l’esclusione
Preferenziale: requisito non indispensabile ma che qualifica positivamente una offerta rispetto ad un’altra Migliorativo: requisito non indispensabile che la commissione si riserva di valutare come proposta migliorativa
5.3Recuperodi datistorici
Data la natura del servizio richiesto non sono previste attività di recupero storico.
5.4Integrazionecon sistemidi BusinessIntelligenceAziendali
Data la natura del servizio richiesto non sono previste attività di integrazione BI.
5.5Migrazioneversoaltrepiattaformea finecontratto
Data la natura del servizio richiesto non sono previste attività di migrazione di fine contratto.
5.6RequisitiMinimiFormazionee Affiancamentoall’Avvio
La formazione dovrà essere necessariamente erogata entro l’avvio in produzione nell’ambito delle aziende sanitarie ed enti del SSRT per il personale coinvolto nell’utilizzo della piattaforma.
L’affiancamento all'avvio dovrà essere necessariamente erogato on site senza oneri aggiuntivi.
Per le eventuali necessità formativa post-partenza (formazione successiva), il fornitore dovrà valorizzare, nell’allegato economico, la singola giornata di formazione on-site.
6 Offerta Tecnica – Predisposizione e Vincoli
Nel presente capitolo si riportano le indicazioni utili alla corretta predisposizione dell’offerta tecnica da parte dei concorrenti.
La presentazione dell’offerta tecnica dovrà chiaramente distinguere tra:
• fase implementativa che include l’installazione, configurazione, realizzazione delle integrazioni nonché formazione e affiancamento all’avvio del sistema informatico a supporto delle attività delle strutture deputate alla gestione del contenzioso delle Aziende/Enti del SSRT;
• fase di supporto e manutenzione (da descrivere nel solo documento A) della piattaforma a partire dall’avvio in produzione e/o dal collaudo con esito positivo e per tutta la durata dell’appalto
Al fine di agevolare i lavori della commissione giudicatrice, si richiede che l’offerta tecnica presentata sia strutturata come segue, descrivendo all’interno dei singoli documenti (o raccolta di essi) gli argomenti elencati:
Doc di riferimento | Oggetto | Ambito di illustrazione | Riferimento |
Documento A | Organizzazio ne dei servizi | • Organizzazione dei processi interni all'Azienda/ATI • Proposte (anche migliorative) sui servizi di assistenza e manutenzione • Proposte sul piano di formazione (inclusa FAD) • Affiancamento all'avvio | Capitolo 2 |
Documento B | Tecnologia e funzionalità del software | • Proposta tecnico-funzionale per il software • Caratteristiche di ergonomicità • Potenzialità di configurazione • Facilità di realizzazione delle integrazioni • Supporto funzionale volto alla semplificazione del flusso di lavoro degli operatori • Utilizzo di prodotti/licenze open source | Capitolo 4 e 5 |
Documento C | Sistemi di reporting | • Ampiezza e completezza delle funzioni di reporting; • Flessibilità nella generazione di nuovi report; • Flessibilità nella scelta dei filtri e configurabilità dei Capitolo 4 e 5 report offerti (informazioni e aggregazioni); • Ergonomicità di accesso e fruizione dei report; • Flessibilità nell'export dei dati | |
Documento D | Documentazi one | • Compilazione dell’allegato 7 - "Scheda check di compliance sicurezza e privacy applicativi software" • Documentazione per l'utente; • Documentazione tecnica del software, con particolare riguardo all'architettura, ai linguaggi di sviluppo, alle librerie o agli standard utilizzati, al disegno del database, alla modalità di archiviazione documentale | Capitolo 5 e 6 |
(filesystem, db, etc…), alla firma digitale, alla semplicità di accesso alle varie funzionalità (compreso reporting); • Disponibilità di servizi on line a supporto dell’apprendimento e dell’uso del software (vedi esempio di cui all’ID 1 del paragrafo 5.2) | ||
Documento E | Portabilità della soluzione | • Modernità delle tecnologie; • Grado di innovazione delle scelte architetturali; • Garanzia della compatibilità con i vari browser; • Modalità di tutela rispetto agli aggiornamenti di versione di SO/browser; • Presenza di ambienti sviluppati in HTML5; • Compatibilità del software con dispositivi mobili; • Capacità della soluzione proposta di funzionare con Capitolo 2 e 4 produttori e versioni diverse di OS, browser; • Compatibilità con le più comuni suite di produttività aziendale; • La distribuibilità della soluzione mediante ambienti di virtualizzazione applicativa; • Integrazione degli ecosistemi applicativi in sistemi di dominio AD per la profilazione utenti; • Modalità di autenticazione weak e strong; |
Documento F | Integrazioni e recupero dati | Proposta tecnico-funzionale in merito a: • Integrazioni • Infrastruttura di riferimento • Gestione delle utenze e tracciamento attività Capitolo 3 e 4 • Recupero dati • Architettura SOA • Documentazione dei servizi di interoperabilità |
Documento G | Sviluppo del progetto | • Caratteristiche qualitative del PM • Gantt Capitolo 6 e • Attinenza del Gantt e delle modalità di esecuzione in allegato PA relazione a quanto descritto nella Procedura LIFECYCLE 46_2018 REV Management (Allegato 3) 01 (LifeCycle) • Grado di copertura delle check list di collaudo |
Documento H | Migliorie e Roadmap | • Caratteristiche migliorative rispetto a quanto richiesto; Capitolo 6 e • Roadmap di sviluppo del prodotto software per gli anni allegato PA successivi 46_2018 REV 01 (LifeCycle) |
Fasedi Implementazione- definizionedei vincoli
Nella predisposizione del Gantt di startUp (presente nel documento G), oggetto di valutazione, relativo alle attività oggetto della fornitura il concorrente, dovrà rispettare i seguenti vincoli:
Oltre ai livelli di servizio per l'assistenza, per la manutenzione correttiva e per la gestione di RDBMS/server (se inclusi), di seguito sono riportati i seguenti vincoli :
Codice Vincolo | Descrizione Vincolo | Gravità (ALTA/MEDI A/ BASSA) |
V1 | Tempo previsto per la messa in produzione di ogni singola Azienda aderente : a. Non più di un mese per singola Azienda Ospedaliera b. Non più di tre mesi per singola Azienda Territoriale c. Massimo sei mesi per il dispiegamento del progetto in caso di sovrapposizione (adesioni) delle aziende e le relative tempistiche del punto a e b. Il tempo sarà calcolato dalla data dell’ordine. | ALTA |
V2 | Non rispetto del GANTT di avvio presentato con un “delay” relativo alla fase di startUp di 60 giorni (Per motivi attribuibili al fornitore) | ALTA |
V3 | Non rispetto del GANTT di avvio presentato con un “delay” relativo alla fase di startUp di 30 giorni (Per motivi attribuibili al fornitore) | MEDIA |
V4 | Non rispetto del GANTT di avvio presentato con un “delay” relativo alla fase di startUp di 15 giorni (Per motivi attribuibili al fornitore) | BASSA |
V5 | Mancata fornitura di adeguata formazione | MEDIA |
V6 | Mancata fornitura di adeguata documentazione (manuali e/o quanto previsto) | MEDIA |
Nota in merito ai vincoli:
Le attività che normano la Verifica e Collaudo del Software, con i rispettivi requisiti, sono descritte nella “PA47-2018 Rev01 Verifiche di Conformità” (Allegato 6), cui il RES e il DEC faranno riferimento per l’eventuale valutazione del rispetto dei vincoli sopra riportati nonché dell'applicazione delle relative penali.
È facoltà del Concorrente proporre Gantt che prevedano la riduzione dei vincoli sopra indicati.
Fasedi Supportoe Manutenzione(post-collaudo)
I dettagli per lo svolgimento della fase di Supporto e Manutenzione sono descritti nella Procedura Lifecycle Management (Allegato 3), per la quale si deve fare riferimento alle fasi 6 e 7, e nell’allegato 1.
Per l’erogazione dei servizi di assistenza e manutenzione del sistema informatico oggetto del capitolato, che dovranno essere quotati nel rispetto della copertura “STANDARD”, “ESTESO” e “H24” come definiti al paragrafo E.1 dell’Allegato 1 “Linee Guida per l’assistenza e la manutenzione dei software”, valgono gli SLA che sono illustrati e normati nel documento stesso, che è parte integrante del presente capitolato.
Il Fornitore, nell’allegato economico, dovrà valorizzare economicamente le 3 tipologie di copertura indicata con il nome di “STANDARD”, “ESTESO” e di “H24”.
Si intende attivo il vincolo V1 per tutta la durata dell’appalto.
Oltre al servizio di help desk e manutenzione ordinaria, normativa e correttiva, il contratto prevede la realizzazione di manutenzione evolutiva sulla piattaforma oggetto del bando. In merito ad essa si descrive la modalità di erogazione:
• Manutenzione evolutiva standard da erogarsi a consumo mediante moduli MEV come da procedura ‘ALLEGATO 4 - PA 45 2018 REV02 SOFTWARE CHANGE REQUEST’ ed attingendo ad una previsione di giornate annuali inserita nella scheda offerta economica; si precisa che non vi è alcuna garanzia di acquisizione di queste evoluzioni;
• Rientrano in questa tipologia le giornate previste per: formazione aggiuntiva, consulenza ed evoluzioni (gg on site o in house).
7 Allegati di Gara
Costituiscono parte integrante del presente capitolato i seguenti allegati:
7.1 Documenticontrattuali
Nella tabella sono riportati gli allegati standard contrattuali per Assistenza e Manutenzione Software e le procedure standard ESTAR a supporto del ciclo di vita del software:
ID | Documento | DescrizioneDocumento |
All. 1 | Linee Guida per l’assistenza e la manutenzione dei software | Delinea le caratteristiche del servizio di assistenza e manutenzione che l’Aggiudicatario dovrà garantire per tutta la durata dell’appalto. Illustra le peculiarità di un servizio di assistenza e manutenzione per un software gestionale, sia in termini di manutenzione ordinaria, sia in termini di manutenzione correttiva ed evolutiva. Esplicita i livelli di servizio attesi e la modalità di misurazione dei Service Level Agreement (SLA). Definisce le penali che il Cliente può applicare in caso di non rispetto dei livelli di servizio contrattualizzati. Specifica le modalità di interazione nel caso di disservizi che abbiano un impatto rilevante ai fini del rischio clinico. |
All. 2 | Esempio calcolo SLA | Fornisce a solo titolo di esempio un report di calcolo degli SLA che l’Aggiudicatario dovrà produrre in allegato alle fatture periodiche. È possibile ovviamente produrre reportistica più ampia e si precisa che quanto contenuto nell’esempio è il livello minimo richiesto. |
All.3 | Procedura Lifecycle Management | La procedura definisce il ciclo di vita del software |
All.4 | Procedura Change Request | La procedura definisce le modalità di gestione delle CHANGE REQUEST sui software in uso in ESTAR e nelle XX.XX., evidenziando il processo da attuare per la gestione delle attività che rientrano nell'ambito dei servizi di Manutenzione Evolutiva (MEV) sul software aggiudicatario per tutta la durata dell’appalto. Rientrano in questa procedura anche le attività eseguite dai fornitori che, seppur non sempre inquadrabili nella tipologia ‘CHANGE REQUEST’, hanno un impatto sulla gestione organizzativa delle manutenzioni evolutive (es. attività sistemistiche, estrazioni ad hoc, migrazioni di infrastrutture e DB, formazione, modifiche ai flussi DOC e RFC, ecc.), pertanto la presente procedura sarà applicata ad ogni ambito di utilizzo delle giornate on site e in house comprese nella fornitura. |
All.5 | Modulo per MEV | Modulo allegato ad All.4 da utilizzare per la definizione e quotazione delle attività di manutenzione evolutive (Change Request) |
All.6 | Procedura Collaudi Forniture Software | La procedura definisce le modalità con cui verranno eseguite le fasi di collaudo di una fornitura di software, definendo sia le fasi di collaudo relative alla realizzazione iniziale del progetto, sia quelle delle successive fasi di manutenzione evolutiva. |
All. 7 | Controlli DEC | Documento che include le attività di monitoraggio e controllo che in linea di massima sono di competenza del DEC. Il DEC nella autonomia gestionale che gli è propria potrà aggiungere/integrare le verifiche che riterrà idonee per monitoraggio e controllo della fornitura |
7.2 Documentidi definizioneambientetecnologico
Si ritengono parte integrante del presente capitolato i seguenti documenti di definizione dell’ambiente tecnologico di riferimento pubblicati alla pagina Web di ESTAR xxxx://xxxxxxx.xxxxx.xxxxxxx.xx/xxxxx.xxx/xxxxxxxxxxxxxx-xxx/0-xxxxxxxxxxxx-xxx-xxxxxxxx; si deve far riferimento all’ultima release vigente alla data di pubblicazione del presente bando:
• Regole di utilizzo della rete InterSST
• Linee Guida Tecnologiche
• CAST Descrizione del Modello
• CAST Specifiche Funzionali Interoperabilità ESB
• CAST Registry OID
• CAST Specifica Interfaccia Applicativa EventHandler
7.3 Allegati tecnologici da referenziare mediante link alla pagina web del sito di Regione Toscana
“Si ritengono parte integrante del presente capitolato i seguenti documenti di definizione delle RFC e dei Flussi Informativi pubblicati alle seguenti pagine Web di Regione Toscana:
❏ xxxx://xxx.xxxx.xxxxxxx.xx/xXxxxxxxxxx/xxxxxxx/xxxxxxXxxxxXXX
❏ xxxxx://xxx.xxxxxxx.xxxxxxx.xx/-/xxxxxx-xxxxxxxxxxx
8 Appendice A – Penali
Di seguito si riportano la definizione e la quantificazione delle penali che l’Ente si riserva di applicare oltre alle penali previste per il servizio di assistenza e manutenzione che sono già definite nell’Allegato 1 e salvo il risarcimento del maggior danno.
Rispetto ai vincoli descritti nel capitolo 6, di seguito sono indicate le relative penalità:
Codice Vincolo | Gravità | Importoe modalitàdi applicazione |
V1 | ALTA | Fino ad un massimo di 2000 euro una tantum/per ogni occorrenza |
V2 | ALTA | Fino ad un massimo di 1000 euro/giorno per ogni giorno solare di ritardo rispetto al GANTT formalmente approvato dal DEC |
V3 | MEDIA | Fino ad un massimo di 500 euro/giorno per ogni giorno lavorativo di ritardo |
V4 | BASSA | Fino ad un massimo di 200 euro/giorno per ogni giorno lavorativo di ritardo |
V5 | MEDIA | Fino ad un massimo di 2000 euro una tantum/per ogni occorrenza |
V6 | MEDIA | Fino ad un massimo di 2000 euro una tantum/per ogni occorrenza |
Deve considerarsi inadempimento e/o ritardo anche il caso in cui il fornitore esegua le prestazioni contrattuali in modo solo parzialmente difforme dalle prescrizioni contenute nella documentazione di gara e nell'offerta presentata dallo stesso fornitore.