INDICE
Capitolato Tecnico di Gara avente ad oggetto “Acquisizione SW per
Bio Banca per l’Azienda Ospedaliera Universitaria Pisana
INDICE
1. Introduzione 3
2. Oggetto della fornitura ed esclusioni 5
3. Contesto 6
4. Processi funzionali ed eventuali sistemi informatici correlati 7
5. Requisiti Funzionali e Tecnologici del sistema 8
6. Offerta Tecnica - Predisposizione e Vincoli 13
7. Allegati di Gara 16
8. Appendice A – Penali 17
1. Introduzione
Premessa
Il presente capitolato disciplina gli aspetti tecnici della fornitura, in locazione operativa, di un sistema software per la gestione delle attività della Biobanca dell’Azienda Ospedaliero Universitaria Pisana; con il capitolato infatti si intendono fornire le specifiche ed indicare i requisiti di base e specifici del sistema informatico richiesto e di tutti i servizi correlati. La fornitura riguarderà soltanto l’acquisizione del software e non prevede l’acquisizione dell’hardware, che sarà messo a disposizione dall’Amministrazione.
Con l'istituzione della biobanca multispecialistica BMS in Azienda Ospedaliera Pisana stanno entrando nella fase operativa vari progetti multicentrici che vedono coinvolta la Biobanca, per cui è scaturita la necessità di adeguamento del software per la gestione di più banche dati, anche relativamente ai campioni della pandemia Covid-19 in corso.
Gli aggiornamenti e le integrazioni del sistema informatico conseguenti alle variazioni della disciplina normativa di settore, successive alla fase di collaudo e intervenute durante la vigenza del contratto di fornitura, rientrano nell’oggetto contrattuale e non comportano oneri per gli enti del SSR.
1.1 Obiettivi
Obiettivo della procedura di affidamento in oggetto è quindi dotare la struttura di uno strumento informatico efficiente ed efficace per la gestione delle biobanche, i cui compiti principali sono la raccolta e la conservazione di materiale biologico utilizzato per diagnosi, per studi sulla biodiversità e per ricerca. Dunque la principale funzionalità cui il software deve assolvere è la gestione dei campioni di materiale biologico e dei dati associati nell’interesse pubblico di migliorare la capacità produttiva e la standardizzazione delle procedure con la riduzione del rischio clinico, attraverso l’utilizzo avanzato di sistemi di tracciabilità.
In specifico il sistema informatico dovrà supportare:
• gestione informatica dell’ Archivio biologico regionale in aderenza con l’attuale normativa in materia di privacy e trattamento dei dati sensibili (Regolamento Ue 2016/679 relativo alla protezione delle persone fisiche con riguardo al trattamento e alla libera circolazione dei dati personali). L’Archivio Biologico (istituito con DGR1223/2004) si configura come biobanca di sicurezza e ha iniziato l’attività nel Gennaio 2005 in aderenza alla normativa vigente in materia di trapianti : accettazione, processamento, stoccaggio e distribuzione di materiale biologico da coppie don/ric multi organo e donatori multitessuto della Regione Toscana, coppie don/ric organo da vivente, donatori muscolo scheletrico da vivente;
• gestione informatica della Biobanca Multispecialistica BMS a supporto della ricerca in aderenza con l’attuale normativa in materia di privacy e trattamento dei dati sensibili (Regolamento Ue 2016/679 relativo alla protezione delle persone fisiche con riguardo al trattamento e alla libera circolazione dei dati personali). La Biobanca BMS accetta, processa, custodisce e distribuisce il materiale biologico in accordo con le linee guida internazionali (ISBER / BBMRI) e nazionali (Presidenza del Consiglio dei Ministri- Comitato Nazionale per la Biosicurezza, le Biotecnologie e le Scienze della Vita. Linee Guida per la certificazione delle biobanche: 19 aprile 2006) per uniformare e standardizzare le variabili legate alle varie fasi del processo di biobancaggio. La biobanca multispecialistica BMS si pone al servizio dei ricercatori e dei cittadini : raccoglie, conserva e distribuisce campioni alla comunità scientifica per sviluppare studi in base a quanto convenuto nel consenso informato.
1.2 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 | Descrizione del 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.3 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 |
Tabella 2 - Glossario
1.5 Riferimenti Normativi
1. PA 45/2018 REV02 – “SOFTWARE CHANGE REQUEST Procedura Gestione Manutenzioni Evolutive e Normativa”
2. PA 46/2018 REV01 “SOFTWARE LIFECYCLE MANAGEMENT Procedura Gestione del Ciclo di Vita del Software”
3. PA 47/2018 “Collaudo forniture software - Procedura Collaudi Forniture Software”
4. PA 90/2020 “Gestione delle richieste di collegamento da remoto alle reti che ospitano le risorse ICT del SSR gestite da ESTAR”
5. Circolare AGID n. 4 del 15/12/2016 – Monitoraggio sull’esecuzione dei contratti
6. Linee guida AGID su acquisizione e riuso di software per le pubbliche amministrazioni del 23 settembre 2019 5/21
7. Piano Triennale per l’informatica nella Pubblica Amministrazione 2020 - 2022
8. Linee guida AGID “La sicurezza nel procurement ICT”
9. UNI ISO 20387:2019 “Biotecnologie - "Biobanking" - Requisiti generali per il "biobanking".
10. Legge 11 settembre 2020, n. 120, di conversione con modifiche del decreto-legge
16 luglio 2020, n. 76 (c.d. Decreto Semplificazioni), recante misure urgenti per la semplificazione e l'innovazione digitale.
2. Oggetto della fornitura ed esclusioni
2.1 Oggetto della fornitura
Il prodotto informatico oggetto della presente fornitura, a seguito riferito come “Prodotto”, riguarda un software gestionale in lingua italiana che dovrà assicurare le specifiche funzionali meglio descritte al capitolo 5 – “Requisiti Funzionali e Tecnologici del sistema”. Il Prodotto sarà utilizzato dal personale della struttura di riferimento assicurando la riservatezza e la conservazione dei dati e dovrà garantire il supporto completo dell’attività della SOD Biobanche della AOUP, che va dalla conservazione e stoccaggio dei campioni biologici alla certezza della reperibilità e tracciabilità del campione stesso, nonché garantire la necessaria reportistica ed ogni altra esigenza di aggregazione del dato strutturato al fine di soddisfare i debiti informativi della struttura verso soggetti istituzionali ed altri enti autorizzati.
Il Prodotto dovrà essere utilizzato in numero illimitato sia come utenti che come postazioni di lavoro registrate e/o contemporanee, nel tempo d’utilizzo e relativamente a qualsiasi altro parametro eventualmente limitante (connessioni, integrazioni, ecc.).Tutte le licenze software necessarie al funzionamento lato server, ivi inclusi gli RDBMS, sono a carico dell’aggiudicatario. La stazione appaltante si riserva di poter acquisire diversamente le licenze necessarie, in particolare su strumenti di acquisto più vantaggiosi economicamente (es Accordo quadro per Oracle, ma anche Consip GOL per Microsoft, ecc.).
Il prodotto dovrà essere interoperabile con i sistemi informatici già in dotazione all’ente, nel rispetto di quanto indicato alla voce “Integrazioni” del paragrafo 4.2 ed a quanto più specificatamente indicato dalle Linee Guida Tecnologiche referenziate al paragrafo 7.2 applicando senza oneri aggiuntivi eventuali versioni aggiornate delle specifiche vigenti al momento dell’avvio del progetto.
I dettagli tecnici delle integrazioni di cui al paragrafo 4.2, devono essere oggetto dell’offerta tecnica in termini di soluzione proposta e secondo le modalità di integrazione rese necessarie sulla base delle specifiche tecniche rese disponibili dai fornitori dei servizi invocati.
Le tre integrazioni previste sono:
• con l’Anagrafe Unica Regionale tramite lo standard RFC249;
• con l’applicativo LIS;
• con la cartella di reparto attualmente in uso in ambito ospedaliero dell’AOUP. Altre funzionalità accessorie:
• comunicazione verso la piattaforma web del network BBMRI (Nodo Nazionale della Infrastruttura di Ricerca Europea) tramite la funzionalità di caricamento dei dati relativi alle collezioni dei campioni esportati mediante formati "universali", es. csv, in modo che i ricercatori interessati possano visualizzare la tipologia di campioni per contatti.
• avere la possibilità di mettere a punto dei cataloghi virtuali.
E’ inoltre indispensabile l’importazione completa e certificata dei dati registrati nella banca dati gestita dall’attuale software.
Le ditte partecipanti alla presente gara dovranno rendere disponibile all’organismo tecnico di valutazione un link cui accedere per visionare in demo il prodotto software offerto ed un contatto per l’eventuale necessità di supporto all’accesso alla demo. I sistemi proposti dovranno prevedere un ambiente di produzione ed il relativo ambiente di test per tutta la durata dell’appalto.
L’offerta dovrà comprendere anche la manutenzione ed assistenza per tutta la durata contrattuale, comprensivo del rilascio degli aggiornamenti del software, come da dettaglio Allegato A1 Linee Guida Assistenza e Manutenzione Software.
2.2 Obiettivi specifici della fornitura
Saranno da garantire le seguenti funzionalità, meglio dettagliate al paragrafo 5.1:
• gestione del paziente e dei dati associati (consenso informato, referti, cartella clinica etc.);
• gestione dei campioni e dei dati associati (test, controlli di qualità etc.);
• gestione delle aliquote;
• gestione dello stoccaggio;
• gestione delle transazioni (In/out);
• gestione della spedizione/rientro dei campioni;
• gestione dei Report;
• gestione delle etichette;
• supporto dei Barcode;
• possibilità di creare cataloghi virtuali.
2.3 Elementi non compresi nella fornitura
Non fanno parte della fornitura:
• l’infrastruttura hardware lato client, server e di rete (sia apparati che connettività);
• i sistemi operativi delle postazioni di lavoro;
• l’onere derivante dall’attività necessaria a recupero dei dati se svolta da fornitori terzi;
• l’onere derivante dall’attività necessaria all’attivazione delle integrazioni con altri sistemi informatici, se svolta da fornitori terzi.
3. Contesto
Al 30-06-2020 sono conservati nella biobanca 14.572 campioni e 170.356 aliquote di materiale biologico. Il flusso in entrata di materiale biologico si attesta sui 185 campioni al mese (circa 2700 aliquote/mese), numero destinato ad incrementare in maniera significativa nel breve periodo con l’avvenuta attivazione della Biobanca multispecialistica BMS a supporto della ricerca, che va ad aggiungersi all’Archivio Biologico regionale (biobanca di sicurezza) e al Centro conservazione valvole cardiache (Istituto dei Tessuti) che si pone come piattaforma trasversale di servizio sia per le strutture presenti all’interno dell’AOUP e sul territorio regionale che per altre istituzioni con finalità scientifiche e assistenziali, con l’obiettivo di implementare una rete di afferenze multicentriche e multidisciplinari al fine di biobancare materiale biologico relativo alle discipline di maggior rilievo in ambito sanitario.
Il software sarà utilizzato da circa dieci operatori, diversificati per ruolo, su altrettante postazioni, fatte salve necessità di espansioni future non computabili come onere aggiuntivo.
4. Processi funzionali ed eventuali sistemi informatici correlati
4.1 Modello Applicativo
Si elencano i principali macro-processi relativi ai campioni che il software oggetto di fornitura dovrà completamente supportare in ogni fase:
• Accettazione
• Processamento
• Stoccaggio, custodia
• Distribuzione, rientri
Dal punto di vista architetturale l’infrastruttura, sia di rete che sistemistica, è a carico dell’ente appaltante che ne garantisce il corretto funzionamento; a tal proposito si precisa che:
• il fornitore dovrà fornire i requisiti necessari al corretto funzionamento del Prodotto e si impegna a fornire un’architettura tecnico-applicativa compatibile con le caratteristiche infrastrutturali di rete e dei server applicativi indicandone il corretto dimensionamento, nel rispetto delle Linee Guida Tecnologiche indicate al paragrafo 7.2;
• l’ente appaltante non riconoscerà costi aggiuntivi nel caso in cui l’aggiudicatario abbia sottostimato i requisiti richiesti, che resteranno completamente a carico di quest’ultimo.
• l’ente appaltante si riserva di decidere a propria discrezione se i server saranno fisici o virtuali o di tipologia mista;
• il fornitore avrà le credenziali di amministratore per la gestione dei server applicativi, per l’accesso alla rete e per le attività di manutenzione accettando l’incarico di responsabile gestione dati ai sensi del GDPR e s.m.i.;
• sarà a carico del fornitore la gestione, come amministratore, di tutte le componenti applicative del software fornito.
4.2 Integrazioni con sistemi interni ed esterni
E’ richiesto che il Prodotto possa operare con i seguenti sistemi informatici dell’ente, per il raggiungimento degli obiettivi elencati:
Sistema Informatico | Fornitore esterno/nome prodotto | Principali funzioni |
Anagrafica pazienti centralizzata | Engineering s.p.a. (XMPI) | Identificazione anagrafica univoca e certificata del paziente, tramite i servizi di ricerca, aggiornamento, censimento, riconciliazione dell’Anagrafe Unica Soggetti SSR. |
Laboratorio anagrafe | Engineering s.p.a. (OpenLIS) | Chiamata contestualizzata sul paziente verso il LIS per visualizzare il referto relativo ad esami diagnostici a carico dei pazienti provenienti dal Laboratorio, |
Cartella di reparto ed ambulatoriale | Sviluppo interno Estar (Pleiade) | Chiamata contestualizzata sul paziente per la visualizzazione dei dati clinici ed antropometrici connessi agli accessi ospedalieri ed ambulatoriali, al fine di controllare ed arricchire il dossier dei dati relativi allo specifico campione |
5. Requisiti Funzionali e Tecnologici del sistema
La fornitura deve includere le funzionalità che seguono, classificate secondo la tematica delle funzioni.
5.1 Requisiti Funzionali
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 |
F1 | Caratteristiche di base | |
F1.1 | Possibilità di gestire campioni biologici e contenitori nel biobanking, basato su una struttura 1 PATIENT (parent) n SAMPLES (child) n ALIQUOTS (grandchild) n Transactions (great grandchild) | obbligatorio |
F1.2 | Assegnazione in automatico di un numero identificativo univoco e NON modificabile per ciascun campione (sample). Assegnazione in automatico di un numero identificativo univoco e NON modificabile per ciascuna aliquota (aliquot) in modo che campioni ed aliquote mantengano le loro identità univoche e separate. | obbligatorio |
F2 | Massima configurabilità e flessibità | |
F2.1 | Creazione e gestione di un numero sostanzialmente illimitato di congelatori e contenitori criogenici, di varie dimensioni e forme di scaffali, scatole, cannucce , armadi etc. con la possibilità di creare sottoinsiemi all’interno dello stesso freezer e di definire illimitate exceptions per adeguare la suddivisione ad ogni tipo di contenitore. Interfaccia grafica in grado di visualizzare la struttura del contenitore (freezer, cryotank etc.) e le posizioni delle singole aliquote nel box selezionato con la possibilità di visualizzare il codice identificativo di ciascuna aliquota/campione mediante menù configurabile (ad es poter scegliere se visualizzare l’ID della aliquota o un ID customizzato creato dal laboratorio per quella specifica collezione o un altro codice definito dall’utente) | obbligatorio |
F2.2 | Creazione di “sample data entry form” completamente configurabili utilizzando i campi di sistema e quelli definiti/creati dall’utente, illimitate e completamente separate per ogni banca dati. | obbligatorio |
F2.3 | Creazione di moduli di immissione “batch” in grado di creare campioni ed aliquote, stampa di etichette ed assegnazioni di posizioni dei congelatori | preferenziale |
F2.4 | Disponibilità di almeno 2000 campi completamente configurabili (es. possibilità di nominare il campo, di creare “sample data entry form” con n combinazioni dei campi , sia quelli definiti dall’utente che quelli di sistema, possibilità di programmare relazioni di dipendenza fra campi differenti, possibilità nei campi “choice list” , | obbligatorio |
sia “single choice” che “multiple choice”, di inserire tipologie illimitate di scelte , possibilità di scegliere nei campi numerico la lunghezza max di cifre che possono essere inserite) | ||
F2.5 | Poter utilizzare almeno le seguenti tipologie di campo: “testo”, numerico, “data/ora”, “vero/falso”, “Elenco di scelte a selezione multipla”, Elenco di scelte a selezione singola”, “solo lettura”, “Obbligatorio in base al valore di un altro campo” Inoltre : “conteggio” : campo contenenti il totale in base a determinate caratteristiche (es. consente di fare una ricerca in grado di individuare solo i campioni di siero che hanno un certo numero di aliquote che non sono mai state scongelate) “calcolato”: crea campi usando valori di altri campi e/o algoritmi creati dall’utente (utile nelle procedure di pseudonimizzazione dei campioni) “numero auto incrementato”: genera automaticamente numeri sequenziali | obbligatorio |
F2.6 | Possibilità di assegnare per ogni campo la caratteristica di unicità ovvero impedire che esistano nel database 2 valori identici per quel campo | obbligatorio |
F2.7 | Possibilità di escludere a priori per ogni campo di essere stampato su etichetta | preferenziale |
F2.8 | Possibilità di escludere a priori per ogni campo di essere stampato su report | preferenziale |
F2.9 | Possibilità di assegnare ad ogni campo l’obbligo di essere compilato e non lasciato in bianco | obbligatorio |
F2.10 | Possibilità di configurare le etichette inserendo, da file esterni, file di testo, grafica | preferenziale |
F2.11 | Possibilità di utilizzare per la composizione dell’etichetta ogni campo definito dall’utente , in qualunque numero e combinazione, sia per quanto attiene ai campi relativi al campione che a quelli relativi alle aliquote. Possibilità di inserire Barcode 1D,2D. | obbligatorio |
F2.12 | Possibilità di creare Gruppi separati che sono in grado di possedere o condividere congelatori (limitando per es. l’accesso ad altri gruppi), schermate di inserimento campioni, formati di ricerca, importazione, esportazione ed etichetta avanzati | preferenziale |
F2.13 | Possibilità di configurare viste SQL in grado di mostrare (in sola lettura) informazioni da altri database | migliorativo |
F2.14 | Possibilità di configurare mediante interfaccia grafica Report customizzati utilizzando i campi di sistema e quelli definiti dall’utente in qualunque numero e combinazione, inclusa la possibilità di stampare report sulla disposizione delle aliquote all’interno dei freezers/contenitori | obbligatorio |
F2.15 | Possibilità di importare/esportare dati nei più comuni formati | obbligatorio |
F2.16 | Possibilità di creare cataloghi virtuali, moduli di annotazione biomedica, alberi genealogici | migliorativo |
F2.17 | Interoperabilità : possibilità di integrarsi con i sistemi gestionali sanitari preesistenti e con eventuali sistemi automatizzati di gestione dei campioni biologici (es. workstation separazione siero/plasma , estrazione acidi nucleici etc) | Preferenziale |
F2.18 | Audit Trail non modificabile | Obbligatorio |
F3 | Funzionalità aggiuntive | |
F3.1 | Sezione “shipping” per la gestione della distribuzione/rientro dei campioni | obbligatorio |
F3.2 | Controllo delle aliquote in ingresso/uscita attraverso flussi di lavoro (ovvero gestire delle attività ripetitive che fanno parte delle attività quotidiane ricorrenti) | preferenziale |
F3.3 | Sezione gestione dei pazienti e dei dati/test associati attraverso data entry form dedicati | preferenziale |
F3.4 | Possibilità di criptare selettivamente il contenuto di alcuni campi e renderlo visibile solo mediante specifiche credenziali/profili di accesso | migliorativo |
F4 | Accesso utenti | |
F4.1 | Gestione di un sistema di sicurezza a tre livelli: Administrator, Data entry, View only con possibilità di creare più ruoli, permessi e restrizioni in base a compiti e restrizioni specifiche da assegnare per es. attraverso “multiple choice” su un elenco specifico (ad es. possibilità per un utente 1 di eliminare campioni e non aliquote , oppure aggiungere nuovi campioni, ma non modificare i vecchi) | obbligatorio |
F5 | Compatibilità con hw esistente | |
F5.1 | Il programma deve essere compatibile con le etichettatrici presenti nella biobanca (XXXXX mod BBP11 e BBP12) che utilizzano etichette resistenti ai vapori di azoto tipo wraparound landscape 2,625 X 0,96875 inches (w x h), printable area 1 X 0,96875 inches (w x h) | preferenziale |
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.2 Requisiti tecnologici
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. Inoltre dovrà essere installato in modo centralizzato nei data-center dell’Azienda Ospedaliera Pisana secondo un’architettura multitier (3-tier) come indicato dalle Linee Guida Tecnologiche più avanti referenziate (par. 7.2) il cui contenuto rappresenta vincolo obbligatorio di riferimento del presente oggetto di fornitura.
Il software deve poter essere utilizzato da qualsiasi pc con le seguenti caratteristiche:
● pc con Microsoft Office o Openoffice/Libreoffice;
● browser Internet Explorer 9 e successive release;
● browser Mozilla Firefox release corrente e successive;
● browser Google Chrome release corrente e successive;
La piattaforma dovrà preferibilmente consentire una distinzione in ambienti software corrispondenti alle singole aziende in caso di successiva acquisizione da parte delle Strutture organizzative delle aziende sanitarie locali e ospedaliere toscane e/o di Estar.
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: ○ 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; ○ Forum: ovvero uno spazio virtuale dedicato agli operatori per lo scambio di esperienze, al confronto e alla discussione; ○ 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 periodicità di rilascio non superiore a 6 mesi. | Preferenziale |
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 | Preferenziale |
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 l’organismo tecnico di valutazione si riserva di valutare come proposta migliorativa.
5.3 Recupero di dati storici
Dovranno essere migrati i dati storici completi a partire dall’anno 2005 dall’archivio precedentemente gestito con Freezerworks 2018 (Database Relazionale 4D) mantenendo la semantica dei dati originali. Attualmente sono conservati nella biobanca circa 15.000 campioni e
180.000 aliquote di materiale biologico; l’archivio contiene solo dati strutturati e non documenti.
Il recupero è indispensabile al passaggio in produzione e dovrà riguardare tutti i dati presenti al momento dell’avvio, al fine di garantire la continuità del servizio.
Non sono da considerarsi a carico dell’aggiudicatario i costi del recupero dati imputabili a fornitori terzi.
5.4 Requisiti di sicurezza
In riferimento alle Linee guida AGID “La sicurezza nel procurement ICT”, oltre a quanto già previsto dalle “Linee guida per i servizi di assistenza e manutenzione per i software” (all.1), dalla scheda “Compliance privacy software” (all.7) e dalla PA 47 “Verifiche di conformità” (all.6) si elencano i seguenti requisiti:
1. il fornitore deve adottare al proprio interno le procedure e politiche di sicurezza definite dall’amministrazione committente, con particolare riferimento alle modalità di accesso ai sistemi dell’amministrazione, all’hardening (esempio installazione di soluzioni di end point security) dei dispositivi utilizzati dal fornitore, alla gestione dei dati dell’amministrazione;
2. qualora il fornitore non possegga certificazione ISO/IEC 27001 deve usare un Sistema di Gestione della Sicurezza delle Informazioni (SGSI) aggiornato nel tempo e/o predisporre un piano di qualità secondo lo standard ISO 10005
3. qualora il fornitore subisca un attacco, in conseguenza del quale vengano compromessi sistemi del committente da lui gestiti, deve farsi carico delle bonifiche del caso, e riportare i sistemi in uno stato di assenza di vulnerabilità
4. il fornitore deve condividere le informazioni necessarie al fine di garantire il corretto monitoraggio della qualità e della sicurezza, eventualmente pubblicando le stesse nel portale della fornitura;
5. il fornitore si impegna a sottoscrivere una clausola di non divulgazione (NDA) sui dati e sulle informazioni dell’amministrazione;
6. le soluzioni e i servizi di sicurezza proposti dal fornitore devono essere aggiornati dal punto di vista tecnologico, con riferimento all’evoluzione degli standard e del mercato; devono essere conformi alle normative e agli standard di riferimento applicabili; devono venire adeguati nel corso del contratto, senza oneri aggiuntivi, alle normative che l’UE o l’Italia rilasceranno in merito a servizi analoghi.
5.5 Migrazione verso altre piattaforme a fine contratto
Al fine di agevolare eventuali attività di migrazione verso altre piattaforme a fine contratto, l’aggiudicatario dovrà mettere a disposizione tutti i dati presenti nel sistema software esplicitandone i contenuti in formati standard fornendo tutto il necessario supporto alla migrazione, con tempistiche utili all’avvicendamento con altro fornitore per garantire la massima continuità operativa. Si ritiene utile valutare eventuali proposte in merito da parte dei concorrenti.
5.6 Requisiti Minimi Formazione e Affiancamento all’Avvio
La formazione riguarda tutte le attività inerenti la preparazione del personale coinvolto al pieno utilizzo del nuovo software e dovrà essere necessariamente erogata entro l’avvio in tempi congrui definiti dal committente.
Tenendo presente che si prevede la necessità di tre giornate formative, una per l’amministratore e due per gli utilizzatori, l’offerta deve contenere il dettaglio del piano formativo con almeno queste informazioni:
• metodologia adottata, tenendo presente che le sessioni dovranno essere erogate on-site senza oneri aggiuntivi, salvo deroghe imposte dalla normativa vigente al momento dell’erogazione, presso la struttura ove sarà presente il nuovo applicativo, distinguendo in base al profilo professionale di amministratore/utilizzatore;
• descrizione dei corsi, specificando il numero minimo e massimo di docenti e partecipanti, gli obiettivi formativi, le modalità di verifica dell’apprendimento, ecc.;
• la documentazione, la manualistica ed il materiale informativo contenuto all’interno del
sistema, specifica per l’impianto e non quella generica di prodotto, che dovrà essere consegnata al massimo una settimana prima delle sessioni formative.
• I curricula del personale docente impiegato.
L’affiancamento all'avvio dovrà essere necessariamente erogato on-site senza oneri aggiuntivi e deve prevedere almeno una risorsa per una giornata per le attività preliminari inerenti il recupero dati e la configurazione del sistema ed almeno una risorsa per le due giornate successive all’avviamento operativo, secondo gli orari di servizio.
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, recupero dati, 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 dell’organismo tecnico di valutazione, 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 |
DOCUMENTO A | Organizzazione 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 |
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 |
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 report offerti (informazioni e aggregazioni); ● Ergonomicità di accesso e fruizione dei report; ● Flessibilità nell'export dei dati |
DOCUMENTO D | Documentazione | ● 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 (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 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à ● Recupero dati ● Architettura SOA ● Documentazione dei servizi di interoperabilità |
DOCUMENTO G | Sviluppo del progetto | ● Caratteristiche qualitative del PM ● Attinenza del Gantt e delle modalità di esecuzione in relazione a quanto descritto nella Procedura LIFECYCLE Management (Allegato 3) ● Grado di copertura delle check list di collaudo |
DOCUMENTO H | Migliorie e Roadmap | ● Caratteristiche migliorative rispetto a quanto richiesto; ● Roadmap di sviluppo del prodotto software per gli anni successivi |
L’offerta tecnica potrà essere aggiornata e/o maggiormente dettagliata nel progetto esecutivo, a tal fine e per tutti i dettagli sulle modalità di svolgimento dei progetti e per il ciclo di vita del software, si deve fare riferimento alle fasi 3, 4, 5 dell’Allegato 3 “Procedure Lifecycle Management”.
6.1 Elementi per la valutazione dell’offerta
L’offerta, per la valutazione dei criteri di congruità ai fini dell’aggiudicazione, deve contenere i seguenti elementi:
- Obbligatori
• requisiti funzionali definiti come obbligatori al paragrafo 5.1
• requisiti tecnologici definiti come obbligatori al paragrafo 5.2
• recupero dello storico di cui al paragrafo 5.3
• piena compatibilità con le Linee Guida Tecnologiche referenziate al paragrafo 7.2 evidenziando che l’architettura tecnologica deve essere multitier a tre livelli (3-tier):
o strato di presentazione, implementato tramite web server
o strato di business logic, implementato tramite application server
o strato di persistenza, implementato tramite l’utilizzo di Relational Database Management System (RDBMS);
• implementazione di un’integrazione anagrafica utilizzando i servizi di accesso all’Anagrafe Unica Soggetti SSR. Vedi “ANAGRAFE Guida all’implementazione della RFC249”. scaricabile dal link referenziato al paragrafo 7.2
• possibilità di richiamare le informazioni di contesto relative ai soggetti trattati presenti nell’applicativo LIS e nella cartella di reparto, come descritto nel paragrafo 4.2
• requisiti ritenuti obbligatori in allegato 7 – scheda compliance privacy software tab.3
- Preferenziali
• requisiti funzionali definiti come preferenziali al paragrafo 5.1
• requisiti tecnologici definiti come preferenziali al paragrafo 5.2
• requisiti di sicurezza indicati al paragrafo 5.4
• prezzo più basso
Fase di Implementazione - definizione dei vincoli
Nella predisposizione del Gantt relativo alle attività oggetto della fornitura il concorrente, dovrà rispettare i seguenti vincoli:
Codice Vincolo | Descrizione Vincolo | Gravità (ALTA/MEDIA/ BASSA) |
V1 | Avviamento della nuova piattaforma entro un mese dall’ordine | ALTA |
V2 | Verifiche di conformità non esitate positivamente e che non impediscono l’avvio in uso del sistema, non risolte entro 30 gg dalla formalizzazione del DEC | MEDIA |
V3 | Predisposizione della documentazione, help on line, ecc. entro i 20 gg precedenti la formazione e l’avvio | MEDIA |
V4 | Aggiornamento semestrale della documentazione e dell’help on line | BASSA |
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.
Fase di Supporto e 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.
Inoltre, facendo riferimento alle fasce orarie indicate nell’Allegato 1, si precisa che per questo software si intendono coperte le seguenti fasce:
supporto esteso lunedì – sabato dalle ore 8 alle ore 18
Per l’erogazione dei servizi di assistenza e manutenzione del sistema informatico oggetto del capitolato, che dovranno essere garantiti nel rispetto della copertura standard come definita 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. Si precisa che tali servizi possono essere erogati anche in collegamento remoto da parte del fornitore la cui richiesta andrà inoltrata al RES/DEC di riferimento utilizzando il modello in allegato 10.
Si intendono attivi il vincolo V4 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: servizio DBA a consumo, sviluppo software (gg in house), consulenza ed evoluzioni (gg on site).
7. Allegati di Gara
Costituiscono parte integrante del presente capitolato i seguenti allegati:
7.1 Documenti contrattuali
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 | Document o | Descrizione Documento |
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 e suoi allegati | 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 | Compliance Sicurezza e Privacy (Con scheda da compilare a cura di ciascun Concorrente) | Il documento illustra le peculiarità dei progetti tecnologici in ambito sanitario, in merito alle problematiche di privacy imposte dalle normative vigenti. In particolare, per i software sanitari, stabilisce buone pratiche evidenziando la necessità di evoluzione verso sistemi nativamente sviluppati secondo i principi di ‘privacy by design’ e ‘privacy by default’. Attenzione: è richiesta la compilazione della scheda ad ogni concorrente. |
All. 8 | Scheda di dettaglio economico | Schema da utilizzare per l’offerta economica |
All. 9 | 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. |
All 10 e suoi allegati | PA 90/2020 gestione accessi da remoto | La procedura definisce le modalità con cui saranno gestite le richieste di collegamento da remoto alle reti che ospitano le risorse ICT del SSR amministrate da ESTAR |
7.2 Documenti di definizione ambiente tecnologico
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
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à | Importo e modalità di applicazione |
V1 | ALTA | Fino ad un massimo di 500 euro/giorno per ogni giorno solare di ritardo rispetto al GANTT formalmente approvato dal DEC |
V2 | MEDIA | Fino ad un massimo di 100 euro/giorno per ogni giorno lavorativo di ritardo |
V3 | MEDIA | Fino ad un massimo di 100 euro/giorno per ogni giorno lavorativo di ritardo |
V4 | BASSA | Fino ad un massimo di 50 euro/giorno per ogni giorno lavorativo di ritardo |
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.