Appalto per l’affidamento dei servizi di personalizzazione, avvio, assistenza e manutenzione dei Sistemi Informativi occorrenti al Servizio di Prevenzione dell’ASUR Marche
Appalto per l’affidamento dei servizi di personalizzazione, avvio, assistenza e manutenzione dei Sistemi Informativi occorrenti al Servizio di Prevenzione dell’ASUR Marche
LOTTO 1 - Acquisizione dei Servizi propedeutici per il Riuso della Piattaforma SIPSO 2.0 - Sistema Informativo Per la gestione degli Screening Oncologici
Capitolato Tecnico
Versione 1.1
Progettisti:
Xxx. Xxxxx Xxxxx - Collaboratore tecnico professionale Area Dipartimentale Sistemi Informativi Asur Marche – Direzione Generale
Dott.ssa Xxxxxxxxx Xxxxxxxxxx - Direttore Medico Unità Operativa Complessa ISP Screening Oncologici Asur Marche – Area Vasta 2
Xxx. Xxxxxxxx Xxxxxxxx - Collaboratore tecnico professionale Area Sistemi Informativi Asur Marche – Area Vasta 2
Indice
1. INTRODUZIONE 3
1.1 Termini Tecnici Acronimi e Abbreviazioni 3
1.2 Contesto organizzativo e di informatizzazione 3
1.3 Normativa di Riferimento 7
2. INQUADRAMENTO DEL SISTEMA DA REALIZZARE 7
2.1 Obiettivi 7
2.2 Valutazione delle principali soluzioni in riuso disponibili 8
2.3 Requisiti Generali (RG) 10
2.4 Requisiti Funzionali Specifici (RF) 11
2.5 Requisiti Tecnici (RT) 16
2.6 Architettura del sistema e caratteristiche hardware 16
3. OGGETTO DELL’APPALTO 17
3.1 Descrizione di dettaglio dei servizi di manutenzione ed assistenza 18
3.2 Descrizione di dettaglio dei servizi di formazione e affiancamento 20
3.3 Inizio e durata delle attività 21
4. MODALITÀ DI PRESENTAZIONE DELL’OFFERTA 21
5. MODALITÀ DI ESECUZIONE DELL’APPALTO 22
5.1 Direttore dell’Esecuzione 22
5.2 Responsabile dell’Attuazione 22
5.3 Gruppo di coordinamento 23
5.4 Gestione del contratto 23
5.5 Documentazione da produrre 23
5.6 Durata del contratto 25
5.7 Modalità della verifica di conformità 26
5.8 Criteri di aggiudicazione 27
5.9 SLA 30
6. ALLEGATO 1 – SCHEMA DI OFFERTA TECNICA 31
1. INTRODUZIONE
1.1 Termini Tecnici Acronimi e Abbreviazioni
Il seguente glossario dei termini tecnici, acronimi ed abbreviazioni, consente di definirne precisamente il significato, allo scopo di limitare al minimo le possibili incomprensioni quando tali termini abbiano diverse interpretazioni in contesti o domini applicativi differenti.
AAVV | Aree Vaste | ||||
Aggiudicatario | Il concorrente al quale è stata aggiudicata la realizzazione del software e dei servizi connessi | ||||
AGID | Agenzia per l’Italia Digitale | ||||
ARCA | Anagrafe Regionale Centralizzata degli Assistiti | ||||
ASR | Anagrafe Sanitaria Regionale | ||||
ASUR | Azienda Sanitaria Unica Regionale delle Marche | ||||
DEC | Direttore dell’Esecuzione | ||||
MMG | Medico di Medicina Generale | ||||
RUP | Responsabile Unico del Procedimento | ||||
Servizi di manutenzione correttiva | Complesso delle attività volte ad eliminare difetti del prodotto rispetto ai requisiti funzionali previsti | ||||
Servizi di manutenzione adeguativa | Complesso delle attività volte ad espandere/adattare le funzionalità del prodotto per renderlo aderente alle nuove disposizioni di legge a livello nazionale e regionale; nella manutenzione adeguativa sono ricomprese anche tutte quelle modifiche al software necessarie per renderlo rispondente a eventuali nuove esigenze, comprese le stampe di output, oltre che per modifiche normative nazionali e regionali. | ||||
Servizi di manutenzione evolutiva | Complesso delle attività volte ad espandere/adattare le funzionalità del prodotto in rapporto a nuove esigenze specifiche dell’utente | ||||
SIPSO 2.0 | Sistema Informativo Screening Oncologici | Per | la | gestione | degli |
SSR | Servizio Sanitario Regionale | ||||
Stazione appaltante | Soggetto responsabile della procedura di gara |
Tabella 1 - Principali acronimi e termini tecnici utilizzati nel documento.
1.2 Contesto organizzativo e di informatizzazione
La Legge Regione Marche n. 13 del 20 giugno 2003 ha istituito l’Azienda Sanitaria Unica Regionale (ASUR), unificando le precedenti 13 ASL e riformando l’intero assetto istituzionale del sistema sanitario della Regione Marche; l’esperienza di un’unica azienda sanitaria nella Regione è stata la prima in Italia, con un dimensionamento territoriale che corrisponde all’intero territorio regionale e con una popolazione assistita di più di 1.500.000 di cittadini.
Sulla base delle modifiche introdotte con la Legge Xxxxxxx Xxxxxx x. 00 del 1 agosto 2011, l’ASUR è articolata in cinque Aree Vaste, di seguito rappresentate, le quali hanno il compito di assicurare alla popolazione residente le prestazioni incluse nei livelli essenziali di assistenza (LEA) e garantire l'equo accesso ai servizi e alle funzioni di tipo sanitario, sociale e di elevata integrazione sanitaria.
In tale contesto, l’ASUR conserva la propria mission di garantire in modo costante ed uniforme la tutela dei cittadini residenti nell’intero territorio della Regione Marche. La dimensione regionale favorisce il perseguimento dell’obiettivo di rendere l’offerta dei servizi sanitari e socio-sanitari omogenea sul territorio ed equamente accessibile, nonché la possibilità di leggere in modo unitario e
coerente i bisogni di salute dei cittadini, nella prospettiva di fornire risposte appropriate su più livelli di complessità.
La programmazione aziendale 2018-2020 è fortemente condizionata dalle dinamiche del Fondo Sanitario Nazionale e dalle molteplici manovre adottate dal governo centrale per la riduzione della spesa pubblica.
In particolare, a rettificare l’iniziale previsione di Fabbisogno prevista nel Patto per la Salute 2014- 2016, che prevedeva quota 115,444 miliardi di euro già per l'anno 2016, è intervenuta dapprima l'Intesa Stato Regioni del 11 febbraio 2016 con la quale sono state stabilite le modalità di conseguimento degli obiettivi di finanza pubblica di cui al comma 680 dell'art. 1 della L. 208/2015 (Legge di Stabilità 2016) per un importo di Euro 3.500 milioni per l'anno 2017 e Euro 5.000 milioni a decorrere dall'anno 2018 rideterminando il Fabbisogno Nazionale in Euro 113.063 milioni per l'anno 2017 e Euro 114.998 milioni per l'anno 2018.
Successivamente, l'articolo 1, comma 392 della Legge di stabilità 2017 ha rideterminato in diminuzione il livello del fabbisogno sanitario nazionale cui concorre lo Stato rispettivamente in
113.000 milioni di euro e in 114.000 milioni di euro; per l'anno 2019 il livello del finanziamento del fabbisogno sanitario nazionale standard cui concorre lo Stato è stabilito in 115.000 milioni di euro. Poiché le autonomie speciali non hanno sottoscritto i singoli Accordi con lo Stato, al fine di assicurare gli effetti finanziari risultanti dalla rideterminazione del livello di finanziamento del SSN, il MEF, con decreto del 5 giugno 2017, ha ridotto di 423 milioni il livello del finanziamento del SSN cui concorre lo Stato per l'anno 2017 e di 604 milioni a decorrere dal 2018.
Per l’anno 2018, pertanto, allo stato attuale, il livello del finanziamento del fabbisogno sanitario nazionale standard cui concorre lo Stato per il triennio 2017-2019 risulta pari rispettivamente a Euro
112.577 milioni, 113.396 milioni e 114.396 milioni, con un incremento dello 0,7% nel 2018 rispetto al 2017 (pari a Euro 819 milioni). Ciò per la Regione Marche significano 6,3 milioni di euro in più rispetto al 2017.
A fronte di tale aumento, nel 2017 il SSR ha dovuto sostenere maggiori costi per accantonamenti per rinnovi contrattuali di 4,2 milioni (applicando la percentuale di 1,45% del DPCM 27 febbraio 2017).
Alla luce di tali vincoli normativi descritti dettagliatamente nella DGRM 1617 del 28/12/2017 di autorizzazione provvisoria alla gestione del Budget 2018 degli Enti del SSR, la programmazione economica regionale dell’anno 2018 prevede un abbattimento dei costi gestionali dell’ASUR dell’anno 2017 del 2%, così come riportato nella DGRM 1617 del 28/12/2017. Con tale delibera, infatti, la Regione Marche ha autorizzato gli Enti del Servizio Sanitario Regionale e quindi anche l’ASUR, alla gestione provvisoria dei rispettivi Bilanci economici preventivi anno 2018 per lo svolgimento delle sole attività istituzionali, assegnando tetto di spesa per l’anno 2018 pari a Euro 2.329.068.069, per la quota relativa ai costi di esercizio al netto degli scambi infragruppo, rinviando ad atto successivo l’assegnazione della quota relativa agli investimenti con fondi correnti.
A fronte di tale programmazione regionale, l’ASUR deve intervenire con azioni di riorganizzazione e di razionalizzazione della spesa al fine di assicurare il rispetto del livello di Budget assegnato dalla Regione, viste le risorse consumate l’anno precedente e le attività avviate che producono un trascinamento di maggiori costi sull’anno 2018.
La realizzazione del nuovo S.I. per il Dipartimento di Prevenzione risponde pertanto ai seguenti obiettivi organizzativi previsti nel Piano delle Performance 2018-2020.
1) Mantenimento dell’equilibrio di bilancio. Il mantenimento dell’equilibrio di bilancio per l’ASUR e per tutti gli Enti del SSR costituisce fattore determinante per la sostenibilità del Servizio Sanitario Regionale e condizione necessaria per garantire nel tempo l’erogazione dei livelli essenziali di assistenza. Favorire la prevenzione con il supporto di un adeguato sistema informativo può aiutare per ridurre il bisogno di cure ed i relativi costi di sistema.
2) Miglioramento dei Livelli Essenziali di Assistenza. La regione partecipa attivamente ai programmi di screening e grazie a questi nell'ultimo biennio (2015-16) sono stati diagnosticati n. 376 casi di carcinomi della mammella; nello stesso biennio sono stati diagnosticati n. 197 casi di carcinomi del colon-retto e ben 908 adenomi avanzati, lesioni di natura pre-neoplastica del colon, la quasi totalità asportate per via endoscopica. Per quanto riguarda le neoplasie della cervice nel triennio ultimo di riferimento (2014-16; dati Regione Marche-ARS), sono stati diagnosticati n. 36 carcinomi della cervice e n. 706 neoplasie intra-epiteliali della cervice uterina (CIN) di grado avanzato (CIN 2-3), tutte trattate in maniera mininvasiva.
Il riferimento normativo, ma anche metodo logico per le principali attività dell'Area della Prevenzione, è rappresentato dal Piano Nazionale della Prevenzione (PNP), parte integrante del Piano Sanitario Nazionale, che affronta le tematiche relative alla promozione della salute e alla prevenzione delle malattie e prevede che ogni Regione predisponga e approvi un proprio Piano. Nel PNP 2014/2018, prorogato al 31/12/2019, sono stati individuati i macro-obiettivi ad elevata valenza strategica, perseguibili dalle Regioni attraverso la messa a punto di piani e programmi che, partendo dagli specifici contesti locali e su un approccio il più possibile intersettoriale e sistematico, permettano di raggiungere i risultati attesi. I macro- obiettivi sono stati individuati e fissati sulla base di specifiche priorità: ridurre il carico di malattia; investire sul benessere dei giovani; rafforzare e confermare il patrimonio comune di pratiche preventive; rafforzare e mettere a sistema l'attenzione a gruppi fragili; considerare l'individuo e le popolazioni in rapporto al proprio ambiente.
Per dare attuazione a tutti i macro-obiettivi del Piano Nazionale, la Regione Marche ha attivato, nell'ambito del proprio Piano Regionale della Prevenzione (PRP), 12 programmi regionali con 77 linee di intervento, i cui obiettivi specifici risultano coerenti con quelli centrali, con l'analisi di contesto locale e con i risultati raggiunti dai precedenti Piani. Con la DGR 540/2015, modificata con la DGR 202/2016, sono stati approvati gli “Interventi regionali di attuazione del Piano Nazionale della Prevenzione 2014 -2018”. Con la DGR 887/2018 è stata approvata la rimodulazione 2018 e la pianificazione 2019 a seguito dell'Atto d'intesa
n. 247 del 21.12.2017, che ha esteso al 31 dicembre 2019 la validità del Piano Nazionale della Prevenzione. Il Piano si sviluppa in un quadro strategico pluriennale e la programmazione prevede azioni “basate sull'evidenza”, già sperimentate e in grado, nel medio-lungo termine, di produrre un impatto sia di salute sia di sistema, da realizzare attraverso interventi sostenibili e “ordinari”; incorpora inoltre gli obiettivi di Piani nazionali di settore.
In sintesi, gli elementi maggiormente innovativi del PRP delle Marche sono: l'estensione degli interventi che abbracciano l'intero arco della vita (Life course); l'articolazione per setting, intesi come contesti (servizio sanitario, scuola, lavoro, comunità, ecc.) in cui è possibile raggiungere più facilmente individui e gruppi di popolazione per promuovere la salute e realizzare interventi di prevenzione; l'impiego di azioni basate su evidenze di efficacia e buone pratiche; l'intersettorialità, con il coinvolgimento di diversi attori/istituzioni, finalizzati a rendere facili le scelte salutari, sviluppando reti e alleanze secondo l'approccio europeo della salute in tutte le politiche. Queste sono le modalità di sviluppo del settore che saranno ottimizzate e proseguite nell'ambito del presente Piano Socio Sanitario Regionale.
Il sistema informativo regionale della sanità, così come pianificato nel progetto regionale del Fascicolo Sanitario Elettronico, si presta a supportare simili attività preventive. Nello specifico esso si presenta come rappresentato in figura 1. In tale schema sono evidenziate le componenti centrali del sistema:
• L’infrastruttura per l’identificazione dei soggetti (FedChoesion 2.0). Tale infrastruttura consente l’accesso in Single Sign On, controllato tramite identificazione forte in ambito federato standard SAML 2.0. Ciascun soggetto utilizzatore viene quindi identificato univocamente in modalità forte, nel pieno rispetto della normativa sulla privacy.
• Il Sistema Amministrativo-Contabile Unico (AREAS) usato dall’ASUR e dalle Aziende Ospedaliere, ad esclusione dell’INRCA. Tale sistema include l’Anagrafe dei soggetti prescrittori.
• Il Sistema di prenotazione unico regionale (CUP), che fornisce il Catalogo regionale delle prestazioni.
• L’Anagrafe aziendale degli Assistiti (ARCA), che rappresenta l’anagrafe di tutti gli assistiti della Regione Marche e alimenta l’anagrafe regionale (ASR);
• L’Anagrafe sanitaria regionale ed i cataloghi regionali (prestazioni, strutture, fornitori, prodotti tra cui farmaci e dispositivi medici, ecc);
• Il repository dei documenti del FSE (comprese le prescrizioni), secondo le specifiche del progetto FSE;
• Sistema SILARM (Rete Laboratori, LIS);
• Sistema RIS unico regionale;
• Connettività per tutte le strutture del sistema sanitario.
Figura 1 - Il Sistema Informativo Sanitario del SSR della Regione Marche.
L’infrastruttura del fascicolo permette l’accesso a vari servizi, tra i quali:
• servizi previsti dal FSE per accedere alle informazioni anagrafiche degli assistiti (ASR-ARCA) e consultare/aggiornare il relativo fascicolo sanitario elettronico. Grazie al registry regionale si accede a tutte le informazioni sanitarie che riguardano gli assistiti marchigiani prodotte dai vari domini e conservate nei rispettivi repository documentali;
• Servizi di accesso ed aggiornamento dei cataloghi regionali;
• Accesso/popolamento del repository delle prescrizioni mediche;
• Servizi di identificazione-autenticazione FedCohesion;
• Servizi per la gestione della TS/CNS;
• Servizi di firma digitale, anche di tipo massivo in collegamento con i sistemi HSM di una o più CA o altri dispositivi di firma (token USB);
Le specifiche di integrazione sono disponibili al link:
xxxx://xxx.xxxxxxx.xxxxxx.xx/Xxxxxxx-Xxxxx/Xxxxxx-Xxxxxxxx/Xxxxxxxx-xx-xxxxxxxxxxx-xxx-xx- realizzazione-di-sistemi-informativi-e-telematici-della-Giunta-regionale#Sistemi-informativi-sanitari-di- valenza-regionale
1.3 Normativa di Riferimento
In materia di nuova organizzazione dei servizi:
• Piano Socio Sanitario Regionale 2019-2021: Il cittadino, l’integrazione, l’accessibilità la sostenibilità.
• Piano della Performance ASUR 2018-2020.
• DGRM 551/2013,
• DG ASUR 850 del 16 dicembre 2014
• DG ASUR 350 del 14 maggio 2015
• DG ASUR 481 del 2/8/2016
• DG ASUR 361/17
• D.P.C.M. del 12/01/2017
• DGR n. 540/2015
• DGR n. 887/2018
In materia di sistemi informativi e gare:
• X.Xxx n.50 del 18 aprile 2016, “Codice dei contratti pubblici”;
• D.Lgs. 7 marzo 2005, n. 82 recante "Codice dell'Amministrazione Digitale", così come integrato e modificato dal D.Lgs. 30 dicembre 2010, n. 235, artt. 68, 69 e 70 relativi al riuso dei programmi informatici.
• Direttiva del Ministro per l'Innovazione e le tecnologie del 19 dicembre 2003, concernente "Sviluppo ed utilizzazione dei programmi informatici da parte delle pubbliche amministrazioni", contenente l'indicazione di criteri tecnici ed operativi per gestire il processo di acquisizione di programmi informatici, fra cui il riuso.
• Linee guida per l’inserimento ed il riuso di programmi informatici o parti di essi pubblicati nella “banca dati dei programmi informatici riutilizzabili” di DigitPA pubblicate del 23/07/2012.
• D.Lgs 30 dicembre 2010, n. 235: “Modifiche ed integrazioni al decreto legislativo 7 marzo 2005, n. 82, recante Codice dell’amministrazione digitale, a norma dell’articolo 33 della legge 18 giugno 2009, n. 69” e s.m.i.;
• D.Lgs 196/2003 “Codice in materia di protezione dei dati personali” relativamente agli aspetti legati alla salvaguardia della privacy e s.m.i.
• Reg. UE n.679/2016 “Nuovo Regolamento Europeo sulla Protezione dei Dati Personali” (GDPR);
• WP 248, “Guidelines on Data Protection Impact Assessment (DPIA) and determining wheter processing is ‘likely to result in a high risk’ for the purposes of Regulation 2016/679”, adottato il 4 aprile 2017.
Il presente elenco non è da ritenersi esaustivo per la prestazione dei servizi. L’appaltatore avrà l’obbligo di aggiornare i riferimenti normativi da prendere in considerazione ai fini del presente appalto.
2. INQUADRAMENTO DEL SISTEMA DA REALIZZARE
2.1 Obiettivi
Sulla base del contesto organizzativo descritto e del Piano Socio Sanitario Regionale 2019-2021 è possibile individuare i seguenti obiettivi del sistema informativo per il Servizio Igiene e Sanità Pubblica:
OBIETTIVI DI AREA PREVENZIONE
1) Miglioramento delle campagne di prevenzione e rafforzamento dei servizi di screening
• Realizzazione e diffusione di reportistica annuale su screening, disponibile anche su web. Indagine sulla qualità percepita dagli utenti dei servizi di screening;
• Trasformazione dell'attuale sistema di screening in un sistema gestionale.
• Interfacciamento del sistema di screening con i sistemi trasversali e con i sistemi di laboratorio analisi.
OBIETTIVI DI AREE DI INTERVENTO TRASVERSALI
2) Sviluppo del nuovo Sistema Informativo Sanitario di governo regionale
• Attivazione delle procedure per l'acquisizione di beni/servizi per l'evoluzione e consolidamento del Sistema Informativo Sanitario Regionale e del suo patrimonio Informativo
• Adozione di strumenti di analisi avanzata dei dati integrati (data-Iake) per: la selezione delle informazioni necessarie per la comprensione del problema; esplorare i dati secondo diversi punti di vista in base alle esigenze dello stesso utente; valutare gli scenari conseguenti alle scelte compiute; interpretare i risultati attraverso percorsi di decision-making; definire modelli per l'analisi di tipo predittivo
2.2 Valutazione delle principali soluzioni in riuso disponibili
In ottemperanza alle linee guida sull’acquisizione e riuso si software per le pubbliche amministrazioni disposte dall’AGID è stata effettuata una ricerca delle principali soluzioni offerte in riuso dalle altre regioni, allo scopo di procedere ad un confronto valutativo su costi e qualità con soluzioni disponibili su mercato o sviluppabili in-house.
Si intende come «riuso» di un software il complesso di attività svolte per poterlo utilizzare in un contesto diverso da quello per il quale è stato originariamente realizzato, al fine di soddisfare esigenze similari a quelle che portarono al suo primo sviluppo. Il prodotto originario viene
«trasportato» nel nuovo contesto arricchendolo, se necessario, di ulteriori funzionalità e caratteristiche tecniche che possono rappresentare un «valore aggiunto» per i suoi utilizzatori.
Dal combinato disposto degli articoli 68 e 69 del CAD, il software in riuso è esclusivamente quello rilasciato sotto licenza aperta da una pubblica amministrazione. Questo è dunque un sottoinsieme di tutto il software open source disponibile per l’acquisizione. Le attuali linee guida distinguono, ove necessario, le modalità di acquisizione di software di pubbliche amministrazioni assoggettato a licenza aperta rispetto a software open source di terzi.
Un aspetto fondamentale del riuso nel contesto della Pubblica Amministrazione è che l’Amministrazione che «riusa» riceve il software gratuitamente dall’Amministrazione cedente, e lo acquisisce sostenendo solo le spese di suo adattamento, ma non quelle di progettazione e realizzazione.
Ogni amministrazione deve, in sede di negoziazione di un contratto volto a commissionare lo sviluppo di un software, garantirsi, all’esito dell’esecuzione del contratto, la piena ed esclusiva titolarità di tutti i diritti sul software oggetto di sviluppo, salvo che questo risulti eccessivamente oneroso per comprovate ragioni di carattere tecnico-economico (dal comma 2 dell’articolo 69 del CAD).
Per software oggetto di sviluppo, si intendono le parti di software effettivamente sviluppate in esecuzione del contratto; resta inteso che lo sviluppo potrebbe basarsi sull’utilizzo di componenti software già esistenti (es: librerie e framework open source di terzi) per le quali non è necessario acquisire titolarità ma solo licenza d’uso (che dev’essere compatibile con le finalità di riuso).
La mancata acquisizione della titolarità dell’opera non può essere utilizzata per ottenere condizioni economiche più vantaggiose, poiché non costituisce comprovata ragione di carattere tecnico- economico ai sensi dell’articolo 69 comma 2 del CAD.
Un’amministrazione, ai sensi dell’articolo 69, deve egualmente acquisire la totalità dei diritti di proprietà intellettuale e industriale su eventuali personalizzazioni o moduli software destinati a integrarsi o interfacciarsi con un software proprietario. In tal caso, l’obbligo di cui all’art. 69 avrà ad oggetto esclusivamente il modulo o la parte del software oggetto di sviluppo; tale modulo dovrà quindi essere separato dal resto del software e rilasciato secondo le modalità indicate in Sviluppo di software ex novo, avendo cura di indicare la necessaria dipendenza proprietaria nella documentazione.
Vista l’eterogeneità delle soluzioni e la difficoltà ad effettuare comparazioni quantitative omogenee, come in caso di confronto tra una soluzione dalla quale possano essere ricavati costi certi (soluzione proprietaria in modalità on premise o in modalità cloud computing) e una soluzione da realizzare ex novo - per la quale si disponga soltanto dello studio di fattibilità - si è preferito indicare un processo decisionale attraverso la descrizione di Xxxx e la loro organizzazione in Macro fasi.
La seguente figura riporta le Xxxxx fasi che caratterizzano il processo decisionale per dare seguito alla valutazione comparativa prevista all’articolo 68 del CAD.
Figura 2 – Fasi del processo decisionale relativo alla implementazione di una soluzione informatica.
Le Macro fasi individuate sono:
MACRO FASE 1: Ha l’obiettivo di definire le esigenze specificando i bisogni e i vincoli (organizzativi ed economici) che condizionano le scelte per l’identificazione di una soluzione adeguata alle esigenze dell’amministrazione;
MACRO FASE 2: Qui la pubblica amministrazione accerta la possibilità di soddisfare le proprie esigenze utilizzando una soluzione già in uso presso altre amministrazioni (di seguito «soluzioni a riuso delle PA») o a software libero o codice sorgente aperto (di seguito «soluzioni Open Source»).
MACRO FASE 3: Ove la Macro fase 2 non permetta di rispondere alle esigenze della Pubblica amministrazione, si persegue il soddisfacimento delle stesse attraverso il ricorso a programmi informatici di tipo proprietario, mediante ricorso a licenza d’uso e/o a realizzazioni ex novo.
Per quanto concerne la macrofase 1, i requisiti generali, funzionali e tecnici sono stati individuati e vengono di seguito riportati nelle sezioni 2.3, 2.4 e 2.5.
Passati alla macrofase 2 al fine di razionalizzare la spesa complessiva la verifica di soddisfacimento delle esigenze ha in un primo momento considerato le «soluzioni a riuso delle PA».
Seguendo le linee guida AGID le attività previste in questa fase sono state:
• ricerca delle «soluzioni a riuso delle P.P.A.A.» presenti all’interno della piattaforma Developers Italia.
• individuazione delle «soluzioni a riuso delle P.P.A.A.» di interesse per la Pubblica amministrazione. Nell’operare una scelta tra le soluzioni a riuso individuate si è fatto riferimento alla metodologia descritta nel documento “check list per la valutazione di adeguatezza e indice di adeguatezza” predisposto da DigitPA (ora AGID). Gli esiti di detta analisi sono riportati nell’allegato 2.
Per ognuna delle «soluzioni a riuso delle PA» potenzialmente d’interesse si è provveduto a:
• verificare in prima battuta la conformità almeno dichiarata alle normative vigenti, come rinvenibile nella scheda del software presente su Developers Italia. In particolare: – la conformità alle regole sull’interoperabilità prescritte dalle linee guida emanate in attuazione dell’articolo 73 del CAD;
– la conformità alle normative sulla protezione dei dati personali;
– la conformità ai livelli minimi di sicurezza previsti per le pubbliche amministrazioni;
– la conformità ai requisiti di accessibilità (Legge 4/2004).
• valutare la qualità della soluzione attraverso i seguenti parametri, alcuni dei quali possono essere rinvenuti nella scheda del software presente su Developers Italia: – grado di copertura dei requisiti, funzionali e non funzionali;
– presenza di un manutentore del software in questione;
– eventuale presenza di accordi con terzi stipulati dall’amministrazione titolare e utilizzabili dall’amministrazione valutante, riguardo attività di supporto per l’installazione e/o la personalizzazione della soluzione o comunque le modalità di fruibilità della soluzione stessa (es: una in-house regionale può mettere a riuso software Open Source per i propri comuni assieme ad un accordo di fornitura di servizi di installazione e formazione);
– presenza di vincoli e dipendenze obbligatorie con altro software aperto e/o con software proprietario; per esempio, un software Open Source potrebbe richiedere necessariamente una licenza per un database proprietario, oppure potrebbe necessitare una licenza per una API proprietaria di un servizio cloud;
– presenza e grado di competenza delle risorse interne alla PA in merito alla gestione degli ambienti e dei linguaggi utilizzati nella soluzione;
– numero e tipologia di altre pubbliche amministrazioni che utilizzano il progetto open source;
– eventuali costi per la formazione del personale, considerando sia quelli necessari per l’addestramento dei soggetti destinati alla gestione della soluzione sia quelli per il suo utilizzo da parte degli utenti finali;
– eventuali costi necessari all’integrazione della soluzione con i propri sistemi;
– eventuali costi di personalizzazione, compresi quelli necessari ad assicurare dei requisiti funzionali e non funzionali, non già presenti nel software a riuso;
– eventuali costi per la verifica di compliance alle normative vigenti.
• stimare i tempi per la messa in produzione della soluzione;
• eventuali altri stime espressione della specificità dell’amministrazione.
Avendo riscontrato che:
• Il costo di personalizzazione e installazione rientrava nei vincoli di bilancio stabiliti;
• I tempi di messa in produzione erano compatibili con i tempi stimati;
E' stata individuata la soluzione maggiormente rispondente alle esigenze dell’amministrazione nel Sistema Informativo Per la gestione degli Screening Oncologici (SIPSO 2.0) ceduto in riuso dalla Regione Lazio.
Il nuovo sistema oggetto del presente capitolato tecnico dovrà sostituire quello attuale, progettato per servire tutte e cinque le aree vaste ASUR e che al momento della stesura del presente documento viene utilizzato per servire circa 1684 utenti.
2.3 Requisiti Generali (RG)
L’applicativo dovrà contenere tutti i meccanismi necessari a garantire la congruenza dei dati (campi obbligatori, validazione dei campi, controllo dei valori nulli etc.). Tutti i meccanismi individuati dovranno essere chiaramente documentati (RG1).
L’inserimento di informazioni utilizzerà anagrafiche di riferimento che agevoleranno l’utente nel caricamento delle informazioni richieste e dove possibile utilizzerà i cataloghi regionali messi a disposizione dall’infrastruttura del fascicolo sanitario elettronico (RG2).
Per le tabelle interne di riferimento dovranno essere gestiti lo storico e i periodi di validità delle informazioni (RG3).
Il sistema, ove possibile, dovrà provvedere a mantenere aggiornate le informazioni presenti nelle tabelle automaticamente (RG4).
La proprietà del contenuto informativo della banca dati dovrà rimanere di proprietà esclusiva del Committente (RG5).
Il sistema fornito dovrà coesistere sulla medesima postazione di lavoro dei professionisti sanitari assieme agli altri applicativi aziendali senza pregiudicarne il funzionamento e non dovrà richiedere l'installazione di client sulle postazioni (RG6).
Tutta la documentazione, la manualistica e l’interfaccia dovranno essere redatti in forma accessibile e in lingua Italiana, e forniti in formato PDF. La documentazione tecnica e la manualistica dovranno essere consegnate alla stazione appaltante e rimarranno di proprietà della stessa (RG7).
Le GUI utilizzate dagli utenti dovranno utilizzare tutte le tecniche disponibili (es. menù personalizzabili, shortcut, help contestuale, help personalizzabili ecc.) al fine di favorirne l’usabilità, tenendo conto delle particolari categorie di utenza. In particolare dovrà essere evitata la navigazione eccessiva o ridondante fra menù e maschere (RG8).
Le singole funzionalità dovranno essere percepite dai vari utilizzatori come parti di un sistema unico: i singoli moduli dovranno presentare la stessa struttura dell’interfaccia. Le modalità operative associate
ai vari profili, le interrogazioni e le stampe dovranno presentare strutture e caratteristiche omogenee (RG9).
Le caratteristiche e i canoni tecnologici degli strumenti di sviluppo e del sistema proposto, dovranno rispondere pienamente agli standard di qualità internazionali, agli standard di mercato ed essere documentati (RG10).
Sia la banca dati che gli applicativi dovranno pienamente rispondere ai requisiti imposti dal D.Lgs. 196/2003 e successive modifiche e ai Regolamenti UE 2016/679 (GDPR) e UE GDPR 25.05.2018 in relazione alla “amministrazione del sistema” con particolare riferimento ai “log” di accounting e auditing (RG11).
2.4 Requisiti Funzionali Specifici (RF)
La personalizzazione del SIPSO 2.0 destinata al Servizio Screening ASUR dovrà implementare tutti i seguenti requisiti funzionali:
NOME | DESCRIZIONE |
RF1:Autenticazione e accesso | Funzionalità che, tramite l’integrazione con il sistema di autenticazione regionale FedCohesion, permette l’accesso ai soli utenti autorizzati. La funzionalità obbliga l’utente a scegliere sia la AV sia il tipo di screening cui accedere (cervicale, mammografico, colon-retto o cardiovascolare). Il software garantisce adeguata funzionalità di autenticazione (login). Il software permette l’integrazione con il sistema di autenticazione centralizzato regionale e di autorizzazione aziendale. |
RF2:Gestione soggetto | Funzionalità di front office, che permette, a partire da una ricerca sulla base dati anagrafica, di gestire i dati anagrafici del soggetto, i relativi recapiti e consensi, l’invito corrente nel tipo di screening scelto (con possibilità di spostamento e creazione nuovo invito) e un’eventuale esclusione temporanea o definitiva. Permette, altresì, sia la visualizzazione che la stampa dell’intera storia di screening del soggetto. Il software fornisce alla segreteria un adeguato cruscotto di ricerca di lettere, inviti, appuntamenti, e referti. Il software permette lo spostamento del singolo appuntamento. Il software permette la generazione di un invito per il singolo paziente. Il software permette la registrazione del referto di I e II livello, nonché di eventuali interventi ed approfondimenti istologici per il singolo paziente, con le peculiarità dei test di ognuno dei tre screening oncologici. Il software permette la rigenerazione della lettera di invito in caso di spostamento. Il software permette la modifica dei dati personali (indirizzo) senza sovrascrittura al successivo aggiornamento anagrafico. Il software permette la registrazione dell’indirizzo mail (in modo da poterlo poi utilizzare automaticamente per l’invio di mail). Il software permette la registrazione del numero di telefono cellulare (in modo da poterlo poi utilizzare automaticamente per l’invio di SMS). E’ auspicabile che vi siano almeno 2 campi separati per la registrazione dei recapiti telefonici. Il software permette di consultare e stampare lo storico del paziente (inviti, referti). Il software permette di stampare lo storico del paziente (inviti, referti). Il software permette di registrare eventuali prestazioni di screening effettuate al di fuori del programma organizzato. Il software permette di registrare se le donne hanno effettuato la vaccinazione anti-HPV (interoperabilità con SIAVr) al di fuori del programma di vaccinazione dell’ASUR, possibilmente su presentazione della relativa documentazione. Il software permette la riapertura dei percorsi e la svalidazione di referti registrati da parte di utenti appositamente autorizzati, senza l’intervento di un amministratore. |
RF3:Generazione automatica inviti | Funzionalità che permette, in base ai filtri impostati dall’utente unitamente a quelli configurati a livello di azienda sanitaria, di individuare la popolazione target che dovrebbe essere invitata con un primo invito, con un richiamo o con un sollecito. La funzionalità è altresì in grado di generare automaticamente gli appuntamenti per tali soggetti, posizionandoli nelle agende indicate e creando anche le relative lettere di invito. Lo spostamento dei richiami , inoltre, permette di dirottare i richiami previsti in un centro in uno o più centri diversi. Il software permette l’invio di file per la realizzazione massiva della stampa lettere (inviti e referti). Il software permette l’invio di file per la realizzazione massiva di SMS. Il software permette l’invio massivo di e.mail. Il software permette la ricezione massiva degli inviti inesitati. Il software permette la scelta della popolazione da invitare tra quella eleggibile a seconda di: - zona geografica - adesione al round precedente - età - data di richiamo - MMG - tipologia invito (primo invito, sollecito, ecc…) - tipologia test (es. HPV o Pap test, FIT o rettosigmoidoscopia) - avvenuta vaccinazione con vaccino anti HPV. Il software permette la scelta della popolazione da invitare definendo numerosità diverse per tipologia di invito. Il software gestisce la periodicità del richiamo previsto, riuscendo a garantire un corretto richiamo alla scadenza dell’intervallo di screening (es. 24 mesi) di ogni singolo soggetto in maniera autonoma dal round di screening o da |
altri determinanti. Il software gestisce il sollecito, permettendo di decidere se e quando è opportuno effettuare invito di sollecito, permettendo di definire gli intervalli standard per il sollecito stesso. Il software gestisce la periodicità del singolo individuo, cioè rende disponibile l’invito alla data prevista per il richiamo. Quindi, il software distingue chiaramente la differenza tra invito routinario di screening, sollecito e reinvito in seguito ad invito inesitato. Il software registra e rende evidente all’operatore le diverse tipologie di invito e ne governa le tempistiche, distinguendo chiaramente la differenza tra invito routinario di screening, sollecito, invito di follow up, invito di early recall e reinvito in seguito ad invito inesitato, invito su richiesta spontanea (ad esempio per sintomi). In merito alle tempistiche, ad esempio, il software non ritarda l’invito in presenza di un sollecito ove il soggetto è non rispondente oppure che sospende l’invito di primo livello per i pazienti in follow up e fino a conclusione dello stesso. Il software permette la realizzazione massiva di: - primi inviti - inviti di sollecito - inviti di follow up - inviti di II livello Il software fornisce le lettere di invito e referto in formato pdf e ne permette la stampa in locale . Il software tiene in memoria e permette la ristampa della lettera di invito già creata. Il software permette la modifica del testo delle lettere di xxxxxx, e la loro personalizzazione almeno a livello di AV., consentendo di gestire in autonomia, senza interventi di amministratori, i modelli di lettere associate ai diversi inviti. Il software permette di generare, al posto di un set di lettere, un file di dati da inviare a Postel, che si occuperà poi della generazione, imbustamento, e spedizione di tali lettere. | |
RF4:Accettazioni | Funzionalità, diversificata per tipo di screening, che permette l’accettazione del paziente all’appuntamento. Garantisce la possibilità di raccogliere dati di anamnesi e sui precedenti, nonché fornisce all’utente strumenti per la compilazione veloce di informazioni su più appuntamenti (come ad esempio l’esito di presenza o assenza). Il software permette di stampare un piano di lavoro giornaliero o plurigiornaliero. Il software permette in automatico (es. lettura bar-code da lettera/tessera) di identificare paziente/appuntamento. Il software permette di segnalare la presenza/assenza del paziente all’appuntamento previsto, differenziando anche i casi in cui non sia possibile eseguire il test di screening. Il software permette di stampare l’elenco degli invitati per seduta/giornata (piano di lavoro). Il software permette di stampare l’elenco dei presentati per seduta/giornata. Il software permette di stampare le etichette identificative per la tracciabilità dei campioni. Il software è integrato con i software gestionali dei laboratori ai fini dell’importazione diretta dell’accettazione. L’identificativo dei campioni dei singoli utenti dovrà essere trasmesso automaticamente ai software gestionali dei laboratori (LIS - laboratory information system) e contemporaneamente registrato nella scheda utente, in modo da consentire ai singoli operatori dei laboratori e dello screening di risalire allo storico dell’utente tramite bar-code. Il software registra le liste di trasporto dei campioni e le condivide con i software gestionali dei laboratori, permettendo a questi di verificare la corrispondenza tra quanto presente nelle liste di trasporto e quanto pervenuto al laboratorio (check-in positivo). Il software permette agli operatori dei laboratori di effettuare il check-in dei campioni direttamente tramite il software stesso, trasmettendo automaticamente l’avvenuto check-in anche ai software gestionali dei laboratori. Il software permette di registrare i dati anamnestici di ciascun paziente, differenziati sui tre screening (compresa l’eventuale vaccinazione contro HPV) e la loro trasmissione ai software gestionali dei laboratori. Il software permette di registrare il consenso alla prestazione. Il software permette di registrare il consenso al trattamento dei dati, in ottemperanza alla normativa sulla privacy (EU GDPR 25.5.2018). |
RF5:Produzione dei Referti di screening cervicale | Screening cervicale: o pap test o hpv o colposcopia o istologia bioptica o intervento e relativa istologia Il software genera lettera di esito comprensiva dei dati principali (data, firma , giudizio diagnostico, richiamo). Il software permette la modifica del testo delle lettere di esito consentendo di gestire in autonomia, senza interventi di amministratori, i modelli di lettere associate ai diversi referti. Il software tiene in memoria e permette la ristampa della lettera di esito già creata (copia conforme). Il software consente di importare i referti dai gestionali dei Centri refertanti generando il richiamo successivo (tipo invito e scadenza) secondo impostazioni definite. Il software genera le comunicazioni di risposta in maniera massiva. |
RF6:Produzione dei Referti di screening mammografico | Screening mammografico: o Mammografia (due letture + eventuale revisione) o Approfondimenti (ecografia, esame senologico) o Citologia o Agobiopsia o intervento e relativa istologia Il software genera lettera di esito comprensiva dei dati principali (data, firma , giudizio diagnostico, richiamo). Il software permette la modifica del testo delle lettere di esito consentendo di gestire in autonomia, senza interventi di amministratori, i modelli di lettere associate ai diversi referti. Il software tiene in memoria e permette la ristampa della lettera di esito già creata (copia conforme). Il software consente di importare i referti dai gestionali dei Centri refertanti generando il richiamo successivo (tipo |
invito e scadenza) secondo impostazioni definite. Il software genera le comunicazioni di risposta in maniera massiva. | |
RF7:Produzione dei Referti di screening del colon-retto | Screening del colon-retto: o Feci sangue occulto o Rettosigmoidoscopia o Endoscopia e relativo esame istologico o intervento e relativa istologia Il software genera lettera di esito comprensiva dei dati principali (data, firma , giudizio diagnostico, richiamo). Il software permette la modifica del testo delle lettere di esito consentendo di gestire in autonomia, senza interventi di amministratori, i modelli di lettere associate ai diversi referti. Il software tiene in memoria e permette la ristampa della lettera di esito già creata (copia conforme). Il software consente di importare i referti dai gestionali dei Centri refertanti generando il richiamo successivo (tipo invito e scadenza) secondo impostazioni definite. Il software genera le comunicazioni di risposta in maniera massiva. |
RF8:Produzione dei Referti di screening cardiovascolare | Screening cardiovascolare: o Questionario su stile di vita Il software genera lettera di esito comprensiva dei dati principali (data, firma , giudizio diagnostico, richiamo). Il software permette la modifica del testo delle lettere di esito consentendo di gestire in autonomia, senza interventi di amministratori, i modelli di lettere associate ai diversi referti. Il software tiene in memoria e permette la ristampa della lettera di esito già creata (copia conforme). Il software consente di importare i referti dai gestionali dei Centri refertanti generando il richiamo successivo (tipo invito e scadenza) secondo impostazioni definite. Il software genera le comunicazioni di risposta in maniera massiva. |
RF9: Firma digitale | Il sistema offerto deve essere predisposto all'utilizzo della firma digitale, al fine di rendere identificabile chi ha creato/modificato un referto o un consenso informato ed eliminare la possibilità di manipolazione non autorizzata del documento stesso. L'ASUR si riserva la possibilità di definire le tipologie di documenti da firmare digitalmente durante la fase precedente al collaudo del sistema, senza ulteriori spese a carico. Il sistema proposto deve permettere agli operatori interessati la firma massiva di un insieme di documenti preliminarmente firmati con firma elettronica e già validati. É richiesta la disponibilità di un modulo di Firma Elettronica Avanzata (FEA) (grafometrica) che consenta di dematerializzare documenti quali consensi informati, consensi privacy, etc. rilasciati dai cittadini/pazienti. L’appaltatore deve consegnare il sistema corredato di tutto il software per implementare tale modalità di firma; l'eventuale acquisizione dell’hardware necessario è a carico delle aziende/strutture che intendano dotarsi di questo modulo. La FEA deve permettere l’apposizione di molteplici firme sullo stesso documento, anche ad opera di persone diverse. Il sistema si deve interfacciare con i servizi di firma digitale remota, marca temporale e verifica della firma messi a disposizione dall’interfaccia FSE descritti nel documento LGF – Linee Guida FSE_v03. Le tipologie di servizi di firma che saranno rese disponibili sono: • firma cades per documenti in formato pdf o cda • firma pades per documenti in formato pdf • firma xades • firma massiva dei documenti |
RF10:Medici | Funzionalità che permette di ricercare i medici di famiglia censiti nel sistema ed i loro assistiti, che possono anche esser stampati. Il software permette l’integrazione con le cartelle cliniche elettroniche dei MMG, comunicando direttamente ai software utilizzati dai MMG gli inviti realizzati, anche al fine di sensibilizzare il MMG alla promozione dell’adesione verso l’utenza. |
RF11:Stampe | Funzionalità che permette di trovare e stampare o ristampare lettere di invito e di referto. Le lettere possono essere stampate sia come pdf che come file di dati da inviare a servizi di posta massiva (ad esempio postel). |
RF12:Agenda | Funzionalità che permette di visualizzare e modificare l’agenda fisica dei centri che prevedono appuntamenti di screening, sia in modalità giornaliera che mensile. Il software permette di inserire in autonomia le agende dei punti di erogazione. Il software permette di differenziare tra appuntamenti di I livello di II livello. Il software permette di modificare l’agenda anche di una sola giornata anomala rispetto al solito. Il software permette di generare agende continuative per lunghe periodi. Il software permette di personalizzare il minutaggio per giornata. Il software permette di gestire a livello del singolo centro l’agenda degli appuntamenti di II livello (es. automatica per alcuni centri, assistito per assistito in altri centri). |
RF13:Configurazio ne del sistema | Funzionalità di configurazione, che permette di gestire da interfaccia (agli utenti abilitati): - Aziende sanitarie - Centri di screening, con dettaglio delle agende teoriche e delle chiusure - Istituti di ricovero - Modelli di documenti, associati anche a tipi di invito o a suggerimenti dei referti Personale medico, con relativa associazione agli utenti, ove previsto - Aree geografiche (associazioni tra comuni e centri, gestione dei round organizzativi dei comuni, gestione delle zone/distretti) - Configurazioni anagrafiche (categorie dei cittadini, filtri di inclusione nella popolazione target, eventuali esclusioni |
associate alla categoria anagrafica) - Import/export (configurazione dei canali di integrazione in input e in output) - Flussi regionali (configurazioni relative a SDO e SPS) Esclusioni temporanee e definitive - Tipi di invito e relative categorie - Suggerimenti dei referti di primo, secondo e terzo livello Accettazione (dizionari usati nelle anamnesi dei vari screening). | |
RF14:Integrazione con agende ambulatoriali | Il software deve presentare un'interfaccia di collegamento con eventuali software di gestione delle agende ambulatoriali. Dal programma di screening deve essere possibile interagire direttamente con le agende dei punti di erogazione degli screening, quando questi sono in grado di interfacciarsi con il sistema. |
RF15:Integrazione con sw di anatomia patologica | Il software deve presentare un'interfaccia di collegamento con eventuali software di gestione della anatomia patologica dei punti di erogazione, quindi dovrebbe acquisire on time (almeno con cadenza settimanale), senza l’azione di un operatore (tecnico o sanitario), gli esiti (referti) delle analisi bioptiche o simili e quindi segnalarne l’acquisizione, tramite listati o alert, in modo che l’operatore possa adottare le azioni successive. L’opportunità della compilazione automatica o semi-automatica dei campi del SS, senza intervento diretto dell’operatore, rimane una scelta locale. |
RF16:Integrazione con RIS unico regionale | Il software va integrato con il sistema di gestione delle immagini (RIS unico regionale) dei punti di erogazione, quindi può acquisire on time, senza l’azione di un operatore (tecnico o sanitario), gli esiti (referti) degli esami inseriti nei gestionali delle immagini e che il programma può attivare azioni dirette (es. alert) in seguito all’inserimento di tali esiti. Import delle accettazioni dei tre screening oncologici con eventuale anamnesi: il software permette la ricezione e l’elaborazione automatica delle accettazioni con eventuale anamnesi tramite messaggistica HL7. Import dei referti di I e II livello degli esami dei tre screening oncologici: il software permette la ricezione e l’elaborazione automatica dei referti tramite messaggistica HL7. |
RF17:Integrazione con LIS unico regionale | Il software va integrato con il sistema di gestione dei referti di laboratorio dei punti di erogazione, quindi può acquisire, senza l’azione di un operatore (tecnico o sanitario), agli esiti (referti) degli esami inseriti nei gestionali dei laboratori e che il programma può attivare azioni dirette (es. alert) in seguito all’inserimento di tali esiti. |
RF18:Integrazione con SIRTE e SISP | Il software è integrato con il flusso ambulatoriale e delle SDO e importa eventuali esclusioni (vedi esclusioni). Il software permette l’export dei piani di lavoro in HL7 verso destinatario configurabile. Il software permette di importare e registrare in automatico e manualmente i dati relativi alla vaccinazione anti HPV (tipo di vaccino, numero di dosi, date delle dosi). |
RF19:Aggiornamen to anagrafico | Funzionalità che permette l’aggiornamento anagrafico in modo manuale o schedulato. L’integrazione dovrebbe avvenire via HL7 con ARCA. Le informazioni da includere nell’aggiornamento devono essere almeno - codice fiscale - nome - cognome - data di nascita - data di inserimento nell’anagrafe - data ultima variazione - fonte del dato - stato in vita/presenza - indirizzo di residenza - indirizzo di domicilio - AV di assistenza - stato dell’assistenza sanitaria con data scadenza o variazione - MMG. L’aggiornamento anagrafico deve essere almeno settimanale. L’operatore può scegliere in maniera massiva e modificabile nel tempo quale categoria di persone inserire in anagrafe (come da indicazioni dell’azienda: assistiti). Il software gestisce le doppie registrazioni: esso propone all’operatore eventuali situazioni di probabile doppia registrazione anagrafica del medesimo soggetto, permettendo sia la fusione manuale sia la fusione automatica di posizioni effettivamente doppie con il ricalcolo del prossimo invito. Il software permette di inserire un paziente anche se non è in anagrafica: esso controlla comunque i dati inseriti (codice fiscale, data di nascita, nome, cognome) e verifica eventuali doppi. |
RF20:Import referti | Funzionalità che permette l’import automatico (ricezione ed elaborazione) dei referti di primo e secondo livello di tutti gli esami (mammografie, citologia, anatomia patologica, laboratorio, colonscopie, colon-TAC, ed i vari accertamenti inclusi nella casella referti dei tre screening. Nelle integrazioni via HL7 viene invece utilizzato il modulo orchestratore. |
RF21:Export appuntamenti (liste di lavoro) | Funzionalità che permette l’invio di una lista di lavoro di appuntamenti, accettazioni o cancellazioni, eventualmente corredate di anamnesi, verso un destinatario. L’export può avvenire via file o via HL7 e può essere invocato in modo cumulativo (su un periodo temporale e un centro), sia in modo puntuale, a partire da un singolo appuntamento. |
RF22:Import presenze | Funzionalità che permette l’import on demand delle presenze, eventualmente corredate di dati di accettazione ed anamnesi. Nelle integrazioni via HL7 viene invece utilizzato il modulo orchestratore |
RF23:Import esclusioni | Funzionalità che permette lo scarico, da sistema regionale integrato, dei file delle SDO ed SPS e l’import delle esclusioni basate su queste informazioni. Il software permette l’inserimento automatico (massivo) di esclusioni da flusso dell’attività specialistica ambulatoriale (SPS) e dal flusso delle SDO (es. mastectomie, isterectomie, diagnosi di tumore pregresse). Il software quindi gestisce |
gli inserimenti delle esclusioni e, a seconda delle regole concordate, gestisce la tipologia di esclusione. Ad esempio, in caso di rilevazione di Pap test recente, gestisce in automatico l’esclusione temporanea dell’invito per tre anni a partire dalla data di prestazione inserita. Il software ri-calendarizza in automatico il richiamo successivo alla esclusione temporanea, calcolando in automatico il periodo di esclusione, a partire dalla data di inserimento della stessa, e rende nuovamente invitabile il soggetto alla sua conclusione. Il software permette di gestire le esclusioni definitive. | |
RF24:Alert | Il software segnala all’operatore situazioni di rischio quali ad esempio: assenza di appuntamento di secondo livello dopo esito positivo, assenza di invito per lungo tempo nei confronti di un avente diritto. Il software permette di visualizzare l’elenco dei referti pendenti, sulla base dei giorni di attesa dalla data di accettazione. Il software permette di visualizzare l’elenco degli inviti pendenti (primo e secondo livello), sulla base della data di scadenza. |
RF25:Statistiche AV | Funzionalità che permette il calcolo di una serie di indicatori statistici preconfigurati legati alle coorti di screening ed al volume attività, nonché la creazione di indicatori personalizzati. Il software permette in automatico la generazione degli indicatori di: - estensione grezza - estensione corretta - adesione grezza - adesione corretta - % inesitati - invio in colposcopia - esito patologia - test inadeguati. Il software permette la gestione delle statistiche (inviti/esiti/diagnosi/raccomandazioni) raggruppate per: - operatore - test - primi esami/esami successivi - classe di età e sesso - zona geografica - MMG - centro - tipo invito (primo invito, sollecito, richiamo ad un anno, follow up). Il software permette l’estrazione di dati a livello regionale da parte di utenti autorizzati. Il software permette l’estrazione dei dati per i MMG (elenco dei pazienti; aderenti /non aderenti). Il software permette di costruire elaborazioni statistiche personalizzate, una vista del tracciato record individuale, nonché un’organizzazione delle tabelle e dei dati affinché i programmi che lo desiderino possano essere messi in grado di costruire tutte le statistiche in autonomia. Il software permette di estrarre i dati necessari alla compilazione dei questionari nazionali GISCI, GISCor, GISMA. Il software permette l’estrazione dei dati su file in vari formati (es. csv, excel, xml). Il software permette di produrre il flusso della specialistica ambulatoriale (SPS) in relazione alle prestazioni di screening erogate.. Il software permette di produrre il flusso previsto dal Ministero per alimentare il datawarehouse nazionale degli screening. |
RF26:Esportazione dati per statistiche regionali | Funzionalità che permette l’estrazione dei dati relativi ad un periodo temporale sotto forma di archivio di file csv, di file excel, e di file xml. Tale funzionalità permette anche la produzione i file da inviare al datawarehouse regionale, secondo la specifica del DWH nazionale degli screening oncologici (a meno dell’anonimizzazione) |
RF27:Flusso SPS | Funzionalità che permette di produrre i flussi ministeriali della specialistica ambulatoriale per le prestazioni effettuate in ambito di screening |
RF28:Orchestratore | Modulo che si occupa delle integrazioni via HL7, tramite meccanismi automatici schedulati. L’orchestratore offre all’utente la possibilità di monitorare i messaggi HL7 ricevuti ed inviati, con la possibilità di visualizzarne gli eventuali errori e richiederne una rielaborazione |
RF29:Orchestratore - Configurazione | Tale funzionalità permette di gestire utenti, ruoli e autorizzazioni. Il software deve infatti permettere la profilazione di utenti con ruoli diversi. |
RF30:Orchestratore - rete mammografica | Questa funzionalità permette di creare una rete tra aziende sanitarie diverse, che si avvalgono l’una dell’altra nella fase di refertazione in doppio cieco delle mammografie di screening. Il sistema permette di configurare dei pool di refertazione con delle disponibilità e associarli, con criteri di preferenza, alle varie AAVV che effettuano mammografie di screening. |
RF31:Adapter Gateway | Componente, installato a livello di singola AV, che collabora con l’orchestratore per la pubblicazione delle immagini da refertare nel FSE ed il loro recupero presso le AAVV che dovranno leggere le mammografie |
Tabella 2 - Requisiti funzionali del SI per il Servizio Screening ASUR.
2.5 Requisiti Tecnici (RT)
Tutte le componenti della piattaforma dovranno basarsi su RDBMS ottimizzati in funzione della tecnologia scelta per garantire tempi ottimali di risposta (RT1). I costi di eventuali licenze di sw RDBMS saranno a carico dell’appaltatore.
In situazioni di almeno 500 utenti contemporanei connessi, e con un data base adeguatamente popolato, su tutte le maschere di input non devono esserci attese superiori al secondo nell'inserimento o aggiornamento di un dato. Per operazioni di ricerca avanzata e complesse, il limite superiore viene fissato in 1 secondo al massimo, misurato sul sistema completo in produzione ovvero in fase di verifica di conformità finale (RT2).
Il sistema dovrà saper esprimere ampie capacità di integrazione con le piattaforme software regionali esterne al sistema stesso di cui alla sezione 2.2; tale capacità dovrà basarsi su protocolli e metodologie di EAI (Enterprise Application Integration) riconosciuti come standard di mercato: Web Services, Messaggi e Code JMS, XML, SOAP, HL7, REST, JSON evitando l’impiego di file transfert o viste DB ove non espressamente indicato (RT3).
Il sistema dovrà essere integrabile con il sistema di autenticazione attualmente in uso e basato sul sistema regionale Fed-Cohesion e sul sistema SPID (secondo quanto previsto dalle indicazioni AgID (RT4).
2.6 Architettura del sistema e caratteristiche hardware
Il sistema, nella sua globalità, dovrà essere basato su 3 ambienti, distinti logicamente e fisicamente, in modo da non influenzarsi vicendevolmente, portando potenzialmente a situazioni di malfunzionamento contemporaneo. I tre ambienti previsti sono:
• produzione
• test
• disaster recovery
Gli ambienti riportati sopra saranno realizzati presso il data center della Regione Marche, solo dopo che l’aggiudicatario abbia superato con esito positivo il collaudo del pilota (milestone A in accordo con le fasi di progetto riportate nei capitoli successivi).
Per l’erogazione del servizio, fino al momento del collaudo del pilota, l’appaltatore deve proporre una soluzione tecnica, fisicamente dislocata sul territorio nazionale, che garantisca la possibilità di testare il sistema ed eseguire il suddetto collaudo. Successivamente al collaudo, se Regione Marche sarà in grado di garantire la disponibilità delle risorse richieste, l'installazione verrà trasferita presso il data center messo a disposizione dalla Regione Marche che garantirà:
• l'hardware nonché i locali e l'infrastruttura di rete necessaria al deploy del sistema
• i sistemi VMWare necessari all’eventuale virtualizzazione delle macchine (se specificata in fase di offerta).
• L’assistenza per l’accesso al data center
• La manutenzione delle componenti HW
• La manutenzione delle componenti HW infrastrutturali rimarrà a carico dell’ASUR pur richiedendo massima collaborazione all’aggiudicatario nell’analisi della risoluzione dei problemi che si dovessero manifestare.
Si richiede alle ditte concorrenti di documentare l'architettura dei sistemi proposti, specificando tutte le componenti che la costituiscono, intese come moduli sviluppati internamente e software di terze parti integrati all'interno della soluzione, necessarie per il dispiegamento della soluzione presso l’ASUR. Vanno sottolineate le caratteristiche fondamentali delle varie componenti, documentando eventuali necessità particolari in termini di configurazioni sistemistiche.
L'hardware necessario alla fornitura, dopo il collaudo, sarà messo a disposizione dell'ASUR secondo le caratteristiche specificate in sede di offerta. É necessario specificare, per ogni entità facente parte dell'architettura del sistema, le caratteristiche hardware necessarie al corretto funzionamento della soluzione. Solo le componenti specificate in fase di offerta saranno fornite dall’ASUR, le altre rimarranno a carico dell’aggiudicatario. A tal proposito, si specifica che vanno indicate anche tutte le
componenti HW che saranno necessarie al corretto utilizzo del sistema nella quotidianità, come eventuali dispositivi per la firma, lettori ottici, ecc., indicando eventuali caratteristiche specifiche necessarie.
Saranno valutate positivamente quelle soluzioni che si rivelino meno dispendiose dal punto di vista delle risorse, ovviamente rispettando i vincoli fondamentali di affidabilità, continuità e velocità che il sistema fornito deve garantire.
3. OGGETTO DELL’APPALTO
L’Aggiudicatario dovrà fornire i servizi di personalizzazione della piattaforma SIPSO 2.0 ceduta in riuso, di installazione, configurazione e trasferimento dati pienamente rispondenti ai requisiti specificati nelle sezioni 2.3, 2.4, 2.5. L’Aggiudicatario deve inoltre essere disponibile ad effettuare tutti gli adeguamenti necessari garantendo l’interoperabilità con altri sistemi regionali per adattare il prodotto offerto al contesto dell’Azienda Sanitaria Unica Regionale ed effettuare tutti i servizi necessari per la corretta e sostenibile messa in esercizio di tale prodotto (formazione, start-up, change management, assistenza e manutenzione ordinaria ed evolutiva, ecc).
In particolare, dovranno essere forniti i seguenti prodotti/servizi:
Sigla | Descrizione |
PSW | L’appaltatore dovrà in ogni caso garantire i servizi di adattamento del software al contesto dell’ASUR, nel rispetto dei requisiti evidenziati nelle sezioni 2.3, 2.4 da svolgersi comunque entro i termini e secondo le modalità indicati nel presente capitolato. L’appaltatore dovrà garantire il trasferimento dei dati dai vecchi sistemi informativi. In generale, le attività di analisi e la predisposizione dei programmi di estrazione/importazione dati devono essere svolte congiuntamente da referenti dell’appaltatore e dalle strutture coinvolte, con particolare attenzione alla minimizzazione della discontinuità operativa. Non è presente alcuna documentazione sui dati attualmente in uso e l’attività di tuning del sistema è a carico dell’appaltatore. Viene richiesto di illustrare, in sede di offerta, un piano di migrazione in linea con le esigenze espresse. La piattaforma software dovrà essere infine fornita comprensiva del software di base ed accessorio necessario (eventuali middleware, ecc) al suo funzionamento, senza l’aggravio di ulteriori costi. |
ANP | Per il progetto e implementazione dell’architettura del sistema informativo, dei relativi servizi di integrazione con le piattaforme regionali/aziendali esterne e per eventuali richieste specifiche (migliorie) che emergessero durante la fase di dispiegamento del sistema nel rispetto dei requisiti evidenziati nelle sezioni 2.5, si richiede il servizio di analisi, progettazione e implementazione correlato al Sistema Informativo oggetto dell’appalto. |
PGE | Attività di coordinamento delle risorse assegnate al progetto in corso d’opera; attività di controllo dell’andamento del progetto, produzione di stati di avanzamento (SAL), valutazione e gestione dei rischi del progetto. L’appaltatore deve provvedere alla garanzia full-risk per tutte le componenti software fornite per l’intero periodo contrattuale. Per facilitare lo svolgimento delle attività di gestione operativa l’appaltatore è tenuto a produrre e a mantenere aggiornato un Progetto Esecutivo che illustri al Committente come intende assicurare la prestazione dei servizi richiesti nei tempi dovuti. |
FOR | Tali servizi, descritti nel dettaglio nel par. 3.2, dovranno permettere l’inserimento graduale del nuovo sistema (sostituendo gli attuali sistemi ove presenti), prevedendo |
un adeguato piano di formazione e di affiancamento agli operatori. Il Piano dovrà essere strutturato in modo da prevedere: - almeno 5 giornate formative da destinare al personale amministrativo aziendale (personale tecnico informatico); - almeno 45 giornate formative da destinare ai soggetti erogatori. - la realizzazione di learning objects da inserire nel sistema e.learning ASUR (Moodle). | |
ASS | Assistenza specialistica, applicativa e sistemistica di primo e secondo livello. Si deve garantire un help desk (HD) a risposta garantita nell’orario di lavoro ed un successivo livello specialistico da attivare in caso di incidenti o richieste di attività tecniche di estrazioni dati o aggiornamenti speciali del database. In tale servizio è compresa l’attività di monitoraggio del corretto funzionamento dei sistemi interoperanti e il regolare scambio di informazioni tra di essi; qualora si verificasse un malfunzionamento l’aggiudicatario è tenuto a fornire gli alert necessari affinché si attivino gli opportuni interventi di risoluzione. L’Affidatario si impegna a mantenere le stesse condizioni economiche e tecniche per tali servizi anche per i successivi due anni, a meno di adeguamenti secondo l’indice Istat. L’attività viene meglio descritta al par. successivo. |
MAN | Servizi di garanzia, di manutenzione correttiva e adeguativa (normativa nazionale, normativa regionale, atti regionali) dell’applicativo, servizi di assistenza sistemistica e servizi di assistenza tecnica, garantendo inoltre l’allineamento del sistema di test a quello di esercizio. Per manutenzione correttiva in particolare si intende un intervento messo in atto per correggere errori e malfunzionamenti, o per mantenere la sicurezza del sistema, o per adeguare le funzionalità del sistema a quanto previsto dal contratto qualora venisse riscontrata anche a posteriori una differenza tra quanto previsto e quanto fornito. L’Aggiudicatario si impegna a mantenere le stesse condizioni economiche e tecniche per tali servizi anche per i successivi due anni, a meno di adeguamenti secondo l’indice Istat. L’attività viene meglio descritta al par. successivo. |
MEV | Servizi di manutenzione evolutiva erogata attraverso l’introduzione di nuove funzioni, o la modifica di funzioni preesistenti, nell’ambito del software già sviluppato. Nel caso di attività a richiesta per manutenzione straordinaria ed evolutiva, si stima un impegno di circa 256 gg-uomo da liquidarsi esclusivamente “a consumo” e comunque successivamente al collaudo del singolo modulo sviluppato. L’attività viene meglio descritta al par. successivo. |
Tabella 3 – Servizi offerti dall’Aggiudicatario
3.1 Descrizione di dettaglio dei servizi di manutenzione ed assistenza
Il servizio di manutenzione ha come obiettivi :
1. il mantenimento del corretto funzionamento del sistema, attraverso la risoluzione di comportamenti non previsti e/o non corretti rispetto ai requisiti
2. l'adeguamento del sistema in seguito a modifiche normative o di processo
3. il potenziamento dell'applicazione attraverso migliorie o aggiunte di funzionalità che rendano più semplice e proficuo il lavoro degli operatori.
I primi due tipi di manutenzione rientrano nella categoria della manutenzione correttiva e adeguativa (MAN), da garantire per tutta la durata dell’appalto, a partire dall'avvio del sistema. Il terzo tipo rientra nella manutenzione evolutiva (MEV).
É richiesta la manutenzione correttiva e adeguativa del sistema per correggere eventuali problematiche di funzionamento e per mantenere la conformità con le normative nazionali e regionali. La manutenzione correttiva e adeguativa assieme al servizio di assistenza specialistica dovranno iniziare ad essere erogati a partire dal milestone A di cui alla sezione 3.3.
La manutenzione correttiva comprende la diagnosi e la rimozione delle cause e degli effetti dei malfunzionamenti delle procedure e dei programmi. Il servizio di manutenzione correttiva è pertanto teso alla risoluzione di difetti presenti nel codice sorgente, o nelle specifiche di formato o di base dati o nella configurazione delle interfacce. L’appaltatore, in attesa che l’ASUR predisponga il sistema di ticketing online VTiger, dovrà rendere disponibile un’adeguata piattaforma di trouble-ticketing nella quale dovrà essere registrata ogni segnalazione ed ogni intervento di manutenzione attribuendo loro la corrispondente categoria di malfunzionamento e collegando tra loro le segnalazioni relative ad un unico guasto. Non appena Il sistema VTiger dell’ASUR diverrà operativo l’appaltatore dovrà curare il trasferimento dati o l’interfacciamento del proprio sistema di ticketing con quello del committente.
Ogni intervento va segnalato sull'interfaccia utilizzata dai vari operatori.
La manutenzione adeguativa comprende l’attività di manutenzione volta ad assicurare la costante aderenza delle procedure e dei programmi all’evoluzione dell’ambiente tecnologico del sistema informativo ed al cambiamento dei requisiti normativi e d’ambiente.
Il servizio di HD richiesto deve essere disponibile almeno nelle seguenti fasce orarie: dal lunedì al venerdì dalle 8:30 alle 13:00 e dalle 14:00 alle 17:30 e sabato dalle 8:30 alle 13:00. Saranno valutate in modo premiante le offerte che estendano l'orario di HD rispetto a quello proposto.
Negli orari al di fuori del servizio, deve essere comunque garantita la reperibilità di un addetto HD, in modo da poter segnalare situazioni particolarmente critiche e bloccanti per la struttura aziendale che andranno risolte secondo gli SLA riportati di seguito. L’appaltatore si impegna a garantire l’intervento immediato da remoto in caso di failure del sistema, e qualora necessario un intervento in loco nel rispetto degli SLA.
Va garantito il mantenimento di una base dati di tutti gli eventi legati a una segnalazione, dallo stato di avanzamento, ai documenti correlati alle singole prestazioni rese. Il sistema di ticketing deve essere opportunamente categorizzato in termini di tipologia di richiesta, prevedendo una procedura chiara di gestione dei ticket che permetta la definizione delle tempistiche di evasione delle richieste. Nella valutazione della tipologia di problema e quindi del suo smistamento dovrà essere definita la valutazione della gravità ed urgenza del problema, secondo le scale definite nella pubblicazione “Quaderni n. 7 gennaio n. 1/2002 del CNIPA”.
Il servizio dovrà comprendere anche il costante monitoraggio delle performance del sistema, per consentire all’appaltatore di intervenire preventivamente e proattivamente sui componenti in modo da ridurre il rischio di disservizi nonché per effettuare diagnosi sui failure di sistema risolvendole in tempi adeguati.
Entro il termine del periodo contrattuale l’appaltatore dovrà consegnare un documento di configurazione degli agenti di monitoraggio e backup, effettuare la formazione sistemistica di base al personale indicato dal Direttore dell’Esecuzione (modalità di shutdown, startup, verifica funzionalità, gestione aggiornamenti, ecc), finalizzata a rendere il suddetto personale autonomo nell’effettuazione delle attività tecnico/sistemistiche.
L’appaltatore è tenuto a garantire anche il servizio di manutenzione evolutiva, volto a potenziare il sistema attraverso l'aggiunta/modifica di funzionalità rispetto a quelle previste dal presente capitolato.
Il servizio dovrà essere garantito nel periodo della manutenzione del sistema in esercizio per un massimo di 256 giornate/uomo, da comprendere nell'offerta economica.
L’appaltatore dovrà indicare le tipologie di professionalità di cui si avvarrà nell’espletare le attività di manutenzione evolutiva, indicando esperienze e competenze. Gli interventi richiesti andranno opportunamente quantificati in termine di giornate/uomo e validati, tramite accettazione del preventivo da parte dell'ASUR, prima di procedere all'effettiva implementazione. Per il computo totale delle giornate fa fede il valore di giornate/uomo stimate e validate dall'ASUR.
Qualora l’amministrazione appaltante riterrà utile per il buon andamento del progetto, potrà richiedere la presenza in sede delle professionalità utilizzate per la realizzazione di determinate attività (assistenza, formazione, manutenzione correttiva/adeguativa ed evolutiva).
L’appaltatore si impegna a mantenere gli stessi importi nell'eventuale prosieguo dei servizi di assistenza e manutenzione per gli ulteriori due anni.
3.2 Descrizione di dettaglio dei servizi di formazione e affiancamento
I servizi relativi alla formazione dovranno permettere l’inserimento graduale del nuovo sistema informatico, sostituendo i sistemi attualmente in uso, prevedendo un adeguato piano di formazione agli operatori, agli amministratori di sistema e agli sviluppatori interni all'ASUR Marche.
Le attività di addestramento all’uso delle procedure dovranno essere progettate preventivamente con dettaglio delle date di svolgimento del corso e dovranno essere realizzate presso le sedi indicate dall'ASUR. Nella definizione delle date, si dovrà tenere in considerazione l’inderogabile esigenza delle strutture coinvolte, di garantire la continuità dei processi di cura. Per questo motivo le date saranno concordate durante l'analisi e l'allestimento del piano di attuazione definitivo.
Per gli utenti che non parteciperanno alla formazione in aula, si deve prevedere la preparazione di servizi di formazione in modalità e-learning (attività formative fruibili tramite rete Internet o Intranet in modo autonomo o assistito). La documentazione elettronica dovrà comunque essere messa a disposizione di tutti gli utenti, in modo da costituire una fonte formativa sempre disponibile.
I corsi in aula, eventualmente per il periodo post pandemico, i cui programmi dovranno essere preventivamente sottoposti all’approvazione dell’Amministrazione, saranno a completo carico della ditta aggiudicataria. L'ASUR metterà a disposizione le aule adibite alla formazione nei tempi e modi più consoni e compatibilmente con le necessità organizzative delle strutture coinvolte e con il piano di formazione proposto.
Gli utenti applicativi dovranno essere resi autonomi nell'utilizzo dell'applicativo, prima dell'effettivo avvio del sistema, e supportati nelle prime fasi di utilizzo.
Per gli amministratori di sistema, oltre alla formazione, è richiesta la documentazione relativa alla configurazione del sistema e alla sua gestione (modalità di shutdown, startup, verifica funzionalità, gestione aggiornamenti, etc.), finalizzata a rendere il suddetto personale autonomo nell’effettuazione delle attività tecnico/sistemistiche (si precisa che l’appaltatore dovrà comunque fornire, su richiesta, supporto per tali attività nel corso di tutto il periodo di appalto).
Nel formulare la proposta si deve tener conto delle diverse tipologie di utenza e del fatto che le conoscenze informatiche di base del personale sono disomogenee. Da qui la necessità di un sistema intuitivo ed usabile e di un piano di formazione chiaro e ben strutturato, comprensibile da tutti.
Va prevista anche una modalità formativa per far fronte a cambiamenti nel software che potranno verificarsi a causa di aggiornamenti, dovuti a manutenzione correttiva ed evolutiva.
Al fine di facilitare l'utilizzo del nuovo sistema agli operatori sanitari, va previsto un affiancamento iniziale, on-site, durante le fasi di avviamento delle strutture coinvolte nel cambiamento.
Le aziende offerenti sono tenute, in sede di offerta, a proporre un piano di affiancamento che descriva l’organizzazione delle fasi di affiancamento, indicando le risorse che saranno impiegate, la loro quantificazione in termini di giornate e la modalità con cui verrà erogato tale servizio.
All’appaltatore è richiesto di collaborare con l’Ente alla gestione del cambiamento fornendo supporto attivo e proattivo in tutte le fasi legate al cambiamento organizzativo e di processo nell’ambito dell’esecuzione dell’appalto.
Le attività di Change Management, necessarie a supportare il cambiamento cui saranno sottoposti gli operatori dell'ASUR, dovranno massimizzare l'accettazione del nuovo sistema e ridurre al minimo l'impedenza iniziale nell'utilizzo dei nuovi strumenti. Le aziende partecipanti dovranno documentare le metodologie di CM proposte, al fine di raggiungere gli obiettivi posti.
3.3 Inizio e durata delle attività
Il periodo di durata contrattuale complessivo è fissato in 36 mesi, oltre alle opzioni previste al successivo par. 5.6, e comprende n. 4 macrofasi:
• una prima macrofase (A) con termine massimo a 4 mesi dalla data di avvio dell’esecuzione del contratto: per la consegna del sistema informativo oggetto di appalto garantendo l’interoperabilità con i sistemi unici aziendali (tra cui l’Anagrafe Regionale Centralizzata dell’Assistito);
• una seconda macrofase (B) con termine massimo a 8 mesi dalla data di avvio dell’esecuzione del contratto: per la parziale (60% delle utenze) messa in esercizio del sistema informativo;
• una terza macrofase (C) con termine massimo a 12 mesi dalla data di avvio dell’esecuzione del contratto: per la completa messa in esercizio del sistema informativo;
• una terza macrofase (D) con termine a 36 mesi dalla data di avvio dell’esecuzione del contratto: per il mantenimento del sistema;
Viene considerato sostenibile il seguente modello temporale di base, ferma restando la possibilità di ottimizzare i lavori abbreviando i tempi di rilascio del sistema; l’eventuale attività di manutenzione correttiva ed adeguativa dovrà essere comunque garantita per il tempo residuo, fino al compimento del terzo anno.
Le scadenze sono misurate in mesi.
Fase | Descrizione | Inizio | Durata | Fine | Milestone |
1 | Data verbale di avvio dell’esecuzione del contratto | 0 | 0 | 0 | |
2 | Approvazione progetto esecutivo | 0 | 1 | 1 | |
3 | Installazione del software definitivo con le principali funzionalità del sistema e integrazione con i principali sistemi aziendali | 1 | 2 | 3 | |
4 | Verifica di conformità a freddo: test delle principali funzionalità del sistema e integrazione con i principali sistemi aziendali | 3 | 1 | 4 | A |
5 | Messa in esercizio del sistema informativo completo di tutte le sue funzionalità ed integrazioni coinvolgendo un numero ridotto di utenze | 4 | 3 | 7 | |
6 | Primo step di verifica di conformità a caldo: verifica di conformità del software distribuito con valutazione delle attività per l’avvio in produzione. | 7 | 1 | 8 | B |
7 | Messa in esercizio del sistema informativo completo di tutte le sue funzionalità ed integrazioni estendendone l’utilizzo a tutte le utenze | 8 | 3 | 11 | |
8 | Secondo step di verifica di conformità a caldo | 11 | 1 | 12 | C |
9 | Mantenimento del sistema in esercizio | 12 | 24 | 36 | |
10 | Collaudo finale | 35 | 1 | 36 | D |
Tabella 4 – Cronoprogramma di base delle attività
4. MODALITÀ DI PRESENTAZIONE DELL’OFFERTA
La ditta partecipante dovrà presentare un’offerta tecnica seguendo lo schema conforme all’allegato
1, contenente le modalità di espletamento dei servizi elencati nel capitolato tecnico, i profili professionali messi a disposizione per l’esecuzione dei servizi stessi ed i livelli minimi di servizi garantiti indicati.
5. MODALITÀ DI ESECUZIONE DELL’APPALTO
La messa in opera di un nuovo sistema informativo prevede la realizzazione di una serie di servizi molto articolata e complessa. Pertanto si ritengono, ai sensi del Decreto legislativo 18 aprile 2016, n. 50, necessarie le nomine specifiche del Direttore dell’Esecuzione del contratto (DEC) e della Commissione che deve svolgere l’incarico della Verifica di conformità del contratto. La Verifica di conformità dovrà essere effettuata in corso di esecuzione.
In questa sezione si intende definire una serie di requisiti e regole da seguire per la programmazione delle attività e per la realizzazione del sistema complessivo.
La Stazione Appaltante nomina:
a) Un Direttore dell’Esecuzione, che dovrà svolgere i propri compiti in riferimento a quanto previsto dalle Linee Guida n. 3 di ANAC;
b) Una commissione di verifica della conformità del contratto, che dovrà essere nominata ed eseguire l’incarico in ottemperanza al Decreto legislativo 18 aprile 2016, n. 50
Il responsabile del procedimento si avvarrà quindi di tali organismi tecnici al fine di assicurare il corretto svolgimento dell’intero procedimento.
5.1 Direttore dell’Esecuzione
Il Direttore dell’Esecuzione dovrà in particolare svolgere i seguenti compiti:
1. controllare che le attività previste dal progetto esecutivo dell’Aggiudicatario siano eseguite a regola d’arte ed in conformità al progetto e al contratto. Per svolgere tale compito potrà avvalersi del controllo quantitativo e qualitativo dei componenti del Gruppo di coordinamento, dei responsabili dei servizi farmaceutici di AV o dei dirigenti dei Sistemi Informativi di AV.
2. Interloquire in via esclusiva con l’Aggiudicatario in merito agli aspetti tecnici e contabili del contratto.
3. Curare la costante verifica di validità della documentazione di progetto, dei manuali d'uso e dei manuali tecnici, richiedendo la modifica e aggiornamento dei contenuti in seguito ad eventuali modifiche o variazione della piattaforma applicativa.
4. Concertare con il responsabile della server farm in cui verrà installato il sistema, le modalità di installazione delle componenti tecnologiche del sistema e le modalità di collegamento all’infrastruttura di rete regionale.
5. In caso si verifichino degli inconvenienti di particolare gravità che possano pregiudicare la corretta consegna del sw e dei servizi connessi, il Direttore dell’Esecuzione può convocare una conferenza unitaria tra i dirigenti dei Sistemi Informativi Aziendali di AV ed il responsabile del procedimento, per definire le azioni più efficaci al fine di superare tali inconvenienti.
5.2 Responsabile dell’Attuazione
L’ Aggiudicatario dovrà nominare, all’inizio dei lavori, una persona, dotata delle necessarie competenze adeguatamente documentate, alla quale sarà affidata la responsabilità di tutte le attività di cui si compone il progetto. Detta persona verrà in seguito indicata come il “Responsabile dell’Attuazione”.
Il Responsabile dell’attuazione provvederà a pianificare ed organizzare tutte le attività che consentono l’espletamento dei servizi, nel rispetto dei requisiti di tempi, costi e qualità di cui al presente documento, al contratto ed ai relativi allegati. Eventuali scostamenti dovranno essere segnalati tempestivamente, indicandone la causa e riportati nella relazione periodica come sopra
indicato.
Il piano a regime delle attività sarà oggetto di successive revisioni, almeno trimestrali, concordate tra l’appaltatore ed il direttore di esecuzione.
5.3 Gruppo di coordinamento
In riferimento alla complessità dell’appalto ed alla molteplicità dei servizi coinvolti si ritiene necessario definire un gruppo di coordinamento del presente appalto che dovrà essere di supporto al DEC e alla Commissione di Verifica della Conformità. In particolare il gruppo di coordinamento i cui componenti saranno definiti dalla Direzione avrà il compito di:
1. Collaborare con il Direttore dell’Esecuzione segnalando eventuali difformità, rispetto al progetto, dei prodotti (moduli) e dei servizi rilasciati dall’Aggiudicatario relativi alle aree di propria competenza e proponendo i necessari interventi correttivi;
2. Assistere il Direttore dell’Esecuzione nell'identificare gli interventi necessari ad ottimizzare l’implementazione del sistema;
3. Individuare ed analizzare le cause che influiscono negativamente sulla qualità dei lavori, proponendo al Direttore dell’Esecuzione le adeguate azioni correttive;
4. Assistere i collaudatori nell'espletamento delle operazioni di verifica di conformità;
5.4 Gestione del contratto
L’Aggiudicatario dovrà svolgere le attività previste nel rispetto del progetto esecutivo e di tutti i dettami contrattualmente previsti. L’Aggiudicatario dovrà attenersi alle seguenti disposizioni:
• designazione di un responsabile dell’attuazione per la gestione dei rapporti con il Direttore dell’Esecuzione;
• tempestiva comunicazione al Direttore dell’Esecuzione, in formato elettronico se disponibile, dell’attuazione di una fase di avanzamento (SAL quadrimestrale e Milestone come da tab. 4);
• garanzia del reperimento e consultazione da parte del Direttore dell’Esecuzione, o di un suo incaricato, della documentazione contrattualmente prevista, mediante l’accesso ai sistemi di gestione della documentazione e della configurazione e al sistema della qualità, predisposti dall’Aggiudicatario;
• disponibilità a sottoporre il sw realizzato e l’esecuzione dei servizi connessi a verifiche mirate, o verifiche di seconda parte, svolte in maniera conforme alla norma UNI EN 30011, volte a controllare l’applicazione e il rispetto dei requisiti contrattuali, nonché l’effettiva applicazione e l’utilizzo dell'impianto produttivo richiesto, così come previsto dall'art. 8 della deliberazione DIGITPA n. 49 del 9 novembre 2000, e dalla norma EN ISO 9001:2000;
• partecipazione con proprio personale a riunioni periodiche per l'esame congiunto dell'andamento delle attività;
• annualmente, entro 10 giorni solari dallo scadere dell'anno contrattuale, dovrà essere prodotta una versione aggiornata del Piano di Lavoro approvata dal Direttore dell'Esecuzione.
5.5 Documentazione da produrre
Per tutti i servizi oggetto del contratto l’Aggiudicatario dovrà produrre, aggiornare in corso d’opera, gestire e consegnare al Direttore dell’Esecuzione tutta la documentazione di progetto comprendente, oltre alla reportistica, anche le specifiche di realizzazione del prodotto e dei servizi.
La documentazione dovrà essere aggiornata a seguito di aggiornamenti della procedura software o manutenzione evolutiva.
Si riporta di seguito, con riferimento alle fasi di progetto indicate al par. 3.3, un riepilogo dei principali deliverables previsti:
Fase | Descrizione | Mile- stone | Cod. | Deliverables | Modalità |
1 | Data verbale di avvio dell’esecuzione del contratto |
2 | Approvazione progetto esecutivo | d.1 | Documenti di analisi | Consolidamento, personalizzazioni e integrazioni | |
d.2 | Progettazione esecutiva | Progetto esecutivo di dettaglio, piano di test | |||
3 | Installazione del software definitivo con le principali funzionalità del sistema e integrazione con i principali sistemi aziendali | d.3 | Consegna software (ambiente di test). Report del Porting | Sviluppo personalizzazione, integrazioni, installazione ambiente di test. Porting dati storici. Verbale di conformità | |
4 | Verifica di conformità a freddo: test delle principali funzionalità del sistema e integrazione con i principali sistemi aziendali | A | d.4 | Piani di esecuzione dei test | Test di funzionamento |
5 | Messa in esercizio del sistema informativo completo di tutte le sue funzionalità ed integrazioni coinvolgendo un numero ridotto di utenze | d.5 | Consegna software (ambiente di produzione) | Installazione, caricamento dati e attivazione ambiente di produzione, verbali di conformità | |
d.6 | Piani di formazione e affiancamento | Obiettivi e programmazione corsi | |||
d.7 | Documentazione tecnica | Manuali operatore e documentazione tecnica | |||
d.8 | Piano di verifica dati migrati e consolidati. Report di debugging e fine tuning. Scenari di resilienza e Piano di contingenza per la gestione degli eventuali fermi di sistema | Attività di fine tuning, debugging e consolidamento di dati in ambiente di produzione | |||
6 | Primo step di verifica di conformità a caldo: verifica di conformità del software distribuito con valutazione delle attività per l’avvio in produzione. | B | d.4 | Piani di esecuzione dei test (aggionamento) | Test di funzionamento |
7 | Messa in esercizio del sistema informativo completo di tutte le sue funzionalità ed integrazioni estendendone l’utilizzo a tutte le utenze | d.7 | Documentazione tecnica (aggiornamento) | Manuali operatore e documentazione tecnica | |
d.8 | Piano di verifica dati migrati e consolidati. Report di debugging e fine tuning. Scenari di resilienza e Piano di contingenza per la gestione degli eventuali fermi di sistema (aggiornamento) | Attività di fine tuning, debugging e consolidamento di dati in ambiente di produzione | |||
8 | Secondo step di verifica di conformità a caldo | C | d.4 | Piani di esecuzione dei test (aggionamento) | Test di funzionamento |
9 | Mantenimento del sistema in esercizio | ||||
10 | Collaudo finale | D | d.9 | Collaudo finale | Verbale di collaudo, codice sorgente |
Con riferimento al Progetto esecutivo, l’Aggiudicatario dovrà predisporre un progetto a tutte le attività previste dal rapporto contrattuale, indicando per ciascuna attività i tempi, le risorse umane necessarie, la loro organizzazione ed il relativo impegno (giorni uomo) rappresentato tramite diagrammi di Pert/Gantt.
La fase di definizione del Progetto Esecutivo, dovrà completarsi nel tempo massimo di 1 mese dalla data di inizio attività e l’approvazione del progetto da parte del Direttore dell’Esecuzione autorizzerà
l’Aggiudicatario a dare seguito alle attività.
Il Progetto Esecutivo sarà uno strumento indispensabile per il buon esito della realizzazione del sw e dei servizi connessi e dovrà essere utilizzato come una guida per effettuare gli opportuni controlli di qualità durante la vita dell’appalto. Tale piano verrà monitorato con una frequenza regolare e rappresenterà uno strumento fondamentale per il raggiungimento degli obiettivi.
Sono parte integrante del progetto esecutivo il Piano di Formazione, il Piano della Qualità, il Piano dei Test ed il Piano di Sicurezza di seguito descritti.
Piano di Formazione e Affiancamento
Il Piano di Formazione e Affiancamento deve comprendere tutte le attività di formazione e avviamento all’utilizzo. In genere la preferenza è per l’erogazione di formazione e addestramento on-site, integrabile con modalità diverse di formazione. Il piano deve comprendere, non solo le attività di pura formazione, ma tutte le attività collaterali necessarie, secondo l’Aggiudicatario, per il pieno avvio del sistema.
Piano della Qualità
Il Piano della Qualità ha la funzione di predisporre tutti quegli elementi che portano al conseguimento dell’obiettivo del presente appalto.
In particolare, dovrà descrivere e documentare la struttura organizzativa, le responsabilità e le attività che regolano l’istituzione, la gestione ed il funzionamento del sistema predisposto allo scopo di garantire la consegna di un prodotto conforme ai requisiti del capitolato, mirare alla soddisfazione delle parti interessate (ASUR e AAVV) e implementare attività di miglioramento continuo.
Il Piano della Qualità dovrà essere realizzato seguendo le prescrizioni contenute nella norma UNI EN ISO 9001.
Piano dei Test
Il Piano dei Test descrive l'oggetto, l'approccio generale, le risorse e la pianificazione delle attività di testing da realizzare; fra l'altro identifica i Test Item, le caratteristiche da testare, le attività di testing, rischi e piani di emergenza, criteri generali di Pass/Fail.
Piano di Sicurezza
Il progetto esecutivo dovrà esplicitare il piano operativo di sicurezza che indichi:
• Distribuzione dei compiti e delle responsabilità nell’ambito delle strutture preposte al trattamento dei dati;
• Analisi dei rischi che incombono sui dati;
• Misure atte a garantire l’integrità e la disponibilità dei dati (piano di continuità operativa);
• Formazione degli incaricati;
• Adozione di misure minime di sicurezza in caso di trattamenti esterni ai dati;
• Criteri per la cifratura o la separazione dei dati sulla salute e sulla vita sessuale;
• Criteri di segmentazione della rete;
• Criteri di gestione ed archiviazione dei log di sistema;
• Misure di sicurezza da adottare a livello di database;
• L’elenco delle operazioni periodiche (il c.d. “libro macchina”) e una tantum da effettuare per assicurare il corretto funzionamento in esercizio e prevengano il verificarsi di possibili situazioni di criticità.
• Gli agents predisposti per l’integrazione con il system monitoring complessivo del Data Center.
5.6 Durata del contratto
La durata del contratto è pari a 36 mesi. L’Amministrazione si riserva in ogni caso di esercitare un’opzione di ulteriori 24 mesi per la prosecuzione dei seguenti servizi: assistenza specialistico- applicativa (ASS), manutenzione correttiva e adeguativa (MAN), manutenzione evolutiva (MEV), formazione e affiancamento (FOR) e management di progetto (PGE), il tutto come meglio descritto al successivo par. 5.8.
I termini per l’avvio del contratto decorrono dalla data del verbale di avvio dell’esecuzione. Alla scadenza dei tempi contrattuali l’Amministrazione dovrà emettere un Certificato di verifica di conformità.
Alla scadenza dell’appalto tutta l’eventuale infrastruttura predisposta dall’Aggiudicatario per l’erogazione dei servizi assieme ad una copia della base dati entrambi opportunamente documentati, dovranno essere consegnati all’ASUR in condizioni di perfetta funzionalità e saranno oggetto di verifica di conformità.
5.7 Modalità della verifica di conformità
Le operazioni di verifica di conformità sono effettuate dalla Commissione seguendo la traccia evidenziata nei successivi punti del presente capitolo.
Le tipologie di verifica di conformità sono di seguito individuate, con riferimento alle diverse macrofasi del contratto:
Prima Verifica “a freddo” (Milestone A):
• Verifica di conformità delle funzionalità software della piattaforma applicativa
• Verifica di conformità delle interoperabilità della piattaforma applicativa Prima verifica di conformità “a caldo” (Milestone B)
• Verifica di conformità delle funzionalità software della piattaforma applicativa
• Verifica dell’operatività del sistema nel 60% dell’utenza interessata Seconda verifica di conformità “a caldo” (Milestone C)
• Verifica di conformità delle funzionalità software della piattaforma applicativa
• Verifica dell’operatività del sistema per i rimanenti utenti Verifica di conformità finale (Milestone D)
• Verifica di conformità complessiva del servizio prestato.
Tali tipologie possono essere utilizzate come traccia per la formulazione del piano di collaudo.
Per esigenze operative che dovessero emergere nel corso dell’esecuzione del contratto, il piano di collaudo prestabilito potrà subire integrazioni e/o variazioni, secondo quanto concordato tra il Direttore dell’esecuzione e l’Aggiudicatario.
Tutte le attività di verifica di conformità “a caldo” presuppongono la raccolta preventiva da parte della Commissione di Verifica di Conformità di eventuali osservazioni da parte degli operatori interessati riguardo a eventuali criticità emerse in fase di attivazione del sistema.
Per tutte le fasi di collaudo previste, la Commissione procederà alla:
• valutazione dei risultati;
• risoluzione delle Non conformità accertate;
Ultimate le prestazioni contrattuali, relativamente a ogni fase prevista di esecuzione del contratto, l’Aggiudicatario provvede a darne comunicazione al Responsabile dell’Attuazione e al DEC, unitamente alla documentazione concernente la predisposizione dei casi prova, per procedere alle operazioni di verifica di conformità.
Per ognuna delle fasi precedenti, sulla base dei documenti prodotti o acquisiti dalla commissione di collaudo attestanti l’esito delle prove e controlli, e dall’esame delle Non Conformità rilevate, la commissione di verifica emette apposito Verbale di Verifica.
Per ogni Non Conformità rilevata, consistente in difetti o mancanze di lieve entità, la commissione di collaudo prescrive all’esecutore gli interventi da effettuare per rendere collaudabile la prestazione, assegnando un termine per adempiere.
I problemi riscontrati saranno risolti prima di passare alle fasi successive.
Dopo l’avvenuta soluzione dei problemi si procederà ad una nuova sessione di collaudo, limitatamente alla verifica della rimozione delle Non Conformità stesse, secondo la metodologia appena descritta, redigendo un nuovo verbale e se necessario una nuova revisione del Piano secondo una tempistica concordata tra l’Aggiudicatario e il Direttore dell’Esecuzione.
5.8 Criteri di aggiudicazione
L’affidamento dei servizi previsti nel presente lotto verrà aggiudicato per singolo lotto intero in base al criterio dell’offerta economicamente più vantaggiosa sulla base del miglior rapporto qualità prezzo. Saranno escluse le offerte che non siano formulate per tutti i servizi richiesti.
La valutazione dell’offerta tecnica e dell’offerta economica sarà effettuata in base ai seguenti punteggi:
ELEMENTI DI VALUTAZIONE | PUNTEGGIO MASSIMO |
Offerta tecnica | 70 |
Offerta economica | 30 |
TOTALE | 100 |
Il punteggio dell’offerta tecnica sarà attribuito in base ai seguenti sub-criteri di valutazione, con i relativi sub-pesi e criteri motivazionali:
Criteri e Sub-Criteri di valutazione | Tipo1 (D,Q,T) | Punti Max | Criteri motivazionali | ||
1 | Piano di lavoro, formazione e gruppo di lavoro | 15 | |||
1 | Qualità e adeguatezza del Piano di lavoro | D | 5 | Commissione Giudicatrice. Si attribuisce punteggio più elevato alla migliore proposta presentata. In particolare saranno valutati: la descrizione generale della proposta, con descrizione chiara delle fasi di lavoro e dell’approccio utilizzato nello svolgimento del servizio, in aderenza a quanto richiesto nel capitolato tecnico. Saranno oggetto di valutazione inoltre la qualità della metodologia e degli strumenti proposti per l’erogazione del servizio. Sarà considerata condizione qualificante la messa a disposizione della stazione appaltante di tool automatici per il Test Management, la gestione ed il monitoraggio dei servizi offerti oltre a documentazione per il controllo e consuntivo delle attività di test. | |
2 | Qualità e adeguatezza del piano di formazione e affiancamento | D | 5 | Commissione Giudicatrice. Si attribuisce punteggio più elevato alla migliore proposta presentata. In particolare sarà valutata la descrizione dettagliata della proposta organizzativa del piano di formazione e di affiancamento per gli operatori e per gli amministratori di sistema, come richiesto nel presente capitolato. Con riferimento alla progettazione delle unità didattiche, saranno valutati: la chiarezza degli obiettivi da raggiungere, i programmi dei corsi, il numero di ore del piano di formazione previsto nell’offerta, il numero di ore previsto per l’attività di affiancamento, i curricula del personale docente, le metodologie di insegnamento, il materiale didattico proposto. | |
3 | Profili professionali coinvolti | D | 5 | Commissione Giudicatrice. Si attribuisce punteggio più elevato al valore delle professionalità utilizzate. In particolare saranno valutati i profili e i livelli di specializzazione e competenza |
1 D=punteggi discrezionali; Q=punteggi quantitativi; T=punteggi tabellari
Criteri e Sub-Criteri di valutazione | Tipo1 (D,Q,T) | Punti Max | Criteri motivazionali | ||
indicati, con riguardo all’individuazione del capo progetto e dei membri del gruppo di lavoro; la coerenza, dal punto di vista qualitativo e quantitativo della composizione delle professionalità proposte con le attività che il concorrente intende portare ad esecuzione, come descritte nel presente capitolato, e che dovranno essere impiegate per l’esecuzione degli interventi richiesti con indicazione dei titoli di studio, di specializzazione, esperienze e competenze possedute dai profili professionali presentati. Sarà valutato l’eventuale possesso delle certificazioni di qualità ISO 12207 (ciclo di vita del software) e ISO 27001 (Gestione della sicurezza) oltre ad altre eventuali certificazioni di qualità. | |||||
2 | Sistema e Piattaforma Software | 35 | |||
1 | Qualità e adeguatezza dei requisiti generali (RG) | D | 10 | Commissione Giudicatrice. Si attribuisce punteggio più elevato alla qualità complessiva dell’offerta. In particolare saranno valutati: la proposta del concorrente circa l’organizzazione degli ambienti di sviluppo e di test, la gestione del versionamento dei singoli componenti sw, il processo di rilascio in produzione delle patch o componenti evolutive e il rilascio dei sorgenti alla Stazione Appaltante. | |
2 | Qualità e adeguatezza dei requisiti funzionali specifici (RF) | D | 10 | Commissione Giudicatrice. Si attribuisce punteggio più elevato alla qualità complessiva dell’offerta per quanto attiene i requisiti funzionali specifici. In particolare sarà valutata la descrizione della proposta tecnico-organizzativa per l’esecuzione del servizio di sviluppo software finalizzato alla personalizzazione dello stesso secondo quanto indicato nel presente Capitolato e per la realizzazione delle integrazioni con i sistemi aziendali e regionali secondo quanto specificato nel presente Capitolato. Saranno oggetto di valutazione da parte della stazione appaltante la qualità della metodologia e degli strumenti proposti per l’erogazione del servizio (organizzazione, attività, processi necessari). | |
3 | Qualità e adeguatezza dei requisiti tecnici (RT) | D | 10 | Commissione Giudicatrice. Si attribuisce punteggio più elevato alla qualità complessiva dell’offerta per quanto attiene la soluzione tecnica e architetturale offerta. | |
4 | Piano di migrazione | D | 5 | Commissione Giudicatrice. Si attribuisce punteggio più elevato alla qualità e adeguatezza del piano di migrazione. In particolare sarà valutata la proposta tecnico-organizzativa per il servizio di migrazione dei dati pregressi in termini di qualità dei processi di analisi delle banche dati degli applicativi sorgente, il pregio tecnico del Piano di Migrazione proposto, la presenza e la qualità tecnica di eventuali strumenti per il trasferimento automatico dei dati, la presenza e la qualità di un sistema di reportistica relativo ai risultati ottenuti in termini di completezza e correttezza del trasferimento dati. | |
3 | Servizi sistemistici e di manutenzione ed assistenza (MAN, MEV, ASS) | 15 | |||
1 | Servizi sistemistici | D | 5 | Commissione Giudicatrice. Si attribuisce punteggio più elevato alla qualità dei servizi sistemistici. In particolare sarà valutata: la descrizione dell’infrastruttura hardware, software e delle attività con i quali il partecipante intende erogare i servizi sistemistici richiesti nel presente capitolato; i processi e le tecnologie adottati per garantire la Continuità Operativa ed il Disaster Recovery ai sensi del CAD. Saranno oggetto di valutazione la qualità della metodologia e degli strumenti proposti per l’erogazione del servizio. | |
2 | Servizi di manutenzione, di assistenza tecnica, di cessazione del servizio ed attività di fine contratto | D | 10 | Commissione Giudicatrice. Si attribuisce punteggio più elevato alla qualità dei servizi proposti. In particolare sarà valutata: la qualità della proposta tecnico-organizzativa per i servizi di manutenzione, di assistenza tecnica, di cessazione del servizio ed attività di fine contratto richiesti nel capitolato, con particolare riferimento all’organizzazione, alle attività e ai processi necessari all’erogazione del servizio che intende proporre. | |
4 | Servizi migliorativi | D | 5 | Commissione Giudicatrice. Si attribuisce punteggio più elevato alle migliori proposte migliorative. In particolare saranno valutate le eventuali migliorie, in termini quantitativi e qualitativi, rispetto alle prestazioni indicate nel Capitolato, quali, a titolo |
Criteri e Sub-Criteri di valutazione | Tipo1 (D,Q,T) | Punti Max | Criteri motivazionali | ||
esemplificativo, migliorie sulle funzionalità del software o dei servizi. | |||||
TOTALE | 70 |
Tabella 5 – Criteri di valutazione qualità
A ciascuno degli elementi qualitativi cui è assegnato un punteggio discrezionale “D”, individuato nella colonna “Tipo” della tabella, ciascun commissario di gara procederà ad attribuire un coefficiente, variabile tra 0 e 1, motivando le ragioni della propria attribuzione e collegando la motivazione ai criteri previsti nella precedente tabella, secondo la seguente scala:
Xxxxxxxxxxxx | Xxxxxxxx |
0 | In caso di mancanza di documentazione o di elementi necessari per la valutazione del parametro considerato |
0,25 | In relazione ad un giudizio espresso sul parametro considerato “scarso” |
0,50 | In relazione ad un giudizio espresso sul parametro considerato “discreto” |
0,75 | In relazione ad un giudizio espresso sul parametro considerato “buono” |
1 | In relazione ad un giudizio espresso sul parametro considerato “ottimo” |
Una volta che ogni commissario avrà attribuito il coefficiente a ciascun criterio/sub-criterio, la commissione calcolerà la media aritmetica dei coefficienti attribuiti dai singoli commissari all’offerta, in relazione al criterio/sub-criterio in esame, al fine di ottenere il coefficiente medio da applicare al medesimo. Il coefficiente sarà arrotondato alla seconda cifra decimale, in eccesso qualora la terza cifra decimale sia pari o superiore a cinque, in difetto qualora la terza cifra decimale sia inferiore a cinque. Il coefficiente medio arrotondato, che risulterà dalla media aritmetica dei coefficienti attribuiti dai singoli commissari, sarà quindi moltiplicato per il peso fissato per ciascun criterio al fine di ottenere il punteggio relativo al criterio.
L’offerta non sarà ritenuta valida e, pertanto, non sarà ammessa alla fase di apertura dell’offerta economica in quanto esclusa dalla gara, qualora non rispetti le seguenti condizioni:
• deve essere rispondente ad ogni requisito generale, funzionale, integrativo e tecnico richiesto (RG, RF, RT) o adeguabile entro un termine congruo o comunque offrire una modalità alternativa, ritenuta valida dalla commissione giudicatrice
• la valutazione qualitativa deve raggiungere un punteggio non inferiore a 6/10 del punteggio massimo stabilito cioè almeno 42 punti.
PREZZO
L’importo a base di gara del presente lotto è pari a € 461.625,16 al netto di IVA. E’ esclusa dalla gara l’offerta in aumento.
Si riporta di seguito, anche ai fini della formulazione dell’offerta, il prospetto contente il dettaglio dei costi, al netto di IVA.
Cod. | Descrizione servizio | UM | Q.tà | Prezzo unitario a base di gara | Importo a base di gara |
PSW | Piattaforma software, secondo le specifiche indicate nel capitolato tecnico | Corpo | 1 | € 95.000,00 | € 95.000,00 |
ANP | Servizi di avviamento della piattaforma software (comprende integrazioni e recupero dati) | Corpo | 1 | € 160.000,00 | € 160.000,00 |
PGE | Servizi di management di progetto | Canone annuale | 3 | € 6.000,00 | € 18.000,00 |
FOR | Servizi di formazione e affiancamento | gg/uomo | 50 | € 307,38 | € 15.369,00 |
TOT1 | Importo totale avviamento progetto | € 288.369,00 | |||
ASS | Assistenza specialistica-applicativa di primo e secondo livello | Canone mensile | 28 | € 3.080,00 | € 86.240,00 |
MAN | Servizi di manutenzione correttiva e adeguativa | Canone mensile | 28 | € 965,00 | € 27.020,00 |
MEV | Servizi di manutenzione evolutiva | gg/uomo | 256 | € 234,36 | € 59.996,16 |
TOT2 | Importo servizi di manutenzione e assistenza | € 173.256,16 | |||
TOTALE IMPORTO SERVIZI | € 461.625,16 |
Tabella 6 – Schema dettaglio costi, netto IVA.
Il punteggio per il prezzo sarà attribuito con il criterio dell'interpolazione lineare secondo la formula:
Vai = Ra / Rmax
dove,
Vai = Coefficiente della prestazione dell’offerta (a) rispetto al requisito (i), variabile tra 0 e 1
Ra = Valore (ribasso) offerto dal concorrente “a”
Rmax = Valore (ribasso) dell’offerta più conveniente
Il coefficiente andrà poi moltiplicato per il punteggio massimo attribuibile.
Per l’esercizio dell’opzione per la prosecuzione dei servizi per ulteriori 24 mesi è altresì stimato un importo pari ad € 133.246,20 al netto di IVA, il cui dettaglio per servizio è riportato nella tabella che segue.
Si precisa che i costi sotto indicati saranno riparametrati ai prezzi unitari offerti a seguito della migliore offerta da parte del concorrente aggiudicatario.
Cod. | Descrizione servizio | UM | Q.tà | Prezzo unitario a base di gara / offerto | Importo a base di gara |
PGE | Servizi di management di progetto | Canone annuale | 2 | € 6.000,00 | € 12.000,00 |
FOR | Servizi di formazione e affiancamento | gg/uomo | 10 | € 307,38 | € 3.073,80 |
TOT1 | Importo totale avviamento progetto | € 15.073,80 | |||
ASS | Assistenza specialistica-applicativa di primo e secondo livello | Canone mensile | 24 | € 3.080,00 | € 73.920,00 |
MAN | Servizi di manutenzione correttiva e adeguativa | Canone mensile | 24 | € 965,00 | € 23.160,00 |
MEV | Servizi di manutenzione evolutiva | gg/uomo | 90 | € 234,36 | € 21.092,40 |
TOT2 | Importo servizi di manutenzione e assistenza | € 118.172,40 | |||
TOTALE IMPORTO SERVIZI | € 133.246,20 |
Tabella 7 – Schema dettaglio costi – Opzione 24 mesi (netto IVA).
5.9 SLA
La ditta è soggetta a penali, senza obbligo di messa in mora, nei seguenti casi:
Cod | Descrizione | U.M. | SLA 2 | Regola applicazione | Penale |
PSW: Servizi di configurazione, personalizzazione e trasferimento dati | |||||
PSW1 | Rispetto dei tempi richiesti per il rilascio del milestone B | giorni | 240 | per ogni U.M. solare di ritardo | 0,5 per mille valore contratto |
PSW2 | Rispetto dei tempi richiesti per il rilascio del milestone C | giorni | 360 | per ogni U.M. solare di ritardo | 0,5 per mille valore contratto |
ASS: Servizi di assistenza | |||||
ASS1 | Tempo di ripristino in caso di malfunzionamento non bloccante a partire dalla segnalazione. | ore | 12 | per ogni U.M. (o frazioni arrotondate per eccesso) di ritardo | € 200,00 |
ASS2 | Tempo di ripristino in caso di malfunzionamento bloccante a partire dalla segnalazione. | ore | 4 | per ogni U.M. (o frazioni arrotondate per eccesso) di ritardo | € 200,00 |
ASS3 | Tempo massimo garantito per prima risposta/ workaround a partire dalla segnalazione. | ore | 1 | per ogni U.M. (o frazioni arrotondate per eccesso) di ritardo | € 200,00 |
MAN / MEV: Servizi di manutenzione | |||||
MAN1 | Tempo massimo garantito per inizio intervento a seguito di segnalazione da parte dei soggetti preposti | ore | 4 | per ogni U.M. (o frazioni arrotondate per eccesso) di ritardo. | € 300,00 |
MAN2 | Tempo massimo di fermo macchina server a seguito di aggiornamenti pesanti | ore | 8 | per ogni U.M. (o frazioni arrotondate per eccesso) di ritardo | € 400,00 |
MAN3 | Tempo massimo per aggiornamento sw | ore | 12 | per ogni U.M. (o frazioni arrotondate per eccesso) di ritardo | € 400,00 |
MEV1 | Tempo massimo di predisposizione del progetto di manutenzione evolutiva | giorni | 7 | per ogni U.M. solare di ritardo | 0,3 per mille valore contratto |
MEV2 | Tempo massimo di erogazione del servizio di manutenzione evolutiva | giorni | come da crono program ma | per ogni giorno solare di ritardo rispetto al cronoprogramma di sviluppo delle implementazioni da realizzare. | 0,3 per mille valore contratto |
Tabella 8 – Performance minime di capitolato.
6. ALLEGATO 1 – Schema di offerta tecnica
Con riferimento all’offerta tecnica, è richiesta ai concorrenti la presentazione della seguente documentazione:
a) Relazione Tecnica, in lingua italiana, priva di qualsivoglia indicazione (diretta o indiretta) di
2 Performance minime di capitolato, ovvero performance migliorative di offerta.
carattere economico, dalla quale si evinca in modo completo e dettagliato, conformemente ai requisiti indicati dal Capitolato Tecnico, la descrizione dei servizi offerti oggetto di gara;
b) Curricula dei profili professionali coinvolti.
I documenti di offerta tecnica sono richiesti con interlinea 1,5 e font EasyReading 12 o Times New Roman 12.
a) RELAZIONE TECNICA
La Relazione tecnica dovrà necessariamente esporre le caratteristiche e le modalità di esecuzione e di prestazione dei servizi offerti, oggetto del presente appalto, con riferimento ai requisiti indicati nel Capitolato tecnico, mediante la trattazione degli argomenti di seguito indicati.
1. Executive summary: max 5 pagine;
2. Piano di Lavoro: max 6 pagine
3. Piano di Formazione e Affiancamento: max 4 pagine
4. Sistema e piattaforma software
4.1. Requisiti generali, funzionali e tecnici: max 10 pagine, oltre alle tabelle requisiti richieste
4.2. Piano di migrazione: max 3 pagine
5. Servizi sistemistici e di manutenzione e assistenza (MAN, MEV, ASS): max 10 pagine
6. Servizi migliorativi: max 3 pagine
1. Executive summary
E’ richiesta ai concorrenti una sintesi della proposta offerta, contente le caratteristiche salienti della stessa.
2. Piano di Lavoro (PGE, FOR, PSW, ANP, MAN, MEV, ASS)
E’ richiesto ai concorrenti di presentare la propria proposta progettuale e organizzativa per la realizzazione dei servizi richiesti dal presente Capitolato.
La proposta dovrà contenere una descrizione chiara delle fasi di lavoro e dell’approccio utilizzato nello svolgimento del servizio, in aderenza a quanto richiesto nel capitolato tecnico; la descrizione della metodologia e degli strumenti proposti per l’erogazione del servizio, indicando eventuali tool automatici per il Test Management, per la gestione ed il monitoraggio dei servizi offerti ovvero eventuale documentazione per il controllo e consuntivo delle attività di test che l’offerente metterà a disposizione. Alla proposta dovrà essere allegato un cronoprogramma delle attività previste.
3. Piano di Formazione e Affiancamento
Il Piano di Formazione e Affiancamento deve comprendere tutte le attività di formazione e avviamento all’utilizzo del sistema. E’ richiesta ai concorrenti una descrizione dettagliata della proposta organizzativa del piano di formazione e di affiancamento per gli operatori e per gli amministratori di sistema, come richiesto nel presente capitolato. In particolare nella proposta dovranno essere esplicitati: obiettivi da raggiungere, programmi dei corsi, numero di ore del piano di formazione previsto nell’offerta, numero di ore previsto per l’attività di affiancamento, curricula del personale docente, metodologie di insegnamento, e materiale didattico proposto, tenendo conto, per la progettazione delle unità didattiche, la distinzione, in primo luogo, del personale coinvolto (operatori e amministratori di sistema) e poi degli specifici argomenti da trattare.
4. Sistema e piattaforma software (PSW, ANP)
4.1 Requisiti generali, funzionali e tecnici
E’ richiesta ai concorrenti la descrizione delle caratteristiche del sistema offerto e, per ognuno dei requisiti indicati nella sezione 2 del Capitolato Tecnico, come questi vengono implementati. In particolare è richiesto di allegare una tabella riepilogativa in cui, rispetto ai requisiti elencati nella sezione 2, siano descritte le funzionalità del sistema ed i riferimenti alle funzioni del prodotto offerto e/o ad altra documentazione allegata in modo da consentire la corretta valutazione qualitativa del
sistema offerto, secondo il seguente schema:
Specifiche di cui al capitolo 2 | SI, conforme 100% | Non e' pienamente conforme, e si esplicita il tempo, in giorni lavorativi, per la conformità al 100% | Modalità alternativa per assolvere il requisito, descrivere |
RG1 | |||
….. | |||
RGn | |||
RF1 | |||
…… | |||
RFn | |||
RT1 | |||
…. | |||
RTn |
Tabella 1 – Descrizione delle caratteristiche del sistema offerto.
Con riferimento ai requisiti generali, oltre alle schede sopra riportate è richiesto a ciascun concorrente di descrivere come intenda organizzare al proprio interno gli ambienti di sviluppo e di test, la gestione del versionamento dei singoli componenti sw, il processo di rilascio in produzione delle patch o componenti evolutive e il rilascio dei sorgenti alla Stazione Appaltante.
Con riferimento ai requisiti funzionali specifici, è richiesta ai concorrenti la presentazione di una proposta tecnico-organizzativa per l’esecuzione del servizio di sviluppo software finalizzato alla personalizzazione dello stesso secondo quanto indicato nel presente Capitolato e per la realizzazione delle integrazioni con i sistemi aziendali e regionali secondo quanto specificato nel presente Capitolato. Il concorrente in sede di offerta dovrà descrivere l’organizzazione, le attività, i processi necessari all’erogazione del servizio di sviluppo software che intende proporre, evidenziando, in particolare:
• le metodologie adottate per l’analisi dei processi;
• le metodologie adottate per effettuare l’analisi dei requisiti e la progettazione degli interventi evidenziando i punti in cui dovranno essere coinvolti gli stakeholders e le responsabilità di ciascun attore;
• i criteri e strategie adottati per la selezione delle attività prioritarie;
• la metodologia di sviluppo adottata (USDP, Agile, ecc.) ed i deliverable previsti per ognuna iterazione, le tipologie di documentazione tecnica prodotta, gli strumenti utilizzati per comunicare lo stato di avanzamento dello sviluppo e la periodicità di aggiornamento, le metodologie di trattamento degli imprevisti e dei possibili rischi
• gli specialisti che verranno impiegati.
Il concorrente dovrà inoltre allegare, a conferma di quanto sopra, i seguenti documenti/deliverables esplicativi del sistema offerto:
• Manuale utente della procedura o estratto relativo alle funzioni più significative.
• Documentazione tecnica che illustri l’architettura software, l’analisi funzionale, la progettazione ad alto livello di dettaglio e lo schema dei flussi dati usando diagrammi UML (casi d’uso, diagramma delle classi di analisi, di sequenza, diagramma dei componenti,
diagramma di deployment, ecc.).
4.2 Piano di migrazione
E’ richiesta ai concorrenti la presentazione di una proposta tecnico-organizzativa per il servizio di migrazione dei dati pregressi che descriva gli strumenti e le metodologie messe in atto per garantire la qualità del piano proposto e la completezza e correttezza del trasferimento dati, tra cui: strumenti/processi per l’analisi delle banche dati degli applicativi sorgente, strumenti per il trasferimento automatico dei dati, sistemi di reportistica relativi ai risultati ottenuti in termini di completezza e correttezza del trasferimento.
5. Servizi sistemistici e di manutenzione e assistenza (MAN, MEV, ASS)
E’ richiesta ai concorrenti la presentazione di una proposta che indichi le attività, l’infrastruttura hardware, software con i quali il partecipante intende erogare i servizi sistemistici richiesti nel presente capitolato. Devono essere, inoltre descritti i processi e le tecnologie adottati per garantire la Continuità Operativa ed il Disaster Recovery ai sensi del CAD (Codice dell’Amministrazione Digitale). La descrizione di tali servizi sarà effettuata con riferimento alla metodologia e agli strumenti proposti per l’erogazione del servizio.
In merito ai servizi di assistenza, manutenzione correttiva e adeguativa e manutenzione evolutiva, è richiesta ai concorrenti la presentazione di una proposta tecnico-organizzativa che illustri, oltre ai servizi di manutenzione e assistenza tecnica, i servizi di cessazione del servizio ed attività di fine contratto. Il concorrente in sede di offerta dovrà descrivere l’organizzazione, le attività, i processi necessari all’erogazione del servizio che intende proporre, descrivendo altresì la metodologia e gli strumenti proposti per l’erogazione del servizio.
Inoltre, è richiesto ai concorrenti di descrivere:
- le modalità di aggiornamento del sistema e i tempi massimi di reazione previsti in caso di adeguamento di legge, per il servizio di manutenzione adeguativa e correttiva;
- l’organizzazione dell’help-desk, il personale utilizzato (allegare i curricula nella sezione apposita) e le modalità con cui viene garantita la copertura oraria e la continuità del servizio in caso di assenza o sostituzione del personale, le modalità di erogazione e di rendicontazione;
- le modalità atte a garantire il controllo di qualità (anche i termini di rispetto degli SLA), sugli interventi effettuati;
- il flusso di processo delle richieste di assistenza e di escalation tecnica dei problemi verso la soluzione, con la proposta di coinvolgimento del personale tecnico ASUR;
- le modalità di aggiornamento del catalogo prodotti erogabili mediante il servizio da sviluppare.
6. Servizi migliorativi
E’ richiesto ai concorrenti di illustrare gli eventuali servizi aggiuntivi o migliorativi in termini quantitativi e qualitativi rispetto alle prestazioni minimali indicate nel Capitolato. Saranno valutati positivamente, per esempio, funzionalità software non richieste o non previste nel presente capitolato ma di utilità nella gestione dei servizi, il miglioramento del servizio di assistenza tecnica.
b) PROFILI PROFESSIONALI COINVOLTI
Per ogni risorsa messa a disposizione per le attività relative al presente appalto dovrà essere compilata una scheda “curriculum” dove deve essere evidenziato in quale profilo viene messo a disposizione, il numero di anni di esperienza nel profilo offerto, le funzioni e le attività svolte fino ad oggi e il know -how.
In particolar modo, devono essere specificate le funzioni e le attività svolte in contesti operativi corrispondenti a quelli previsti nel presente Capitolato. L’esperienza dichiarata per ogni risorsa messa a disposizione deve essere evidenziata tramite opportuna documentazione – ad es. lettere di referenza e/o attestati – da presentare prima dell’avvio del servizio.
Si precisa che le risorse messe a disposizione non potranno coprire più profili professionali.
Si chiede, inoltre, di indicare l’eventuale possesso delle certificazioni di qualità ISO 12207 (ciclo di vita del software) e ISO 27001 (Gestione della sicurezza) oltre ad altre eventuali certificazioni di qualità.
Capo Progetto
Tale figura assume un ruolo chiave nello svolgimento del progetto in quanto cura la progettazione concettuale, stima e pianificazione, conduzione e controllo dell’appalto nel suo complesso.
Inoltre esegue attività di consulenza applicativa, supporto a livello di progettazione concettuale e tecnica, rapporti con i clienti.
Per tale ruolo si richiede una figura professionale con le seguenti caratteristiche:
a.CAPO PROGETTO | |
Titolo di studio | Laurea in discipline tecnico/informatiche/economiche |
Esperienze lavorative | Anzianità lavorativa di almeno 5 anni, con almeno 4 di provata esperienza lavorativa nella specifica funzione su progetti complessi. Almeno 5 anni di provata esperienza su analisi e progettazione di sistemi informativi, package e procedure complesse nel settore pubblico, con periodi di permanenza continuativa presso lo stesso cliente non inferiori a 6 mesi. Nell’ambito delle esperienze di lavoro deve avere, nel ruolo richiesto, almeno 3 progetti iniziati e/o conclusi negli ultimi 5 anni. Si richiede di evidenziare i progetti richiesti, esplicitando in modo chiaro i prodotti realizzati che corrispondono agli ambiti richiesti |
Conoscenze | Nelle esperienze lavorative ha approfondito la conoscenze relativa a: Metodologie di stima, metrica, misura tempi e risorse, pianificazione e controllo di progetti. Tematiche applicative nell’ambito dei sistemi di conservazione e/o gestione documentale nella Pubblica Amministrazione. Redazione di requisiti e specifiche di progetto conformi allo standard IEEE 830-1998. Analisi di processi Analisi e progettazione concettuale e fisica di sistemi informativi, package, procedure complesse Conoscenze ed uso di tecniche e prodotti SW per project management e risk management Responsabilità su gruppi di progetto |
Tabella 2 – Schema cv del capo progetto.
Analisti funzionali senior
Per la corretta progettazione concettuale e logica in ambiente distributivo dei diversi sistemi, la predisposizione delle procedure di test e validazione e della documentazione tecnica, si richiede uno o più analisti senior con le seguenti caratteristiche generali:
b.ANALISTA FUNZIONALE SENIOR | |
Titolo di studio | Laurea in discipline tecnico/informatiche |
Esperienze lavorative | Anzianità lavorativa di almeno 5 anni, di cui 3 come analista. Partecipazione a progetti di sviluppo presso realtà della Pubblica Amministrazione su tematiche relative alla gestione dei prodotti di assistenza integrativa e relativi servizi facendo esperienza nei seguenti ambiti: • Gestione ed organizzazione di attività di sviluppo • Redazione di specifiche di progetto • Redazione di modelli dei processi |
• Controllo realizzazione procedure • Stima di risorse per realizzazione di progetto • Stima di tempi • Coordinamento di gruppi di lavoro • Disegno e progettazione di test | |
Conoscenze | Xxxxx esperienze lavorative ha approfondito la conoscenze relativa a: Metodologie di analisi dei processi Metodologie di analisi e disegno di prodotti SW Service Oriented e Objeco Oriented, tramite UML Tecniche di gestione e controllo dei progetti basate su “Unified Process” Tecniche di programmazione e strumenti CASE Object Oriented in ambiente Java e/o Microsoft. Tematiche applicative/gestionali, preferibilmente in ambito di processi relativi alla Pubblica Amministrazione |
Tabella 3 – Schema cv dell’analista funzionale senior.
Analisti programmatori
Per l’analisi di dettaglio, realizzazione e codifica unit test dei programmi, si richiede almeno una figura professionale con i seguenti requisiti generali:
c.ANALISTA PROGRAMMATORE | |
Titolo di studio | Diploma di perito informatico o cultura equivalente |
Esperienze lavorative | Anzianità lavorativa di almeno 3 anni come programmatore e almeno 1 nella funzione di analista programmatore. Partecipazione a progetti software presso realtà della Pubblica Amministrazione facendo esperienza nei seguenti ambiti: • Metodologie di analisi e disegno di prodotti SW, anche con strumenti MDA-oriented • Metodologie di analisi e progetto di servizi in cloud (IaaS, PaaS, SaaS) prodotti SW service oriented • Verifica della corretta applicazione di metodi e standard • Documentazione procedure • Programmazione e test (preparazione casi di test ed esecuzione di test) • Partecipazione a gruppi di progetto di medie/grandi dimensioni • Installazione e personalizzazione di sistemi anche complessi • Progettazione ed integrazione di sistemi • Utilizzo linguaggi XHTML e XML • Tecniche di programmazione strutturata Service Oriented e Object Oriented |
Conoscenze | Metodologie di analisi e disegno di prodotti SW tramite strumenti MDA- oriented Tecniche di programmazione in ambiente Java e/o Microsoft DBMS relazionali Strumenti di modellazione dati Linguaggi XHTML e XML |
Tabella 4 – Schema cv dell’analista programmatore.
Inoltre, si richiede almeno un esperto nella gestione dei flussi documentali che abbia esperienza nello sviluppo di sistemi di dematerializzazione ovvero con le seguenti con le seguenti caratteristiche generali:
d.ANALISTA PROGRAMMATORE - esperto gestione flussi documentali | |
Titolo di studio | Diploma di perito informatico o cultura equivalente |
Esperienze lavorative | Anzianità lavorativa di almeno 3 anni come programmatore e almeno 2 nella funzione di analista programmatore. Partecipazione a progetti di dematerializzazione presso realtà della Pubblica Amministrazione facendo esperienza nei seguenti ambiti: • Document Management System in ambito open source • Metodologie di analisi e disegno di prodotti SW, anche con strumenti MDA-oriented • Verifica della corretta applicazione di metodi e standard • Documentazione procedure • Programmazione e test (preparazione casi di test ed esecuzione di test) • Partecipazione a gruppi di progetto di medie/grandi dimensioni • Installazione e personalizzazione di sistemi anche complessi • Progettazione ed integrazione di sistemi • Utilizzo linguaggi UML, XHTML e XML • Tecniche di programmazione strutturata Service Oriented e Object Oriented |
Conoscenze | Metodologie di disegno di prodotti SW Tecniche di programmazione in ambiente Java e/o Microsoft DBMS relazionali Strumenti di modellazione dati Linguaggi UML, XHTML e XML |
Tabella 5 – Schema cv dell’analista programmatore esperto di flussi documentali.
Inoltre, per la progettazione di dettaglio di interfacce utente per applicazioni Web, definizione percorsi di navigazione e livelli di validazione, si richiede almeno un esperto che abbia le seguenti caratteristiche generali:
e.ANALISTA PROGRAMMATORE - esperto user interface design, usability testing, graphics design | |
Titolo di studio | Diploma di perito informatico o cultura equivalente |
Esperienze lavorative | Anzianità lavorativa di almeno 3 anni come programmatore e almeno 1 nella funzione di analista programmatore. Partecipazione a progetti di portali Web presso realtà della Pubblica Amministrazione facendo esperienza nei seguenti ambiti: • Sviluppo interfacce web conformi ai principi di usabilità e accessibilità. • Tecniche di disegno del dialogo applicazione/utente in ambienti grafici (GUI) • Metodologie di analisi e disegno di prodotti SW, anche con strumenti MDA-oriented • Sviluppo di web app o mobile app. • Verifica della corretta applicazione di metodi e standard • Sviluppo di analisi tecnica di media complessità • Documentazione procedure • Programmazione e test (preparazione casi di test ed esecuzione di test) • Partecipazione a gruppi di progetto di medie/grandi dimensioni • Installazione e personalizzazione di sistemi anche complessi |
• Progettazione ed integrazione di sistemi • Utilizzo linguaggi UML, XHTML e XML • Tecniche di programmazione strutturata Service Oriented e Object Oriented | |
Conoscenze | Metodologie di disegno di prodotti SW Tecniche di programmazione in ambiente Java e/o Microsoft DBMS relazionali Strumenti di modellazione dati Linguaggi UML, XHTML e XML |
Tabella 6 – Schema cv dell’analista programmatore esperto di user interface design.
Data Base e System Administrator
Per la gestione dei data base si richiede almeno due figure professionali con le seguenti caratteristiche generali:
f.DBA e system administration | |
Titolo di studio | Diploma di perito informatico o cultura equivalente |
Esperienze lavorative | Anzianità lavorativa di almeno 6 anni • Amministrazione di SQL-based RDBMS per l’ottimizzazione, il dimensionamento, il tuning e gli aspetti di sicurezza e di recovery. • Supporto tecnico per la progettazione logica e fisica delle basi di dati • Gestione policy di accesso ai sistemi • Supporto all’integrazione di sistemi e servizi applicativi • Implementazione procedure e politiche di backup e recovery |
Conoscenze | Gestione di RDBMS Microsoft SQL server o Postgres o Oracle PL/SQL |
Tabella 7 – Schema cv del database e system administrator.
Di seguito viene fornito lo schema che il concorrente dovrà utilizzare per la compilazione dei curriculum vitae. Si sottolinea che nella compilazione dei contenuti dovranno essere privilegiati gli aspetti di interesse per l’appalto. Si rammenta che non è obbligatorio indicare il nominativo della risorsa.
Nominativo | (Inserire il Cognome e il Nome della risorsa) |
Ruolo | (Inserire il Ruolo attualmente ricoperto dalla risorsa) |
Profilo | (Fornire una breve descrizione del profilo professionale in termini di competenze e di aree chiave in cui la risorsa ha maturato esperienze significative) |
Principali Esperienze Lavorative | (Indicare le esperienze più significative, ed in particolare per la gara in oggetto, a partire dalla più recente, fornendo una breve descrizione delle attività svolte, del cliente, del ruolo ricoperto, della durata del progetto. E' necessario suddividere le esperienze per anno e per settore (Es: Bancario, Telecomunicazioni, Pubblica Amministrazione) |
Settore | Anno | Esperienze | |
Competenze Tecniche | (Indicare le competenze di cui si è in possesso (es: progettazione ed implementazione di strategie di marketing; analisi di settore; sviluppo di analisi di fattibilità; gestione del cambiamento organizzativo etc.) | ||
Specializzazioni /Certificazioni | (Indicare eventuali specializzazioni, certificazioni, master, ecc.) | ||
Anno | Titolo | Descrizione | |
Istruzione | (indicare i titoli di studio) | ||
Università, Scuola….. | Tipologia di Laurea o Diploma, …. | ||
Luogo e Data _ Il legale rappresentante
_