Accordo di Programma Quadro in materia di “e- Government e Società dell’Informazione” nella Regione Puglia
Gara a procedura aperta per l’affidamento di servizi di progettazione, realizzazione e conduzione operativa del “Sistema di Accesso Unificato dei Servizi Sanitari per il Cittadino”
Allegato 4: Capitolato Tecnico
Tecnopolis XXXXX x.x.x.x.
Xx. xxxx. Xxxxxxxxxxx Xx 0 00000 Xxxxxxxxx XXXX
Xxxxxx
25 Luglio 2008
Indice
1 INTRODUZIONE 5
1.1 Scenario di riferimento 5
1.2 Obiettivi del Portale della Salute 7
2 OGGETTO DELLA FORNITURA 11
2.1 Sviluppo software per la realizzazione del Portale e manutenzione 11
2.2 Infrastruttura tecnologica e strumenti per l’erogazione dei servizi 32
2.3 Formazione e addestramento 50
2.4 Servizio di assistenza tecnico-applicativa e conduzione operativa 55
2.5 Piano di comunicazione integrato e connessi servizi di attuazione 68
3 TEMPI DELLA FORNITURA 76
4 INFORMAZIONI GENERALI SULLA FORNITURA 78
4.1 Sedi di lavoro 78
4.2 Relazione Tecnica e Piano di Progetto 78
4.3 Progetto esecutivo 78
4.4 Rilascio prodotti 79
4.5 COLLAUDO 80
4.6 Livelli di servizio e penalità 81
5 NORMATIVA DI RIFERIMENTO 83
6 APPENDICE A - IL PORTALE DEL CALL CENTER INFORMATIVO SANITARIO DELLA REGIONE PUGLIA 85
6.1 Informazioni gestite 85
6.2 Gestione delle richieste 88
6.3 Gestione delle segnalazioni 89
7 APPENDICE B - SERVIZI ESPOSTI DAL SISTEMA INFORMATIVO SANITARIO TERRITORIALE 90
7.1 Elenco casi d’uso per componente 90
7.2 Diagrammi di sequenza 126
7.3 Elenco dei web service relativi a servizi al cittadino 128
Indice Figure
Figura 1 - Modello Organizzativo 10
Figura 2 – Architettura funzionale 12
Figura 3 - Modello di riferimento per la TV digitale terrestre 22
Figura 4 - Topologia logica rete Portale 33
Figura 5 - Architettura logica del Centro Servizi Portale della Salute 36
Figura 6: SD_Identificare Cittadino : in Anagrafe 126
Figura 7: SD_Consultare FSE Ricerca Avanzata Da Elenco 127
Figura 8: SD_Recuperare Dati Emergenza GUI 128
Figura 9: SD_Recuperare Scheda Sanitaria 128
Indice Tabelle
Tabella 1 – Risorse coinvolte per la Gestione del Portale 10
Tabella 2 - Infrastruttura Centro Servizi Portale 35
Tabella 3 - Ubicazione e sedi Centri Servizi Portale 49
Tabella 4 – Azioni del Piano di comunicazione integrata 71
Tabella 5 - Fasi di rilascio del Portale 77
Tabella 6 – Collaudi 81
1 Introduzione
Il presente Capitolato Tecnico disciplina gli aspetti tecnici connessi alla fornitura a Tecnopolis CSATA S.c.r.l. (di seguito chiamata Committente) di servizi informatici e di servizi di predisposizione ed attuazione del Piano di Comunicazione Integrato necessari alla realizzazione del progetto denominato Sistema di Accesso Unificato dei Servizi Sanitari per il Cittadino (di seguito denominato anche Portale della Salute o Portale).
Il Portale della Salute realizzerà l’infrastruttura unica regionale per il cittadino per l’accesso a servizi informativi e di comunicazione oltre che ai servizi interattivi in via di realizzazione in altri Sistemi Informativi Sanitari regionali (Rete dei Medici di Medicina Generale, Nuovo Sistema Informativo Sanitario Regionale).
Il Portale della Salute costituirà la piattaforma infrastrutturale del Sistema di Informazione e Comunicazione in Sanità rendendo disponibili strumenti di web content management che consentano, con differenti livelli di governo, l’attuazione delle politiche di informazione e comunicazione in Sanità da parte della Regione, delle Aziende, degli Enti.
La realizzazione del Portale, in coerenza con gli obiettivi del Piano Sanitario Nazionale 2006 – 2008, con la Politica Condivisa per la Sanità Elettronica definita dal Tavolo per la Sanità Elettronica1, con il Piano della Sanità Elettronica della Regione Puglia, con il Piano di azione e-government (Decreto Presidente del Consiglio dei Ministri del 14 febbraio 2002) persegue i seguenti obiettivi strategici:
▪ promuovere la salute mediante servizi informativi e di comunicazione erogati dagli attori del Sistema Sanitario Regionale, mediante comunicazione istituzionale applicata soprattutto alla prevenzione;
▪ facilitare l’accesso ai servizi sanitari attraverso canali innovativi;
▪ accrescere la partecipazione e la responsabilità da parte di individui, gruppi, istituzioni e comunità per la protezione e la promozione della salute.
1.1 Scenario di riferimento
La realizzazione del Portale si innesta in un contesto di sviluppo di iniziative promosse a livello nazionale attraverso i programmi di e-gov e recepiti localmente attraverso le azioni dell’”APQ – e-government e società dell’informazione” per lo sviluppo di servizi innovativi per cittadini, imprese e Pubbliche Amministrazioni e di recepimento a livello regionale (Piano per la Sanità Elettronica in Puglia) delle direttive nazionali in tema di Sanità Elettronica.
L’accessibilità alle informazioni in ambito sanitario ed ai servizi sanitari stessi, costituisce il presupposto fondamentale per valutare grado di soddisfazione dei cittadini rispetto ai livelli essenziali di assistenza. In questo contesto, la Regione ha realizzato un progetto di modello unitario per l’organizzazione ed il funzionamento del Sistema di Informazione e Comunicazione in Sanità che, parta dall'attuale assetto e dall'esperienza del Call Center Informativo Sanitario della Regione Puglia nonché dall'attuale assetto organizzativo delle Aziende Sanitarie Locali e consenta di definire le linee guida tecniche, organizzative e funzionali a livello regionale ed aziendale delle attività di informazione e comunicazione in ambito sanitario, favorendo la valorizzazione del ruolo e delle funzioni degli uffici Relazioni con il Pubblico all’interno di Enti ed Istituzioni Pubbliche Sanitarie.
Tra le iniziative in ambito di e-health a livello regionale, si evidenziano le seguenti, in corso ed in via di realizzazione:
▪ Servizio Regionale del Call Center Informativo Sanitario strumento a disposizione dei cittadini per l’accesso alle informazioni, per la segnalazione di problemi: tale servizio ha consentito da un lato la crescita della ‘confidenza’ dei cittadini in un servizio capace di rispondere ai propri bisogni di informazione e di indirizzo nel mondo della Sanità, dall’altro ha coinvolto le strutture sanitarie e in particolare gli organi preposti alla comunicazione con il cittadino, in un approccio nuovo al servizio che prevede la presa ‘in carico’ del bisogno del cittadino;
▪ Progetto Rete dei Medici di Medicina Generale (RMMG) per la realizzazione del Sistema Informativo Sanitario Territoriale (SIST) che organizza un sistema di servizi telematici per la gestione di alcuni processi
1 Emesso dal Dipartimento Innovazione e Tecnologie, marzo 2005
clinico-amministrativi attivati nel contesto dell’Assistenza Primaria Territoriale, cioè attivati da Medici di Medicina Generale, Pediatri di Libera Scelta, Medici della Continuità Assistenziale, Medici Specialisti e Medici di Pronto Soccorso per l’alimentazione e l’accesso al Fascicolo Sanitario Elettronico;
▪ Nuovo Sistema Informativo Sanitario Regionale (N-SISR), che consente alla Regione Puglia di analizzare, monitorare e governare la gran parte dei processi di “produzione” di salute nelle proprie strutture, è costituito avendo a modello la cooperazione paritetica con i diversi Sistemi Informativi sviluppati e gestiti in autonomia dai singoli soggetti istituzionali: da quelli centrali a quelli regionali, per finire con i sistemi informativi aziendali. La cooperazione si fonda su regole concordate e su soluzioni tecniche aperte e condivise dai soggetti che raccolgono e possiedono l'informazione; questo al fine di garantire una visione unitaria del sistema, un più efficace governo del Sistema Sanitario Regionale e, ultimo ma non meno importante, un miglioramento complessivo e continuo del servizio reso ai cittadini;
▪ Il Sistema Informativo per il Monitoraggio delle Prestazioni Sanitarie (Sovra CUP Regionale), sistema informativo che consente di monitorare l'offerta complessiva ambulatoriale e i tempi di attesa delle prestazioni per:
• favorire la distribuzione della domanda sui punti d'offerta, migliorando la saturazione complessiva e minimizzando la probabilità di lunghe code d'attesa;
• valutare l’equilibrata localizzazione delle strutture;
• abbattere i vincoli territoriali di prenotazione, consentendo di prenotare prestazioni da un qualunque punto del territorio;
• minimizzare o azzerare le prenotazioni multiple presso più strutture;
• valutare il fenomeno della sospensione delle erogazioni delle prestazioni in rapporto alla domanda in particolare per quanto riguarda le strutture individuate dalle ASL per l’erogazione delle prestazioni con tempi massimi garantiti;
• consentire una programmazione sanitaria e un monitoraggio della spesa più efficienti.
Per quanto riguarda l’eGovernment e l’eDemocracy, la Regione Puglia ha promosso, attraverso strumenti di democrazia partecipata, la definizione del Nuovo Piano della Salute mediante il coinvolgimento di cittadini, gruppi, associazioni. Il processo di partecipazione per la redazione del Piano Regionale della salute è stato “[..] finalizzato a raccogliere i contributi dei cittadini nella definizione degli obiettivi, nella costruzione delle strategie di intervento e nella adozione delle proposte di miglioramento dei servizi”2.
Dal punto di vista infrastrutturale la regione Puglia ha realizzato la Rete Unitaria della Pubblica Amministrazione Regionale Pugliese, che offre servizi di interoperabilità e di autenticazione coerenti con quelli della Rete nazionale, di cooperazione applicativa intra e inter-amministrativa (firma digitale, posta elettronica certificata, protocollo informatico, gestione dei documenti elettronici, …). Su tale infrastruttura attualmente la Regione Puglia è coivolta nella fase di realizzazione dei servizi di base a livello infrastrutturale e di strumenti di gestione, conformi a modelli logici e specifiche condivise a livello interregionale attraverso il progetto ICAR che si articola in tre interventi infrastrutturali (“Realizzazione dell’Infrastruttura di base per l’Interoperabilità e la Cooperazione Applicativa a livello interregionale”,“Gestione di Strumenti di Service Level Agreement a livello interregionale”, “Realizzazione di un Sistema Federato interregionale di Autenticazione”) e interventi applicativi pilota finalizzati a validare l’infrastruttura di cooperazione.
Infine, nell’ambito dell’Accordo di Programma Quadro (APQ) tra Regione Puglia e MIT, il progetto T-Gov (progetto complementare al progetto “Sistema Pubblico di Connettività (RUPAR2)”) ha per obiettivo di “…… realizzare, presso il Centro Tecnico della Rupar, un nodo di interconnessione con il sistema della Televisione Digitale a livello regionale, al fine di creare le condizioni infrastrutturali sufficienti per poter predisporre un Canale Televisivo interattivo della PA regionale, attraverso il quale veicolare i servizi interattivi delle PA collegate in Rupar verso i cittadini”. Tra i servizi che sono erogati attraverso il canale della Televisione Digitale vi sono i servizi informativi sulla Sanità del Portale del Call Center Informativo Sanitario della Regione Puglia.
2 DGR 11 luglio 2007, n.1165 “Ip Piano della Salute con il contributo dei cittadini”
1.2 Obiettivi del Portale della Salute
L’obiettivo principale del Portale della Salute per il Cittadino è di offrire, attraverso il canale web, ma anche attraverso canali complementari come il Digitale Terrestre, servizi informativi, di comunicazione e di interazione dei cittadini con il sistema sanitario. In particolare nel primo gruppo rientrano un insieme di servizi informativi, di accesso alla modulistica e alla documentazione, di comunicazione; nel secondo gruppo rientrano servizi interattivi per richieste di prestazioni sanitarie, per l’accesso alle informazioni del Fascicolo Sanitario Elettronico individuale, per le interazioni amministrative con il sistema sanitario (come la prenotazione di prestazioni sanitarie), per il monitoraggio di procedure in corso con il sistema sanitario. Si colloca tra i servizi informativi la realizzazione delle Carte dei Servizi aziendali per accedere a informazioni continuamente aggiornate sull’offerta dei servizi, superando la criticità storicamente evidenziata dalle carte dei servizi in formato cartaceo circa l’attualità e l’affidabilità delle informazioni sui servizi e sulle strutture erogatrici.
Il Portale della Salute rappresenta per il cittadino pugliese il punto di accesso alle informazioni e ai servizi Sanitari della Regione Puglia realizzati attraverso molteplici sistemi informativi. Quale infrastruttura unica regionale del Sistema di Informazione e Comunicazione in Sanità, esso realizza una rete tra i responsabili della Informazione e Comunicazione degli Enti consentendo loro, pur nell’autonomia della propria attività, di condividere informazioni e modelli di comunicazione armonizzati. Il Portale, infatti, realizzerà una base informativa condivisa sia a livello regionale che aziendale e renderà disponibili strumenti di gestione dei contenuti differenziati per ruoli e livelli (regionale e aziendale), per l’attuazione delle politiche di Informazione e Comunicazione della Regione in ambito sanitario. Il Portale si propone quindi oltre che come Portale della Salute Regionale anche come soluzione alla necessità delle singole Aziende Sanitarie/Ospedaliere attualmente soddisfatte attraverso la realizzazione di singoli Portali web aziendali.
Anche per quanto riguarda i servizi interattivi il Portale della Salute rappresenta il Punto unico di Accesso ad una serie di servizi interattivi, realizzati da altri Sistemi Informativi Sanitari (N-SISR, SIST, ecc) e fruibili attraverso il Portale, per offrire al cittadino un accesso più semplice e trasparente attraverso il canale web ad alcuni servizi sanitari.
Per quanto riguarda l’uso della Firma Digitale in procedimenti che attualmente prevedono la firma in calce, sarà valutata la possibilità di rimuovere tale vincolo in ottemperanza a quanto previsto dal Codice dell’Amministrazione Digitale e in conseguenza di opportuni adeguamenti normativi a livello regionale.
1.2.1 Caratterizzazione funzionale
I servizi del Portale della Salute per il Cittadino sono classificati in servizi al cittadino e servizi per la gestione.
1.2.1.1 Servizi al cittadino
Il Portale deve esporre servizi informativi e interattivi sia a livello regionale che aziendale. Per tutti i servizi, laddove la competenza non è regionale ma aziendale, il Portale della Salute deve consentire la selezione della Azienda di appartenenza e la navigazione nelle pagine relative alla stessa.
Per supportare questa ipotesi di navigazione ad albero, il Portale della Salute sarà organizzato su più livelli: il livello regionale, il livello di Aziendale che si articolerà ulteriormente per distretti, presidi ospedalieri, strutture e dipartimenti. Tutti i livelli devono essere armonizzati sia dal punto di vista dei contenuti che degli stili di presentazione.
I servizi al cittadino si possono classificare in:
▪ Servizi informativi, di accesso alla modulistica, di partecipazione
▪ Servizi interattivi
analizzati in dettaglio nei successivi paragrafi.
1.2.1.1.1 Servizi informativi, download modulistica, di partecipazione
Rappresentano i servizi ad accesso libero o con credenziali deboli (è sufficiente che il cittadino si registri al Portale della Salute). In particolare sono ad accesso libero tutti i servizi di accesso alle informazioni e alla modulistica quali:
▪ Informazioni sui Medici di Medicina Generale/Pediatri di Libera Scelta: il servizio deve consentire di accedere a tutte le informazioni relative ai MMG/PLS quali ubicazione ambulatorio, orari, medicina di gruppo, associazionismo, servizi dell’associazione, bacheca di comunicazione dal medico verso il cittadino (solo per gli utenti registrati)
▪ Carta telematica dei servizi sanitari: il servizio agevola la fruizione, da parte dei cittadini, delle informazioni relative a servizi e prestazioni: essa consente, infatti, di selezionare e consultare facilmente le informazioni secondo diversi criteri di ricerca (specifiche patologie, singole prestazioni e/o branche specialistiche, strutture erogatrici). Il servizio integrando le informazioni su tempi di attesa consente anche l’accesso alle informazioni ulteriori criteri (su base logistica, in base ai tempi di attesa ecc.) in coerenza con quanto previsto dal Piano regionale e dai Piani aziendali sul contenimento dei tempi d’attesa
▪ Informazioni e modulistica relative a: scelta/revoca del medico, esenzioni, assistenza domiciliare, assistenza protesica (albo fornitori), assistenza residenziale, assistenza riabilitativa (ricerca strutture convenzionate ex art 26)
▪ Campagne informative, news ed eventi: campagne di sensibilizzazione (ad es. donare sangue, organi, midollo), campagne di prevenzione, ma anche notizie sull’attività dell’Assessorato e delle Aziende di interesse per il cittadino. In questa sezione potranno essere ripresi anche news ed eventi di valenza europea e/o nazionale.
▪ Servizi per la partecipazione: richiedono al cittadino la registrazione al Portale della Salute consentendogli la partecipazione a Forum, sondaggi proposti dall’Assessorato e dalle Aziende, l’invio di segnalazioni e richieste anche con riferimento a quanto previsto dal Sistema di Garanzia dei LEA di cui al D.M. del 12/12/2001 (indicatori di qualità) che saranno gestite dagli Uffici Relazioni con il Cittadino.
1.2.1.1.2 Servizi interattivi
Rappresentano i servizi accessibili con credenziali forti. Sulla base di come è modellato il servizio nei Sistemi Sanitari con cui il Portale della Salute interagirà, consentono di inoltrare richieste ad operatori e/o di accedere direttamente ad informazioni sanitarie che riguardano il singolo cittadino.
▪ Scelta/revoca del medico: il servizio consentirà al cittadino di effettuare la scelta e la revoca del Medico di Medicina Generale o del Pediatra di Libera Scelta eventualmente apponendo sulla richiesta la Firma Digitale;
▪ Esenzioni: consentirà al cittadino di accedere alle informazioni sulle esenzioni riconosciutegli e sulle prestazioni/farmaci alle quali l’esenzione da diritto;
▪ Assistenza domiciliare e residenziale: consentirà al cittadino di accedere alla S.V.A.M.A.3 elaborata dall’Unita di Valutazione Multidisciplinare, per conoscerne gli esiti e gli interventi previsti, e di prendere visione del Piano di Assistenza Programmata di interventi sanitari /socio sanitari;
▪ Assistenza protesica: consentirà al cittadino di monitorare una propria richiesta di ausili e protesi, ottenendo informazioni sullo stato della stessa (in attesa di autorizzazione da parte della ASL, autorizzata, ecc.);
▪ Assistenza riabilitativa: consentirà al cittadino di accedere ad un proprio Piano di intervento per conoscere la diagnosi clinica, le disabilità rilevate, il progetto riabilitativo individuale, la tipologia e la frequenza degli interventi riabilitativi e specialistici praticati nel corso del trattamento, le valutazioni finali relative agli esiti;
▪ Assistenza farmaceutica/integrativa: consentirà al cittadino di accedere al Piano terapeutico, conoscerne i contenuti, i tempi di validità ecc.;
▪ Prenotazione prestazioni: consentirà al cittadino di effettuare la prenotazione, (o pre-prenotazione)4, la disdetta prenotazione da parte del cittadino, e consentirà al CUP di inviare comunicazioni al cittadino (avvertenze particolare prima di una prestazione, modifica di una prenotazione ecc.);
▪ Pagamento ticket: consentirà al cittadino di effettuare il pagamento del ticket per una prestazione. Sarà possibile sia pagare una prestazione indipendentemente dalla prenotazione della prestazione, che eseguire il pagamento a seguito della prenotazione effettuata con il Portale della Salute;
3 Scheda per la Valutazione Multidimensionale dell'Anziano
4 Il sistema consentirà di configurare il servizio sulla base delle politiche aziendali.
▪ Accesso al Fascicolo Sanitario Elettronico e alla Scheda Sanitaria Individuale, gestione del Consenso: consentirà al cittadino di consultare gli atti sanitari presenti nel proprio Fascicolo Sanitario Elettronico e nella Scheda Sanitaria Individuale contenente le informazioni registrate dal Medico di Medicina Generale o Pediatra e di gestire il proprio consenso al trattamento dei dati sensibili.
1.2.1.2 Servizi di gestione del Portale
I servizi di gestione del Portale sono riservati agli operatori di back-office (Redattori e Amministratori) e saranno accessibili con Carta nazionale dei Servizi (CNS). In particolare consentono ai Redattori di gestire i servizi informativi, di modulistica, servizi di partecipazione (segnalazioni, sondaggi ecc.), agli addetti dei Call Center Informativo Sanitario di registrare e monitorare le segnalazioni/richieste, agli Amministratori del Portale della Salute di gestire gli utenti, la multicanalità, di configurare la gestione dei pagamenti, di gestire l’integrazione con servizi offerti da altri Sistemi Sanitari Regionali.
1.2.2 Utenti del Portale della Salute
Il Portale della Salute per il Cittadino prevede il coinvolgimento, a vario titolo, dei seguenti attori principali:
▪ Utenti finali del Sistema: Cittadino/assistito
▪ Utenti di back-office: Redazioni (regionale, di Aziende sanitarie), Amministratori del Portale, addetti del Call Center Informativo Sanitario della Regione Puglia
1.2.2.1 Cittadini
La Regione Puglia ha una popolazione di 4.020.7075 abitanti, di questi il 42,9% possiede un Personal Computer, il 30,2% il collegamento ad Internet, il 10,4% di tali collegamenti è in Larga Banda.
Tutti i cittadini potranno accedere ai servizi informativi, di accesso alla modulistica/documentazione presenti sul sistema. In particolare potranno accedere ai servizi informativi anche attraverso Televisione Digitale i cittadini (già in possesso del Set Top Box per il Progetto Puglia T-GOV) ai quali all’interno del progetto sarà resa disponibile la connessione ADSL. (300 cittadini).
I cittadini registrati al Sistema potranno accedere ai servizi di comunicazione (segnalazioni, forum ecc.)
I cittadini in possesso di CNS potranno accedere ai servizi interattivi. Il progetto provvederà alla distribuzione di circa 5000 CNS ad un campione di cittadini per la sperimentazione nella fase di erogazione dei servizi.
1.2.2.2 Comitati Guida/Redazioni
Il modello organizzativo per la gestione del Portale della Salute è rappresentato nella seguente figura:
5 ISTAT 14° Censimento generale della popolazione - 2001
Comitato Guida regionale
Redazione regionale
Comitato guida Azienda Sanitaria Locale
_ Redazione
Azienda Sanitaria Locale
Comitato guida Aziendale Ospedliera
__ _ Redazione
Azienda Ospedaliera
Comitato guida IRCCS/Enti ecclesiastici
Redazione
IRCCS/Enti ecclesiastici
Redazione distretto
Redazione presidio ospedaliero
Figura 1 - Modello Organizzativo
Nella seguente tabella è riportata un’ipotesi di composizione dei Comitati guida e delle Redazioni a livello Regionale, di ASL e di Aziende Ospedaliere e di IRCCS/Enti ecclesiastici.
Regionale | Azienda Sanitaria Locale | Azienda Ospedaliera | IRCCS/Ente ecclesiastico | |
Comitato Guida | 3 | 3 | 3 | 2-3 |
Redazione | 5 | 3 | 3 | 2-3 |
Tabella 1 – Risorse coinvolte per la Gestione del Portale
Tale composizione, che deve essere considerata ipotesi minimale, prevede circa 39 Redattori, numero ottenuto ipotizzando 5 Redattori regionali, 3 Redattori per ciascuna delle 6 ASL, 2 Redattori (in media) per ciascuno degli 8 Enti (Aziende Ospedaliere/IRCCS/Enti Ecclesiastici regionali). L’Azienda Sanitaria Locale può organizzare ulteriori postazioni per redazioni di distretto/presidio ospedaliero.
1.2.2.3 Amministratori del Portale
Gli Amministratori del Portale saranno responsabili, attraverso l’uso di funzioni messe a disposizione dal Portale, di gestire gli utenti, la multicanalità, di configurare la gestione dei pagamenti, di gestire i processi associati alla distribuzione e gestione delle CNS/lettori, di gestire l’integrazione con servizi offerti da altri Sistemi Sanitari Regionali. Tale ruolo è assunto per le fasi di avvio in esercizio e esercizio del Portale, da personale specializzato della Ditta Aggiudicataria.
1.2.2.4 Addetti del Call Center Informativo Sanitario della regione Puglia
Gli Addetti (Operatori e Responsabili) al Call Center Informativo Sanitario della regione Puglia (di seguito denominato Call Center Informativo Sanitario) attraverso l’uso di funzioni messe a disposizione dal Portale, forniranno informazioni ai cittadini, gestiranno segnalazioni e richieste. Il numero di addetti del Call Center Informativo Sanitario che useranno le funzioni del Portale è di circa 40 unità.
2 Oggetto della fornitura
E’ richiesta la fornitura di servizi informatici per lo sviluppo del Portale e dei servizi connessi alla predisposizione ed attuazione del Piano di Comunicazione Integrato, come di seguito specificato:
▪ Servizio di Sviluppo software (di seguito indicato brevemente come Sviluppo Software) per la realizzazione del Portale e manutenzione correttiva e adeguativa (cap. 2.1)
▪ Servizio di fornitura e installazione delle Infrastrutture e fornitura degli strumenti per l’erogazione dei servizi (di seguito indicato brevemente come Infrastruttura e strumenti per l’erogazione dei servizi) comprensiva dell’Acquisizione di Carte per l’Accesso ai Servizi e lettori per utenza pilota (cap. 2.2)
▪ Servizio di Formazione e addestramento (di seguito indicato brevemente come Formazione e addestramento) per gli operatori di back-office del Portale (Redattori, Addetti del Call Center Informativo Sanitario e Amministratori) (cap.2.2)
▪ Servizio di assistenza tecnico-applicativa e conduzione operativa (di seguito indicato brevemente come assistenza tecnico-applicativa e conduzione operativa) nella fase di esercizio del Portale e monitoraggio della fase di esercizio (cap. 2.4). In particolare si richiedono i seguenti sotto-servizi:
o Allestimento del Contact Center Portale
o Assistenza tecnico-applicativa
o Conduzione operativa
o Controllo dei livelli di servizio
o Misura della Customer Satisfaction
▪ Servizio di realizzazione del Piano di comunicazione integrato e connessi servizi di attuazione (cap. 2.5)
Non sono oggetto della fornitura, in quanto offerti dal Centro Servizi Sanitari presso il Centro Tecnico Rupar/Tecnopolis, i seguenti servizi:
▪ Gestione sicurezza Logica (Servizio di gestione dei dispositivi di sicurezza perimetrale, Servizio di gestione IDS - Intrusion Detection System -, Servizio di content filtering)
▪ Gestione Sicurezza Fisica (Sicurezza di area, Sicurezza delle apparecchiature)
▪ Il servizio di Gestione e manutenzione reti
2.1 Sviluppo software per la realizzazione del Portale e manutenzione
Il servizio comprende la progettazione e realizzazione del Portale e i servizi per la manutenzione correttiva e adeguativa della componente applicativa dello stesso.
2.1.1 Sviluppo software per la realizzazione del Portale
Il servizio comprende la progettazione e realizzazione del Portale inteso come sistema applicativo che realizza i servizi al cittadino e i servizi per la gestione.
Il Portale consentirà ai cittadini l’accesso alle informazioni sui servizi sanitari, alla modulistica, a servizi interattivi esposti da altri progetti in ambito sanitario (N-SISR, SIST, Sovra CUP Regionale, CUP aziendali). Il Portale deve consentire la ricerca di informazioni e servizi secondo i diversi ambiti di competenza (regionali, di Azienda, di Distretto) consentendo la navigazione tra i diversi livelli organizzativi del sistema sanitario regionale.
La Figura 2 rappresenta graficamente l'architettura funzionale complessiva del Portale. Essa pone in evidenza gli attori, i sottosistemi informativi a cui accedere, quelli da realizzare (Sfondo bianco) tra cui le componenti aggiuntive richieste ai sistemi informativi esistenti ai fini della loro integrazione. L’accesso ai servizi offerti dai
Sistemi Informativi Sanitari (N-SISR, SIST, CUP, …) dovrà essere implementato attraverso le modalità dettate dal protocollo di cooperazione applicativa.
Redazione AAmmmmiinniissttrraazziioonnee PPoorrttaallee
CCiittttaaddiinnoo
Cittadino
Accesso attraverso Internet / TV digitale
Sistema di Accesso Unificato ai Servizi Sanitari per il Cittadin o
Front-end
Gestione servizi Gestione
informativi e Autenticazione Gestione Gestione Gestione servizi Gestione
modulistica Autorizzazione utenti pagamenti community multicanalità
Gestione servizi
Sistema di Accesso Unificato ai Servizi Sanitari per il Cittadin o
Gestione servizi
Gestione multicanalità
Gestione servizi community
Gestione pagamenti
Gestione utenti
Gestione Autenticazione Autorizzazione
Gestione servizi informativi e modulistica
Front-end
Redazioni
Rete MMG
Sovra CUP Regionale
N-SISR
Assistenza farmaceutica/ integrativa
Anagrafe assistiti
Assistenza riabilitativa
Assistenza domiciliare
Assistenza protesica
Assistenza residenziale
CUP
Gestione pagamento ticket
Sovra CUP Regionale
Gestione prenotazioni
Rete MMG
Fascicolo Sanitario Elettronico
Amministrazione Portale
N-SISR
Figura 2 – Architettura funzionale
2.1.1.1 La cooperazione applicativa
L’ esigenza di cooperazione applicativa del Portale è riconducibile allo scenario di interazione applicativa tra Portale ed un altro sistema informativo/applicativo.
L’interazione applicativa deve essere basata sull’utilizzo di una Porta di Dominio conforme alla normativa CNIPA in ambito SPCoop nel rispetto dei vincoli tecnici descritti nella relativa sezione.
Premesso che:
▪ la Porta di Dominio è intesa costituita da una componente di Cooperazione e da una componente di Integrazione;
la Ditta Offerente si obbliga e deve provvedere nell’ambito della fornitura, a:
▪ realizzare l’esposizione dei servizi di cooperazione applicativa Portale e l’attivazione di servizi di cooperazione esposti da altri sistemi informativi attraverso la progettazione e l’implementazione della componente di Integrazione della Porta di Dominio complementare alla componente di Cooperazione SCATEL. Tale sviluppo è inoltre inclusivo di tutte le funzionalità di logging, tracciatura previste dalle specifiche tecniche della Porta di Dominio, nonché della gestione delle relative politiche di accesso da parte dei sistemi cooperanti;
▪ realizzare la componente di integrazione della Porta di Dominio sulla base delle specifiche tecniche preliminari disponibili sul sito Internet del Centro Tecnico della RUPAR;
▪ realizzare i necessari interventi tecnici di manutenzione, senza oneri aggiuntivi, per adeguare il sistema offerto alle nuove specifiche tecniche che saranno rilasciate nel corso della durata del contratto.
L’interazione tra Componente di Integrazione e sistema locale deve essere realizzata attraverso l’utilizzo di Web Services (SOAP) acceduti tramite protocollo di trasporto HTTP/HTTP-S e deve supportare il transito delle richieste attraverso i sistemi di protezione (ad es., firewall) presenti nell’ infrastruttura tecnologica del Portale.
Tutti i servizi esposti su Porta di Dominio devono essere descritti secondo gli standard di accordi di servizio emanati dal CNIPA e registrati in un repository XML.
Si precisa che nel seguito del documento, se non esplicitamente indicato, l’espressione cooperazione applicativa deve sempre intendersi come cooperazione applicativa a norma CNIPA in ambito SPCoop implementata secondo le prescrizioni precedentemente indicate.
2.1.1.2 Interfaccia Utente
Le funzionalità di Interfaccia devono essere implementate utilizzando tecnologie quali JSP, XML/XSL. Esse devono consentire di:
▪ centralizzare la definizione del layout delle pagine e la generazione di tutti gli elementi accessori delle stesse, in modo da garantire l’uniformità di presentazione;
▪ offrire la possibilità di definire uno o più layout per le pagine, individuando template parzialmente statici in cui inserire dinamicamente i contenuti, separando le zone delle pagine entro cui inserire le informazioni da quelle dove mostrare informazioni di navigazione (menu, banner, loghi, ecc.);
▪ offrire la possibilità agli utenti del Portale di personalizzare i contenuti in base alle proprie preferenze (personalizzazione): selezionare autonome porzioni delle pagine (portlet) di interesse per la visualizzazione, scegliere la collocazione nella pagina, l’ordine di visualizzazione, la forma grafica, il colore, ecc;
▪ gestire il delivery multicanale, che permette successivamente la generazione di contenuti adatti a terminali diversi dal browser Web;
▪ differenziare le modalità di presentazione delle pagine, nel caso di utenti con particolari disabilità così come previsto dalle regole di accessibilità in base a cui devono essere realizzati i siti Web della pubblica amministrazione.
▪ verifica sintattica dei dati immessi, preliminare all’invocazione dell’attività transattiva per l’erogazione dei servizi interattivi.
Nella progettazione e realizzazione dell’interfaccia utente, la Ditta Offerente deve tener conto di quanto indicato in questo paragrafo; in particolare, per la realizzazione del Progetto grafico e della Architettura delle pagine del Portale, la Ditta Offerente deve considerare quanto indicato nei successivi paragrafi. Il Portale deve rendere disponibili contenuti in lingue diverse dall’italiano come definito nel paragrafo 2.1.1.2.3.
2.1.1.2.1 Progetto grafico del Portale
La realizzazione del progetto grafico del Portale deve fare uso di prototipi. Entro 20 giorni dall'inizio della fase di realizzazione (cioè dall’approvazione del documento di Architettura del Software) la Ditta Aggiudicataria deve proporre almeno due progetti grafici e il primo prototipo delle principali funzioni del Portale, per una validazione diretta dell'approccio alla soluzione.
Alla validazione prenderanno parte rappresentanti della Ditta Aggiudicataria e un Gruppo di Lavoro individuato dal Committente.
La Ditta Aggiudicataria terrà conto di eventuali feed back, derivanti dall'esame dei prototipi per la realizzazione del sistema finale, proposti durante l’attività di validazione.
Il Portale deve essere conforme alla normativa nazionale in tema di accessibilità. Il rispetto di questi requisiti deve risultare dal Piano della Qualità del progetto. Nel Piano devono essere definiti gli obiettivi qualitativi posti al sistema, nonché gli indicatori, le metriche, le tecniche di valutazione e i valori di soglia che devono essere utilizzati per verificare in corso d'opera il livello di raggiungimento degli obiettivi, nei diversi stadi di sviluppo del sistema.
2.1.1.2.2 Architettura delle pagine del Portale
Il Portale deve essere costituito da pagine accessibili al cittadino (pagine pubbliche) e pagine accessibili unicamente agli amministratori, ai redattori del Portale e agli addetti del Call Center Informativo Sanitario. Le pagine pubbliche devono essere organizzate al minimo in tre livelli: pagine regionali, aziendali e di distretto, con un meccanismo di navigazione dal livello regionale a quello di distretto e viceversa.
La Ditta Offerente deve presentare un progetto di organizzazione delle pagine del Portale per la presentazione dei servizi descritti nei punti successivi (informativi, interattivi, di gestione), mettendo in evidenza i gradi di flessibilità della soluzione stessa rispetto a interventi di riorganizzazione dei contenuti che potranno essere richiesti dai Comitati Guida/Redazioni.
Tutti i contenuti informativi e i servizi del Portale devono poter essere classificati in base a classificazioni definite dalle Redazioni/Comitati Guida. A titolo esemplificativo si considerano classificazioni:
▪ “I servizi per la salute” (organizzata in “Prevenzione, il medico di Medicina Generale, la medicina specialistica, l’assistenza farmaceutica, l’assistenza domiciliare ecc”.)
▪ “Utenti” (organizzata in “Anziani, Xxxxxxx, Giovani, Donne, Stranieri, Disabili, ecc.”).
Le classificazioni devono essere utilizzate, oltre che per consentire una Ricerca avanzata nelle funzioni di Motore di Ricerca (par. 2.1.1.3.6), per l’organizzazione delle componenti del Portale (Pagine, Menu, Barra di navigazione, ecc.).
2.1.1.2.3 Contenuti/sezioni in lingue straniere
Il Portale deve consentire la gestione di contenuti informativi/sezioni in lingue diverse dall’italiano. La Ditta Offerente deve prevedere al minimo la traduzione in lingua inglese, albanese, arabo e rumeno dei contenuti informativi rivolti agli stranieri. La Ditta Aggiudicataria deve realizzare un sistema in grado estendere tali contenuti/sezioni (fino ad un massimo di 8 lingue) senza richiedere interventi sul software.
2.1.1.3 Gestione dei servizi informativi/modulistica
Le funzionalità di Gestione dei servizi informativi/modulistica consentono ai Redattori di gestire dinamicamente tutti i contenuti informativi del Portale assolvendo alle funzioni di Web Content Management.
In particolare si richiede la creazione di un sistema di gestione dei contenuti che consenta – al minimo – di effettuare operazioni quali:
▪ Gestione del repository dei contenuti: gestione del ciclo di vita e delle versioni dei contenuti, gestione dei metadati, gestione della configurazione, gestione dei link, supporto per contenuti multimediali (testo, immagini, audio, video). In particolare deve essere consentito:
o ad ogni redazione, di gestire le informazioni, la modulistica, i documenti relativi ai servizi offerti dalla organizzazione (Assessorato/Azienda Sanitaria ecc.) di appartenenza;
o alla redazione regionale di selezionare contenuti prodotti dalle redazioni Aziendali, e che abbiano valenza regionale, per alimentare le sezioni regionali del Portale;
▪ Gestione del collegamento tra più documenti, tra documenti e servizi ecc.;
▪ Classificazione dei contenuti;
▪ Pubblicazione e rimozione a tempo dei contenuti, aggiornamenti automatici, supporto multicanale (PC, palmare, telefoni cellulari, carta/PDF, ecc.), strumenti per trasformazione/adattamento dei contenuti, versioning del sito e dei contenuti, possibilità di rollback delle modifiche al Portale;
▪ Creazione e gestione di workflow editoriali per l’approvazione e modifica dei contenuti: nella componente deve essere prevista una funzionalità per la definizione di un processo di approvazione dei contenuti sulla base dei ruoli (al minimo deve essere previsto per i ruoli di Redattore Regionale e Redattore Aziendale) che consenta di definire dinamicamente gli oggetti che richiedono l’approvazione, le regole e i tempi per l’approvazione, implementando anche meccanismi di alert per gli attori coinvolti nel processo di approvazione.
▪ Storicizzazione ai fini di revisione e controllo;
Per motivi di ottimizzazione dei tempi di accesso e di ricerca delle informazioni, i contenuti gestiti da tale componente saranno memorizzati localmente nel Portale, secondo un modello dei dati funzionale alle necessità del Portale. Tali database saranno alimentati, laddove possibile, da dati provenienti da altri Sistemi Informativi Sanitari, mentre per i dati ivi non disponibili, il Portale deve rendere disponibili funzionalità di alimentazione da altre fonti attendibili, nonché strumenti di supporto alle Redazioni per l’alimentazione e la gestione di tali dati. La Ditta Offerente deve presentare ipotesi di alimentazioni/gestione dei contenuti che considerino:
▪ i servizi esposti da altri Sistemi Informativi Regionali (N-SIRS, SIST, ecc.) in cooperazione applicativa e attraverso flussi informativi e le modalità operative per l’aggiornamento dei database (frequenza degli aggiornamenti per classi informative, tecnologie per il trasferimento dei dati, ecc.);
▪ possibili scenari per l’acquisizione e l’alimentazione dei database dei contenuti informativi da altre fonti (siti web istituzionali, ecc.) e con differenti formati in modalità automatica;
▪ funzionalità di gestione dei contenuti per l’acquisizione e l’alimentazione dei database dei contenuti informativi con differenti formati (testo, immagini, audio, video) in modalità manuale da parte degli utenti Redattori.
Devono essere considerati tra i contenuti informativi al minimo:
▪ tutti i contenuti già gestiti nel Portale del Call Center Informativo Sanitario, le cui principali tipologie sono descritte in Appendice A;
▪ tutti i contenuti necessari per realizzare i servizi (la cui realizzazione è ovviamente anch’essa richiesta) descritti nei paragrafi dal 2.1.1.3.1 al 2.1.1.3.4.
Devono, inoltre, essere realizzate le funzioni di classificazione dei contenuti e di motore di ricerca come indicato rispettivamente nei paragrafi 2.1.1.3.5 e 2.1.1.3.6.
2.1.1.3.1 Carta telematica dei servizi sanitari
Alla Ditta Offerente si richiede:
- la realizzazione della Carta telematica dei Servizi sanitari intesa come guida utile alla fruizione appropriata delle prestazioni sanitarie in tutta la Regione Puglia;
- l’implementazione di servizi per la gestione della stessa e per l’accesso user friendly da parte dei cittadini. Tale strumento dovrà essere conforme a:
▪ Decreto del Presidente del Consiglio dei Ministri 19 maggio 1995 "Schema generale di riferimento della "Carta dei servizi pubblici sanitari""
▪ “Linee guida per la redazione della Carta dei Servizi” redatto dall’Area Qualità Accreditamento Formazione dell’ARES Puglia (xxxx://xxx.xxxxxxxxxx.xx/xxxxxx/xxxxx%00xxxxx%00xxxxx%00xxx%00xxxxxxx.xxx)
▪ “Finanziaria 2008” – Lg. 24 12 2007 N. 244 - art. 2 comma 461.
Tenendo conto della normativa e delle linee guida di cui sopra, la Carta telematica dei Servizi dovrà essere strutturata per gestire le seguenti informazioni:
▪ Informazioni sui servizi forniti e sulle strutture
▪ Standard di qualità praticati, quantità ed efficacia delle prestazioni, impegni e programmi per singola unità operativa
▪ Presentazioni dell’azienda sanitaria e principi fondamentali
▪ Meccanismi di tutela e di verifica della qualità dei servizi
▪ Procedure di verifica dell’esattezza/aggiornamento delle informazioni.
Il servizio deve consentire agli utenti finali la selezione e consultazione delle informazioni in esse contenute al minimo secondo i seguenti criteri di ricerca:
▪ specifiche patologie
▪ singole prestazioni con evidenza dei tempi di attesa
▪ branche specialistiche
▪ strutture erogatrici (ospedali, poliambulatorii, consultori, ecc.) Il servizio deve consentire anche:
▪ l’aggiornamento di tutte le informazioni, anche atomiche (ad es. un numero telefonico) in modo semplice da parte delle Redazioni;
▪ il salvataggio e/o la stampa di parte o tutto il contenuto della Carta da parte del cittadino.
Poiché l’accesso alle informazioni sui servizi sanitari per ‘patologie’ rappresenta un’innovazione rispetto all’approccio tradizionalmente utilizzato dalle Carte dei servizi, la Ditta Aggiudicataria si impegna a recepire, nella modellazione e realizzazione di tale servizio, le indicazioni che saranno fornite da un Gruppo di Lavoro Regionale.
2.1.1.3.2 Tempi di attesa e ticket
Il servizio consentirà l’accesso alle informazioni sui tempi di attesa e sui ticket delle differenti prestazioni sanitarie. Per esporre tali informazioni il sistema si alimenterà anche mediante:
▪ i servizi di cooperazione applicativa resi disponibile dal N-SISR e le informazioni contenute nella repository del Portale (Carte dei servizi sanitari) per le informazioni sulle strutture erogatrici,
▪ il Sovra CUP Regionale e i CUP Aziendali per le informazioni sui tempi di attesa e ticket.
2.1.1.3.3 Informazioni e modulistica
Il servizio consentirà l’accesso:
▪ alle informazioni relative ai MMG/PLS quali ubicazione ambulatorio, orari, medicina di gruppo, associazionismo, servizi dell’associazione, bacheca di comunicazione dal medico verso il cittadino (solo per gli utenti registrati);
▪ alle informazioni relative a Aziende sanitarie, Ospedali, Aziende ospedaliere, Case di Cura, Consultori, Farmacie, Servizi Dipendenze, Strutture ambulatoriali, Strutture socio-sanitarie, Strutture riabilitative, Salute mentale, Centri dialisi, Centri trapianti, Centri trasfusionali, Centri antidolore, Volontariato, Associazioni pazienti familiari, URP;
▪ alle informazioni e alla eventuale modulistica disponibile, relative alle operazioni di: Xxxxxx/revoca del medico, Prenotazione visite ed esami, Richiesta di esenzioni, Richiesta di assistenza domiciliare, Richiesta di assistenza residenziale, Xxxxxxxxx assistenza protesica (con accesso all’albo fornitori), Richiesta assistenza riabilitativa (ricerca strutture convenzionate ex art 26), Accessi al Pronto Soccorso, Ricoveri in ospedale, Richiesta di cartelle cliniche, Richiesta di protesi e ausili, Donazione del sangue, degli organi, ecc., Assistenza all’estero, Pagamento ticket.
Per esporre tali informazioni il sistema accederà, laddove disponibili, ai servizi di cooperazione applicativa resi disponibili dal N-SISR, ai servizi esposti dal Sovra CUP Regionale e dai CUP Aziendali. Per le informazioni non gestite da sistemi informativi esterni il Portale deve rendere disponibili strumenti per la gestione di tali informazioni da parte delle Redazioni.
2.1.1.3.4 Campagne informative, news ed eventi
Il servizio consentirà la pubblicazione di news, eventi, campagne di sensibilizzazione (ad es. donare sangue, organi, midollo), campagne di prevenzione di interesse per il cittadino, con meccanismi automatici di pubblicazione/archiviazione. Per esporre tali informazioni il Portale deve rendere disponibili strumenti per la gestione di tali informazioni da parte delle Redazioni ed eventualmente strumenti di acquisizione automatica di informazioni da altri siti web/portali istituzionali (ad es. sito della Regione Puglia, sito del Ministero della Salute, ecc).
Un metadato relativo ad una News/evento deve contenere al minimo:
▪ sommario della news/evento;
▪ documento allegato (ad es., documento PDF, Microsoft Word, …);
▪ periodo di disponibilità della news/evento.
Le news/eventi saranno rese disponibili sul Portale secondo una classificazione predefinita delle stesse, attraverso cui consentire l’accesso e la ricerca di tutte le news, sia di quelle pubblicate sia di quelle archiviate. Le news, eventi, campagne informative devono essere classificate. Il sistema consentirà, inoltre, di evidenziare a ciascun utente diverse classi di news/eventi sulla base del profilo utente (preferenze sugli argomenti).
2.1.1.3.5 Classificazione dei contenuti
Il servizio deve consentire ai Redattori la creazione e gestione delle classificazioni dei contenuti informativi del Portale. A titolo esemplificativo deve essere consentito definire una nuova classificazione ad es. utenti destinatari dell’informazione sanitaria (bambini, donne, anziani, disabili, stranieri, …) e classificare i contenuti informativi (informazioni, normative, circolari, regolamenti, news, eventi ..) secondo tale classificazione. Ogni contenuto informativo deve poter essere associato a più classificazioni.
2.1.1.3.6 Motore di ricerca
Il servizio deve consentire l'accesso diretto alle informazioni presenti nella base informativa del sistema secondo particolari criteri di ricerca, attraverso un form di interrogazione anche mediante l’utilizzo di parole chiave. Tre tipologie di ricerca saranno consentite:
▪ ricerca per parole-chiave;
▪ ricerca per valori di campi (valori di particolari proprietà);
▪ ricerca full-text.
Indipendentemente dal tipo di ricerca effettuata, il risultato sarà costituito da un elenco di informazioni che soddisfano il criterio di ricerca impostato, a partire dal quale sarà possibile visualizzare le eventuali informazioni di dettaglio associate (modulistica, ecc).
2.1.1.4 Gestione servizi di community
Le funzionalità di Gestione servizi di community gestiscono tutti i servizi offerti dal Portale per la comunicazione telematica con gli utenti, servizi di invio segnalazioni e richieste, di partecipazione a forum e sondaggi proposti dall’Assessorato/Aziende, FAQ. Tali servizi devono essere accessibili al cittadino previa registrazione al Portale, al minimo con credenziali deboli. Solo le segnalazioni devono poter essere fatte anche in forma anonima
La Ditta Offerente deve realizzare al minimo i servizi per la gestione di sondaggi (proposti dall’Assessorato/Azienda), Forum, Gestione Richieste/segnalazioni, FAQ. I servizi Forum, Gestione Richieste/segnalazioni, FAQ sono descritti nei parag. 2.1.1.4.1, 2.1.1.4.2, 2.1.1.4.3.
2.1.1.4.1 Gestione Forum
Il servizio deve rendere disponibili strumenti di creazione e gestione di forum tematici di discussione pubblica, attraverso cui sarà possibile raccogliere pareri, contributi, sollecitazioni circa le tematiche connesse ai Servizi sanitari. Il Forum deve poter essere configurato per tutte le necessità legate:
▪ al tipo di argomenti (aree tematiche);
▪ alla modalità di partecipazione (pubblica, ad accesso controllato);
▪ alla possibilità o meno di “mediare” i messaggi scambiati nel Forum (attraverso l’intermediazione del Moderatore);
▪ alla possibilità di creare liste “chiuse” di utenti interessati ad un particolare argomento del Forum;
▪ alla possibilità di “tracciare” e ricercare i messaggi scambiati nel Forum sulla base dell’argomento, del periodo di inserimento dei messaggi, delle correlazioni tra i vari messaggi.
2.1.1.4.2 Gestione richieste, segnalazioni e reclami
Il servizio deve rendere disponibile l’accesso a uno o più form interattivi attraverso i quali gli utenti potranno inviare richieste, segnalazioni e reclami. La richiesta (o segnalazione o reclamo) sarà automaticamente smistata dal sistema verso il responsabile della redazione di riferimento dell’Utente per la ‘presa in carico’ e, quando possibile (segnalazioni non anomime), dandone conferma al richiedente attraverso il canale di comunicazione predefinito (mail, SMS, pagina di Portale). Il servizio deve inoltre rendere disponibili tutte le funzionalità di gestione delle segnalazioni attualmente disponibili per gli operatori del Call Center Informativo Sanitario per la gestione delle richieste/segnalazioni che pervengono attraverso il servizio di Call Center (canale telefonico). Le specifiche di tali funzionalità sono definite nell’allegato A (cap 6.)
2.1.1.4.3 Gestione FAQ
Il servizio deve rendere disponibile l’accesso a un form interattivo attraverso il quale gli utenti potranno inserire criteri di ricerca per la selezione delle FAQ. Le FAQ devono essere classificate al minimo per area tematica. La ricerca deve essere consentita al minimo per parola/e chiave, per condizioni sulle parole chiave inserite (frase esatta, parte della frase), per area tematica. Il servizio deve inoltre rendere disponibili tutte le funzionalità di gestione delle FAQ da parte delle Redazioni.
2.1.1.5 Gestione Utenti
Il servizio riguarda tutte le attività connesse alla gestione e monitoraggio delle classi di utenza (Ruoli) e degli utenti appartenenti a queste ultime, che sono, in modo differenziato, abilitati ad accedere ai servizi Portale.
Poiché gli utenti appartengono a due grandi categorie, utenti pubblici e utenti di ‘back office’ (Redattori, Amministratori), di dimensioni molto diverse tra loro, si richiede la modellazione di due differenti processi di gestione utenti.
Alla Ditta Offerente si richiede pertanto di modellare:
un processo di gestione degli utenti pubblici che preveda le seguenti operazioni:
▪ Registrazione utente con login/password proposte dell’utente o con smart card o in modalità degradata con credenziali rilasciate dall’Amministrazione Sanitaria previo accertamento dell’identità dell’utente;
▪ Abilitazione dell’utente e rilascio dell’eventuale PIN;
▪ Distribuzione e gestione delle Smart Card per gli utenti selezionati per la sperimentazione;
▪ Modifica del profilo utente;
▪ Cancellazione utente;
un processo di gestione degli utenti operatori di back-office che preveda le seguenti funzionalità:
▪ Registrazione utente con smart card o in modalità degradata con credenziali rilasciate dall’Amministrazione Sanitaria;
▪ Rilascio dell’eventuale PIN;
▪ Distribuzione e gestione delle Smart Card per gli utenti operatori di back-office;
▪ Modifica del ruolo utente;
▪ Cancellazione utente.
Nel modellare tali processi di gestione utente e le relative funzionalità applicative di supporto, la Ditta Offerente deve tener conto dei seguenti vincoli/opportunità:
▪ Il modello organizzativo deve rispettare le indicazioni contenute nel documento “Il Modello Organizzativo di gestione delle CNS” approvato con Delibera di Giunta Regionale n.1386 del 22.7.2008. Tale documento descrive il Modello Organizzativo di riferimento per il governo di tutte le attività di gestione delle Carta Nazionale di accesso ai Servizi (CNS) emesse dalla Regione Puglia, che opera in qualità di Ente Emettitore. In tale modello, i ruoli coinvolti (Operatore Ufficio Registrazione CNS) sono responsabili solo della distribuzione delle CNS ad operatori del Sistema Sanitario, pertanto, per la distribuzione della CNS ai Cittadini, la Ditta Offerente dovrà assicurare non meno di 25 giornate di consulenza, da parte di personale specializzato, di supporto agli uffici preposti alla distribuzione delle CNS. Il servizio di gestione del processo di consegna, rilascio e attivazione della CNS si avvarrà delle funzionalità definite nel paragrafo 2.1.1.7;
▪ il modello funzionale deve usufruire, per verificare l’appartenenza all’Anagrafe Assistiti della regione Puglia degli utenti, dei servizi esposti in cooperazione applicativa dal N-SISR (in particolare dall’anagrafe degli assistiti).
Si riportano di seguito le funzionalità minime che devono essere previste:
▪ attivazione Utente: supporto all’attività, di competenza degli Amministratori Portale, di creazione di un utente operatore di Back-office; la funzionalità deve consentire la selezione del soggetto che si intende attivare come operatore e l’immissione di tutti i dati significativi per l’account che si sta creando (es. modalità di autenticazione, username e password, ruoli associati all’utente, dominio di pertinenza, ecc.);
▪ altre funzioni di Gestione Utente: devono essere supportate tutte le altre funzionalità di gestione utente, di competenza degli Amministratori Portale, quali ad esempio modifica dei dati relativi ad un particolare utente, modifica dei ruoli associati ad un utente, cancellazione, individuazione delle utenze con specifico ruolo, produzione di rapporti analitici e sintetici sulla base di criteri di personalizzazione, ecc.;
▪ modifica Profilo: devono essere supportate funzionalità rivolte all’utente stesso che gli consentano di ritrovare e modificare il proprio profilo, quali, ad esempio modifica password, recupero password, ecc.. Il recupero della password deve prevedere la re-assegnazione di una password generata automaticamente dal sistema e la trasmissione della stessa in modalità sicura.
Il sistema deve prevedere, alla base del processo informatizzato di Gestione Utenti, un insieme di Xxxxx ciascuno dei quali abilitato ad usufruire di determinati servizi/funzionalità del Portale e, per gli utenti con il ruolo cittadino, anche sulla base della modalità di accesso; tali abilitazioni vengono realizzate creando delle associazioni ruoli/funzioni.
Assunti i Ruoli, le funzionalità e le associazioni ruoli/funzioni emerse durante la fase di analisi e predisposti in fase di start-up del sistema, il sistema deve essere sviluppato in modo tale da consentire la modifica delle associazioni ruoli/funzioni, ovvero deve consentire di modificare i ruoli (aggiungere o eliminare), espandendo o riducendo le funzionalità ad essi associate, senza comportare modifiche al software.
Dal punto di vista tecnico il sistema di gestione utenti, in una logica di possibile apertura verso un sistema di autenticazione federato di identità digitali, deve basarsi su un servizio di directory LDAP con capacità di sincronizzazione con altri sistemi LDAP.
Si richiede che tutte le attività connesse con la gestione dell’utenza e delle connesse problematiche di identificazione, autenticazione ed autorizzazione siano gestite in modo da minimizzare gli interventi necessari per migrare verso un modello di autenticazione federata.
2.1.1.6 Gestione dell’autenticazione e autorizzazione
Le funzionalità di Gestione dell’autenticazione e autorizzazione devono consentire l’accertamento dell’identità personale dell’utente che accede ai servizi e la verifica che possieda i privilegi per l’accesso al servizio.
2.1.1.6.1 Autenticazione
Il sistema deve supportare processi di autenticazione basati su:
▪ credenziali deboli: cioè username e password definite dall’utente;
▪ credenziali forti:
o attraverso l’utilizzo di smartcard: in particolare devono essere supportate la Carta Nazionale dei Servizi (CNS) con dispositivo di firma.
o In modalità degradata con credenziali rilasciate dall’Amministrazione Sanitaria previo accertamento dell’identità dell’Utente
Ai fini dell’autenticazione dell’utenza, il sistema, a regime, deve far uso delle CNS (Carta Nazionale dei Servizi).
Poiché il processo di distribuzione delle CNS sarà progressivo, la dotazione di dispositivi di autenticazione basati su smart card per tutti gli utenti del Portale che richiedano servizi attraverso il Portale non può che rappresentare un obiettivo di medio-lungo periodo; pertanto i servizi predisposti devono essere fruibili sia da utenti provvisti di CNS che, eventualmente in maniera degradata, da utenti sprovvisti della stessa. L’operatività in modalità degradata, cioè la limitazione della capacità funzionale, deve essere evidenziata con chiarezza in sede di offerta tecnica e, successivamente, in sede di progettazione esecutiva.
L’utilizzo di uno specifico meccanismo di autenticazione dell’utente deve automaticamente riflettersi sulla tipologia di servizi fruibili dallo stesso.
Si fa presente che, per quanto riguarda il processo di autenticazione basato su smart-card, essendo questo strettamente legato alla consultazione delle Certificate Revocation List (CRL), il sistema deve prevedere gli opportuni meccanismi per mantenere aggiornate tali liste. In particolare, devono essere supportate le seguenti modalità:
▪ aggiornamento manuale: deve essere disponibile una funzione, attivabile dall’interfaccia utente, che realizzi il download e l’acquisizione nel sistema delle CRL aggiornate dalla Certification Authority (CA) di pertinenza, relative alle smart-card previste dal sistema;
▪ aggiornamento automatico: deve essere previsto un meccanismo, attivato in modo automatico su base temporale, di download ed acquisizione delle CRL aggiornate dalla Certification Authority (CA) di pertinenza, relative alle smart-card previste dal sistema. La funzionalità amministrativa del sistema deve consentire di definire la frequenza temporale del processo (es. ogni N. ore, giornaliera, settimanale, mensile). Devono essere previsti sia meccanismi per monitorare lo stato di aggiornamento delle CRL (ad es., ultimo aggiornamento) sia meccanismi pro-attivi che evidenzino all’amministratore del sistema il fallimento di un processo di aggiornamento.
2.1.1.6.2 Autorizzazione
Il servizio realizza il processo di autorizzazione dell’utente ad utilizzare il servizio richiesto, sia esso del Portale, sia esso un servizio offerto, attraverso il Portale, da altri Sistemi Informativi Sanitari. L’autorizzazione è l’insieme delle procedure che hanno il compito di accertare se il servizio richiesto può essere erogato all’utente richiedente. Il servizio deve garantire il rispetto del D. Lgs. 196 del 30 giugno 2003 “Codice in materia di protezione dei dati personali”.
2.1.1.7 Gestione CNS/lettori
Le funzioni di Gestione CNS realizzano la gestione dei procedimenti amministrativi connessi con il rilascio di Carte Nazionali di Accesso ai Servizi (CNS), sia di tipo Operatore che Cittadino ed il rilascio di lettori di CNS. L’accesso a tali funzioni deve essere consentito:
▪ al Committente/Amministrazione Sanitaria per le operazioni di richiesta di CNS e di distribuzione e gestione delle stesse dopo la consegna da parte della Ditta Aggiudicataria;
▪ alla Ditta Aggiudicataria per la gestione delle richieste fino alla fase di consegna al Committente/Amministrazione Sanitaria.
Devono essere supportate al minimo le seguenti funzionalità:
▪ Gestione delle richieste ed emissione: supporto alle operazioni di Richiesta di CNS/lettori da parte del Committente/Amministrazione Sanitaria, Emissione della CNS (sia di tipo Cittadino che Operatore),
Distribuzione della CNS e del lettore, Estrazione dei dati relativi ad una richiesta o a gruppi di richieste in formato XML nel rispetto della sintassi definita dal fornitore delle CNS, Spedizione e gestione dei resi, Monitoraggio dello stato di avanzamento delle richieste e delle assegnazioni delle CNS
▪ Gestione del ciclo di vita delle CNS: supporto alle operazioni di sospensione, revova, attivazione, denuncia di smarrimento, restituzione ecc.
▪ Gestione dei certificati di firma: sospensione, riattivazione, revoca, validazione.
▪ Monitoraggio: supporto alle attività di monitoraggio delle attività svolte; produzione di rapporti sintetici ed analitici per il monitoraggio delle CNS.
2.1.1.8 Gestione multicanalità
La funzione Gestione multicanalità gestisce il servizio di multicanalità attraverso il quale inviare informazioni all’utente su canali diversi dal Portale e offrire servizi informativi attraverso il canale della televisione digitale. Nella predisposizione dell’Offerta, la Ditta Offerente deve considerare prioritariamente l’uso di canali che non comportino costi di servizio a carico degli Enti erogatori (Assessorato/Aziende Sanitarie Pubbliche). La descrizione del servizio attraverso il canale della televisione digitale è dettagliato nel successivo paragrafo.
2.1.1.8.1 Servizi informativi mediante Televisione Digitale Terrestre
Il Portale deve consentire, in continuità con la sperimentazione realizzata nell’ambito del progetto Puglia T- Gov6, l’erogazione di parte dei contenuti informativi sanitari del Portale attraverso Televisione Digitale Terrestre. La Ditta Offerente deve realizzare le componenti software per l’erogazione al minimo dei seguenti servizi:
▪ Ricerca Strutture: ricerca per provincia di una struttura sanitaria; il servizio restituisce gli indirizzi e i recapiti telefonici ed elettronici;
▪ Ricerca Prestazioni: ricerca per provincia e per comune di una struttura sanitaria che fornisce una prestazione; il servizio restituisce gli indirizzi e i recapiti telefonici ed elettronici;
▪ Ambulanze di volontariato: ricerca per provincia delle organizzazioni di volontariato che forniscono il servizio di ambulanza; il servizio restituisce gli indirizzi e i recapiti telefonici ed elettronici;
▪ Centri di vaccinazione: elenco dei centri di vaccinazione presenti sul territorio regionale;
▪ Guardia medica: ricerca per provincia delle guardie mediche;
▪ Farmacie di turno: ricerca per citta, quartiere, turni delle farmacie;
▪ RSA: elenco delle residenze sanitarie assistenziali, con scheda informativa generale;
▪ Commissioni di invalidità: elenco per provincia delle commissioni di invalidità;
▪ Servizi amministrativi: 40 schede informative relative ai servizi amministrativi della sanità pugliese;
▪ Campagne di prevenzione: elenco (stile news) delle campagne di prevenzione attive nella regione; Tali servizi dovranno essere esposti tramite cooperazione applicativa.
2.1.1.8.1.1 Modello funzionale di riferimento
La figura seguente illustra il layout del modello funzionale di riferimento
CS Portale
RUPAR
Puglia
TECNOPOLIS
-BIX
-Centro Servizi DVB-T
Internet
Link trasporto
Return channel
HeadEnd Televisioni
STB
STB
STB
Rete TV
Rete TV
Figura 3 - Modello di riferimento per la TV digitale terrestre
Il segnale digitale terrestre inviato dalle emittenti televisive verso i set top box (STB) degli utenti contiene, oltre alla normale programmazione televisiva, anche l’applicazione MHP sviluppata nell’ambito del progetto Puglia T-Gov.
Un’applicazione MHP, in generale, consiste in una serie di schermate visibili sulla TV e utilizzabili tramite il telecomando del STB digitale interattivo.
I contenuti dei servizi possono essere statici (dati inviati via broadcast indistintamente a tutti gli utenti) o dinamici (forniti ad un singolo STB in seguito ad una specifica richiesta da parte dell’utente xxx xxxxxx xx xxxxxxx).
I contenuti dei servizi statici sono raccolti tramite opportuni software di back-end che leggono dalla sorgente (Portale web, database, web services ecc.) e li formattano in un formato prestabilito; i dati così costruiti vengono inviati tramite i link di trasporto agli headend delle televisioni, che provvederanno ad aggiornare i dati inviati via broadcast.
I servizi su canale di ritorno vengono implementati tramite opportune servlet java (ospitate dal CS DVB-T), che rispondono via internet alla richiesta di servizio. La risposta alla richiesta di servizio viene creata leggendo dalla sorgente (Portale web, database, web services ecc.) i dati richiesti formattando i dati nel formato prestabilito.
L’applicazione Puglia T-Gov è una infrastruttura software che permette sia la creazione di servizi informativi di tipo statico sia quelli su canale di ritorno.
L’infrastruttura fornisce e definisce:
▪ il frontend di presentazione dei servizi informativi, modificabile tramite configurazione di alcuni file XML;
▪ i formati XML di interfacciamento tra i servizi di back-office (servlet) e il frontend MHP;
▪ I formati XML per la presentazione dei dati statici;
▪ uno Scheduler, che ha il compito di lanciare i processi di raccolta dati statici, in intervalli di tempo liberamente configurabili;
▪ le API per la creazione dei servizi di raccolta dei dati statici da inserire nello scheduler;
▪ le API per la creazione delle classi per l’implementazione dei servizi su canale di ritorno.
La realizzazione dei Servizi informativi mediante Televisione Digitale Terrestre è subordinata alla disponibilità del servizio di broadcasting, che non è oggetto della fornitura in quanto si prevede sia realizzato come servizio Rupar Puglia.
Si richiede alla Ditta Offerente la realizzazione delle seguenti componenti software:
▪ file XML per il frontend MHP, seguendo i formati forniti da Puglia T-Gov;
▪ le classi java che realizzano la raccolta dei dati statici, da integrare nello Scheduler del CS DVB-T seguendo i formati XML e le API fornite da Puglia T-Gov;
▪ le classi che realizzano i servizi su canale di ritorno, da integrare con le servlet del CS DVB-T, seguendo i formati XML e le API fornite da Puglia T-Gov.
▪ Il frontend dei servizi MHP;
▪ le servlet per i servizi su canale di ritorno.
Alla Ditta Aggiudicataria saranno rese disponibili le specifiche dei formati XML e le API java relative alle componenti con cui l’oggetto della fornitura deve integrarsi.
2.1.1.9 Gestione servizi
Le funzionalità di Gestione servizi hanno lo scopo di integrare i Servizi offerti da altri Sistemi Sanitari nell’ambito del Portale. Realizza funzioni di raccolta delle informazioni (da form di inserimento dati) e verifica semantica dei dati inseriti dall’utente, di invocazione dei servizi esposti da altri Sistemi Informativi, di organizzazione delle informazioni ottenute secondo una ‘vista’ utente del servizio. Realizza quindi funzioni di integrazione dei servizi offerti, differenziate a seconda della granularità dei servizi esposti.
I servizi interattivi che la Ditta Offerente deve realizzare sono al minimo quelli indicati nei successivi paragrafi
2.1.1.9.1 - 2.1.1.9.3, e organizzati sulla base dei Sistemi informativi che erogano il servizio stesso. Si richiede nella presentazione dei servizi ‘interattivi’ la possibilità per l’utente sia di accedere direttamente al servizio che di accedere alle informazioni disponibili del servizio (livello informativo dell’e-government), all’eventuale modulistica associata (livello di interazione one-way) e infine al servizio interattivo.
2.1.1.9.1 Servizi di integrazione con il Nuovo Sistema Informativo Sanitario Regionale
La Ditta Offerente deve realizzare, utilizzando i servizi che saranno esposti dall’N-SISR, al minimo i seguenti servizi:
▪ Scelta/revoca del medico: il servizio consentirà al cittadino di effettuare la scelta e la revoca del MMG/PLS eventualmente apponendo sulla richiesta la Firma Digitale;
▪ Esenzioni: consentirà al cittadino di accedere alle informazioni sulle esenzioni riconosciutegli e sulle prestazioni/farmaci alle quali l’esenzione da diritto;
▪ Assistenza domiciliare e residenziale: consentirà al cittadino di accedere alla S.V.A.M.A. elaborata dall’Unita di Valutazione Multidisciplinare, per conoscerne gli esiti e gli interventi previsti, e di prendere visione del Piano di Assistenza Programmata di interventi sanitari /socio sanitari;
▪ Assistenza protesica: consentirà al cittadino di monitorare una propria richiesta di ausili e protesi, ottenendo informazioni sullo stato della stessa (in attesa di autorizzazione dal parte della ASL, autorizzata, ecc.);
▪ Assistenza riabilitativa: consentirà al cittadino di accedere ad un proprio Piano di intervento per conoscere la diagnosi clinica, le disabilità rilevate, il progetto riabilitativo individuale, la tipologia e la frequenza degli interventi riabilitativi e specialistici praticati nel corso del trattamento, le valutazioni finali relative agli esiti;
▪ Assistenza farmaceutica/integrativa: consentirà al cittadino di accedere al Piano terapeutico, conoscerne i contenuti, i tempi di validità ecc..
Le specifiche dei servizi esposti dall’N-SISR ed utili al fine della realizzazione dei servizi sopra elencati saranno fornite alla Ditta Aggiudicataria dal Committente non appena disponibili. Qualora tali specifiche non si rendano disponibili nei tempi previsti per la Fase di progettazione e realizzazione del Portale (cfr. successivo Cap 3), la Ditta Aggiudicataria si impegna comunque a rilasciare al termine di tale fase l’insieme dei servizi definiti nel presente Capitolato a meno dei servizi di integrazione con il Nuovo Sistema Informativo Sanitario Regionale, e a realizzare questi ultimi servizi nella Fase di esercizio del Portale, entro mesi tre dalla data di rilascio delle specifiche.
2.1.1.9.2 Servizi di integrazione con il Sistema Informativo Sanitario Territoriale
La Ditta Offerente utilizzando i servizi che saranno esposti dal SIST, deve realizzare al minimo i seguenti servizi:
▪ Gestione del consenso: Gestire la registrazione della volontà espressa dal cittadino per il trattamento dei suoi dati sensibili (cfr. Legge sulla Privacy dlgs 196/2003) e il tipo di consenso (affermativo o negativo) fornito;
▪ Accesso al Fascicolo Sanitario Elettronico: consentirà al cittadino di consultare gli atti sanitari presenti nel proprio Fascicolo Sanitario Elettronico. Devono essere previste diverse modalità di accesso agli atti (per tipologia di atto, per data o range di date ecc);
▪ Accesso alla Scheda Sanitaria Individuale: è la scheda gestita dal MMG/PLS contenente i dati anagrafici, l’anamnesi, i dati di base comprensivi dei dati di emergenza.
Le specifiche dei web service esposti dal SIST ed utili al fine della realizzazione dei servizi del Portale sono riportate nell’Allegato B (cap. 7) del presente documento. Si precisa che alla data della pubblicazione del presente Capitolato di Gara, tali specifiche non sono state ancora approvate definitivamente e che pur mantendo le stesse funzionalità queste potranno ancora variare nei dettagli implementativi. La versione definitiva sarà resa disponibile alla Ditta Aggiudicataria nei tempi utili per la realizzazione della integrazione dei servizi.
2.1.1.9.3 Servizi di prenotazione prestazioni e pagamento ticket
La Ditta Offerente deve realizzare al minimo i seguenti servizi:
▪ Prenotazione prestazioni: il servizio di prenotazione di prestazioni sanitarie deve consentire
• al cittadino, di effettuare le operazioni di prenotazione (o pre-prenotazione)7 e di disdetta di una prenotazione, ricerca di una prenotazione.
• al CUP, di effettuare comunicazioni verso il cittadino (avvertenze particolare prima di una prestazione, modifica di una prenotazione ecc.).
▪ Pagamento ticket: consentirà al cittadino di effettuare il pagamento del ticket per una prestazione sanitaria. Deve essere gestito sia il pagamento con l’inserimento da form dei dati relativi alla prestazione da pagare, sia il pagamento di una prestazione prenotata attraverso il Portale, i cui dati quindi siano accessibili attraverso le funzionalità di “ricerca prenotazione” del Portale stesso. Per le prenotazioni non effettuate attraverso il Portale deve essere consentito pagare le prestazioni prenotate tramite CUP per le quali si disponga di un numero di prenotazione:
• rilevabile dalla ricevuta di prenotazione CUP
• comunicato verbalmente da chi ha effettuato la comunicazione (ad es. CUP)
Il servizio deve ritornare al Portale una comunicazione di conferma dell’avvenuto pagamento.
Deve essere consentito il pagamento con le più diffuse carte di credito e carte di debito. Al minimo deve essere possibile effettuare il pagamento con carte Visa e Mastercard. Il sistema deve indicare il costo della commissione per il pagamento.
7 Il sistema consentirà di configurare il servizio sulla base delle politiche aziendali.
Deve essere consentito scaricare e stampare la ricevuta di pagamento, anche successivamente al pagamento (ristampa in caso di smarrimento).
Le informazioni gestite dal sistema relativamente ai pagamenti delle prestazioni devono essere organizzate ed esposte attraverso cooperazione applicativa per consentite ai sistemi gestionali presenti presso le Casse Ticket aziendali di accedere ed importare tali informazioni.
Si richiede alla Ditta Offerente di:
▪ definire le specifiche dei servizi che i sistemi informativi con i quali è prevista la cooperazione applicativa (esistenti come i CUP aziendali o di prossima realizzazione come il Sovra CUP Regionale) devono realizzare per consentire l’erogazione dei suddetti servizi
▪ realizzare, per al minimo due distinte soluzioni CUP aziendali, di differenti fornitori, in uso presso le ASL o le Aziende Ospedaliere pugliesi, la componente di integrazione che esponga in modalità di cooperazione applicativa i suddetti servizi di prenotazione.
▪ organizzare le informazioni relative ai pagamenti effettuati attraverso il Portale ed esporre tali informazioni attraverso servizi per consentite ai sistemi gestionali presenti presso le Casse Ticket aziendali (tutte e sole quelle rispetto ai quali sarà stata attivato il servizio di prenotazione attraverso il Portale) di accedere ed importare tali informazioni.
La Ditta Offerente, nella predisposizione dell’offerta relativa alla componente di pagamento elettronico, deve prioritariamente considerare l’integrazione/uso di servizi offerti da circuiti di servizi interbancari al cui interno rientrano le Banche già convenzionate con le Aziende Sanitarie per il servizio di Tesoreria.
2.1.2 Manutenzione Correttiva e Adeguativa
E’ richiesto alla Ditta Offerente il servizio di Manutenzione Correttiva e Adeguativa che include:
▪ per la manutenzione correttiva, la diagnosi e la rimozione delle cause e degli effetti dei malfunzionamenti delle procedure e dei programmi;
▪ per la manutenzione adeguativa, l’attività di manutenzione volta ad assicurare la costante aderenza delle procedure e dei programmi alla evoluzione dell’ambiente tecnologico del sistema informativo ed al cambiamento dei requisiti (organizzativi, normativi, d’ambiente).
Gli obiettivi della Manutenzione Correttiva e Adeguativa sono così definiti:
▪ mantenere operativa la soluzione (software) attraverso attività che assicurino in via continuativa la rimozione dei malfunzionamenti;
▪ assicurare il miglioramento tempestivo delle funzionalità e delle prestazioni, per esempio quando un programma non ha prestazioni adeguate al livello di servizio richiesto e ciò viene percepito come un malfunzionamento, richiedendo un intervento di correzione;
▪ garantire l’evoluzione tecnico funzionale della soluzione software (in questo contesto definita come manutenzione adeguativa);
▪ fornire servizi di supporto per risolvere tempestivamente problemi relativi a malfunzionamenti ed errori;
▪ assicurare l’aggiornamento periodico della soluzione, attraverso il miglioramento della funzionalità, dell’affidabilità e dell’efficienza dei prodotti. L'aggiornamento presuppone il rilascio di nuove versioni e/o correzioni dei prodotti da parte della Ditta Offerente.
2.1.2.1 Manutenzione correttiva
Per la Manutenzione Correttiva il servizio deve almeno prevedere:
▪ la raccolta delle segnalazioni relative a malfunzionamenti applicativi;
▪ la presa in carico del problema che deve essere garantita entro il tempo massimo di due ore dal ricevimento della segnalazione;
▪ la risoluzione dei malfunzionamenti;
▪ la produzione della reportistica tecnica;
▪ il rilascio delle versioni aggiornate dell’applicativo.
Nel caso di Manutenzione Xxxxxxxxxx la risoluzione del problema deve essere testimoniata dalla scomparsa del malfunzionamento che ha generato la richiesta di intervento. L’intervento si ritiene concluso a seguito del rilascio della versione aggiornata del pacchetto applicativo.
Il servizio di Manutenzione Correttiva è richiesto per 12 mesi dalla data di collaudo positivo.
2.1.2.2 Manutenzione adeguativa
Per la Manutenzione Adeguativa, il servizio deve prevedere, senza oneri economici aggiuntivi, al minimo gli interventi di seguito descritti:
▪ adeguamento all’evoluzione tecnica del servizio di cooperazione applicativa reso disponibile dalla RUPAR Puglia;
▪ adeguamento per recepimento di variazioni tecniche che si possano verificare nei Sistemi Informativi (N- SISR, SIST, Sovra CUP Regionale, CUP Aziendali) relativamente ai servizi esposti attraverso il Portale.
Nel caso di Manutenzione Adeguativa l’intervento di adeguamento deve essere testimoniato dalla capacità del Portale di continuare ad offrire le stesse funzionalità previste prima delle variazioni tecniche intervenute nei sistemi con cui il Portale interagirà (RUPAR, N-SISR, SIST, Sovra CUP Regionale, CUP Aziendali). L’intervento si ritiene concluso a seguito del rilascio della versione aggiornata del pacchetto applicativo e della corrispondente documentazione di progetto.
Il servizio di Manutenzione Adeguativa è richiesto per 12 mesi dalla data di collaudo.
2.1.3 Requisiti non funzionali
Di seguito sono descritti i principali requisiti non funzionali che devono caratterizzare il Portale nel suo complesso.
▪ il livello di presentazione e di interfaccia del Portale deve essere realizzato nel rispetto dei criteri di accessibilità e fruibilità definiti dalla Legge n.4 del 9/01/2004 e relativo regolamento di attuazione (DPR 1 marzo 2005, n. 75) e nel rispetto dei requisiti tecnici definiti dal DM dell’8/07/2005 “Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici”;
▪ il sistema deve essere conforme alla normative in tema di Tutela dei dati personali e sensibili (D. Lgv. 196/2003, Regolamento Regionale 5/2006);
▪ Interfaccia utente totalmente in italiano, tranne che per i contenuti previsti per gli stranieri;
▪ tutte le pagine, in aggiunta alle strutture di navigazione, offriranno anche l'indicazione della loro posizione assoluta (URL) nella topografia del sito e daranno la possibilità di eseguire una stampa formattata ed un invio a mezzo posta elettronica diretto della parte testuale contenuta;
▪ il sistema deve far uso di un unico sistema di gestione della base dati relazionali (RDBMS);
▪ il sistema deve far uso di un set di caratteri adeguato per la corretta scrittura dei nomi e dei luoghi, anche relativi a paesi esteri;
▪ il sistema non deve avere limitazioni tecniche (ad es., sul numero massimo di utenza attiva) se non quella determinata dal dimensionamento dei sistemi di elaborazione;
▪ il sistema deve garantire la protezione da infezioni da virus informatici in relazione sia alle attività che prevedono l’acquisizione di file sia a quelle che prevedono la circolazione di file potenzialmente esposti a tale fenomeno;
▪ con riferimento ai processi di lavoro per i quali è ipotizzabile l’acquisizione dei dati da altri sistemi informativi devono essere supportate parallelamente le seguenti modalità:
a) Inserimento interattivo per mezzo di form da parte di utente del sistema
b) importazione dei dati da supporto di memorizzazione
c) acquisizione dei dati tramite utilizzo di servizi di cooperazione applicativa;
▪ il sistema deve essere supportato da una manualistica consultabile online e da funzionalità di help contestuale alla specifica funzionalità da cui viene attivata;
▪ si richiede la disponibilità di strumenti software per la migrazione di contenuti da siti e/o archivi già esistenti e l’assistenza alla migrazione. Deve essere prevista al minimo la migrazione dagli archivi del Sistema Informativo del Call Center Informativo Sanitario (Cap 6);
▪ il sistema di gestione utenti deve basarsi su un servizio di directory LDAP con capacità di sincronizzazione con altri sistemi LDAP;
▪ è richiesta compatibilità con le portlet standard Java (JSR 168); supporto per JSR 170 (API Java 2 Standard per l’accesso a “content repositories”);
▪ l’interazione applicativa tra il Portale e gli altri Sistemi Sanitari (N-SISR, SIST, CUP, Sovra CUP) deve essere realizzata, dal punto di vista applicativo, attraverso lo scambio di documenti HL7 (V3) CDA Release 2, laddove applicabile;
▪ si richiede la predisposizione di un ambiente di test ossia dell’insieme delle apparecchiature, strumenti, tecnologie, documenti e dati che devono essere predisposti e messi a disposizione per l'esecuzione del collaudo e delle successive verifiche di nuove funzionalità o di interventi di manutenzione. La Ditta Offerente deve, inoltre, prevedere la realizzazione delle componenti di test (test stub e test driver) da utilizzare durante il collaudo delle funzionalità di cooperazione applicativa con i sistemi informativi N-SISR, SIST, Sovra CUP Regionale e CUP aziendali. Tale ambiente deve essere installato sul server di pre-esercizio;
▪ si richiede la progettazione ed implementazione nel sistema applicativo di meccanismi di protezione applicativa da tentativi di accesso non autorizzato. A titolo esemplificativo si considerano le seguenti vulnerabilità software e le relative minacce:
o mancanza di validazione dei dati di input (attacchi di tipo Buffer Overrun, SQL Injection, XML Injection, ecc…)
o gestione non sicura delle sessioni (attacchi di tipo Session Hijacking)
o gestione non sicura delle password (attacchi Brute Force basati su dizionari)
o gestione non corretta delle eccezioni (divulgazione di dettagli interni dell’applicazione, attacchi DoS);
▪ la Ditta Offerente deve predisporre, per l’accesso sicuro a pagine web in particolare per l’accesso a dati sensibili, l’installazione, configurazione, manutenzione e supporto del software SSL (SSL 2.0 e SSL 3.0).
2.1.3.1 Metodologia e standard tecnologici
I sistemi software custom sviluppati nell’ambito del progetto devono essere disegnati ed implementati assumendo a riferimento quanto più possibile metodologie e standard tecnologici orientati a garantire condizioni di:
▪ leggibilità dei documenti di analisi e disegno;
▪ portabilità del software da un ambiente operativo ad un altro;
▪ separazione logica e realizzativa delle componenti software per semplificare i processi di manutenzione software;
▪ robustezza del codice e semplificazione dei processi di test.
Ciascun sistema software custom sviluppato nell’ambito del progetto deve pertanto:
▪ essere progettato con l’ausilio dello standard UML v2 e della metodologia di sviluppo software Unified Process
▪ essere disegnato e progettato utilizzando i principi delle architetture SOA utilizzando il modello dei web services per l’esposizione dei servizi fruibili da altre componenti e/o sistemi applicativi;
▪ essere disegnato ed implementato isolando le componenti funzionali al fine di semplificare i processi di manutenzione del software;
▪ utilizzare pattern di disegno di riferimento come, ad esempio, MVC, DAO;
▪ essere conforme all’architettura Java 2 Enterprise Edition (J2EE);
▪ utilizzare componenti software Open Source ove applicabili, disponibili e ritenute valide alternative a prodotti/componenti commerciali;
▪ utilizzare la tecnologia XML per la rappresentazione di strutture informative oggetto di scambio tra componenti e sistemi.
2.1.3.2 Requisiti di avvio in esercizio
I requisiti di avvio in esercizio comprendono le attività di consegna e di installazione dell’intera fornitura presso i locali indicati dal Committente. La Ditta Aggiudicataria deve realizzare, successivamente all’accettazione dei singoli servizi applicativi ed al collaudo finale, l’avvio dell’esercizio, l’organizzazione, la pianificazione, l’attivazione, la gestione e il controllo del funzionamento dei servizi. In particolare, la Ditta Aggiudicataria, al minimo deve:
▪ rilasciare la documentazione di progetto, operativa e di esercizio;
▪ rilasciare e distribuire il manuale utente per gli operatori di back-office (Redattori, Addetti del Call Center Informativo Sanitario, Amministratori del Portale);
▪ rilasciare e distribuire il manuale utente per i cittadini cui saranno distribuite le smart card (CNS) e i lettori per la sperimentazione che contenga al minimo:
o le istruzioni per l’installazione del lettore di CNS e del software a corredo (integrando eventualmente la documentazione fornita dai fornitori delle CNS e dei lettori)
o la descrizione dei servizi ai quali il cittadino può accedere con la CNS con i passi operativi per effettuare gli stessi
o le modalità per richiedere assistenza (attraverso il Contact Center Portale o pagine dedicate del Portale);
▪ realizzare l’attivazione, cioè l’installazione e configurazione, degli eventuali prodotti software di mercato aggiuntivi forniti;
▪ realizzare l’attivazione, cioè l’installazione e configurazione, dei sistemi applicativi forniti;
▪ realizzare l’attivazione dei servizi di Portale;
▪ realizzare l’attivazione dell’integrazione con gli altri sistemi applicativi sanitari: N-SISR, SIST, CUP Aziendali, Sovra CUP Regionale (attraverso l’uso di stub se non disponibile, con il sistema non appena questo sarà reso disponibile);
▪ attivare, in maniera concordata con il Committente, tutti gli aggiornamenti del software rilasciati durante la durata del contratto.
Al termine del progetto, la Ditta Aggiudicataria deve predisporre una relazione contenente indicazioni di massima per una eventuale evoluzione del sistema.
2.1.4 Vincoli
Di seguito sono descritti i principali vincoli che devono essere rispettati per il servizio di Sviluppo software per la realizzazione del Portale.
2.1.4.1 Vincoli tecnici
La Ditta Offerente deve formulare una proposta progettuale e successivamente garantirne la realizzazione che assuma e rispetti, i seguenti vincoli generali:
▪ il sistema deve essere basato su un’architettura di tipo web-based con interazione utente-sistema, anche relativamente alle attività di amministrazione, basata sull’utilizzo di un browser Internet. In particolare:
o l’utilizzo del Portale deve essere realizzabile da una stazione di lavoro (personal computer) client:
i. con utilizzo dei seguenti browser Internet Explorer 6.x o superiori, Netscape 6.0/7.0 o superiori (obbligatori); Opera 6.0/7.0 o superiori, Mozilla 1.6 o superiori (raccomandati);
ii. non richiedere, se non preventivamente concordato ed autorizzato dal Committente, l’utilizzo di plugin (ad es., Microsoft ActiveX, applet Java)
o le componenti operative sul server devono operare in ambiente Microsoft Windows 2003 Server o Linux.
▪ Il sistema deve essere fruibile dall’utenza attraverso:
o la rete RUPAR Puglia per l’utenza che afferisce ad organizzazioni che sono abilitate all’accesso alla RUPAR Puglia (ad es., Redazioni delle Aziende Sanitarie Locali)
o la rete Internet per utenza non connessa alla RUPAR (ad es., cittadini).
▪ Il sistema deve far uso, nelle interazioni tra domini organizzativi, della infrastruttura di comunicazione RUPAR Puglia (nel seguito brevemente RUPAR) per quanto riguarda sia le problematiche di connettività fisica che quelle di cooperazione applicativa
▪ Qualora, durante la normale operatività del Portale, non sia possibile attivare la cooperazione applicativa, per qualsiasi motivo, la stessa deve essere attivata e portata a completamento senza alcun intervento umano non appena si siano ripristinate le opportune e naturali condizioni operative
▪ Il sistema deve trattare, ove applicabile, documenti con valore probatorio ai fini legali e non impugnabili
▪ Il sistema deve prevedere l’applicazione della Firma Digitale su tutti i documenti informatici trattati che attualmente prevedono l’applicazione della firma in calce nei casi in cui lo stesso è compilato dal soggetto firmatario. Il documento firmato, comprensivo della firma, deve essere reso persistente avendo opportune funzionalità per il recupero (download) del documento firmato comprensivo della firma.
▪ Il sistema deve supportare in maniera trasparente, rispetto all’applicazione, il processo di cifratura dei dati avvalendosi dei meccanismi tecnici resi disponibili dal RDBMS utilizzato
▪ Il sistema deve supportare l’accesso dell’utenza anche attraverso connessioni HTTP-S
▪ Il sistema deve supportare, per i processi di identificazione/autenticazione e di firma digitale, i lettori di smartcard (CNS) e le CNS oggetto della fornitura richiesta dal presente Capitolato Tecnico.
2.1.4.2 Vincoli organizzativi
La realizzazione del progetto deve assumere i seguenti vincoli organizzativi:
▪ il sistema deve garantire il rispetto del modello organizzativo per la gestione del Portale illustrato in Figura 1, delle competenze e responsabilità di ciascuna azienda sanitaria, di ciascuna struttura equiparata, dell’Assessorato alle Politiche della Salute e dell’ARES. Nel modello i Comitati Guida sono presenti solo nei livelli aziendali e regionale, ogni ASL o Azienda Ospedaliera può al suo interno organizzare redazioni distribuite sul proprio territorio (Redazioni di distretto, redazioni di presidio ospedaliero) coordinate dal Comitato Guida aziendale. Tali redazioni potranno fruire dei servizi applicativi che saranno sviluppati per il Portale della Salute (pagine del Portale, funzioni di gestione dei contenuti per le redazioni).
▪ il sistema deve garantire l’adattamento a variazioni del modello organizzativo del Sistema Sanitario Regionale: a titolo esemplificativo e non esaustivo, deve supportare la ridefinizione del numero delle
aziende sanitarie; la ridefinizione degli ambiti territoriali delle ASL; la ridefinizione delle strutture organizzative di livello inferiore (ad es., Distretti). Tutte le attività necessarie per realizzare l’adattamento sono a carico della Ditta Offerente e sono da intendersi coperte dal complesso dei servizi richiesti nel presente Capitolato Tecnico senza ulteriori oneri economici a carico del Committente.
Si fa osservare che la connettività dei soggetti non è oggetto di fornitura.
2.1.5 Livelli di servizio e penali
I livelli di servizio individuati per tale servizio attengono alle attività di manutenzione correttiva (MAC) e di
manutenzione evolutiva (MEV). Per tali servizi si applica la seguente finestra temporale di erogazione:
Lun-Ven dalle ore 8:00 alle ore 17:00 escluso festivi Sabato dalle ore 8:00 alle ore 14:00 escluso festivi
Finestra temporale di erogazione
2.1.5.1 Manutenzione correttiva
2.1.5.1.1 Livelli di servizio
La correzione dei malfunzionamenti deve essere garantita secondo i seguenti livelli di servizio:
Codice indicatore | Indicatore | Unità di misura | Soglia di accettazione | Modalità di calcolo |
MAC.FRT3 | Tempo di risoluzione di un malfunzionamento bloccante del sistema (Sistema indisponibile all’utente)8 | Ore | Entro 8 ore lavorative | Differenza tra la data (giorno e ora) di soluzione del problema e la data (giorno e ora) di registrazione della segnalazione |
MAC.FRT4 | Tempo di risoluzione di malfunzionamento non bloccante del sistema ( Funzionalità dell’applicazione sono indisponibili agli utenti) | Ore | Entro 16 ore lavorative | Differenza tra la data (giorno e ora) di soluzione del problema e la data (giorno e ora) di registrazione della segnalazione |
2.1.5.1.2 Penali
Nel seguito sono riportati i parametri per l’applicazione delle penali relative al mancato rispetto dei livelli di servizio definiti nel precedente paragrafo.
8 La chiusura del disservizio viene ratificata dalla Ditta Aggiudicatario previa verifica dell’avvenuto ripristino della corretta operatività
Codice Indicatore | Indicatore | Penale | ||
MAC.FRT3 | Tempo di risoluzione di un malfunzionamento bloccante del sistema (Sistema indisponibile all’utente) | 0,1% del Costo del Servizio per ogni scostamento dalla soglia di accettazione. | ora | di |
MAC.FRT4 | Tempo di risoluzione di malfunzionamento non bloccante del sistema ( Funzionalità dell’applicazione sono indisponibili agli utenti) | 0,1% del Costo del Servizio per ogni scostamento dalla soglia di accettazione. | ora | di |
2.1.5.2 Manutenzione adeguativa
2.1.5.2.1 Livelli di servizio
La manutenzione adeguativa deve essere garantita secondo i seguenti livelli di servizio:
Codice indicatore | Indicatore | Unità di misura | Soglia di accettazione | Modalità di calcolo |
MAC.ADE1 | Tempo di attesa fra la richiesta di modifica a livello di interfaccia utente e suo rilascio | Giorno | Entro 10 gg. | Differenza tra la data di soluzione del problema e la data di registrazione della segnalazione |
MAC.ADE2 | Tempo di attesa fra la richiesta di modifica a livello di base dati sul server e suo rilascio | Giorno | Entro 10 gg. | Differenza tra la data di soluzione del problema e la data di registrazione della segnalazione |
MAC.ADE3 | Tempo di attesa fra la richiesta di modifica a livello di funzionalità applicative e suo rilascio | Giorno | Entro 10 gg. | Differenza tra la data di soluzione del problema e la data di registrazione della segnalazione |
2.1.5.2.2 Penali
Nel seguito sono riportati i parametri per l’applicazione delle penali relative al mancato rispetto dei livelli di servizio definiti nel precedente paragrafo.
Codice Indicatore | Indicatore | Penale |
MAC.ADE1 | Tempo di attesa fra la richiesta di modifica a livello di interfaccia utente e suo rilascio | 0,1% del Costo del Servizio per ogni giorno di scostamento dalla soglia di accettazione. |
MAC.ADE2 | Tempo di attesa fra la richiesta di modifica a livello di base dati sul server e suo rilascio | 0,1% del Costo del Servizio per ogni giorno di scostamento dalla soglia di accettazione. |
MAC.ADE3 | Tempo di attesa fra la richiesta di modifica a livello di funzionalità applicative e suo rilascio | 0,1% del Costo del Servizio per ogni giorno di scostamento dalla soglia di accettazione. |
2.1.6 Modalità di valorizzazione del corrispettivo e di pagamento
Per il servizio Progettazione e realizzazione del Portale sono definite le componenti di spesa riportate nella tabella seguente.
Servizio | Modalità di valorizzazione | Modalità di pagamento | ||||
Progettazione e | A corpo | 100% del valore del servizio indicato nell’Offerta | ||||
realizzazione del Portale | Economica. | |||||
Il corrispettivo è riconosciuto a seguito del collaudo | ||||||
positivo del servizio. | ||||||
Manutenzione correttiva | A corpo | 100% del valore | del | servizio | indicato | nell’Offerta |
e adeguativa | Economica. | |||||
2.2 Infrastruttura tecnologica e strumenti per l’erogazione dei servizi
Il servizio comprende la progettazione e realizzazione dell’infrastruttura tecnologica del Portale. Il servizio si articola in:
1. fornitura dell’infrastruttura tecnologica, di elaborazione e comunicazione, funzionale all’erogazione ed utilizzo del servizio Portale di seguito denominato Centro Servizi Portale
2. fornitura di stazioni di lavoro funzionali alle attività delle Redazioni (presso le Aziende Sanitarie Pubbliche e l’Assessorato)
3. fornitura delle Smart Card e dei lettori per utenza pilota;
La Ditta Offerente in sede di Offerta Tecnica dovrà predisporre nell’ambito della Relazione Tecnica un progetto di dettaglio, per la fornitura e realizzazione dell’infrastruttura tecnologica, definendo l’adeguata configurazione e dimensionamento delle attrezzature previste e di quelle aggiuntive ritenute necessarie in modo tale che siano conformi alle specifiche minime descritte nel presente documento. Il progetto dovrà specificare almeno:
1. l’architettura logica e fisica proposta: l'architettura logica deve fare riferimento agli elementi architetturali identificati e descritti di seguito, opportunamente integrati dagli altri ritenuti necessari da parte della Ditta Offerente;
2. la descrizione di ciascuna attrezzatura offerta, la sua configurazione e dimensionamento;
3. il computo metrico delle attrezzature oggetto della fornitura comprendente per ciascun prodotto fornito:
a. riferimento architetturale (ad es. firewall)
b. nome costruttore
c. nome prodotto
d. modello prodotto o, per i prodotti software, edizione commerciale (ad es. Enterprise Edition)
e. quantità offerta
4. il computo metrico dei circuiti trasmissivi necessari
5. il piano di dispiegamento dei singoli prodotti software per specifica attrezzatura hardware.
Il dimensionamento delle attrezzature dovrà prevedere una potenzialità di crescita delle condizioni di utilizzo del servizio senza richiedere espansioni dell'infrastruttura tecnologica.
Per tutti i prodotti forniti, hardware e software deve essere garantito da parte del produttore:
1. il supporto certificato della compatibilità hardware
2. il supporto certificato della compatibilità software
3. il supporto certificato delle configurazioni realizzate
La Ditta Offerente può apportare modifiche migliorative alla soluzione indicata nelle sue linee generali. La progettualità richiesta deve tendere a massimizzare la valorizzazione delle attrezzature disponibili. Il Committente si riserva il diritto nella fase esecutiva del contratto di richiedere integrazioni/modifiche al progetto presentato in fase di Offerta Tecnica che dovranno essere recepite dalla Ditta Aggiudicataria.
2.2.1 Architettura complessiva del Portale
L’architettura tecnologica del Portale dovrà essere basata su un modello fisicamente distribuito comprendente (Figura 4):
▪ N.1 Centro Servizi Portale ubicato presso Tecnopolis CSATA.
▪ N.1 Postazione di lavoro per la Redazione del Portale presso l’Assessorato alle Politiche della Salute della Regione Puglia ed ARES Puglia (Redazione Regionale)
▪ N.8 Postazioni di lavoro per le Redazioni del Portale presso le 8 Aziende Sanitarie Pubbliche
Il Centro Servizi Portale e le Postazioni di lavoro per le Redazioni saranno interconnessi tra loro attraverso la rete RUPAR utilizzando le Porte di Rete RUPAR (PdR RUPAR) già esistenti presso ciascun dominio organizzativo.
Figura 4 - Topologia logica rete Portale
La topologia logica della infrastruttura di comunicazione del Portale prevede, quindi, due livelli di rete:
▪ rete backbone: realizzata attraverso la rete RUPAR, interconnette tutte le Aziende Sanitarie Pubbliche e l’Assessorato alle Politiche della Salute
▪ rete locale geografica: realizzata attraverso linee predisposte dall’amministrazione, interconnette le postazioni di lavoro delle Redazioni alla LAN delle Aziende Sanitarie di riferimento.
L’utente pubblico accederà tramite internet all’applicazione del Portale, che a sua volta interagirà attraverso la rete RUPAR con i Sistemi Informativi Sanitari (N-SISR, SIST, CUP, …) per la richiesta di servizi interattivi.
2.2.2 Fornitura, installazione ed attivazione dell’infrastruttura tecnologica del Centro Servizi Portale
Il sotto-servizio ha l’obiettivo di fornire, realizzare e rendere totalmente operativa l’infrastruttura tecnologica di supporto all’erogazione dei servizi ed utilizzo del Portale. L’infrastruttura tecnologica comprende le attrezzature hardware, le attrezzature software (base, middleware) e quanto altro necessario al funzionamento dell’intero sistema informativo Portale.
La Ditta Offerente dovrà rispettare, nella proposta di progettazione e nella realizzazione della infrastruttura del Portale i seguenti requisiti:
▪ L’accesso ai servizi offerti dai Sistemi Informativi Sanitari (N-SISR, SIST, CUP, …) dovrà essere implementato attraverso le modalità dettate del protocollo di cooperazione applicativa. In generale, ai fini della comunicazione tra i diversi sistemi informativi, per supportare la Cooperazione Applicativa, si considera la componente Porta di Dominio Standard (PDDS), l’elemento tecnologico che realizza la cooperazione applicativa: essa ha la funzione di invocare servizi remoti esposti da altri sistemi o sottosistemi software e di attivare propri servizi esposti per l’accesso alle proprie risorse informative. Si fa presente che la fornitura non richiede l’implementazione della componente Porta di Dominio, bensì richiede l’utilizzo, quando necessario, delle componenti già rese disponibili come servizi RUPAR Puglia. La Ditta Offerente dovrà sviluppare le componenti di integrazione della PDDS necessarie alla realizzazione del Sistema, utilizzando le specifiche tecniche di PDDS nelle versione 2.0 e nelle successive versioni adottate dagli altri sistemi informativi con cui il Portale interagirà. La PDDS sarà disponibile sul sito della RUPAR Puglia (xxx.xxxxx.xxxxxx.xx) alla Sezione “Standard Tecnici”.
▪ Le piattaforme serventi application server dovranno supportare sia l’alta disponibilità del servizio sia il bilanciamento di carico delle richieste. Il bilanciamento del carico su tali server sarà realizzato dall’infrastruttura tecnologica del Centro Tecnico della Rupar Puglia. Le piattaforme serventi database server dovranno essere configurate in modalità cluster preferibilmente di tipo active/active. I nodi componenti il cluster saranno contemporaneamente attivi nell’evadere le richieste e nel caso di malfunzionamento di uno dei nodi, il sistema in modalità del tutto automatica e trasparente dovrà migrare tutto il carico del lavoro sul nodo superstite.
▪ Con riferimento ai prodotti software forniti, gli stessi devono essere forniti nell’ultima versione commercialmente disponibile. E’ ammesso l’utilizzo della versione immediatamente precedente purché la stessa sia supportata dal costruttore. Si fa presente che i prodotti in uso devono essere sempre supportati9 dal costruttore: qualora un prodotto non sia più supportato dal costruttore, la Ditta Aggiudicataria deve realizzare, senza oneri economici aggiuntivi, il necessario upgrade ad una versione successiva con conseguente adeguamento dei sistemi applicativi nell’ambito del servizio di manutenzione software.
▪ Tutte le attrezzature, se non diversamente concordato, dovranno essere fornite in versione installabile in rack ed installate in rack standard 19” ; si fa presente che i rack non sono oggetto di fornitura.
▪ La Ditta offerente potrà richiedere di effettuare un sopralluogo dei locali adibiti all’installazione della fornitura al fine di verificare l’infrastruttura esistente
9 Per prodotto supportato si intende che il ciclo di vita del prodotto non si è esaurito e pertanto il costruttore garantisce il relativo supporto tecnico attraverso un servizio di manutenzione
▪ Tutte le attività (ad es. consegna, installazione e configurazione hardware e software) necessarie per rendere pienamente operative le attrezzature offerte sono a carico della Ditta Aggiudicataria, presso la sede che ospita il Centro Servizi Portale.
Al termine delle attività dovrà essere redatto dalla Ditta Aggiudicataria e consegnato al Committente un apposito “Verbale di configurazione, di avvio operativo e verifica funzionalità”.
2.2.2.1 Infrastruttura di elaborazione del Centro Servizi Portale
L’infrastruttura di elaborazione del Centro Servizi Portale, deve comprendere tutti gli elementi infrastrutturali indicati nella Tabella 2. Tra questi elementi si distinguono le componenti dalla A1 alla A5 che costituiscono parti nuove di acquisizione. Le componenti A6 ed A7 sono, invece, delle estensioni dell’infrastruttura di rete e di Storage e di RACK esistenti per permettere l’integrazione delle nuove componenti con quelle già esistenti. A tal fine si faccia riferimento al paragrafo 2.2.2.1.2 per la descrizione della Storage Area Network, la rete e il RACK esistenti.
Codice elemento architetturale | Elemento architetturale | Classe di server di elaborazione | Ridondanza | Funzionalità |
A1 | Sistema di Application Server | A | Si | Server di erogazione del servizio |
A2 | Sistema di Database Server | A | Si | Server di erogazione del servizio |
A3 | Sistema di pre-esercizio | A | No | Server di test |
A4 | Server di management e backup | B | No | Sistema hardware di system/network management e gestione delle attività di backup/restore |
A5 | Sistema di backup | Sistema software e hardware per la gestione delle attività di backup/restore | ||
A6 | Estensione Storage Area Netowkr, LAN e RACK esistente | Fornitura di apparati necessari ad estendere Storage Area Network , LAN e KVM esistente |
Tabella 2 - Infrastruttura Centro Servizi Portale
L’infrastruttura servente del Centro Servizi Portale sarà ospitata presso il Centro Tecnico della RUPAR, ubicato presso Tecnopolis CSATA. Il Centro Tecnico è organizzato in n. 2 ambienti, denominati CED-A e CED-H, ubicati in 2 edifici distanti fra loro circa m. 400.
La configurazione dell’infrastruttura tecnologica dovrà prevedere di ripartire equamente ciascun sistema logico tra i due ambienti. In ciascuno di essi sarà installata ed attivata una configurazione completa dell’infrastruttura di esercizio del Portale che si compone degli elementi indicati come A1 e A2 nella Tabella 2 (per gli elementi A3, A4 e A5 non è richiesta la ridondanza).
I locali messi a disposizione dal Centro Servizi Portale sono già a norma e non necessitano di nessun lavoro di adeguamento anche per quanto concerne la potenza elettrica installata e lo smaltimento del calore.
L’integrazione del Centro Servizi Portale con il backbone RUPAR avverrà attraverso interconnessione con gli apparati di comunicazione (switch) forniti dalla Ditta Aggiudicataria (come da specifiche tecniche indicate al paragrafo 2.2.2.1.2) secondo le modalità indicate dal personale del Centro Tecnico RUPAR.
La Ditta Offerente in fase di offerta dovrà illustrare l’architettura tecnologica che intende implementare indicando esplicitamente quali componenti del sistema saranno ridondate tramite configurazioni in cluster di server e/o apparati. Nell’offerta tecnica dovranno essere indicate tutte le caratteristiche tecniche delle apparecchiature, per ciascuna delle quali dovrà essere fornita oltre alla marca e al modello anche il rispettivo datasheet. L’architettura tecnologica di riferimento, rispondente ai requisiti indicati nel paragrafo precedente, è proposta nella seguente figura:
Figura 5 - Architettura logica del Centro Servizi Portale della Salute
Per l’infrastruttura tecnologica servente del Centro Servizi Portale si richiede al minimo la fornitura delle seguenti componenti:
▪ n. 2 Application Server di Classe B (descritti in 2.2.2.1.1.2)
▪ n. 2 Database Server di Classe A (descritti in 2.2.2.1.1.1)
▪ n. 1 Server di pre-esercizio di Classe A (descritto in 2.2.2.1.1.1)
▪ n. 1 Server di management e backup di Classe B (descritto in 2.2.2.1.1.2)
▪ n. 1 Sistema di backup (descritto in 2.2.2.1.3)
2.2.2.1.1 Sistemi serventi di elaborazione
Le caratteristiche prestazionali dei server oggetto della fornitura sono indicate in relazione al benchmark SPEC CPU2006, effettuato dalla “Standard Performance Evaluation Corporation” e consultabile alla URL xxxx://xxx.xxxx.xxx.
I server forniti devono presentare una configurazione hardware tale da garantire scalabilità verticale. In altre parole deve essere possibile aumentare il numero di hard disk e la capacità di memoria RAM.
Di seguito sono riportate le caratteristiche tecniche minime dei sistemi previsti suddivisi per classi:
2.2.2.1.1.1 Sistema di elaborazione di classe A
Caratteristiche minime:
▪ microprocessori x86 di ultima generazione attualmente in produzione installati su almeno n° 2 socket diversi che consentano l’esecuzione di sistemi operativi a 32 e 64 bit e l’esecuzione simultanea, nel caso di sistemi operativi a 64-bit, di applicazioni a 32 e 64 bit;
▪ Utilizzando il benchmark SPEC CPU 2006 il server deve raggiungere il valore minimo esplicitato dai seguenti parametri:
o SPECint_rate2006 > 110
o SPECint_rate_base2006 > 136
▪ montaggio in rack standard 19”;
▪ RAM 16 GB; l’installazione della RAM deve lasciare almeno due slot disponibili per upgrade futuri;
▪ Lettore DVD/CD-ROM interno;
▪ Controller Dischi - Controller SAS o RAID SCSI-Ultra320 con supporto di RAID 0, 1, 0+1, 5;
▪ n. 2 Hard Disk da 146 GByte di tipo Hot Plug – SAS a 10K rpm oppure SCSI-Ultra320 a 15K rpm;
▪ n. 4 interfacce di rete Ethernet 10/100/1000 TX UTP;
▪ n. 2 Controller PCI Fibre Channel 2Gb a 1 canale e relativi cavi in fibra ottica per il collegamento alla Storage Area Network esistente. Tali componenti, dovranno essere certificate dal produttore per quanto concerne la compatibilità con il sistema SAN esistente, del quale si riportano di seguito le caratteristiche tecniche nel paragrafo 2.2.2.1.2;
▪ interfacce esterne: n. 1 SCSI per collegare una unità tape, n. 2 USB 2.0 (almeno 1 frontale), n. 1 seriale, video, mouse, tastiera;
▪ Alimentatori ridondati hot-plug;
▪ Ventole di raffreddamento ridondate;
▪ Utility Software per configurazione e Diagnostica;
▪ Servizio di manutenzione e garanzia 3 anni on-site next business day per tutte le componenti;
▪ Compatibilità certificata dal produttore con Sistemi Operativi Linux Enterprise Edition ultima versione stabile del Kernel disponibile e Microsoft Windows Server 2003 (e versioni successive).
2.2.2.1.1.2 Sistema di elaborazione di classe B
Caratteristiche minime:
▪ microprocessori x86 di ultima generazione attualmente in produzione installati su almeno n° 2 socket diversi che consentano l’esecuzione di sistemi operativi a 32 e 64 bit e l’esecuzione simultanea, nel caso di sistemi operativi a 64-bit, di applicazioni a 32 e 64 bit;
▪ Utilizzando il benchmark SPEC CPU 2006 il server deve raggiungere il valore minimo esplicitato dai seguenti parametri:
o SPECint_rate2006 > 58
o SPECint_rate_base2006 > 60
si fa presente che i valori specificati risultano da test di benchmark effettuati con 16 GB di RAM;
▪ montaggio in rack standard 19” con occupazione massima pari a 1U;
▪ RAM 8 GB; l’installazione della RAM deve lasciare almeno due slot disponibili per upgrade futuri;
▪ Lettore DVD/CD-ROM interno;
▪ Controller Dischi - Controller SAS o RAID SCSI-Ultra320 con supporto di RAID 0, 1, 0+1, 5;
▪ n. 2 Hard Disk da 146 GByte di tipo Hot Plug – SAS a 10K rpm oppure SCSI-Ultra320 a 15K rpm;
▪ n. 2 interfacce di rete Ethernet 10/100/1000 TX UTP;
▪ interfacce esterne: n. 1 SCSI per collegare una unità tape, n. 2 USB 2.0 (almeno 1 frontale), n. 1 seriale, video, mouse, tastiera;
▪ Alimentatori ridondati hot-plug;
▪ Ventole di raffreddamento ridondate;
▪ Utility Software per configurazione e Diagnostica;
▪ Servizio di manutenzione e garanzia 3 anni on-site next business day per tutte le componenti;
▪ Compatibilità certificata dal produttore con Sistemi Operativi Linux Enterprise Edition ultima versione stabile del Kernel disponibile e Microsoft Windows Server 2003 (e versioni successive).
2.2.2.1.1.3 Specifiche tecniche minime per l’interfaccia di rete dedicata alla gestione remota
Tutti i server dovranno avere l’interfaccia Ethernet per la gestione remota, differenziata dalle altre interfacce Ethernet richieste, che deve consentire il controllo completo del server remoto come se fosse gestito in locale. Inoltre, deve permettere la modifica delle impostazioni hardware e software del server remoto, l’installazione di applicazioni e driver, la modifica della risoluzione video e lo spegnimento (shutdown) del sistema.
Tale porta dovrà avere un microprocessore dedicato e il sistema operativo incorporato in modo da essere totalmente indipendente dal sistema operativo del server. L’installazione di questa porta, non dovrà prevedere l’utilizzo o l’installazione di alcun driver sul server.
Inoltre tale componente dovrà essere in grado di garantire le seguenti funzioni:
▪ Console remota virtuale sia in modalità testo che in modalità grafica: tale opzione Remote Console (Console remota) deve permettere il reindirizzamento della console del server al browser del client che lo gestisce, fornendo accesso completo in modalità testo e grafica di tastiera e mouse al server remoto.
▪ Pulsante di accensione virtuale: la presente opzione di Accensione virtuale deve permettere il controllo dello stato di alimentazione del server. Se il server host remoto non dovesse rispondere, questa funzione deve consentire all'amministratore di eseguire un riavvio a caldo o a freddo per riavviare il server.
▪ Supporti virtuali quali floppy disk e lettore CD: l'opzione Supporti virtuali deve offrire all'amministratore un'unità disco floppy virtuale e un'unità CD-ROM virtuale che consentono di avviare un server host remoto e utilizzare i supporti standard da un punto qualsiasi della rete.
▪ Integrazione con sistemi di management remoto: la porta dovrà prevedere la sua integrazione con almeno un sistema di management remoto con funzionalità di notifica multi-canale, quali cerca persone o posta elettronica, in grado di segnalare agli amministratori di sistema potenziali errori o malfunzionamenti del server, gestire il Supporto per la gestione e consegna di trap e allarmi SNMP.
▪ Possibilità di connessione ad una rete LAN dedicata: tale caratteristica deve permettere la connessione della porta di gestione del server ad una rete dedicata al management con un proprio indirizzo IP.
▪ Amministrazione utente e protezione con codifica a 128 bit dei dati delle pagine Web e della console remota e supporto del protocollo SSL (Secure Socket Layer): tale funzione di protezione deve garantire la gestione remota in ambienti di rete distribuiti e assicurare la protezione delle informazioni HTTP durante la trasmissione in rete. I dati della console remota devono essere protetti dalla codifica bidirezionale a 128 bit.
2.2.2.1.2 Estensioni Storage Area Network, LAN e RACK
Presso il Centro Tecnico RUPAR, sito in Tecnopolis, è già disponibile una Storage Area Network, e questa, pertanto, non è oggetto della fornitura.
La Storage Area Network (SAN) esistente è una infrastruttura composta da due nodi completamente ridondati nelle sue componenti e installata su due differenti armadi rack. Ognuno dei due nodi si compone di:
▪ n. 1 armadio rack mod. HP 10000 da 42 unità comprensivo di KVM modello HP 336044-B21;
▪ n. 2 switch Fiber Channel 16 porte mod. HP A7985A;
▪ n. 1 Storage Disk Array mod. HP EVA4000 con enclosure da 14 dischi ciascuno;
La Ditta Aggiudicataria dovrà testare durante le operazioni di avvio del servizio, l’integrazione dei server oggetto di Fornitura con la SAN esistente.
Allo scopo di ampliare la presente SAN, è richiesta la seguente fornitura:
▪ N. 2 Enclosure per alloggiare nuovi dischi in FC. Questi enclosure devono essere compatibili con la SAN descritta e sono indicati dal produttore con questo modello: HP M5314B FC Drive Enclosure
▪ N. 10 dischi in FC da 300 GB (10K rpm) da alloggiare nei due enclosure indicati (5 dischi per enclosure)
▪ N. 8 connettori GBIC di tipo 1000BASE-SX “short wavelength” multimode-only da installare negli switch in fibra indicate (mod. HP A7985A)
▪ N.8 cavi in fibra di tipo bi-fibra MM connettorizzate LC-LC
Per l’estensione del RACK esistente è richiesta:
▪ Espansione per poter collegare ulteriori N. 16 server al KVM già esistente ed indicato in precedenza. Di questo devono essere forniti tutti i cavi necessari al collegamento dei server
▪ Moduli di espansione di distribuzione elettrica Cavi e PDU (Power Distribution Unit) come estensioni del RACK indicato (stessa marca) necessari per il collegamento alla rete elettrica di tutta la fornitura oggetto del presente bando
Per l’estensione della LAN invece sono richiesti:
• N. 2 switch Catalyst 3560E 48 10/100/1000T + 4 SFP (WS-C3560E-48TD-S)
• Cavi in fibra necessari al collegamento dei due switch forniti utilizzando tutte le porte in fibra
2.2.2.1.3 Sistema di backup
La Ditta Offerente dovrà fornire un software di backup che garantisca al minimo:
▪ supporto dell’esecuzione di procedure di salvataggio, in modalità manuale e automatica;
▪ capacità di gestione automatizzata delle procedure di salvataggio e ripristino dei dati;
▪ supporto di backup a caldo dei dati presenti su file system e nei database del Portale senza interruzione del servizio.
Il sistema di backup del Centro Servizi Portale, pertanto, deve essere composto da:
▪ n. 1 server di backup (elemento A4 della Tabella 2) ospitante il software di gestione delle procedure automatizzate di salvataggio e ripristino dei dati;
▪ n. 1 tape library che interagirà col server di backup per la memorizzazione dei dati su nastro.
La tape library deve presentare le seguenti caratteristiche tecniche minime:
▪ n. 8 slot e capacità di memorizzazione nativa interna di 6,4 TB compressi;
▪ tecnologia LTO Ultrium;
▪ interfaccia SCSI per il collegamento al server di backup;
▪ montaggio in rack standard 19” con occupazione massima pari a 2U;
Per la tape library oggetto di fornitura si richiedono almeno:
▪ n. 10 supporti di memorizzazione di tipo LTO Ultrium;
▪ n. 2 cartucce di pulizia.
2.2.2.1.4 Sistema di network/system management
La Ditta Offerente dovrà fornire un software di system/network management inerente all’elemento architetturale A4 della Tabella 2 che permetta di effettuare:
▪ monitoraggio a livello di servizi di rete (SMTP, POP3, HTTP, ICMP, ecc..);
▪ monitoraggio delle risorse relative al singolo host (carico del processore, utilizzo di disco e memoria, processi in esecuzione, file di log, ecc..);
▪ creazione di script aggiuntivi per la personalizzazione dei check a livello di servizio;
▪ notifiche (via e-mail, SMS, ecc..) relative allo stato dei sistemi controllati;
▪ mappe di rete che facilitino la gestione complessiva del sistema.
Lo strumento oggetto della fornitura dovrà possedere, oltre alle funzionalità di cattura dei dati, anche funzionalità di reportistica, con presentazione anche grafica, in grado di rendere disponibili al Committente elaborazioni di trend temporali. I report di misura delle prestazioni, i cui contenuti saranno specificati in dettaglio in fase attuativa, faranno parte integrante del Report trimestrale Monitoraggio Sistemi descritto nel seguito del presente paragrafo.
2.2.2.1.5 Armadi rack
Come già detto in precedenza, gli armadi rack per il Centro Servizi Portale non sono oggetto di fornitura.
I rack esistenti presso Tecnopolis sono dotati di apparati KVM Console Switch HP; si richiede, pertanto, la piena compatibilità (certificata dal produttore) tra i server oggetto di fornitura e tali apparati.
2.2.2.1.6 Database relazionale
I sistemi applicativi oggetto della fornitura devono gestire le proprie basi informative attraverso un unico sistema di database relazionale (RDBMS) basato su uno dei seguenti prodotti:
▪ Microsoft SQL Server
▪ Oracle
▪ MySQL
Alla Ditta Offerente si richiede di:
▪ fornire licenza d’uso illimitata, per numero di utenti e per durata temporale, a prescindere dal prodotto RDBMS (ultima versione disponibile);
▪ fornire quanto altro connesso direttamente o indirettamente a tale scelta, per tutti i server della categoria Server di Database, nella configurazione e nel dimensionamento previsti, con servizio di manutenzione come specificato nella sezione specifica;
▪ provvedere a tutte le attività tecniche (ad esempio, installazione, configurazione, …) necessarie per l’attivazione del RDBMS anche per quanto concerne la relativa configurazione in cluster e l’integrazione con la Storage Area Network preesistente;
▪ assumere a proprio carico ogni onere economico direttamente o indirettamente connesso con la fornitura del RDBMS.
2.2.2.1.7 Sistemi operativi e licenze d’uso
Per la realizzazione del Centro Servizi Portale, si richiede quanto segue:
▪ Licenza d’uso e/o Supporto di tutti i Sistemi Operativi che la Ditta Offerente intende installare. I sistemi operativi previsti per lo sviluppo del Centro Servizi Portale sono Microsoft Windows Server 2003 Enterprise Edition o successive, e Linux Enterprise Edition, ultima versione stabile del Kernel disponibile. I Sistemi Operativi dovranno essere installati e aggiornati con le ultime patch disponibili e dovranno essere compatibili con tutte le componenti hardware che saranno installate sui server dove risiederanno (controller dischi, schede di rete, schede in fibra, ecc.). Inoltre è richiesta la compatibilità, dimostrata attraverso certificazione del produttore HP, con lo Storage HP EVA 4000 con cui i server richiesti con il presente bando dovranno collegarsi.
▪ Licenze d’uso ed installazione di tutti i prodotti software necessari per realizzare le configurazioni cluster di tutti o parte dei server;
▪ Licenze d’uso del software di gestione remota del server, associato alla caratteristica tecnica di gestione remota del server specificata nel paragrafo 2.2.2.1.1.3.
▪ Eventuali licenze d’uso legate alle funzionalità di alta disponibilità richieste per la Storage Area Network;
▪ Licenze d’uso dei software aggiuntivi necessari per il system/network management (paragrafo 2.2.2.1.4) e per le operazioni centralizzate di backup/restore dell’intera infrastruttura (paragrafo 2.2.2.1.3);
▪ Licenze client per le operazioni di backup/restore dei server del Portale come specificato nel paragrafo 2.2.2.1.3;
▪ Per tutto il software fornito si richiede un supporto non inferiore due anni.
2.2.2.2 Requisiti tecnici
L’infrastruttura tecnologica proposta per il Centro Servizi Portale dovrà presentare le seguenti caratteristiche generali e minimali:
▪ unitarietà del costruttore degli apparati offerti per le seguenti classi di attrezzature:
o tutti gli apparati appartenenti ai sistemi di elaborazione, di memorizzazione e di backup
o tutti gli apparati appartenenti ai sistemi di comunicazione.
L’offerta nell’ambito di una classe di attrezzature di prodotti appartenenti a costruttori distinti deve essere motivata dal costruttore stesso. Il Committente si riserva il diritto, durante la fase esecutiva del contratto, di chiedere la sostituzione di tali apparati con altri equivalenti prodotti dal costruttore di riferimento della classe;
▪ ridondanza completa, degli apparati funzionali all’erogazione e fruizione del servizio Portale da parte dell’utenza;
▪ tutti i sistemi utilizzati devono presentare caratteristiche intrinseche di alta disponibilità e assenza di SPOF (single point of failure) che, unitamente al servizio di assistenza e manutenzione proposto, devono assicurare una assoluta continuità operativa della piattaforma;
▪ elevata scalabilità orizzontale (ossia ad esempio la possibilità di aggiungere nodi serventi ad un cluster esistente);
▪ elevata scalabilità verticale in modo da poter espandere l’apparato server sia in numero dei processori (in architettura multi core) sia in memoria RAM (per la quale deve essere possibile un incremento di almeno il 25% della RAM installata senza rimozione della stessa);
▪ utilizzo sui server di sistemi operativi preferibilmente open source e idonei a lavorare su ambienti a 32 e a 64 bit con alte performance, anche in modalità cluster;
▪ tutti i server che manipoleranno dati cifrati e che quindi eseguiranno operazioni di cifratura dovranno prevedere opportune schede acceleratrici per alleggerire il lavoro delle CPU principali;
▪ fornitura di tutto il corredo software di base necessario per le elaborazioni previste dalle singole applicazioni informatiche installate, con riferimento alla fornitura delle licenze per il DBMS comprensive degli oneri che ne derivano per far fronte al completamento di tutte le fasi progettuali, delle licenze dei sistemi operativi per i server e del software di base per effettuare operazioni di Backup/Recovery su SAN di tutti i server oggetto di fornitura.
▪ Tutto il materiale dovrà essere completo d’ogni accessorio (cavi d’alimentazione, cavi paralleli, cavi SCSI, cavi USB, fibre ottiche, transceivers ecc.) necessario al funzionamento delle attrezzature, dei driver, del sistema operativo e dei materiali di consumo necessari al collaudo;
▪ Prediligire piattaforme tecnologiche orientate al risparmio energetico ed al rispetto dell’ambiente
Tutti i server aggiuntivi necessari alle funzionalità richieste dal bando e non esplicitamente previsti nel presente documento sono a carico della Ditta Offerente senza oneri aggiuntivi per il Committente.
2.2.2.2.1 Sicurezza del Portale
La sicurezza del Portale riguarda il complesso delle attività e degli strumenti necessari per la gestione della sicurezza del sistema informativo Portale. Di seguito verranno descritti gli accorgimenti minimi necessari che il Portale deve rispettare per soddisfare i requisiti di sicurezza per i sistemi serventi, le basi di dati e la rete.
2.2.2.2.1.1 Sicurezza dei sistemi di erogazione del servizio
La sicurezza dei sistemi di erogazione del servizio dipende anche dal grado di sicurezza offerto dai sistemi operativi installati su di essi. Dunque, già a partire dal livello sistema operativo, i sistemi di erogazione del servizio devono avere caratteristiche di robustezza ovvero capacità di resistenza ad un attacco informatico. Per far sì che i sistemi serventi siano immuni il più possibile agli attacchi, la Ditta Offerente deve realizzare il cosiddetto hardening di sistema (documentato attraverso reportistica generata da software per l’individuazione di vulnerabilità, ad es. Nessus) all’attivazione dello stesso e poi periodicamente durante il periodo di conduzione operativa.
2.2.2.2.1.2 Sicurezza nella base dei Dati
La sicurezza delle basi di dati deve essere supportata da funzionalità di cifratura dei dati attraverso opportuni algoritmi di cifratura.
Il sistema di cifratura deve:
▪ Essere implementato dal software di gestione della base di dati ed essere trasparente alle applicazioni che vi si interfacciano
▪ Essere applicato in maniera selettiva su specifiche colonne delle tabelle della base dati (ad es., le colonne corrispondenti ai dati identificativi di un Assistito)
La Ditta Offerente dovrà proporre nella fase esecutiva del contratto e concordare con il Committente i dati da cifrare.
Particolare importanza deve essere posta nella gestione delle chiavi di cifratura prevedendo apposite misure di sicurezza.
La soluzione offerta deve poter garantire operazioni di backup/restore di dati cifrati su supporti di tipo magnetico e ottico.
Nel caso in cui il prodotto RDBMS scelto dalla Ditta Offerente non offra capacità native di cifratura dei dati, sono ammesse soluzioni che prevedano per la cifratura l’utilizzo di appliance software certificate dal produttore del RDBMS.
2.2.2.2.1.3 Sicurezza di rete
Il sistema di sicurezza di rete a protezione del Portale sarà fornito dal Centro di Sicurezza di rete del Centro Sanitario Regionale;
2.2.2.3 Altri Requisiti
La Ditta Offerente dovrà rispettare, nella proposta della progettazione e nella realizzazione della infrastruttura del Portale i requisiti definiti nel successivo paragrafo.
2.2.2.3.1 Certificazioni del Fornitore
Alla Ditta Offerente viene richiesto che le apparecchiature siano state prodotte in regime di qualità, certificato ISO-9000:2000.
Analogamente per la manutenzione/assistenza i centri di riparazione devono essere dotati di certificazione della famiglia ISO 9000:2000.
La Ditta Offerente deve tener conto delle modalità di erogazione del servizio di manutenzione/assistenza nella sua analisi economica, e null’altro potrà pretendere in merito a tempi di intervento più brevi di quelli standard offerti dalle case madri o dai centri di riparazione abituali, centri che come detto precedentemente devono comunque essere dotati di certificazione della famiglia ISO 9000:2000.
Si precisa che le parti delle apparecchiature eventualmente sostituite devono rispettare gli standard di qualità e sicurezza prescritti nelle norme nazionali e comunitarie vigenti e devono inoltre essere prodotti da ditta certificata ISO 9000:2000.
Si richiede che i servizi di “Fornitura, installazione ed attivazione dell’infrastruttura tecnologica del Centro Servizi Portale” vengano realizzati da personale qualificato e certificato dai vendor selezionati dalla Ditta Concorrente. A titolo d’esempio si considerano le seguenti certificazioni:
▪ Linux RedHat Enterprise (RHCT)
▪ Windows Server 2003 (MCSE)
▪ MySQL Server (CMDBA)
▪ Oracle (OCA)
Si fa presente che questi certificati devono essere inseriti nella busta dell’offerta tecnica.
2.2.3 Fornitura, installazione ed attivazione delle stazioni di lavoro presso le Redazioni
Il sotto-servizio ha l’obiettivo di fornire stazioni di lavoro per uso diretto da parte di personale del Sistema Sanitario Regionale (con il ruolo di Redattore) e di realizzare tutte le attività necessarie per rendere completamente operative le stazioni di lavoro nelle sedi di utenza.
Di seguito sono riportate le specifiche della fornitura.
La consegna ed installazione dovrà essere realizzata dalla Ditta Aggiudicataria, attraverso personale specializzato, presso le sedi nel territorio della regione Puglia, di seguito indicate:
▪ Assessorato alle Politiche della Salute della Regione Puglia ed ARES Puglia – Bari (Redazione Regionale)
▪ Aziende Sanitarie Locali – Bari, BAT, Brindisi, Foggia, Lecce, Taranto
▪ Ospedale Riuniti - Foggia
▪ Azienda Ospedaliera Policlinico - Bari
Il Committente si riserva di apportare modifiche all’elenco delle sedi di fornitura delle Redazioni del Portale, per adeguamenti alla normativa regionale.
Tali attività si intendono comprensive di ogni onere relativo ad imballaggio, trasporto, facchinaggio, consegna “al piano”, posa in opera, installazione del sistema operativo e degli altri prodotti software forniti, verifica della funzionalità delle apparecchiature, asporto dell’imballaggio e qualsiasi altra attività ad esse strumentale. La Ditta Aggiudicataria dovrà garantire l’immagazzinamento delle attrezzature fino al momento della consegna presso le sedi di installazione.
Per ciascuna apparecchiatura richiesta, la Ditta Aggiudicataria dovrà procedere a:
▪ installare e rendere funzionanti i prodotti software richiesti e forniti
▪ configurare le stazioni di lavoro nell’ambito dell’infrastruttura di comunicazione dell’organizzazione, ove già disponibile, sulla base delle indicazioni espresse e di quanto concordato con il Responsabile dei Servizi Informativi della stessa
▪ installare, configurare e rendere operative le periferiche associate alla stazione di lavoro (per es. stampante, scanner) oggetto della fornitura
Le apparecchiature dovranno essere rese funzionanti e consegnate unitamente alla manualistica tecnica d’uso (hardware e software), e su di esse sarà effettuata una verifica di funzionalità, intesa come verifica dell’accensione e del funzionamento dell’apparecchiatura (completa di tutti i dispositivi sia base che opzionali); la verifica del caricamento e delle funzionalità del sistema operativo e dei prodotti software installati; la verifica dell’utilizzabilità delle periferiche personali e di rete/gruppo.
Al termine dell’attività dovrà essere redatto dalla Ditta Aggiudicataria e consegnato al Committente un apposito “Verbale di installazione, configurazione, di avvio operativo e verifica funzionalità.
2.2.3.1 Stazioni di lavoro presso le Redazioni
La Ditta Offerente dovrà fornire presso ciascuna delle 9 (nove) Redazioni, elencate nel precedente paragrafo, al minimo la seguente strumentazione:
▪ n.1 personal computer
▪ n.1 stampante individuale
▪ n.1 scanner
Le caratteristiche di tale strumentazione sono definite nei successivi paragrafi.
La Ditta Offerente potrà formulare proposte migliorative, in termini quantitativi e qualitativi, rispetto a quanto indicato.
2.2.3.1.1 Personal computer
Si richiede la fornitura di xxxxxx x. 0 (xxxx) Personal Computer.
Le caratteristiche prestazionali dei Personal Computer da fornire sono state stabilite in funzione del benchmark SYSMARK 2007 Preview, consultabile al sito xxx.xxxxx.xxx, in cui sono riportati i benchmark effettuati dalla “Business Applications Performance Corporation”. L’offerente dovrà obbligatoriamente corredare l’offerta tecnica con una dichiarazione relativa ai test effettuati, per dimostrare la capacità del modello offerto di raggiungere un punteggio minimo di 135 nel citato benchmark.
Su richiesta del Committente, in fase di collaudo, la Ditta Offerente dovrà dimostrare sul campo, rendendo disponibili le necessarie attrezzature (ivi compreso il software SYSmark 2007 se richiesto dalla Commissione di Collaudo), il rispetto dei requisiti prestazionali richiesti e da essa dichiarati.
Il Personal Computer dovrà presentare le seguenti caratteristiche tecniche minime:
▪ Unità Centrale: Microprocessore x86 di ultima generazione;
▪ Case: Midi-Tower;
▪ Memoria RAM: 2Gb espandibile ad almeno 4Gb;
▪ Controller: Serial ATA;
▪ Disco Rigido: 160GB, velocità minima 7200 rpm;
▪ Scheda Grafica: PCI-Express, 256Mb integrati, uscita DVI-I, adattatore DVI-I – VGA;
▪ Interfacce esterne: 4 porte USB 2.0 (di cui almeno due frontali), 1 porta seriale, 1 porta mouse, 1 porta tastiera;
▪ Masterizzatore: Interno DVD±R/±RW dual layer 16x DVD Combo Drive con software per la masterizzazione di ultima versione;
▪ Scheda di rete: Ethernet 10Base-T/100Base-TX/1000Base-T UTP;
▪ Tastiera: Italiana con tasto Euro;
▪ Scheda audio: integrata (con porte Microfono-IN, Line-IN, Headphone/Line-OUT);
▪ Altoparlanti stereo esterni;
▪ Lettore Floppy da 3,5”/1,44 MByte interno;
▪ Mouse: Ottico con rotella di scorrimento;
▪ Sistema operativo: Windows Vista Business Edition, preinstallato nell’ultima versione commercialmente disponibile e configurato con driver per la configurazione fornita - CD e licenza d’uso; il produttore deve garantire la possibilità di downgrade a Windows XP Professional;
▪ Sistema di produttività individuale:
o Microsoft® Office System 2007 Standard Edition in Italiano, preinstallato;
o Adobe Acrobat PDF Writer, preinstallato nell’ultima versione disponibile;
▪ Logo "Windows Vista Capable" sui Personal Computer, al fine di assicurare il funzionamento ottimale delle funzionalità disponibili in tutte le edizioni del sistema operativo Windows Vista Business Edition;
▪ Lettore di smart card, possibilmente interno, compatibile CNS. Per le caratteristiche tecniche si faccia riferimento alla sezione 2.2.4.1.1.
Il Monitor dovrà presentare le seguenti caratteristiche tecniche minime
▪ Tecnologia dello schermo: TFT a matrice attiva
▪ Dimensioni dello schermo: 19 pollici
▪ Luminosità dello schermo: 250 nits
▪ Livello di contrasto: 500:1
▪ Tempo di risposta di aggiornamento: 8 ms
▪ Frequenza di scansione: Frequenza orizzontale: 30-83 kHz, Frequenza verticale: 56-76 Hz
▪ Colori: 16 milioni
▪ Dot Pitch: 0,26 mm
▪ Risoluzione: 1280 x 1024 a 60 HZ (analogico e digitale)
▪ Connettore video: Due connettori: uno VGA analogico mini D-sub da 15 pin e uno DVI
▪ Multimediale: Altoparlanti stereo
▪ Certificazioni: Tco 03, ISO 9241, ISO 13406-2
2.2.3.1.2 Stampanti individuali
Si richiede la fornitura di almeno n.9 (nove) stampanti laser bianco/nero per uso individuale. Ciascuna stampante deve essere collegata al corrispondente Personal Computer fornito. Di seguito sono riportate le caratteristiche tecniche minime che dovranno essere supportate:
▪ Emulazione linguaggio PCL;
▪ Velocità di stampa: fino a 24 ppm;
▪ Ciclo Operativo: fino a 8.000 pagine al mese;
▪ Qualità di stampa: 1.200 x 1.200 dpi;
▪ Interfaccia e connessione: porta USB 2.0;
▪ Gestione dei supporti di stampa: capacità di massima di alimentazione di 250 fogli di tipo X0, X0, X0, X0, xxxxx (X0, XX, X0);
▪ Stampa fronte/retro: di tipo manuale;
▪ Compatibilità con i sistemi operativi: Microsoft® Windows® 2000, XP 32 bit e Vista
2.2.3.1.3 Scanner
Si richiede la fornitura di almeno n.9 (nove) scanner. Ciascuno scanner deve essere collegato al corrispondente Personal Computer fornito. Di seguito sono riportate le caratteristiche tecniche minime che dovranno essere supportate:
▪ Velocità di scansione: fino a 12 ppm;
▪ Risoluzione di scansione: fino a 2.400 x 2.400 dpi;
▪ Produttività giornaliera: fino a 500 pagine;
▪ Presenza di alimentatore automatico di documenti da 50 pagine;
▪ Formato massimo del documento: 21,6 x 35,6 cm;
▪ Interfaccia e connessione: 1 Hi-Speed USB – compatibile con le specifiche USB 2.0;
▪ Compatibilità con i sistemi operativi: Microsoft® Windows® 98, 98 SE, Me, 2000, XP (Professional e Home Edition) e Vista Business Edition; Mac OS X v 10.2 e versioni successive;
▪ Formato dei file Windows®: TIFF, JPEG, GIF, PDF, HTML, RTF.
La fornitura deve comprendere anche il software di gestione della scansione.
2.2.4 Fornitura di Smart Card e lettori
Il sotto-servizio ha l’obiettivo di fornire ed attivare smartcard con caratteristiche tecnico-funzionali di Carta Nazionale di Accesso ai Servizi (CNS) e connessi dispositivi e prodotti software.
La fornitura comprende:
▪ n. 5.000 (cinquemila) CNS aventi le caratteristiche minime di seguito riportate e dotate di certificati di autenticazione e di firma;
▪ n. 5.000 (cinquemila) lettori di CNS aventi le caratteristiche minime di seguito riportate; I sistemi applicativi forniti devono supportare pienamente le CNS ed i relativi lettori.
Il Committente si riserva il diritto di non procedere all’acquisizione di quanto richiesto ovvero di ridurre i quantitativi richiesti che devono pertanto essere assunti come quantitativi massimi.
La fornitura delle CNS e relativi lettori potrà essere richiesta su base singola o a blocchi dal Committente senza limitazioni sul numero minimo richiesto per ciascun blocco.
Per ciascun blocco di richieste il Committente provvederà a fornire le informazioni necessarie per la personalizzazione delle CNS. La consegna delle CNS dovrà avvenire entro un tempo massimo di 30 (trenta) giorni dalla richiesta.
Per la rilevazione delle richieste di CNS, la Ditta Offerente dovrà avvalersi delle specifiche funzionalità di Gestione CNS/lettori del Portale (par. 2.1.1.7). Per il periodo precedente alla disponibilità delle funzionalità, la Ditta Offerente dovrà predisporre un servizio di accettazione di richieste basato su canali alternativi quali fax e/o posta elettronica.
I certificati digitali presenti sulla CNS dovranno essere stati rilasciati da un'Autorità di Certificazione accreditata presso il CNIPA ed avere una validità di non meno di 12 mesi.
2.2.4.1 Requisiti tecnici
La Ditta Offerente dovrà rispettare, nella proposta di fornitura di Smart Card e lettori, quanto definito nei successivi paragrafi.
2.2.4.1.1 Caratteristiche lettori smartcard
Il lettore dovrà essere del tipo ad inserzione, con o senza tastierino numerico, ed avere, al minimo, le caratteristiche di seguito riportate:
▪ Supporto smartcard ISO 7816 Class A,B e C (5V, 3V e 1.8V);
▪ Supporto smartcard standard ISO 7816 1/2/3/4;
▪ Protocolli ISO 7816 supportati: Xx0 x Xx0;
▪ Protezione da Corto Circuito;
▪ Standard di riferimento:
o ISO/IEC 7816-1,2,3,4: IC Cards with contacts;
o PC/SC;
o Microsoft Windows Hardware Quality Labs (WHQL);
▪ Interfaccia verso il PC: USB 2.0 full speed;
▪ Sistemi operativi supportati: Microsoft Windows (2000, XP e Vista) e MacOS X;
▪ Software API da fornire di corredo al lettore: driver PC/SC per ambienti Microsoft Windows e MacOS X; driver di interfacciamento del token hardware PKCS#11.
2.2.4.1.2 Caratteristiche smartcard
Le CNS oggetto della fornitura devono essere conformi alle norme in vigore in tema di Carta Nazionale dei Servizi e di Firma Digitale, si riportano di seguito le principali caratteristiche tecniche che al minimo devono essere rispettate:
▪ conformità a quanto stabilito dal decreto 9/12/2004 “Regole tecniche e di sicurezza relative alle tecnologie e ai materiali utilizzati per la produzione della Carta nazionale dei servizi”;
▪ conformità alle specifiche ISO/IEC 7816 1-2-3-4-8-9-10;
▪ conformità alle specifiche tecniche pubblicate sul sito del CNIPA (specifiche del sistema operativo APDU, struttura del file system, struttura e modalità d’uso del certificato di autenticazione, specifiche inerenti il progetto NetLink);
▪ presenza sulla carta di una memoria EEPROM della capacità non inferiore a 64 KB;
▪ conformità alle specifiche NetLink HPC (carta del professionista). La fornitura di ciascuna CNS deve comprendere:
▪ il certificato digitale per la firma digitale di documenti informatici
▪ la licenza d’uso di prodotto software per l’applicazione della firma digitale a documenti informatici
▪ la licenza d’uso di plug-in in tecnologia Java per l’applicazione della firma digitale a documenti informatici
le cui specifiche sono di seguito riportate.
2.2.4.1.3 Caratteristiche software di firma digitale
Il prodotto software richiesto deve supportare almeno le seguenti caratteristiche:
▪ Operatività in ambiente Microsoft Windows XP, Microsoft Vista e, opzionalmente, Apple MacOS X
▪ Supporto firma digitale conforme allo standard PKCS#7 ed allo standard XML Signature
▪ Firma digitale a valore legale: firma di documento informatico con visualizzazione in chiaro del contenuto del documento da firmare
▪ Firma multipla ovvero applicazione di più firme digitali in una o più delle seguenti forme:
o Firme congiunte (o parallele o indipendenti): una firma di pari livello ad un documento già firmato (senza limitazione al numero di firme)
o Firme innestate (o annidate): una firma di livello superiore ad un documento già firmato (senza limitazione al numero di livelli)
▪ Cifratura: cifratura di un documento informatico utilizzando l’apposito certificato digitale
▪ Decifratura: decifratura di un documento informatico utilizzando l’apposito certificato digitale
▪ Verifica firma digitale: verifica della validità della firma digitale con consultazione delle CRL
2.2.4.1.4 Layout
Per quanto riguarda il layout della carta, si fa presente che le specifiche per la personalizzazione delle CNS, in termini di layout grafico, colori, logo, ecc. saranno oggetto di ulteriore approfondimento da effettuarsi durante la fase esecutiva del contratto in maniera congiunta tra il Committente e la Ditta Aggiudicataria sulla base di una proposta grafica predisposta dalla Ditta Offerente. In ogni caso sulla carta dovranno al minimo essere presenti:
▪ la scritta “Carta Nazionale dei Servizi”;
▪ il logo dell’Amministrazione Pubblica;
▪ il nome, cognome e codice fiscale del Titolare;
▪ eventuali altre informazioni che il Committente riterrà opportuno inserire.
2.2.5 Requisiti tecnici
La Ditta Offerente deve rispettare, nella proposta complessiva di fornitura dell’infrastruttura tecnologica e strumenti per l’erogazione dei servizi i requisiti di seguito definiti.
2.2.5.1 Xxxxxxxx e manutenzione
Si richiede la fornitura del servizio di manutenzione per i prodotti hardware, software di base e di mercato, oggetto della fornitura.
2.2.5.1.1 Prodotti hardware: garanzia e manutenzione
Con riferimento agli eventuali prodotti hardware forniti, la Ditta Offerente deve assicurare un servizio garanzia e manutenzione. Il servizio deve essere erogato dalla Ditta Offerente, attraverso personale specializzato, per tutta la durata del periodo del contratto a partire dalla data di accettazione della fornitura. La manutenzione hardware deve essere erogata in modalità on-site e entro il giorno lavorativo successivo alla segnalazione.
Il servizio di manutenzione ed assistenza si intende comprensivo di tutte le parti di ricambio, nonché di tutte le eventuali unità che dovessero essere impiegate, quali sostituzioni, per la corretta erogazione del servizio stesso.
Il servizio di manutenzione ed assistenza deve essere esteso a tutte le apparecchiature e le componenti opzionali hardware offerte, al sistema operativo, all‘eventuale software di base e al firmware costituenti dette apparecchiature.
La Ditta Offerente deve quindi fornire gratuitamente su richiesta del Committente, gli adeguamenti (patch) rilasciati dal produttore del software (sistema operativo e software di base) nelle versioni dei prodotti installati per tutta la durata del periodo di garanzia.
La Ditta Offerente deve garantire la disponibilità di un numero telefonico/fax di assistenza in grado di acquisire le segnalazioni inerenti gli eventuali problemi e le anomalie rilevate. L’operatività di tale servizio è definita nel paragrafo 2.4.3.
2.2.6 Vincoli
La Ditta Offerente deve rispettare, nella proposta complessiva di fornitura dell’infrastruttura tecnologica e strumenti per l’erogazione dei servizi i seguenti vincoli:
▪ devono essere recepite tutte le specifiche tecniche e gestionali definite in sede nazionale ed in particolare quelle sulla cooperazione applicativa definite e in corso di definizione dal CNIPA o dal Ministro dell’Innovazione Tecnologica.
▪ il sistema, in ogni sua componente essenziale, deve essere scalabile, flessibile, modulare, portabile (nel senso che esso potrà essere replicabile su diverse architetture informatiche) e, per l’effetto, riutilizzabile. Inoltre, occorre prediligere soluzioni non proprietarie basate su standard aperti.
▪ l’integrazione tra la Postazione di Redazione presso le Aziende Sanitarie Pubbliche e la relativa intranet sarà a carico della Ditta Aggiudicataria che deve agire in accordo e sotto le direttive del responsabile informatico dell’Azienda di riferimento e del Committente.
2.2.6.1 Ubicazione e sedi dei Centri Servizio Portale
La Tabella 3 riporta l’ubicazione geografica e la sede che ospiterà le Redazioni e il Centro Servizi Portale. Il Committente si riserva di confermare ovvero di modificare, in fase esecutiva del progetto, l’ubicazione e le sedi.
Ubicazione | Sede | |
Redazione Aziende Sanitarie Locali | Capoluoghi di provincia della regione Puglia | Aziende Sanitarie Locali |
Redazione Azienda Ospedaliera Policlinico | Bari | Azienda Ospedaliera Policlinico |
Redazione Ospedali Riuniti di Foggia | Foggia | Ospedali Riuniti di Foggia |
Redazione Assessorile | Bari | Regione Puglia - Assessorato alle Politiche della Salute |
Centro Servizi Portale | Valenzano | Tecnopolis CSATA |
Tabella 3 - Ubicazione e sedi Centri Servizi Portale Il Centro Servizi Portale della Salute sarà dislocato presso Tecnopolis CSATA.
2.2.7 Livelli di servizi e penali
2.2.7.1 Fornitura, installazione ed attivazione dell’infrastruttura tecnologica del Centro Servizi Portale
2.2.7.1.1 Livelli di servizio
Per il servizio di Fornitura, installazione ed attivazione dell’infrastruttura tecnologica deve essere garantito il rispetto dei seguenti livelli di servizio:
Codice indicatore | Indicatore | Unità di misura | Soglia di accettazione | Modalità di calcolo |
INF.AST | Aderenza alle Specifiche Tecniche (Numero di installazioni collaudate con esito positivo rapportato al numero di installazioni collaudate) | Percentuale | AST ≥ 98% | Rapporto tra il numero di collaudi con esito positivo e il numero di collaudi eseguiti. |
2.2.7.1.2 Penali
Nel seguito sono riportati i parametri per l’applicazione delle penali relative al mancato rispetto dei livelli di servizio definiti nel precedente paragrafo.
Codice indicatore | Indicatore | Penale |
INF.AST | Aderenza alle Specifiche Tecniche | 0,5 % del corrispettivo del sotto-servizio per ogni punto percentuale o frazione, di violazione della soglia prefissata |
2.2.7.2 Fornitura di Smart Card e lettori
2.2.7.2.1 Livelli di servizio
Codice indicatore | Indicatore | Unità di misura | Soglia di accettazione | Modalità di calcolo |
INF.RCNS | Tempo consegna CNS/lettore | Giorno | ≤ 30 | Differenza tra la data di inoltro della richiesta da parte dell’Amministrazione/Committente e la data di consegna da parte della Ditta Aggiudicataria |
2.2.7.2.2 Penali
Nel seguito sono riportati i parametri per l’applicazione delle penali relative al mancato rispetto dei livelli di servizio definiti nel precedente paragrafo.
Codice indicatore | Indicatore | Penale |
INF.RCNS | Tempo invio della CNS/lettore | 0,5 % del corrispettivo del sotto-servizio per ogni giorno o frazione, di ritardo |
2.2.8 Modalità di valorizzazione del corrispettivo e di pagamento
Per il servizio Infrastruttura tecnologica, di elaborazione e comunicazione sono definite le componenti di spesa riportate nella tabella seguente.
Servizio | Modalità di valorizzazione | Modalità di pagamento |
Infrastruttura tecnologica Portale | A corpo | 100% del prezzo del sottoservizio indicato nell’Offerta Economica. |
Stazioni di lavoro | A corpo | 100% del prezzo del sottoservizio indicato nell’Offerta Economica. |
Smart-card (CNS) e lettori per utenza pilota | A misura (secondo le quantità che il Committente comunicherà alla Ditta Aggiudicataria) | 100% del prezzo del sottoservizio indicato nell’Offerta Economica. Il corrispettivo è determinato in funzione del numero reale di CNS e lettori richiesti. |
2.3 Formazione e addestramento
Obiettivo primario del servizio è quello di trasferire la conoscenza degli aspetti organizzativi e delle capacità tecniche e strumentali necessarie per il completo utilizzo delle funzionalità messe a disposizione dal sistema realizzato.
Le necessità di formazione e addestramento riguardano:
▪ tutti gli operatori delle Redazioni
▪ tutti gli operatori del Call Center Informativo Sanitario.
La Ditta Offerente dovrà progettare e realizzare tutte le attività necessarie per rendere gli utenti in grado di:
▪ conoscere le potenzialità e le caratteristiche del Portale
▪ utilizzare tutte le funzionalità del Portale relative al proprio ambito di competenze
▪ attivare le procedure organizzative per fruire dei servizi di assistenza tecnico-applicativa.
2.3.1 Utenti del servizio e tempi di realizzazione
Gli utenti del servizio sono identificati in 1.2.2.2 e 1.2.2.4, ovvero tutti quelli definiti come utenti nella fase esecutiva del progetto.
Il numero di utenti interessato dal servizio è stimato complessivamente in non meno di 120 (centoventi) unità, di cui:
1. circa 80 (ottanta) corrispondenti ad utenti Redattori
2. circa 40 (quaranta) corrispondenti ad utenti Operatori del Call Center Informativo Sanitario
La Ditta Offerente dovrà identificare, in accordo e con l’assistenza del Committente per le parti di competenza specifica, le categorie di utenti destinatarie di ciascun intervento didattico.
A seguito della identificazione di tali categorie, il Committente trasmetterà alla Ditta Aggiudicataria tutte le ulteriori informazioni necessarie per la convocazione degli utenti definiti ed individuati.
In caso di aggiornamenti dovuti a trasferimenti o variazioni di organico, il Committente darà tempestiva comunicazione alla Ditta Aggiudicataria, che dovrà inserire i nuovi utenti nel programma di addestramento.
La formazione e addestramento degli utenti deve essere completato entro e non oltre il ventesimo giorno antecedente la data fissata per l’avvio dell’esercizio del Portale
2.3.2 Modalità di realizzazione del servizio
Il servizio dovrà essere erogato attraverso corsi tradizionali.
Le attività didattiche dovranno essere svolte prioritariamente presso locali, messi a disposizione dalle ASL (ubicati uno per ciascuno dei sei capoluoghi di provincia della Regione Puglia) o dall’Assessorato alle Politiche della Salute.
Sarà onere della Ditta Offerente mettere a disposizione risorse logistiche e tecniche ed eventuali altri servizi, necessari per lo svolgimento delle attività didattiche.
Il Servizio Formazione e Addestramento è articolato nei seguenti sotto-servizi fondamentali:
▪ Progettazione e pianificazione dei percorsi didattici
▪ Predisposizione della documentazione didattica
▪ Predisposizione ambienti ed infrastruttura tecnologica a fini didattici
▪ Erogazione dei contenuti didattici
▪ Valutazione del processo di apprendimento e dei risultati conseguiti.
2.3.2.1 Progettazione e pianificazione dei percorsi didattici
Il sotto-servizio ha l’obiettivo di progettare e pianificare i percorsi didattici ritenuti necessari per l’addestramento dell’utenza. Prima dell'avvio delle attività didattiche, la Ditta Offerente dovrà consegnare al Committente il Programma Didattico, costruito sulla base di quanto già indicato nella Relazione Tecnica, che descriverà:
▪ l’articolazione complessiva delle attività formative
▪ le metodologie formative che si intendono adottare
▪ le risorse logistiche e la strumentazione che si intende utilizzare per la realizzazione delle attività didattiche
▪ le azioni non formative previste con particolare riferimento alla Valutazione
▪ i moduli didattici previsti
Il Programma Didatttico è soggetto ad approvazione da parte del Committente e tale approvazione condiziona l’avvio delle successive attività.
2.3.2.2 Predisposizione delle documentazione didattica
Il sotto-servizio ha l’obiettivo di predisporre tutta la documentazione funzionale all’erogazione dei contenuti didattici.
Il materiale didattico, sotto forma di documentazione cartacea o in formato elettronico, dovrà essere prodotto e reso disponibile al Committente almeno una settimana prima dell'inizio dell'erogazione del modulo didattico a cui si riferisce.
Tutto il materiale prodotto ed utilizzato dovrà essere reso disponibile in formato elettronico all’utenza anche attraverso la sezione del Portale riservata agli utenti di back-office.
2.3.2.3 Predisposizione degli ambienti e dell’infrastruttura tecnologica
Il sotto-servizio ha l’obiettivo di predisporre gli ambienti destinati ad ospitare l’attività didattica con tutto quanto risulti funzionale allo svolgimento delle attività previste e di realizzare l’infrastruttura tecnologica di supporto al servizio di addestramento.
L’infrastruttura tecnologica per l’addestramento comprende almeno:
▪ le attrezzature periferiche, hardware e software, da rendere disponibili e da attivare in tutti i locali destinati all’addestramento.
▪ l’ambiente Portale, hardware e software, a scopo didattico perfettamente identico, dal punto di vista funzionale, a quello in esercizio, ad uso esclusivo del servizio di addestramento. A tale scopo La Ditta Offerente potrà utilizzate l’ambiente di test descritto in 2.2.2.1.
2.3.2.4 Erogazione dei contenuti didattici
Il sotto-servizio realizza l’erogazione dei contenuti didattici sulla base del Programma Didattico facendo uso della documentazione didattica predisposta. I contenuti didattici devono essere erogati tramite corsi tradizionali in aula.
Il sotto-servizio dovrà comunque prevedere:
▪ Composizione delle classi e convocazione dei Partecipanti
▪ Riproduzione e distribuzione della documentazione didattica a ciascun Partecipante
▪ Attività di docenza
▪ Tutoraggio (in aula e/o a distanza)
2.3.2.5 Valutazione
La Ditta Offerente dovrà predisporre al termine delle attività di Formazione e Addestramento un 'Rapporto di Valutazione’ per verificare la corrispondenza di quanto eseguito rispetto al Programma Didattico ed il conseguimento degli obiettivi attesi. Tale rapporto dovrà contenere risultati di sintesi e analitici raccolti attraverso un “Questionario di apprendimento e di gradimento dei partecipanti”. Al completamento di ogni attività, la Ditta Offerente provvederà ad elaborare i questionari compilati trasferendo al Committente sia i questionari compilati che i risultati delle elaborazioni.
A seguito della valutazioni ex post, il Committente potrà richiedere interventi correttivi senza alcun ulteriore costo per il Committente, la Ditta Offerente sarà tenuta a ripetere l'edizione del corso che avrà conseguito un risultato negativo.
Il 'Rapporto di Valutazione’ sarà sottoposto all'approvazione del Committente.
2.3.3 Vincoli operativi
La Ditta Offerente deve formulare una proposta progettuale e successivamente garantirne la realizzazione che assuma e rispetti i seguenti vincoli generali
▪ Il materiale predisposto relativo ai corsi di formazione e addestramento e tutta la documentazione relativa, non dovranno, in alcun modo e in qualsiasi forma, essere comunicati o divulgati a terzi, e non potranno essere utilizzati, da parte della Ditta Offerente o da parte di chiunque collabori alle sue attività, per fini diversi da quelli contrattuali
▪ Tutti i materiali prodotti risulteranno di proprietà del Committente che potrà liberamente utilizzarli senza limitazioni di alcun tipo
▪ La pianificazione degli interventi dovrà tener conto in generale delle esigenze di servizio dei partecipanti. Ogni intervento giornaliero dovrà avere una durata massima di 6 ore, per non più di due giorni lavorativi consecutivi.
▪ Le attività didattiche organizzate e gestite dalla Ditta Offerente dovranno tenere conto delle esigenze, esistenti o eventualmente determinatesi in tempi successivi, di operatività della strumentazione (in relazione ad aggiornamenti e manutenzioni) e di presenza dei partecipanti (in relazione a eventuali periodi di sospensione delle attività lavorative).
▪ Tutto il materiale didattico prodotto ed utilizzato dovrà essere integralmente in lingua italiana
▪ A tutti i partecipanti dovrà essere fornita una quantità adeguata dei supporti informatici eventualmente necessari per le esercitazioni.
▪ I docenti dovranno rendersi disponibili per fornire assistenza integrativa ai partecipanti che la richiedano, per almeno mezz’ora per ogni sessione didattica.
▪ Al termine dell'addestramento, la Ditta Offerente dovrà produrre e consegnare a ciascun partecipante alle attività di addestramento un attestato di partecipazione.
2.3.4 Documentazione
Per il presente servizio è richiesta la consegna formale dei documenti elencati nella seguente tabella.
Documento | Scadenza consegna |
Programma Didattico e Calendario delle Attività | Entro e non oltre il 60-esimo giorno dalla data prevista di avvio delle attività di addestramento |
Copia del Materiale Didattico | 7 gg. prima dell'inizio dell'erogazione del modulo didattico a cui si riferisce |
Rapporto di Valutazione e Questionari di apprendimento e di gradimento | 30 gg. dopo il termine di tutte le attività didattiche |
Il Committente si riserva di chiedere alla Ditta Aggiudicataria la ripetizione degli interventi, a distanza di tempo da definire, al costo indicato in fase di offerta.
2.3.5 Livelli di servizio e penali
2.3.5.1 Livelli di servizio
Il servizio di Formazione deve essere garantito secondo i seguenti livelli di servizio:
Codice indicatore | Indicatore | Unità di misura | Soglia di accettazione | Modalità di calcolo |
ADD.RIT | Puntualità nella erogazione delle attività corsuali (Giorni di ritardo rispetto alla data di termine programmata) | Giorno | δ2 | Massimo valore misurato della differenza tra la data di effettivo termine delle attività didattiche di ciascun corso e la data programmata indicata nel Programma Didattico |
ADD.SQC | Qualità del corso rispetto a: - materiale didattico - docenza - organizzazione | Grado di soddisfazione degli allievi rilevato al termine del percorso didattico attraverso la somministrazione di un questionario di gradimento | > 75% | Minimo valore della percentuale di risposte positive (di valore uguale o superiore a 3 in una scala da 1 a 4) calcolata su tutte le risposte fornite nell'ambito di ciascun corso. |
ADD.SOD | Efficacia dell'azione didattica | Numero di ripetizioni di corso | δ2 | Massimo valore misurato delle edizioni di corsi ripetute in conseguenza di un livello insufficiente di gradimento da parte degli allievi. |
2.3.5.2 Penali
Nel seguito sono riportati i parametri per l’applicazione delle penali relative al mancato rispetto dei livelli di servizio definiti nel precedente paragrafo.
Codice Indicatore | Indicatore | Penale |
ADD.RIT | Puntualità nella erogazione delle attività corsuali | 1000 Euro per ogni giorno in più rispetto alla soglia fissata |
ADD.SQC | Qualità del corso rispetto a: - materiale didattico – docenza - organizzazione | 500 Euro per ogni punto in riduzione rispetto alla soglia fissata |
ADD.SOD | Efficacia dell'azione didattica | 1000 Euro per ogni corso oltre la soglia fissata |
2.3.6 Modalità di valorizzazione del corrispettivo e di pagamento
Per il servizio Formazione e addestramento sono definite le componenti di spesa riportate nella tabella seguente.
Servizio | Modalità di valorizzazione | Modalità di pagamento |
Formazione e addestramento | A corpo | 100% del valore del servizio indicato nell’Offerta Economica. Il corrispettivo è riconosciuto a seguito dell’approvazione del Rapporto di Valutazione |
2.4 Servizio di assistenza tecnico-applicativa e conduzione operativa
Il servizio consiste nel supporto tecnico da offrire:
▪ alle Redazioni, agli Addetti del Call Center Informativo Sanitario nello svolgimento di tutte le attività tecniche ed operative della fase di erogazione dei servizi del Portale;
▪ ai Cittadini coinvolti nella sperimentazione CNS (circa 5000) per l’accesso ai servizi;
▪ al Committente per il monitoraggio della fase di esercizio del Portale. Si articola nei seguenti servizi:
▪ Progettazione esecutiva
▪ Allestimento del Contact Center Portale
▪ Assistenza tecnico-applicativa
▪ Conduzione operativa
▪ Controllo dei livelli di servizio
▪ Misura della Customer Satisfaction.
2.4.1 Progettazione esecutiva
Il sotto-servizio ha l’obiettivo di realizzare, sulla base della proposta predisposta in fase di Offerta Tecnica, la progettazione esecutiva del servizio di assistenza tecnico-applicativa e conduzione operativa comprensiva anche degli aspetti organizzativi e delle procedure operative dello stesso. La Ditta Offerente si obbliga a recepire le osservazioni formulate dalla Stazione Appaltante in relazione sia alla proposta di Servizio formulata in sede di Offerta Tecnica che alla progettazione esecutiva realizzata.
2.4.2 Allestimento del Contact Center Portale
Il servizio ha l’obiettivo di predisporre l’intera infrastruttura tecnologica di supporto all’erogazione del servizio di
Contact Center Portale e di definire le procedure operative dello stesso.
L’attività del Contact Center Portale deve essere supportato da una soluzione applicativa basata su tecnologia Internet e fruibile via browser Internet, che consenta la gestione delle attività di competenza dei vari soggetti coinvolti (operatori del Contact Center, eventualmente Help Desk di secondo livello).
La soluzione applicativa deve essere integrata nel Portale ed essere fruibile, oltre che dal personale della Ditta Offerente addetto al Contact Center Portale, con le necessarie autorizzazioni e restrizioni funzionali, anche da:
▪ Redazioni Portale, operatori del Call Center Informativo Sanitario, cittadini coinvolti nella sperimentazione con CNS: a titolo esemplificativo, l’utente redattore deve poter sottomettere una richiesta di assistenza con contestuale apertura del ticket; verificare lo stato di avanzamento della lavorazione di una richiesta e delle azioni intraprese; ricercare i ticket di propria competenza che soddisfano un criterio; elencare le richieste sottomesse; sottomettere un sollecito; riaprire un ticket relativo ad una richiesta ritenuta non chiusa; certificare la chiusura di un ticket
▪ personale individuato dal Committente: per monitorare l’attività del Contact Center, esportare tutti i dati relativi ai ticket (le modalità tecniche saranno determinate in fase di progettazione esecutiva) almeno su supporto di memorizzazione locale alla stazione di lavoro dell’utente, produrre report periodici.
Il servizio realizza il punto unico di raccolta e gestione delle richieste di assistenza e segnalazione di malfunzionamenti relativi ai servizi di assistenza tecnico-applicativa, conduzione operativa.
2.4.2.1 Modalità di accesso al servizio
Il servizio Contact Center Portale deve essere accessibile da parte dei Redattori del Portale, degli addetti del Call Center Informativo Sanitario e dei Cittadini coinvolti nella sperimentazione (Cittadini ai quali sarà distribuita la CNS/lettore). Il servizio deve supportare almeno le seguenti modalità di accesso:
▪ Accesso tramite servizio telefonico: deve essere predisposto un unico numero telefonico, con costo della chiamata a carico del chiamante
▪ Accesso tramite applicazione basata su web: deve essere predisposta una specifica applicazione per gestire la richiesta con apertura diretta dell’intervento da parte dell’utente. L’accesso all’applicazione deve essere basata sulle stesse credenziali utilizzate dall’utente per accedere al Portale.
Il servizio telefonico deve essere disponibile per non meno di otto ore giornaliere esclusi il sabato e i giorni festivi, l’accesso tramite applicazione basata su web deve essere disponibili in modalità H24, tutti i giorni dell’anno.
La modalità di accesso tramite servizio telefonico, quando non assistita dalla presenza di personale, deve prevedere la disponibilità e l’operatività della segreteria telefonica.
2.4.2.2 Fasi della richiesta di assistenza
La richiesta di assistenza sarà caratterizzata al minimo dalle seguenti fasi:
▪ Apertura Ticket: rappresenta la presa in carico della richiesta, l’operatore registra tutte le informazioni.
▪ Assegnazione gravità e priorità: l’operatore analizza la richiesta ed assegna il livello di gravità (impatto sull’utenza pubblica del Portale) e priorità (in base al livello di limitazione del servizio ed ai carichi di lavoro in corso). Durante il contratto, i criteri di definizione dei livelli di gravità e priorità potranno essere rivalutati ed adattati sulla base di esigenze specifiche del Committente, senza alcun onere aggiuntivo, ovvero proposti dalla Ditta Offerente al Committente per l’approvazione preventiva alla modifica di quanto sopra riportato.
▪ Chiusura del ticket: corrisponde al completamento della risposta attesa dall’utente (ad es., fornitura di informazioni, soluzione di un problema). Per ciascuna richiesta che ha determinato l’intervento di soggetti terzi rispetto agli addetti all’accoglimento della richiesta, entro 5 (cinque) giorni solari dalla soluzione del problema, l’addetto al Servizio deve verificare, con l’utente che ha avviato la richiesta di assistenza, l’efficacia dell’intervento eseguito raccogliendo anche eventuali segnalazioni sulla qualità dell’assistenza. La verifica dell’efficacia dell’intervento corrisponde alla chiusura del ticket.
2.4.2.3 Xxxxxx e orari del servizio
Il servizio deve essere operativo dal primo giorno dell’entrata in esercizio del Portale e deve essere disponibile fino alla data di conclusione del contratto.
Il servizio deve essere disponibile nelle seguenti modalità:
presidiata con presenza di personale: nei giorni lavorativi e secondo l’orario di servizio tipico degli operatori delle strutture coinvolte (8.00 – 17.00 dei giorni lavorativi)
non presidiata senza presenza di personale: nei giorni non lavorativi ovvero nelle fasce orarie diverse per le quali non è prevista la modalità presidiata.
La Ditta Offerente si obbliga a variare, su richiesta e senza alcun onere economico aggiuntivo, l’articolazione dell’orario di servizio fermo restando la quantità totale di ore settimanali per il servizio presidiato.
2.4.3 Assistenza tecnico-applicativa
Alla Ditta Offerente è richiesto un servizio di assistenza tecnico-applicativa per:
▪ fornire tutte le informazioni necessarie agli utenti Redattori e Addetti del Call Center Informativo per l’efficace utilizzo delle funzionalità e delle potenzialità del Portale durante la fase di esercizio del Portale;
▪ risolvere le anomalie di funzionamento che impediscono o limitano l’utilizzo del Portale, avvalendosi del servizio di Manutenzione Correttiva e Adeguativa;
▪ rilevare le nuove esigenze (tecniche, funzionali ed organizzative) a partire dalle richieste sottomesse dalle utenze.
Il personale impegnato nel Servizio deve avere, ad integrazione delle necessarie conoscenze tecniche e di dominio, specifica attitudine per:
▪ guidare l’utente nell’utilizzo di servizi che fanno uso sempre più frequente di tecnologie diversificate opportunamente integrate
▪ analizzare le anomalie di funzionamento segnalate, interagendo e coordinandosi con gli altri soggetti responsabili delle infrastrutture tecnologiche (ad es., responsabile dei sistemi informativi aziendali), e provvedere alla risoluzione del problema ed al ripristino delle corrette funzionalità.
Per la realizzazione delle attività previste, la Ditta Offerente si avvarrà del servizio di Contact Center Portale.
La Ditta Offerente deve rispettare, nella proposta di progettazione e nella realizzazione del servizio i requisiti tecnici definiti nei successivi paragrafi.
2.4.3.1 Gestione tecnico-organizzativa del servizio
Il sotto-servizio ha l’obiettivo di gestire e manutenere, rispetto alle evoluzioni che il Servizio potrà assumere nel corso della durata del contratto, l’infrastruttura tecnologica e le procedure operative funzionali alla realizzazione del servizio.
2.4.3.2 Gestione delle richieste
Il sotto-servizio ha l’obiettivo di accogliere la richiesta di assistenza e le segnalazioni di malfunzionamenti sia applicativi che infrastrutturali e fornire una risposta risolutiva alla stessa.
La richiesta, intercettata dal Contact Center Portale, deve essere analizzata dal personale addetto che fornirà una adeguata risposta avvalendosi delle opportune professionalità sia interne che esterne, con eventuali interventi sul campo da parte del personale addetto a tale tipologia di attività. Le principali responsabilità dell’addetto alla gestione delle richieste di assistenza sono le seguenti:
▪ provvedere all’accoglimento ed alla registrazione delle richieste di assistenza
▪ fornire una prima od una completa risposta alla richiesta
▪ fornire informazioni sull’utilizzo dei sistemi applicativi e sulle procedure organizzative ed operative relative ai servizi offerti (Assistenza consulenziale)
▪ scalare e trasferire la gestione della richiesta al servizio di Assistenza Tecnica/Manutenzione ove la risoluzione esuli dalle possibilità risolutive del Contact Center per competenza o per strumenti
▪ mantenere la gestione della richiesta, anche quando la stessa superi i confini di responsabilità diretta del Servizio Assistenza, per controllarne l’avanzamento, garantirne la tempestiva e efficace risoluzione e verificarne gli esiti
▪ riportare all’utente lo stato di avanzamento della richiesta.
Le richieste di assistenza tecnica comprendono anche quelle riferite alle stazioni di lavoro, oggetto di fornitura nell’ambito dell’appalto, di diretto uso da parte del personale delle Redazioni del Portale.
2.4.3.3 Assistenza operativa
Il sotto-servizio ha l’obiettivo di realizzare tutte le attività, tipicamente di natura applicativa, necessarie per garantire dopo l’avvio in esercizio e per l’intera durata contrattuale, la piena fruibilità del servizio Portale. A titolo non esaustivo, rientrano in tale ambito
▪ l’aggiornamento di basi informative tecniche (ad es., aggiornamento delle CRL associate all’utilizzo delle smartcard);
▪ La traduzione nelle lingue previste (inglese, albanese, arabo, rumeno) dei contenuti informativi rivolti agli stranieri e gli eventuali aggiornamenti. La Ditta Aggiudicataria deve prevedere un servizio di traduzioni che sarà svolto parte durante la fase di start-up del progetto (popolamento iniziale delle basi informative del Portale), parte durante la fase di sperimentazione del Portale.
2.4.3.4 Assistenza consulenziale
Il sotto-servizio ha l’obiettivo di realizzare assistenza consulenziale in relazione alle attività della Redazione per l’intera durata contrattuale per:
▪ attività redazionali svolte direttamente dalle Redazioni mediante strumenti di Content management realizzati dalla Ditta Aggiudicataria;
▪ organizzazione e classificazione dei contenuti nell’ambito della struttura di navigazione del Portale mediante gli strumenti di Content Management;
▪ gestione di cicli operativi per l’aggiornamento e l’approvazione dei contenuti;
▪ pubblicazione dei contenuti (anche multimediali);
▪ formulazione proposte per il miglioramento dei contenuti del Portale;
Per questo sotto-servizio, la Ditta Offerente dovrà assicurare non meno di 100 giornate di consulenza, da parte di personale specializzato.
La Ditta Offerente si impegna e si obbliga a fornire lo stesso sotto-servizio ad altre strutture (ad es., strutture sanitarie private accreditate), previa autorizzazione da parte del Committente, alle stesse condizioni economiche indicate nell’Offerta Economica e con oneri economici a carico della struttura richiedente.
2.4.3.5 Produzione report
La Ditta Aggiudicataria dovrà produrre trimestralmente (entro il 15 del mese successivo al trimestre di riferimento) Report Trimestrale di Assistenza tecnico-applicativa nel quale saranno riportati il numero di richieste di assistenza/segnalazioni pervenute al minimo classificate in:
▪ richieste di assistenza consulenziale
▪ interventi di assistenza operativa
▪ segnalazioni di malfunzionamenti (risolti dall’operatore di Contact Center Portale, che hanno generato la richiesta di interventi di manutezione del software correttiva/adeguativa del sistema applicativo Portale, ecc.). In particolare per i malfunzionanamenti che generano interventi di manutenzione, il Report Trimestrale di Assistenza tecnico-applicativa dovrà riportare al minimo i seguenti indicatori:
• Numero di interventi di manutenzione totali, differenziati per pianificabili e non, suddivisi tra: richiesti nel mese (nuovi interventi), chiusi nel mese e residui a fine mese
• Numero totale di interventi di manutenzione, differenziati per pianificabili e non, richiesti e chiusi, suddivisi per tipologia di problema
• Numero totale di interventi di manutenzione chiusi, suddivisi per tipologia di problema riscontrato
• Tempo medio di completamento di un intervento di manutenzione, per tipologia di intervento
• Tempo medio di completamento di un intervento di manutenzione per tipologia di intervento Il Report Trimestrale di Assistenza tecnico-applicativa dovrà essere prodotto formato elettronico (MS Word).
2.4.4 Conduzione Operativa
Alla Ditta Offerente è richiesto un servizio di Conduzione Operativa per:
▪ assicurare la piena operatività, utilizzabilità e governo dei sistemi applicativi e delle infrastrutture tecnologiche;
▪ assicurare la sicurezza complessiva dei dati nel rispetto dei livelli di servizio minimi individuati.
Essa comprende l’insieme dei servizi e delle attività relative alla conduzione dei sistemi in esercizio (sia applicazioni sia sistemi infrastrutturali) nonché alla supervisione e monitoraggio dell’infrastruttura tecnologica e di tutte le loro evoluzioni nel corso di durata del contratto.
Oltre a ciò è inclusa nel servizio la fornitura di tutto il materiale consumabile e EDP necessario allo svolgimento delle prestazioni della Ditta Aggiudicataria con esclusione della carta funzionale alla produzione dei rapporti.
La Conduzione operativa è articolata nei seguenti sottoservizi fondamentali:
1. Predisposizione, mantenimento e gestione tecnico-organizzativa del servizio
2. Gestione Operativa dell’infrastruttura del Portale
2.4.4.1 Predisposizione, mantenimento e gestione tecnico-organizzativa del servizio
Il sotto-servizio ha l’obiettivo di predisporre e manutenere, rispetto alle evoluzioni che il servizio potrà assumere nel corso della durata del contratto, le procedure operative funzionali alla realizzazione del servizio.
Le procedure operative saranno soggette ad accettazione tecnica da parte del Committente.
2.4.4.2 Gestione Operativa dell’infrastruttura del Portale
Il sotto-servizio ha l’obiettivo di garantire la totale operatività dei sistemi e delle applicazioni costituenti il Portale attraverso la pianificazione e la gestione operativa di tutte le attività tecnico-sistemistiche sui sistemi gestiti volte ad assicurare la completa disponibilità ed operatività degli stessi (esercizio, test e collaudo, sistemi di monitoraggio e gestione). La Ditta Aggiudicataria dovrà svolgere:
▪ pianificazione ed esecuzione delle attività tecnico-sistemistiche sui sistemi oggetto di fornitura (amministrazione sistemi, gestione configurazioni, parametrizzazioni, gestione schedulazione, ecc.);
▪ controllo della corretta disponibilità e funzionalità operativa dei sistemi (sia hardware sia software);
▪ attivazione e gestione degli interventi conseguenti a ripianificazioni e/o malfunzionamenti;
▪ tuning dei sistemi e delle basi dati (tuning DBMS) finalizzato all’ottimizzazione delle prestazioni;
▪ predisposizione dell’ambiente di test;
▪ esecuzione dei cambiamenti di configurazione degli elementi infrastrutturali;
▪ attivazione procedure di problem management in caso di problemi.
2.4.4.2.1 Monitoraggio e Gestione Problemi
L’attività di Monitoraggio e Gestione Problemi è relativa a tutte le azioni di monitoraggio e risoluzione dei malfunzionamenti rilevati (sia in termini di infrastruttura che di software di base) del Portale, nell’ottica di garantire costantemente il corretto funzionamento dei servizi erogati.
Obiettivo dell’attività è:
▪ monitorare il funzionamento dei sistemi forniti e dei relativi servizi applicativi mediante un sistema automatizzato di system-network management (paragrafo 2.2.2.1.4) che consenta di analizzare e produrre adeguata reportistica di sintesi a partire dai dati di dettaglio, raccolti dal sistema stesso, sulle transazioni Web eseguite dai singoli utenti del Portale allo scopo di fornire una valutazione esatta del tempo di risposta dell’applicazione, correlata ad una stima del tempo di risposta percepito dall’utilizzatore, per tutte le transazioni del Portale
▪ rilevare qualsiasi condizione di malfunzionamento dei sistemi gestiti sia in ottica correttiva sia preventiva: ai fini del presente servizio di gestione operativa, con il termine “malfunzionamento” si intendono sia problemi ed eventi che rendono non fruibili i servizi erogati agli utenti sia degradi di prestazione.
Le tipologie di problemi gestiti dall’attività di Monitoraggio e Gestione Problemi possono essere sia relativi a malfunzionamenti sui sistemi gestiti (quindi rilevati in autonomia dalla Ditta Aggiudicataria mediante il sistema di system-network management oppure attraverso altri canali di comunicazione direttamente attivati dalle redazioni del Portale) sia a condizioni operative tali da non costituire nell’immediato un blocco o degrado delle funzioni dei sistemi ma comunque tali da causare malfunzionamenti in futuro.
A fronte di ogni malfunzionamento rilevato, la Ditta Aggiudicataria dovrà attivare tutti gli interventi necessari a garantire la rimozione delle cause che hanno generato il malfunzionamento del sistema. La Ditta Aggiudicataria dovrà svolgere gli interventi di risoluzione dei malfunzionamenti, registrando le informazioni relative all’evento e certificandone la conclusione, come definito nel paragrafo 2.4.3.2.
A fronte delle modifiche effettuate sulla configurazione del Portale, successivamente alle attività di risoluzione di malfunzionamenti rilevati, la Ditta Aggiudicataria dovrà aggiornare la documentazione di riferimento.
Inoltre, la Ditta Aggiudicataria, per rendere congruenti i dati forniti dovrà prevedere l’implementazione di una infrastruttura NTP che detti l’orario di riferimento a tutti gli apparati del Portale monitorati, avvalendosi del servizio NTP erogato sulla rete RUPAR dal Centro Tecnico Regionale.
2.4.4.2.2 Amministrazione database
Le attività di amministrazione Database riguardano lo svolgimento di attività di gestione e di amministrazione delle basi dati del Portale. Le attività di amministrazione dei database comprendono:
▪ installazione e upgrade dei prodotti software che implementano database;
▪ configurazione ed amministrazione di database;
▪ riorganizzazioni e parametrizzazioni di dati;
▪ analisi di occupazione spazio ed interventi di tuning;
▪ configurazione dei parametri relativi alle repliche;
▪ manutenzione preventiva e correttiva.
La Ditta Aggiudicataria è responsabile delle attività di:
▪ Pianificazione delle attività inerenti upgrade ed installazione/modifiche sulle componenti software;
▪ Valutazione delle modifiche sull’organizzazione dei dati ed esecuzione delle stesse nei tempi concordati e nel rispetto del piano.
2.4.4.2.3 Gestione Software
Le attività di gestione software sono relative all’esecuzione degli interventi di installazione e configurazione del software (applicativo e di base) del Portale. Queste vengono svolte sia su base preventiva sia correttiva.
La Ditta Aggiudicataria dovrà predisporre, formalizzare ed applicare adeguate procedure operative per la gestione dei rilasci in esercizio delle applicazioni e delle relative modifiche. In particolare dovrà essere assicurato che ogni rilascio in esercizio avvenga secondo procedure che ne garantiscano un adeguato controllo e validazione.
Le attività di gestione software vengono svolte preventivamente sulla base delle evoluzioni del sistema gestito (es. rilascio nuovi prodotti software, upgrade prodotti, ecc.) nonché su base correttiva in relazione alle segnalazioni del sistema di monitoraggio e controllo ovvero su richiesta delle redazioni del Portale ove non già rilevato il problema autonomamente dalla Ditta Aggiudicataria.
Le attività costituenti sono le seguenti:
▪ Pianificazione interventi di gestione software;
▪ Rilevazione segnalazioni di malfunzionamento;
▪ Attivazione interventi di gestione software (sia preventivi che correttivi).
▪ Monitoraggio, supervisione e affiancamento degli interventi di gestione software (sia preventiva che correttiva).
▪ .Esecuzione intervento;
▪ Registrazione e chiusura intervento;
▪ Reporting periodico.
La Ditta Aggiudicataria dovrà garantire durante tutto il periodo della conduzione operativa del Portale definito nel contratto che il software di base e di ambiente (S.O., database, middleware ecc.) installato sui sistemi serventi sia in manutenzione dalla casa produttrice.
2.4.4.2.4 Backup e restore
Le attività previste sono relative alla pianificazione e all’esecuzione delle attività di backup e restore. La Ditta Aggiudicataria definisce le Procedure di Backup e Restore in conformità alle politiche di sicurezza e continuità operative del Portale, nonché nel rispetto della normativa vigente in merito alla gestione e conservazione dei dati, con particolare riferimento ai dati gestiti ed al periodo di conservazione degli stessi.
Per le operazioni di backup, le Procedure di Backup e Restore definite dalla Ditta Aggiudicataria dovranno garantire:
▪ La presenza di tutte le informazioni necessarie ad effettuare le attività di backup del Portale, da parte della Ditta Aggiudicataria, per quanto attiene l’esecuzione del salvataggio, archiviazione e gestione dei supporti contenenti le procedure ed i dati salvati;
▪ La separazione del backup di archivi e applicazioni
▪ La modalità di “backup a caldo” per tutti quei servizi per i quali non è prevista l’interruzione.
▪ La gestione dei supporti specificando il periodo di retention, il ciclo di rinnovamento e riutilizzo.
▪ La minimizzazione di periodi di degrado prestazionale dovuto alla concorrenza del backup. In ogni caso le “finestre di backup” predisposte durante il periodo di minore attività delle applicazioni.
▪ Il ripristino dei dati a non più di 24 ore precedenti la loro perdita, ovvero deve essere sempre disponibile una copia di backup dei dati risalente al massimo alle 24 ore precedenti la loro perdita.
▪ La sicurezza dei supporti specificando il luogo dove depositarli, la loro identificazione e i cicli di rotazione
Le funzioni di restore incluse nelle procedure definite dalla Ditta Aggiudicataria all’interno delle Procedure di Backup e Restore dovranno prevedere le modalità operative per:
▪ individuazione del supporto con ultimo salvataggio completo;
▪ individuazione dell’eventuale supporto con l’ultimo salvataggio incrementale;
▪ individuazione dei supporti con i salvataggi dei file successivi al salvataggio completo o a quello incrementale e comunque immediatamente precedente alla situazione che ha causato la richiesta di ripristino;
▪ ripristino e verifica del buon esito della esecuzione di ripristino.
Le operazioni di ripristino non dovranno superare le 24 ore dal momento della richiesta da parte del richiedente. Periodicamente, devono essere previste delle prove di restore per verificarne la corretta efficacia.
Per le prove di ripristino potrà essere utilizzato, se ritenuto necessario, il Sistema di Pre-esercizio previsto per il Centro Servizi Portale. In ogni caso nel report periodico andrà evidenziata l’esecuzione e l’esito positivo delle prove di restore.
.La Ditta Aggiudicataria recepirà le ulteriori indicazioni che potranno essere fornite del Committente in sede di definizione ovvero di approvazione delle Procedure di backup e restore.
2.4.4.2.5 Gestione della sicurezza
Sono a carico della Ditta Offerente tutte le attività e adempimenti, ivi inclusa la redazione del Documento Programmatico di Sicurezza (DPS), inerenti la completa rispondenza del Portale ai dettami del codice in materia di protezione dei dati personali emanato con DLGS n°196/03.
Alla Ditta Offerente è richiesto un servizio di Gestione della Sicurezza che realizzi e gestisca le contromisure di tipo tecnologico volte alla difesa perimetrale e di contenuto del sistema informativo. La gestione della sicurezza ha lo scopo di:
▪ valutare e gestire il rischio associato alle minacce di tipo informatico;
▪ acquisire strumenti tecnologici e competenze in grado di affrontare e risolvere rapidamente ed efficacemente eventuali incidenti di sicurezza.
La Gestione della sicurezza si concretizza attraverso la realizzazione e la gestione dei seguenti servizi:
▪ Servizio di content security: il servizio provvede ad una gestione efficace delle contromisure atte a contrastare la diffusione dei codici malevoli, quali virus o worm su sistemi sia client (postazione di redazione) sia server. Il servizio prevede anche la gestione sistemistica e la manutenzione dei componenti utilizzati.
▪ Servizio security host hardening: il servizio provvede alla definizione, manutenzione e controllo delle politiche di configurazione e di aggiornamento dei sistemi server rilevanti per l’Amministrazione, in termini di sistema operativo e applicazioni di base.
Le principali attività che caratterizzano la Gestione della Sicurezza, comuni a tutti i tipi di servizi offerti, possono essere riassunte in:
▪ Monitoraggio degli eventi significativi per la sicurezza, evidenziati durante l’erogazione del servizio;
▪ Gestione delle emergenze attraverso l’uso efficace degli strumenti adottati per l’erogazione del servizio;
▪ Aggiornamento delle componenti critiche per il servizio.
2.4.4.3 Produzione report
La Ditta Aggiudicataria dovrà produrre trimestralmente (entro il 15 del mese successivo al trimestre di riferimento) Report Trimestrale di Monitoraggio Sistemi nel quale saranno riportati:
▪ disponibilità mensile sistemi (minuti di disponibilità erogati nel mese e minuti di disponibilità totali previsti nel mese per ogni sistema gestito);
▪ il numero di malfunzionamenti per tipologia rilevati nel mese;
▪ il numero di malfunzionamenti per tipologie chiusi nel mese;
▪ il dettaglio di ogni malfunzionamento chiuso nel mese, ed in particolare:
a) ID del malfunzionamento;
b) Tipologia del malfunzionamento (preventivo/correttivo);
c) Sistemi e applicazioni impattate;
d) Data/ora di rilevazione;
e) Data/ora di risoluzione del malfunzionamento (chiusura tecnica);
f) Data/ora di certificazione della risoluzione del malfunzionamento da parte della Ditta Aggiudicataria (chiusura amministrativa);
g) Tutte le azioni effettuate dalla Ditta Aggiudicataria;
▪ gli interventi di installazione e configurazione del software (applicativo e di base) del Portale
▪ Il numero di backup effettuati nel mese. Per ogni backup dovranno essere esplicitate almeno le informazioni circa tipologia del backup, dati salvati, data/ora pianificata per il backup, data/ora dell’inizio del backup, data/ora termine del backup;
▪ Il numero di restore effettuati nel mese. Per ogni restore dovranno essere esplicitate almeno le informazioni circa tipologia del restore, dati ripristinati, richiedente, data/ora pianificata per il restore, data/ora dell’inizio del restore, data/ora termine del restore.
Il Report dovrà essere prodotto formato elettronico (MS Word).
2.4.4.4 Vincoli operativi
Nelle attività del servizio di Conduzione Operativa, la Ditta Aggiudicataria è tenuta a rispettare i seguenti vincoli:
2.4.4.4.1 Disponibilità del Portale
Il servizio Portale deve essere operativo e fruibile da parte dell’utenza in modalità H24 tutti i giorni dell’anno. La Ditta Aggiudicataria è integralmente responsabile della disponibilità dei servizi erogati agli utenti per il tramite del Portale nel rispetto dei livelli di servizio. Allo scopo è tenuto a svolgere tutte le attività di pianificazione e coordinamento degli interventi sui sistemi gestiti (ivi incluso il capacity planning di tutte le risorse elaborative necessarie) in modo da garantire il costante allineamento tra le risorse informatiche e le esigenze degli utenti.
2.4.4.4.2 Continuità operativa per gli utenti
Le attività di gestione operativa vengono svolte senza arrecare discontinuità operativa ai servizi erogati agli utenti: gli interventi che possono creare interruzione dei servizi erogati agli utenti e che non potessero essere effettuati al di fuori dell’orario di disponibilità dei servizi erogati agli utenti, dovranno essere preventivamente concordati con il Committente e comunicati alla stessa con preavviso di almeno una settimana (per eventi non pianificati).
2.4.5 Controllo dei livelli di servizio
Alla Ditta Offerente è richiesto un servizio di Controllo dei Livelli di Servizio che include tutte le attività finalizzate alla misura e alla rendicontazione degli indicatori per il controllo della qualità dei servizi erogati.
Il servizio deve essere erogato mediante l’utilizzo di un sistema per la gestione delle misure, se possibile basato sull’utilizzo di strumenti automatici, in grado di offrire una comune metodologia per la raccolta dati, l’elaborazione, aggregazione, conservazione e produzione di reportistica. Le caratteristiche degli strumenti, riguardo le modalità di raccolta ed elaborazione delle misure vanno definite insieme alle misure stesse. Il sistema automatizzato che ne deriva deve essere in grado di soddisfare i seguenti obiettivi:
▪ ridurre/eliminare l’operatività manuale nelle fasi di raccolta, elaborazione e rendicontazione dei dati statistici;
▪ ridurre la probabilità di errore insita negli interventi manuali;
▪ ridurre/eliminare i possibili punti di “manipolazione” dei dati, per aumentare la trasparenza nei confronti dell’utente;
▪ standardizzare la modalità di conservazione dei dati di dettaglio o di sintesi;
▪ far coincidere, laddove possibile, gli strumenti di raccolta dati con quelli per il monitoring dei sistemi;
▪ disporre di una base dati statistica che possa fornire informazioni su dati pregressi;
▪ fornire una verifica diretta dei dati di rendicontazione con accesso diretto da parte degli utenti;
▪ consentire un’analisi delle variazioni delle grandezze significative;
▪ rendere disponibili i dati statistici e di rendicontazione su specifica richiesta del Committente. Le funzionalità necessarie per il sistema di Controllo dei Livelli di Servizio sono le seguenti:
1. acquisizione dei dati di dettaglio necessari alla determinazione dei livelli di servizio;
2. raccolta, aggregazione e normalizzazione dei dati di dettaglio, eventualmente provenienti da fonti diverse, e determinazione dei valori dei livelli di servizio con riferimento alla finestra temporale di osservazione;
3. gestione delle soglie se queste possono variare nel corso del tempo;
4. produzione di dati aggregati secondo viste differenti, in funzione dei diversi utenti del sistema.
Al sistema di gestione deve consentire la pubblicazione dei dati nel Portale, in grado di assicurare le seguenti funzionalità di base:
1. presentazione dei dati su pagine del Portale secondo viste definite;
2. produzione di report
La Ditta Aggiudicataria dovrà produrre trimestralmente (entro il 15 del mese successivo al trimestre di riferimento) Report Trimestrale di Controllo dei Livelli di Servizio nel quale saranno riportati tutti i dati necessari alla verifica del rispetto o della violazione dei livelli di servizio stabiliti.
2.4.6 Misura della Customer Satisfaction.
Alla Ditta Offerente è richiesto un servizio di Misura della Customer Satisfaction. La Ditta Offerente deve rendere disponibili funzioni di supporto al monitoraggio e all’analisi dell’uso dei servizi del Portale per i Comitati Guida e le Redazioni. Tali funzioni dovranno essere fruibili tramite pagine ad accesso controllato del Portale. Devono essere previsti al minimo i servizi di Monitoraggio Utilizzazione Servizi, Monitoraggio dei servizi richiesti dal cittadino e della Citizen Satisfaction e Produzione report, descritti nei successivi paragrafi.
▪ Monitoraggio Utilizzazione Servizi: Il servizio deve fornire ai Comitati Guida e alle Redazioni le indicazioni circa l’utilizzo dei servizi del Portale da parte dei cittadini. L’analisi dei servizi, per tipologia di ‘segmento utente’, è orientata a fornire il riscontro in termini di quantità e di modalità di utilizzo dei servizi stessi. Deve essere consentito sia il monitoraggio dell’uso dei servizi interattivi che dei servizi informativi. Il servizio deve consentire la produzione di report automatici. La Ditta Offerente deve formulare una proposta progettuale e successivamente garantirne la realizzazione rispetto agli indicatori che adotterà per la realizzazione del servizio.
▪ Monitoraggio dei servizi richiesti dal cittadino e della Citizen Satisfaction: Il servizio deve fornire ai Comitati Guida e alle Redazioni elementi di valutazione utili a comprendere le esigenze del cittadino, basandosi sull’analisi statistica delle richieste ricevute, al fine di migliorare la propria strategia nei riguardi del cittadino. L’indagine può interessare tutti i servizi richiesti, sia quelli erogati che quelli inesistenti (rilevabili tramite sondaggi, questionari), con particolare orientamento alla singola tipologia di ‘segmento utente’. Le informazioni fornite devono essere ricavate dalle informazioni acquisite attraverso questionari atti a valutare anche la soddisfazione del cittadino rispetto ai servizi erogati. Il servizio deve consentire, tramite la produzione di report automatici, il monitoraggio dei dati sui servizi richiesti dai cittadini. La Ditta Offerente deve formulare una proposta progettuale e successivamente garantirne la realizzazione rispetto agli indicatori che adotterà per la realizzazione del servizio.
▪ Produzione report Il servizio corrisponde alla fornitura ai Comitati Guida e alle Redazioni di informazioni, elementari o correlate, ecc. che interessano i servizi e gli oggetti considerati dai servizi di Monitoraggio
sull’utilizzo del sistema. Il servizio potrà fornire le informazioni richieste dal personale autorizzato, su stampa o a video. Il servizio deve consentire la produzione di report personalizzati, corrispondenti alle esigenze specifiche dell’operatore o dell’ente a cui sono destinati. L’operatore deve poter selezionare liberamente le misure (indicatori numerici) e le dimensioni di analisi relative ai cittadini ed ai servizi per incrociare differenti informazioni o analizzare i dati a differenti livelli di aggregazione.
La Ditta Aggiudicataria dovrà produrre semestralmente (entro il 15 del mese successivo al semestre di riferimento) Report Semestrale di Customer Satisfaction nel quale saranno riportati dati di sintesi del servizio.
2.4.7 Livelli di servizio e penali
2.4.7.1 Assistenza tecnico-applicativa
2.4.7.1.1 Livelli di Servizio
Il servizio di Assistenza tecnico-applicativa deve essere garantita secondo i seguenti livelli di servizio:.
Codice Indicatore | Indicatore | Unità di misura | Soglia di accettazione | Modalità di calcolo |
SATA.NCTLCT | Numero di contatti avvenuti entro un tempo limite attraverso il canale telefonico. | Percentuale | NCTLCT >= 90% | NCTLCT = (Conta(TRi ≤ TRmax)/N)*100 Ove: Tri= differenza tra il tempo inizio della risposta ed il tempo di arrivo della chiamata i-esima N=Numero complessivo chiamate con risposta TRmax=limite di soglia per la risposta assunto pari a 120 secondi |
La misura è determinata come la percentuale di risposte avvenute, nel periodo di riferimento, entro un certo tempo limite. | ||||
(Per tutte le chiamate nel periodo di osservazione si misura il ritardo (differenza) tra il tempo di arrivo della chiamata e il tempo di inizio della risposta.) | ||||
SATA.TS1C | Tempestività della soluzione al primo contatto per richieste | Percentuale | TS1C ≥ 90,0% | TS1C = (Conta(Data.giorno(Dc) = Data.giorno(Da))/N)*100 Ove: Dc=Data/ora di chiusura tecnica della Richiesta Da=Data/ora di presa in carico della Richiesta N=Numero complessivo richieste nel mese |
(L’indicatore misura l’efficienza nel rispondere completamente alla richiesta al primo contatto. | ||||
Per richiesta risolta al primo contatto si intende una richiesta la cui data di |
apertura e data di chiusura ticket rientrano nello stesso giorno lavorativo. La misura dell’indicatore è data dal numero di richieste la cui chiusura tecnica avviene nello stesso giorno lavorativo di presa in carico della chiamata.) |
2.4.7.1.2 Penali
Nel seguito sono riportati i parametri per l’applicazione delle penali relative al mancato rispetto dei livelli di servizio definiti nel precedente paragrafo.
Codice Indicatore | Indicatore | Penale |
SATA. NCTLCT | Numero di contatti avvenuti entro un tempo limite attraverso il canale telefonico | 1% del canone mensile del servizio per ogni punto percentuale, o frazione, di scostamento dal valore di soglia |
SATA.TS1C | Tempestività della soluzione al primo contatto per richieste | 1% del canone mensile del servizio per ogni punto percentuale, o frazione, di scostamento dal valore di soglia |
2.4.7.2 Conduzione operativa
2.4.7.2.1 Livelli di Servizio
Il servizio di Conduzione operativa deve essere garantita secondo i seguenti livelli di servizio:
XXX.XX - Disponibilità sistemi | Disponibilità percentuale mensile | 99,8% | (Disponibilità richiesta - tempo di manutenzione schedulato - minuti fuori servizio) x 100 / (Disponibilità richiesta - tempo di manutenzione schedulato) dove: Disponibilità richiesta: minuti del mese calcolati in base alle richieste di disponibilità del sistema concordate con il Committente e riportate nelle rendicontazioni dei LdS specifici Tempo di manutenzione schedulato: minuti di non servizio a seguito di manutenzione concordata con il Committente Minuti fuori servizio: somma dei minuti di indisponibilità di tutto o parte del sistema indipendentemente dalla causa dell’indisponibilità (indisponibilità del server, malfunzionamento applicativo, |
ecc.). Tale indisponibilità dovrà essere rilevata mediante monitoraggio remoto di tutte le funzioni applicative o dei servizi infrastrutturali erogati agli utenti (ad es. attraverso il software di system/network managment). L’assenza di registrazioni per qualsiasi causa è assimilata all’indisponibilità dell’apparato. Il calcolo della indisponibilità deve essere effettuato al netto delle indisponibilità dovute all’hardware (rete, ecc….) messo a disposizione da terze parti fuori dal controllo della Ditta Aggiudicataria. Il calcolo dovrà essere effettuato su base mensile. Il calcolo del LdS deve essere effettuato per ogni sistema (applicazione o sistema infrastrutturale) approssimato al millesimo di punto percentuale (terza cifra dopo la virgola): il valore così risultante deve essere approssimato per difetto alla seconda cifra dopo la virgola (es: 99,989% diventa 99,98%, mentre 99,994% diventa 99,99%) | |||
INF.TIMS - Tempo di Intervento malfunzionamenti sistemi | Minuti | 10 | Tempo intercorrente tra la rilevazione del malfunzionamento e l’attivazione dell’intervento da parte della Ditta Aggiudicataria |
INF.TMRMS - Tempo massimo di risoluzione malfunzionamenti sistemi | Minuti | 60 | Tempo massimo intercorrente tra la rilevazione del malfunzionamento e la risoluzione del problema (solo per malfunzionamenti di pertinenza della Ditta Aggiudicataria) |
2.4.7.2.2 Penali
Nel seguito sono riportati i parametri per l’applicazione delle penali relative al mancato rispetto dei livelli di servizio definiti nel precedente paragrafo.
XXX.XX | Disponibilità sistemi | 0,1% dell’importo mensile del servizio in cui si è verificato il mancato rispetto del LdS per ogni decimo di punto percentuale o frazione di scostamento dalla soglia prevista; tale penale si applica alla somma degli scostamenti di tutti i sistemi cui si applica il presente LdS |
INF.TIMS | Tempo di Intervento malfunzionamenti sistemi | 0,01% dell’importo mensile del servizio in cui si è verificato il mancato rispetto del LdS per ogni minuto o frazione di scostamento dalla soglia prevista; tale penale si applica alla somma degli scostamenti di tutti i sistemi cui si applica il presente LdS |
INF.TMRMS | Tempo massimo di risoluzione malfunzionamenti sistemi | 0,01% dell’importo mensile del servizio in cui si è verificato il mancato rispetto del LdS per ogni |
minuto o frazione di scostamento dalla soglia prevista; tale penale si applica alla somma degli scostamenti di tutti i sistemi cui si applica il presente LdS | ||
INF.MCD | Mancata Consegna di Documentazione ovvero la consegna di documenti aventi contenuti non conformi a quelli minimi indicati | € 1000 per ogni documento non consegnato o avente contenuti non conformi a quelli minimi indicati |
2.4.8 Modalità di valorizzazione del corrispettivo e di pagamento
Per il servizio sono definite le componenti di spesa riportate nella tabella seguente.
Servizio | Modalità di valorizzazione | Modalità di pagamento |
Progettazione esecutiva Allestimento del Contact Center Portale | A corpo | 100% del prezzo del sottoservizio indicato nell’Offerta Economica. |
Gestione operativa (Assistenza tecnico- applicativa, Conduzione operativa, Controllo dei livelli di servizio, Misura della Customer Satisfaction) | A misura | 100% del prezzo di riferimento del sotto-servizio. Il prezzo di riferimento del sotto-servizio è calcolato rapportando il prezzo indicato nell’Offerta Economica al periodo temporale complessivo, espresso in mesi, di reale erogazione del servizio sulla base della seguente formula: |
PrezzoMensile*NMesiEsercizio | ||
Ove: | ||
PrezzoMensile Prezzo mensile del sotto-servizio indicato nell’Offerta Economica | ||
NMesiEsercizio Durata in mesi, arrotondato per eccesso all’intero successivo, di esercizio del N-SISR. | ||
Il prezzo di riferimento del sotto-servizio non può superare il valore totale indicato nell’Offerta Economica. | ||
Il corrispettivo dovuto per il sotto-servizio è erogato in canoni mensili posticipati a partire da quello successivo alla data di entrata in esercizio del Portale. |
2.5 Piano di comunicazione integrato e connessi servizi di attuazione
Il servizio di definizione del Piano di comunicazione integrato e dei connessi servizi di attuazione, deve essere finalizzato a:
▪ informare i potenziali beneficiari finali, i soggetti destinatari degli interventi, le autorità locali, le altre autorità pubbliche competenti, le organizzazioni professionali, le parti sociali, le associazione dei cittadini, sulle possibilità offerte dal progetto Portale della Salute.
▪ promuovere l’iniziativa a livello nazionale, al fine di fornire un chiaro inquadramento del progetto all’interno delle iniziative per lo sviluppo della società dell’informazione
▪ promuovere l’iniziativa a livello regionale, al fine di generare conoscenza ed interesse degli operatori della Sanità e dei cittadini della Regione Puglia.
▪ assicurare una capillare promozione del Portale in tutto il Web, con la registrazione del Portale sui Motori di Ricerca, monitorando continuamente la sua posizione secondo le parole chiave scelte.
2.5.1 Obiettivi
Il progetto di realizzazione del Portale deve essere supportato da una adeguata attività di comunicazione, rivolta sia ai destinatari “interni” del progetto (le redazioni e, più in generale, tutti coloro che per posizione e competenze possono contribuire, direttamente o indirettamente, al successo del progetto), sia ai destinatari “esterni”, ossia il pubblico indistinto, costituito da tutti i cittadini residenti nel territorio regionale, principali beneficiari dei risultati del progetto.
Verso i primi, la finalità sarà soprattutto quella di ottenerne il pieno coinvolgimento e la fattiva collaborazione; verso i secondi, la finalità sarà quella di rendere nota l’esistenza dello strumento e farne comprendere i vantaggi che dal suo uso ne possono derivare.
Per i destinatari interni sono previste giornate informative, incontri di lavoro, comunicazioni attraverso circolari, comunicazioni attraverso la posta elettronica, mentre per i destinatari esterni la comunicazione potrà essere realizzata attraverso incontri di presentazione con la stampa, manchette pubblicitarie su giornali a diffusione regionale e locale, spot pubblicitari su emittenti televisive regionali e locali, affissioni per strada e nei punti di aggregazione degli utenti del servizio sanitario (centri prenotazione, casse ticket, poliambulatori, studi medici,…).
L’attività di comunicazione sarà svolta secondo un Piano di Comunicazione che, prodotto all’inizio del progetto, deve definire nel dettaglio:
▪ lo scenario iniziale
▪ gli obiettivi
▪ il target
▪ la strategia
▪ gli strumenti
▪ i tempi e le risorse
▪ il monitoraggio.
Nella definizione del piano si deve ovviamente tenere conto della politica di comunicazione dell’ente regione.
Particolare attenzione sarà riservata alla verifica dei risultati (il monitoraggio), che avrà l’obiettivo di valutare se l’attività di comunicazione ha raggiunto il target e se il pubblico di riferimento ha compreso il messaggio trasmesso e ha modificato, di conseguenza, il suo comportamento.
Poiché il Portale stesso è uno strumento di comunicazione, la sua organizzazione grafica ed ai suoi contenuti devono essere coerenti con quanto previsto dal Piano di Comunicazione.
2.5.2 Attori coinvolti e destinatari
La realizzazione del Portale prevede la creazione di un sistema integrato di informazioni e di servizi in ambito sanitario per la Regione Puglia.
In questo progetto l’Assessorato alle Politiche della Salute, le ASL della Regione, gli operatori del Call Center Informativo Sanitario sono attori del processo, mentre i cittadini e le associazioni di utenti sono i destinatari dei servizi.
I soggetti pubblici coinvolti nell’iniziativa sono:
▪ Assessorato alle Politiche della Salute, ARES, OER Puglia;
▪ Assessorato alla Trasparenza e alla Cittadinanza attiva;
▪ Il Settore Comunicazione Istituzionale della Regione Puglia
▪ Direzioni generali delle Aziende Sanitarie pubbliche regionali e relativi Uffici Relazioni con il Pubblico (in modo particolare le direzioni delle Aziende Sanitarie Locali e delle Aziende Ospedaliere)
▪ Il Call Center Informativo Sanitario della Regione Puglia I soggetti privati che potranno usufruire dei servizi sono:
▪ I cittadini
▪ Le associazioni di cittadini
In base a tali segmenti potranno essere sviluppati obiettivi specifici da perseguire, il piano dei mezzi, delle azioni e degli strumenti di informazione e di comunicazione, diversificato per ciascuno dei target identificati, in modo da ottenere la massima efficacia a fronte della politica di comunicazione adottata.
2.5.3 Le azioni
In base ai target di utenza e agli obiettivi di comunicazione, riportati nei paragrafi precedenti, la Ditta Offerente deve individuare gli obiettivi operativi, il pubblico di riferimento, le modalità e gli stili di contatto, gli strumenti ed i mezzi di comunicazione più idonei.
La strategia di comunicazione deve tener conto dei destinatari a cui la campagna o azione si rivolge e delle modalità di comunicazione più adeguate al raggiungimento degli scopi prefissati.
Il piano di comunicazione integrata proposto deve, in ogni caso, prevedere almeno le seguenti azioni:
Azioni | Strumenti Proposti | Scopo | |
1 | Creazione dell’immagine coordinata di progetto | Ideazione e creazione di un marchio/logo declinabile su tutti i mezzi previsti | Identificazione dell’immagine distintiva del Progetto / Servizio |
2 | Lancio dell’iniziativa | Organizzazione di eventi per il lancio dell’iniziativa, redazione e diffusione di annunci, comunicati stampa, informative digitali su mezzi di comunicazione di massa (periodici, giornali, TV, Radio, …) nazionali e locali e su mezzi di comunicazione on-line (siti Web, portali, newsletter, posta elettronica,…) | In questa fase è importante raggiungere innanzitutto gli opinion maker e le PA coinvolte per attivare più ampi canali di diffusione dell’informazione. |
3 | Coinvolgimento del pubblico di riferimento | Organizzazione di incontri dimostrativi con i destinatari dei servizi o loro rappresentanze (almeno 6 eventi) Il servizio richiesto consiste nella organizzazione logistica (sede, dotata delle attrezzature necessarie), messa a disposizione di personale per l’organizzazione e l’accoglienza, produzione e distribuzione di materiali, comunicazione e diffusione dell’evento attraverso i media, produzione degli atti del seminario. Il seminario dovrà essere organizzato nei 6 capoluoghi di provincia della Regione Puglia, con riferimento ad una partecipazione di n. 80/100 persone, in siti che | In questa fase è necessario raggiungere un pubblico più vasto e in particolare, i cittadini e le diverse associazioni di cittadini. |
Azioni | Strumenti Proposti | Scopo | |
prevedano parcheggio e facili collegamenti. | |||
4 | Fornire un quadro d’insieme dei servizi offerti | Ideazione, produzione e consegna/diffusione di materiale pubblicitario atto a dare informazioni dettagliate sui servizi resi, sulle modalità di accesso e sui vantaggi attesi. | L’azione è orientata a veicolare informazioni di dettaglio che possano essere trattenute, assimilate ed elaborate dal destinatario. Si pensa a documentazione scritta (in forma cartacea e digitale) in forma di pieghovole, scheda informativa, ecc., da rendere disponibili in luoghi (e siti WEB) frequentati dai potenziali utenti (studi medici, strutture sanitarie, ecc). |
Tabella 4 – Azioni del Piano di comunicazione integrata
In fase di qualificazione sarà necessario presentare una proposta di Piano di Comunicazione con:
▪ Una prima analisi di scenario
▪ L’individuazione degli obiettivi di comunicazione
▪ L’individuazione degli utenti di riferimento
▪ Le scelte strategiche (ipotesi ed alternative)
▪ Le scelte di contenuto (ipotesi ed alternative)
▪ L’individuazione e la pianificazione di massima delle azioni e degli strumenti di comunicazione individuati
▪ Le scelte sulle metodologie di misurazione dei risultati che si intendono adottare.
Nella fase successiva si procederà ad implementare il Piano di Comunicazione proposto, definendo in dettaglio i singoli prodotti / servizi da fornire e tutte le azioni di supporto necessarie al raggiungimento degli obiettivi.
Nella fase finale del progetto è attesa una specifica azione di monitoraggio dell’intero piano che ne verifichi l’effettiva efficacia (rassegna stampa, rassegna dei servizi TV, ecc) e fornisca dati obiettivi sulla diffusione dell’informazione e sul riscontro da parte dei soggetti coinvolti dei vantaggi offerti dal progetto (questionari, interviste telefoniche, faccia a faccia)
La fornitura comprende, oltre alla progettazione e realizzazione dei materiali informativi, la completa gestione operativa di tutte le azioni previste dal piano, ivi inclusi i costi di attuazione di tutte le azioni proposte direttamente dalla Ditta Offerente.
2.5.3.1 Modalità di esecuzione dei servizi
Alla stipula del contratto, la Ditta Offerente deve presentare i curricula nominativi dei professionisti che saranno coinvolti e nominare un Referente di Fornitura Comunicazione come coordinatore di tutti i servizi oggetto della fornitura.
Il Referente di Fornitura Comunicazione deve assumere la piena responsabilità del team di lavoro per quanto riguarda il personale della Ditta Offerente, delle attività svolte e deve gestire i rapporti e coordinarsi con il Responsabile del Progetto designato dal Committente.
Fin dall’avvio e per tutta la durata della fornitura, il Ditta Offerente deve avvalersi esclusivamente di proprio personale altamente qualificato, dotato delle professionalità richieste, i cui curricula siano allegati all’offerta tecnica come richiesto nel presente capitolato.
I servizi richiesti devono essere erogati da professionisti con attitudine al lavoro di gruppo, elevata capacità relazionali, facilità di comunicazione, capacità di gestione degli utenti e delle risorse umane.
Le eventuali sostituzioni di personale durante l’esecuzione della fornitura devono essere preventivamente concordate con il Committente, dietro presentazione e approvazione dei curricula, fermo restando la necessità di un adeguato periodo di affiancamento per la risorsa entrante, il cui costo sarà interamente a carico del Ditta Aggiudicataria.
Data l’elevata dinamicità del contesto in cui si opera, è comunque richiesto al Ditta Offerente un elevato grado di flessibilità nell’allocazione delle risorse e la capacità di far fronte ad improvvisi picchi di lavoro.
2.5.3.2 Gestione della fornitura
L’esecuzione e il controllo della fornitura deve avvenire con un’attività di continua pianificazione e monitoraggio di cui il Piano di Lavoro è lo strumento di riferimento.
In particolare, il Piano di Lavoro predisposto dal Ditta Offerente deve contenere:
▪ La pianificazione tenendo conto dei punti di controllo, ovvero le date in cui devono essere consegnati e valutati i prodotti finiti previsti nel presente capitolato e devono essere verificate le attività svolte
▪ L’individuazione e la quantificazione delle risorse necessarie ed i profili professionali che devono essere coinvolti per lo svolgimento delle attività.
L’iter di massima previsto per l’esecuzione della fornitura è il seguente:
Punto di Controllo | Descrizione | Mese (indicativo) |
0 | Inizio delle attività della fornitura | 0 |
I | Piano di lavoro dettagliato Entro 30 (trenta) gg solari dall’inizio del contratto, la Ditta Aggiudicataria deve presentare il Piano di Comunicazione. Entro 20 (venti) gg solari dalla consegna, il Committente valuterà il piano e fornirà eventuali indicazioni di modifica e/o integrazione di quanto prodotto. Entro 20 (venti) gg la Ditta Aggiudicataria deve riformulare, se necessario, i piani esecutivi tenendo conto delle indicazioni specificate. | 2 |
II | Completamento dell’azione 1 del Piano di Comunicazione | 5 |
III | Completamento dell’ azione 2 del Piano di Comunicazione, Produzione materiale di comunicazione per il grande pubblico(azione 4) | 8 |
IV | Completamento delle azioni 3 e 4 del Piano di Comunicazione | 9 |
V | Chiusura delle attività operative e consegna della documentazione relativa alla valutazione dei risultati del Piano di comunicazione | 15 |
2.5.3.3 Modalità di consegna e standard di progetto
Per la documentazione la modalità di consegna è su CD ed in formato cartaceo, accompagnati da lettera di consegna. Ogni CD deve essere accompagnato anche dal documento indice della consegna.
Il Committente si riserva di definire diverse modalità di consegna della documentazione, anche accedendo per via telematica ad apposite applicazioni rese disponibili dalla Ditta Aggiudicataria o via web.
Gli eventuali rilievi sui documenti saranno comunicati dal Committente in forma scritta, assegnando il tempo previsto per effettuare le correzioni. La Ditta Aggiudicataria sarà tenuto ad aggiornare i documenti senza oneri aggiuntivi per il Committente.
L’approvazione dei documenti rappresenta l’accettazione degli stessi. La documentazione prodotta in esecuzione della fornitura deve essere compatibile con i seguenti strumenti:
▪ MS Project
▪ MS Word
▪ MS Excel
▪ MS Power Point
▪ MS Access
L’utilizzo di qualsiasi altro strumento deve essere preventivamente concordato tra le parti.
2.5.3.4 Proprietà dei risultati
Tutti i risultati di progetto, oggetto della fornitura, sono di esclusiva proprietà del Committente.
2.5.4 Livelli di servizio e penali
2.5.4.1 Livelli di servizio
Il livello qualitativo dei servizi erogati nell’ambito del piano di comunicazione e informazione sono definiti in funzione dei seguenti paramentri:
▪ numero di contatti generati per ciascuna azione e scostamento rispetto alle previsioni:
▪ numero di interventi (eventi, pubblicazione brochure, ecc.) realizzati rispetto alla pianificazione definita nel piano di comunicazione;
▪ rispetto dei tempi
La tabella seguente riporta i Livelli di Servizio minimi richiesti per le prestazioni
Codice Indicatore | Indicatore | Unità di misura | Soglia accettazione | di | Modalità di calcolo | ||
COM.NDC | Numero di contatti | Percentuale | > 10% | Minimo valore percentuale di scostamento tra il numero totale di contatti previsti e il numero totale di contatti effettivi (contatti TV, radio, cartellonistica, web) | |||
COM.NPE | Numero partecipanti evento | di | Percentuale | > 5% | Minimo valore percentuale di scostamento tra il numero di partecipanti previsti e il numero di partecipanti effettivi | ||
COM.PRA | Puntualità realizzazione attività | nella delle | Giorni di rispetto pianificazione temportale | ritardo alla | > 10 | Differenza tra la data di avvio prevista e la data di avvio effettiva in giorni lavorativi | |
2.5.4.2 Penali
Nella tabella seguente sono riportati i parametri per l'applicazione delle penali relative al mancato rispetto dei livelli di servizio definiti nel precedente paragrafo.
Codice Indicatore | Indicatore | Penale |
COM.NDC | Numero di contatti | 10% = 3% di penale sull’importo contrattualizzato 20 % = 5% di penale sull’importo contrattualizzato 30% = 10% di penale sull’importo contrattualizzato |
COM.NPE | Numero di partecipanti evento | 5% = 3% di penale sull’importo contrattualizzato 10 % = 5% di penale sull’importo contrattualizzato |
20% = 10% di penale sull’importo contrattualizzato | ||
COM.PRA | Puntualità nella realizzazione delle attività | 10 giorni = 2% di penale sull’importo contrattualizzato 20 giorni = 4% di penale sull’importo contrattualizzato 30 giorni = 6% di penale sull’importo contrattualizzato |
2.5.5 Modalità di valorizzazione del corrispettivo e di pagamento
Per il servizio sono definite le componenti di spesa riportate nella tabella seguente.
Servizio | Modalità di valorizzazione | Modalità di pagamento |
Piano di comunicazione integrato e connessi servizi di attuazione | A corpo | 100% del prezzo del sottoservizio indicato nell’Offerta Economica. |
3 Tempi della fornitura
Di seguito sono riportati i tempi essenziali e mandatori che la Ditta Offerente deve rispettare nella predisposizione della propria offerta.
Fase di progettazione e realizzazione:
A) Entro 4° mesi dalla contrattualizzazione (T1) devono essere state completate e collaudate con esito positivo tutte le attività funzionali e necessarie per l’avvio del servizio Portale (Fase A) le principali delle quali comprendono:
▪ progettazione esecutiva di ciascun servizio oggetto della fornitura;
▪ realizzazione della infrastruttura tecnologica;
▪ realizzazione del Sistema applicativo per la parte di servizi informativi e di gestione del Portale;
▪ addestramento dell’utenza all’utilizzo dei servizi amministrativi e redazionali del Portale.
B) Entro il 7° mese dalla contrattualizzazione (T2) devono essere state completate e collaudate con esito positivo tutte le attività funzionali e necessarie per l’avvio del servizio Portale (Fase B) le principali delle quali comprendono:
▪ realizzazione del Sistema applicativo per l’erogazione dei servizi interattivi.
Fase di esercizio:
C) Dall’8° mese dalla contrattualizzazione e per 12 mesi:
▪ Conduzione operativa del Portale e della connessa Assistenza Tecnica-Applicativa, nonché del previsto Servizio di Manutenzione software.
D) Entro il 9° mese dalla contrattualizzazione:
▪ Completamento delle azioni 1, 2, 3 e 4 del Piano di Comunicazione (Tabella 4 – Azioni del Piano di comunicazione integrata)
E) Entro il 15° mese dalla contrattualizzazione:
▪ Chiusura delle attività operative e consegna della documentazione relativa alla valutazione dei risultati del Piano di comunicazione
F) Dal 18° mese dalla contrattualizzazione e per 2 mesi:
▪ eventuale trasferimento delle competenze e dei beni al nuovo Fornitore alla conclusione del contratto, nei tempi e nelle modalità indicate nell’offerta tecnica formulata.
Servizi | Fase di progettazione e realizzazione | |
(Sottofase A) Scadenza T1 | (Sottofase B) Scadenza T2 | |
Servizi informativi e di download modulistica | ● | |
Servizi informativi mediante Televisione Digitale Terrestre | ● | |
Servizi per la partecipazione | ● | |
Servizi interattivi | ● | |
Servizi per amministratori/redattori del Portale | ● | |
Tabella 5 - Fasi di rilascio del Portale
Il Committente si riserva di modificare i tempi e le modalità di esecuzione descritte, anche in corso d’opera, dandone congruo preavviso alla Ditta Aggiudicataria. In aggiunta, tali modalità di esecuzione potranno essere congiuntamente riviste, su proposta della Ditta Aggiudicataria, e potranno essere concordate opportune variazioni in funzione delle specificità dei singoli interventi.
4 Informazioni generali sulla fornitura
4.1 Sedi di lavoro
Le attività lavorative, oltre che presso le sedi della Ditta Offerente, devono essere svolte prevalentemente sul territorio della Regione Puglia ed in particolare presso:
▪ le sedi delle aziende sanitarie pubbliche e strutture equiparate
▪ la sede dell’Assessorato alle Politiche della Salute della regione Puglia
▪ la sede dell’ARES Puglia (Agenzia Regionale Sanitaria della Regione Puglia)
▪ la sede di Tecnopolis CSATA S.c.r.l. xxxxxx xxxxxxxxxxx xxx Xxxxxxxxxxx xx. 0, Xxxxxxxxx (Xxxx)
La Ditta Offerente si obbliga a partecipare inoltre, senza ulteriori oneri aggiuntivi, ad incontri di lavoro relativi a problematiche riguardanti il Portale che potranno aver luogo presso le sedi di terze parti ubicate sul territorio nazionale.
4.2 Relazione Tecnica e Piano di Progetto
La Ditta Offerente deve descrivere il piano di realizzazione del progetto attraverso la predisposizione della Relazione Tecnica i cui contenuti sono indicati nel documento “Offerta tecnica”.
Questa Relazione Tecnica sarà successivamente dettagliata dall’Offerente nei tempi e con la modalità di seguito indicate e costituirà il Piano di Progetto. Tale Piano di Progetto assume il ruolo di strumento di riferimento per la successiva esecuzione ed il monitoraggio delle attività previste.
Nel Piano di Progetto sono identificate le attività da svolgere con indicazione delle metriche utilizzate per la valutazione delle attività, i tempi previsti, i deliverables, le milestones, ecc. Sono da ritenersi parte integrante del Piano di Progetto tutti i riferimenti a documenti connessi alla lavorazione delle attività del progetto.
Il Piano di Progetto sarà costituito secondo la seguente procedura:
1) entro 15 giorni solari dalla firma del contratto, la Ditta Aggiudicataria presenta alla Stazione Appaltante il Piano di Progetto;
2) entro i successivi 7 giorni solari, la Stazione Appaltante approva o non approva il Piano di Progetto, comunicando contestualmente le proprie osservazioni; la Stazione Appaltante può convocare la Ditta Aggiudicataria per la presentazione e discussione del Piano di Progetto.
3) In caso di non approvazione la Ditta Aggiudicataria deve riformulare il Piano di progetto entro 7 giorni solari dalla comunicazione di non approvazione, integrando le eventuali osservazioni formulate.
Il Piano di progetto potrà essere rivisto, in maniera concordata tra Stazione Appaltante e Ditta Aggiudicataria su richiesta di una delle parti, durante l’intera durata del contratto in funzione delle esigenze progettuali.
4.3 Progetto esecutivo
A valle della contrattualizzazione e nei tempi e con le modalità indicate nel Piano di Progetto, la Ditta Aggiudicataria si obbliga a predisporre il progetto esecutivo complessivo che contenga almeno le progettazioni esecutive, comprensive anche degli eventuali aspetti organizzativi e procedure operative, di quanto di seguito indicato:
▪ Infrastruttura Tecnologica
▪ Sistema Applicativo Portale
▪ Servizio Formazione e Addestramento
▪ Servizio Assistenza tecnica-applicativa e Conduzione operativa
▪ Piano di Comunicazione
La Ditta Aggiudicataria si obbliga a recepire le osservazioni formulate dalla Stazione Appaltante in relazione sia alle proposte dei servizi formulate in sede di Offerta Tecnica che alle progettazioni esecutive realizzate.
4.4 Rilascio prodotti
I prodotti risultanti dalla lavorazione delle attività del progetto saranno sottoposti a consegna e/o approvazione da parte dalla Stazione Appaltante.
I termini utilizzati sono da intendersi come segue:
▪ Consegna: processo formale di rilascio da parte della Ditta Aggiudicataria alla Stazione Appaltante di un prodotto
▪ Approvazione: processo formale di verifica e validazione da parte della Stazione Appaltante di un prodotto rilasciato dalla Ditta Aggiudicataria. Nell’Approvazione del prototipo di Progetto grafico e della mappa del Portale, il Committente potrà essere affiancato da un Gruppo di Lavoro regionale con competenze nel campo della Comunicazione Pubblica
Di seguito è riportata la lista non esaustiva dei prodotti soggetti a consegna ed approvazione.
Prodotto | Approvazione | Consegna |
Piano di Progetto, comprensivo dello Stato Avanzamento Lavori e della rendicontazione attività | ● | |
Piano di qualità | ● | |
Piano dei test | ● | |
Specifiche dei test e relativi risultati eseguiti nel ciclo di vita del software dalla Ditta Aggiudicataria | ● | |
Progettazione esecutiva | ● | |
Documento dei Requisiti comprensivo anche dell’analisi di processo | ● | |
Documento di Architettura del Software | ● | |
Documento di Disegno del Software (comprendente il Dizionario dei dati ed il Modello dei dati) | ● | |
Codice sorgente | ● | |
Codice di test | ● | |
Prototipo del progetto grafico e mappa del Portale | ● | |
Manuale utente (Redattore e Amministratore) | ● | |
Piano della formazione (Programma didattico, Calendario delle Attività, Questionario di apprendimento e di gradimento) | ● | |
Contenuti informativi per l’attività di addestramento | ● | |
Rapporto di valutazione attività di formazione e addestramento | ● | |
Report Trimestrale di Assistenza tecnico-applicativa | ● | |
Report Trimestrale di Monitoraggio Sistemi | ● | |
Report Trimestrale di Controllo dei Livelli di Servizio | ● | |
Report Semestrale di Customer Satisfaction | ● | |
Rapporto di fine lavoro | ● |
4.5 Collaudo
Il collaudo ha il fine di verificare la rispondenza complessiva e in esercizio di tutte le attrezzature e soluzioni applicative realizzate rispetto a quanto riportato nelle prescrizioni del Capitolato Tecnico, nella Relazione Tecnica, nel Piano di Progetto e nei documenti prodotti nella realizzazione e a quanto via via consegnato ed approvato.
Il collaudo del Sistema o del componente consegnato verrà avviato da una Commissione di Collaudo, in contraddittorio con la Ditta Aggiudicataria, entro (20 venti) giorni solari dalla consegna della documentazione relativa o del “Rapporto di Lavoro” e a seguito dell‘invio della comunicazione di “pronti al collaudo“ da parte della Stazione Appaltante. Delle operazioni di collaudo verrà redatto apposito verbale. Il collaudo si intende positivamente superato solo se il Sistema (o la componente oggetto del collaudo) risulta funzionare correttamente e rispecchia tutte le caratteristiche richieste, sia nelle sue singole parti sia nella sua complessità, secondo le specifiche indicate nel Capitolato Tecnico, nell’offerta Tecnica e nella documentazione tecnica e d'uso fornita dalla Ditta Aggiudicataria. Nel caso di collaudo positivo, la data del verbale verrà considerata quale “Data di Accettazione”, da parte della Stazione Appaltante. Questo procedimento di collaudo e accettazione è applicato a tutte le consegne di componenti e, al termine delle attività, all’intero Sistema.
Nel caso di esito negativo del collaudo, la Ditta Aggiudicataria dovrà eliminare i vizi accertati entro il termine massimo di 30 (trenta) giorni solari. In tale ipotesi il collaudo verrà ripetuto, ferma l’applicazione delle penali di cui al paragrafo successivo (ritardo nella consegna). Tutti gli oneri che la Stazione Appaltante dovrà sostenere saranno posti a carico della Ditta Aggiudicataria.
Nell’ipotesi in cui anche il secondo collaudo dia esito negativo, la Stazione Appaltante, fermo restando l’applicazione delle penali di cui al successivo paragrafo, avrà facoltà di dichiarare risolto il presente contratto ai sensi dell’art.1456 c.c.
Il collaudo della fornitura prevede:
▪ Collaudo di pre-accettazione
▪ Collaudo finale
Il collaudo di pre-accettazione rappresenta un collaudo parziale e preliminare avente l’obiettivo di verificare la conformità di una parte della fornitura, corrispondente tipicamente ad un servizio o sottoservizio avente legami e/o dipendenze da altri servizi. I servizi sottoposti singolarmente al collaudo di pre-accettazione saranno complessivamente oggetto di collaudo finale.
Il collaudo finale ha l’obiettivo di verificare la piena e reale funzionalità ed operatività dell’intera fornitura nonché la piena integrazione di tutte le parti costituenti la fornitura completa.
Il collaudo finale è realizzato al completamento con esito positivo di tutti i collaudi di pre-accettazione. In fase di collaudo finale potranno essere ripetute le verifiche documentali e le prove tecniche già oggetto di un collaudo di pre-accettazione.
La Ditta Aggiudicataria deve predisporre tutto quanto necessario per la realizzazione del collaudo ivi comprese le basi dati dimostrative.
La Tabella 6 riporta le tipologie di collaudo da realizzare per ciascun servizio.
Servizio | Collaudo | |
Pre-accettazione | Collaudo finale | |
Infrastruttura Tecnologica – Infrastruttura Portale | • | |
Infrastruttura Tecnologica – Stazioni di Lavoro | • | |
Infrastruttura Tecnologica – CNS | • | |
Sistema Applicativo | • | • |
Tabella 6 – Collaudi
Qualora la Ditta Aggiudicataria articoli la fornitura del sistema applicativo Portale nelle due Fasi A e B come definito in Tabella 5 - Fasi di rilascio del Portale, il collaudo finale sarà ripetuto per ciascuna delle Fasi.
4.6 Livelli di servizio e penalità
La Stazione Appaltante a tutela della qualità dei servizi richiesti e della sua scrupolosa conformità alle norme di legge e contrattuali, si riserva di applicare sanzioni pecuniarie in ogni caso di verificata violazione di tali norme, secondo il principio della progressione.
La sanzione sarà applicata dopo formale contestazione ed esame delle eventuali controdeduzioni della Ditta Aggiudicataria.
Le definizioni dei Livelli di Servizio (Service Level Agreement, SLA), per ogni singolo servizio e/o sottoservizio in cui è articolato l’affidamento, con connesse penali sono riportati nel presente Capitolato, per ogni sisngolo servizio.
Si fa presente che:
a) la Ditta Aggiudicataria deve:
o organizzare un sistema di raccolta ed elaborazione dei dati necessari per la misurazione dei Livelli di Servizio come definito in 2.4.5
o documentare, periodicamente su base trimestrale i Livelli di Servizio conseguiti evidenziando le violazioni delle soglie di accettazione e motivando le cause delle stesse
o rendere disponibili, periodicamente su base mensile, i dati raccolti ed elaborati in formato digitale
o rendere disponibile uno o più accessi in consultazione alla Stazione Appaltante a tale sistema di raccolta/elaborazione dei dati avendo la stessa la capacità autonoma di estrazione di tutti i dati raccolti.
La Relazione Tecnica deve specificare le caratteristiche tecniche ed organizzative ritenute significative del processo di raccolta/elaborazione dei Livelli di Servizio che sarà dettagliato nella progettazione esecutiva di ciascun servizio.
b) le consegne effettuate dalla Ditta Aggiudicataria saranno ritenute valide ai fini dell’accettazione da parte della Stazione Appaltante e ai fini dell’applicazione delle penali connesse al rispetto delle scadenze, solo se risulteranno complete dei contenuti e conformi ai formati previsti, ove espressamente indicato e/o concordato successivamente fra le parti;
c) l’applicazione delle penali per tutti i casi contemplati e indicati in dettaglio nel presente Capitolato comporta:
o per i crediti derivanti dall’applicazione delle penali, la Stazione Appaltante potrà, a sua insindacabile scelta, avvalersi della cauzione definitiva, senza bisogno di diffida o procedimento giudiziario, ovvero compensare il credito con quanto dovuto alla Ditta Offerente a qualsiasi titolo;
o ove per effetto dell’applicazione delle penali e delle conseguenti compensazioni con la cauzione definitiva prestata dalla Ditta Offerente, l’importo garantito dovesse risultare inferiore al 50% del valore della cauzione originariamente prestata, la Ditta Offerente è tenuta a reintegrare tale cauzione fino alla originaria consistenza, a semplice richiesta da parte del Committente, entro i termini perentori da questa assegnati, a pena di risoluzione ai sensi dell’art. 1456 c.c.
o ove l’importo complessivo delle penali applicate dovesse superare il 10% (dieci per cento) dell’importo contrattuale, l’inadempimento si intenderà non di scarsa importanza ex art. 1455 c.c., e pertanto, la Stazione Appaltante avrà facoltà di dichiarare risolto il contratto ai sensi dell’art.1456 c.c.
d) la Ditta Offerente prende atto che l’applicazione delle penali previste non preclude il diritto della Stazione Appaltante a richiedere il risarcimento degli eventuali maggior danni ai sensi dell’art. 1382 cod. civ. e a fare eseguire a terzi gli interventi necessari, addebitando all’Offerente tutti gli oneri sostenuti.
e) ove previsto il collaudo di componenti consegnati, la data del verbale di collaudo positivo verrà considerata quale “Data di Accettazione”, da parte della Stazione Appaltante per la relativa fatturazione e, ove pertinente, come data di avvio di azioni operative collegate.
5 Normativa di riferimento
La Ditta Offerente deve tener conto e rispettare la normativa vigente a carattere nazionale e, con riferimento alla Regione Puglia a carattere regionale.
Di seguito sono elencate le principali norme di carattere generale alle quali la Ditta Offerente deve attenersi nella fornitura dei servizi oggetto dell’appalto
1. per quanto concerne il Sistema Sanitario Nazionale:
▪ “Piano sanitario nazionale 2006-2008” Ministero della Salute
▪ “Una Politica per la Sanità Elettronica” Tavolo Permanente per la Sanità Elettronica, 31 marzo 2005
▪ D. Lgs. 196 del 30 giugno 2003 “Codice in materia di protezione dei dati personali”
▪ Decreto del Presidente del Consiglio dei Ministri 19 maggio 1995 "Schema generale di riferimento della "Carta dei servizi pubblici sanitari"" (Pubblicato nella G.U. 31 maggio 1995, n. 125, S.O.)
2. per quanto concerne la Regione Puglia:
▪ L. R. 3 agosto 2006, n. 25 “Principi e organizzazione del Servizio sanitario regionale”
▪ Deliberazione della Giunta Regionale 27 dicembre 2001 n. 2087 “Piano Sanitario Regionale 2002- 2004 e Piano Regionale di Salute 2002 – 2007. Adozione definitiva a seguito di integrazioni al progetto di Piano di cui alla DGR 28 novembre 2001, n. 1697”
▪ D.G.R. 22 dicembre 2006, n. 2005 “Piano per la Sanità Elettronica della Regione Puglia.
▪ Regolamento Regionale 25 maggio 2006, n. 5 “Regolamento per il Trattamento dei Dati Sensibili e Giudiziari ai sensi degli artt. 20 e 21 del Decreto Legislativo 196/03”.
▪ D.G.R. 4 agosto 2006, n. 2005 “Adempimenti ex intesa Stato Regioni del 28/04/2006: Piano regionale di contenimento dei tempi d’attesa per il triennio 2006-2008”
▪ D.G.R. 6 febbraio 2007, n. 68 “Adempimenti ex intesa Stato Regioni del 28/04/2006: Piano regionale di contenimento dei tempi d’attesa per il triennio 2006-2008. Integrazioni e modificazioni alla D.G.R. n.1200/2006”
▪ D.G.R. 31 gennaio 2008, n.90 “Linee guida di indirizzo per le attività di comunicazione istituzionale dei settori della Regione Puglia
3. per quanto concerne l’ICT
▪ Piano di azione e-government (Decreto Presidente del Consiglio dei Ministri del 14 febbraio 2002)
▪ Decreto Legislativo 7 marzo 2005, n. 82 “Codice dell'amministrazione digitale.”
▪ Decreto Legislativo x.xx 42 del 28/2/2005 “Istituzione del Sistema Pubblico di Connettività e della Rete internazionale della Pubblica Amministrazione, a norma dell’art. 10, della L. 229 del 29/7/2003 (G.U. x.xx 73 del 30/3/2005)
▪ Legge 9 gennaio 2004, n. 4 “Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici”
▪ Decreto del Ministro per l’Innovazione e le Tecnologie dell’8 luglio 2005 “Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici”
▪ Direttiva del 27 luglio 2005 “Direttiva per la qualità dei servizi on line e la misurazione della soddisfazione degli utenti”
▪ Presidenza del Consiglio dei Ministri, Dipartimento della Funzione Pubblica Circolare 13 marzo 2001, n. 3/2001 “Linee guida per l'organizzazione, l'usabilità' e l'accessibilità' dei siti Web delle pubbliche amministrazioni”.
6 Appendice A - Il Portale del Call Center Informativo Sanitario della Regione Puglia
Il Portale CCIRS (il Portale del Call Center Informativo Regionale della Sanità) è una piattaforma software costituita da due applicazioni web-based, una ad accesso pubblico, l’altra ad accesso riservato:
1. l’applicazione pubblica, liberamente raggiungibile dagli utenti Internet all’indirizzo xxx.xxxxxx.xxxxxx.xx o xxx.xxxxxx.xxxxxx.xx, consente di accedere alle informazioni contenute nella Banca Dati del Call center (BDC);
2. l’applicazione ad accesso riservato, oltre a consentire l’accesso in lettura/scrittura alla BDC, mette a disposizione una serie di funzionalità di supporto alla gestione delle attività del Call Center, ed è utilizzabile solo dagli addetti del Call Center Sanitario della Regione Puglia.
6.1 Informazioni gestite
Le principali informazioni gestite attraverso il Portale CCIRS sono riepilogate nella seguente tabella:
Categorie | Principali descrittori |
Aziende sanitarie (ASL, AO, IRCCS, EE, …) | - Denominazione - Sede - Riferimenti telefonici, fax, posta elettronica, Internet, … - Collegamenti - Responsabili legali, sanitari, amministrativi - URP - Punti Informativi - Casse Ticket - Uffici Prenotazione - … |
URP | - Indirizzo - Riferimenti telefonici, fax, posta elettronica, Internet, … - Responsabili - Giorni e orari di apertura - … |
Punti Informativi | - Indirizzo - Riferimenti telefonici, fax, posta elettronica, … - Responsabili - Giorni e orari di apertura - … |
Casse Ticket | - Indirizzo - Riferimenti telefonici, fax, posta elettronica, … - Giorni e orari di apertura - … |
Uffici Prenotazione | - Indirizzo - Riferimenti telefonici, fax, posta elettronica, … - Giorni e orari di apertura - … |
Associazioni di volontariato | - Denominazione - Indirizzo - Riferimenti telefonici, fax, posta elettronica, Internet, … - Responsabile - Finalità - … |
Servizi sociali | - Ubicazione - Riferimenti telefonici, fax, posta elettronica, Internet, … - Responsabile - … |
Ospedali | - Denominazione - Indirizzo - Riferimenti telefonici, fax, posta elettronica, Internet, … - Collegamenti |
- Responsabili sanitari - Reparti - … | |
Reparti | - Disciplina - Denominazione - Direttori - Capo-sala - Riferimenti telefonici, fax, posta elettronica, Internet, … - Prestazioni ambulatoriali erogate, giorni e orari di erogazione, modalità di prenotazione e di pagamento, importo ticket, tempo di attesa - Orario visitatori - … |
Pronto Soccorso, Primo Intervento | - Indirizzo - Riferimenti telefonici, fax, posta elettronica, … - Direttori - Capo-sala - … |
Pronto Soccorso Estivo | - Indirizzo - Riferimenti telefonici, fax, … - Periodo e orari di operatività - … |
Day Hospital | - Patologia - Struttura/Reparto di riferimento - Responsabile - Riferimenti telefonici, fax, posta elettronica, … - Modalità di erogazione e di prenotazione - … |
Centri Trapianto | - Organo/Tessuto - Struttura/Reparto di riferimento - Responsabile - Riferimenti telefonici, fax, posta elettronica, … - … |
Centri Donazione Sangue | - Sede/Indirizzo - Responsabile - Riferimenti telefonici, fax, posta elettronica, … - Orari apertura - … |
Centri Malattie Rare | - Malattia (gruppo, sottogruppo, sinonimi, nome, codice esenzione, …) - Struttura/Reparto di riferimento - Riferimenti telefonici, fax, posta elettronica, Internet, … - … |
Ospedali di Comunità | - Denominazione - Indirizzo - Riferimenti telefonici, fax, posta elettronica, Internet, … - Collegamenti - Coordinatori - … |
RSA | - Denominazione - Indirizzo - Riferimenti telefonici, fax, posta elettronica, Internet, … - Collegamenti - Responsabili sanitari - Orario visitatori - … |
Distretti Socio-sanitari | - Denominazione - Indirizzo - Riferimenti telefonici, fax, posta elettronica, Internet, … - Collegamenti - Responsabili - Copertura territoriale - Uffici periferici - Servizi erogati, loro descrizione ed informazioni correlate (anche in lingue straniere), giorni e orari di erogazione - … |
Ambulatori (Poliambulatorii, Consultori, CSM, SERT, Medicina Fisica e Riabilitazione, Diagnostica per Immagini, Medicina di Laboratorio, …) | - Denominazione - Indirizzo - Riferimenti telefonici, fax, posta elettronica, Internet, … - Collegamenti - Responsabili sanitari - Prestazioni erogate, giorni e orari di erogazione, modalità di prenotazione e di pagamento, importo ticket, tempo di attesa - … |
Guardia Medica (Continuità Assistenziale) | - Indirizzo - Riferimenti telefonici, fax, posta elettronica, … - … |
Centri Vaccinali | - Denominazione - Indirizzo - Riferimenti telefonici, fax, posta elettronica, … - Referente medico - Xxxxxx e orari di apertura - … |
Commissioni di invalidità | - Indirizzo - Riferimenti telefonici, fax, posta elettronica, … - Responsabile - Giorni e orari di accesso - Competenza territoriale - Sportelli consegna domande - Tempi di attesa - … |
Uffici Igiene | - Indirizzo - Riferimenti telefonici, fax, posta elettronica, … - Responsabile - Giorni e orari di apertura - Riferimenti, giorni e orari di accesso per le certificazioni medico-legali - Riferimenti, giorni e orari di accesso per l’ufficio veterinario - … |
Dipartimenti Prevenzione | - Indirizzo - Riferimenti telefonici, fax, posta elettronica, … - Responsabile - Giorni e orari di apertura - Riferimenti, giorni e orari di accesso per il SIAN, SIAV, SPESAL - … |
Fabbricanti dispositivi medici su misura | - Denominazione - Indirizzo - Riferimenti telefonici, fax, posta elettronica, … - Numero registrazione - Campo di applicazione - … |
Farmacie di turno | - Denominazione - Indirizzo - Turno di apertura - … |
Uffici visite mediche rinnovo patenti | - Indirizzo - Giorni e orai di accesso - Tipo patente - … |
Ambulanze associazioni di volontariato | - Denominazione associazione - Indirizzo sede - Responsabile - Riferimenti telefonici - … |
Centri antifumo | - Indirizzo - Referente - Riferimenti telefonici - … |
Centri antiveleno | - Indirizzo - Riferimenti telefonici - … |
Campagne di prevenzione | - Descrizione - Periodo di attivazione - Riferimenti telefonici - … |
Progetti di screening | - Denominazione - Strutture coinvolte - Responsabile - Riferimenti telefonici - … |
6.2 Gestione delle richieste
Gli operatori del Call Center registrano in un apposito archivio tutte le richieste pervenute al Call Center. I principali descrittori delle richieste sono i seguenti:
- estremi della richiesta
- modalità di ricezione
- riferimenti del chiamante
- identificativo operatori di front office di 1° e di 2° livello e di back office che trattano la richiesta
- tipologia della richiesta
- descrizione della richiesta
- stato della richiesta
- modalità e descrizione della risposta
- elementi per rilevazioni statistiche (età del richiedente, sesso, professione, titolo di studio, …)
Il Portale rende disponibili una serie di funzionalità per la gestione delle richieste, le principali delle quali sono:
• registrazione
• assegnazione (le richieste non evase nel corso della telefonata sono assegnate agli operatori di back office)
• gestione (attivata dagli operatori di back office per gestire le richieste loro assegnate)
• monitoraggio
Sono state sviluppate, inoltre, una serie di funzionalità per l’elaborazione di statistiche sulle richieste, le principali delle quali sono:
• andamento delle richieste registrate, per intervallo di tempo
• distribuzione per sesso, per fasce d’età, per titolo di studio, per professione
• distribuzione per area geografica di provenienza
• distribuzione per tipologia di richiesta e per tempo di risposta (nel corso della telefonata o in un secondo momento).
6.3 Gestione delle segnalazioni
Gli operatori del Call Center registrano in un apposito archivio tutte le segnalazioni, pervenute telefonicamente o attraverso compilazione del form disponibile sul Portale ad accesso pubblico.
I principali descrittori delle segnalazioni sono i seguenti:
- estremi della segnalazione
- modalità di ricezione
- riferimenti dell’autore
- tipologia della segnalazione (reclamo, suggerimento, elogio/ringraziamento)
- descrizione della segnalazione
- categoria della segnalazione
- identificativo operatori di front office e di back office che gestiscono la segnalazione
- stato della segnalazione e altri dati relativi al processo di gestione della segnalazione
- elementi per rilevazioni statistiche (età dell’autore, sesso, professione, titolo di studio, …)
Il Portale rende disponibili una serie di funzionalità per la gestione delle segnalazioni, le principali delle quali sono:
• registrazione
• assegnazione (le segnalazioni sono assegnate agli operatori di back office)
• gestione (attivata dagli operatori di back office per gestire le segnalazioni loro assegnate)
• monitoraggio
Sono state sviluppate, inoltre, una serie di funzionalità per l’elaborazione di statistiche sulle segnalazioni, le principali delle quali sono:
• andamento delle segnalazioni registrate, per intervallo di tempo
• distribuzione per sesso, per fasce d’età, per titolo di studio, per professione
• distribuzione per area geografica di provenienza
• distribuzione per tipologia di segnalazione, per categoria e per azienda sanitaria alla quale la segnalazione fa riferimento.
7 Appendice B - Servizi esposti dal Sistema Informativo Sanitario Territoriale
Il progetto Rete dei Medici di Medicina Generale prevede la predisposizione e l’avviamento dell’esercizio di un sistema di servizi per il potenziamento dei servizi sanitari territoriali e dell’assistenza sanitaria primaria. Il progetto Rete dei Medici di Medicina Generale fornirà pertanto al personale medico, Medici di Medicina Generale (MMG) e Pediatri di Libera Scelta (PLS), ed altro personale sanitario che operino con finalità di Assistenza Primaria per gli assistiti della Regione Puglia la necessaria interconnessione in rete, l’accesso ad un proprio sistema informativo e l’integrazione dello stesso nel complessivo Sistema Informativo Sanitario della Regione Puglia. Il progetto prevede il coinvolgimento progressivo nella Regione Puglia dei Medici di Medicina Generale e dei Pediatri di Libera Scelta e di altri attori del Sistema Sanitario della Regione al fine di favorire la circolazione e la condivisione delle informazioni e la cooperazione con altri attori del sistema socio-sanitario territoriale.
Il progetto prevede inoltre la realizzazione di un primo nucleo di servizi orientati agli Assistiti per l’accesso alle proprie informazioni sanitarie e per l’adempimento di alcune questioni amministrative. In particolare:
▪ Gestione del consenso: Gestire la registrazione della volontà espressa dal cittadino per il trattamento dei suoi dati sensibili (cfr. Legge sulla Privacy dlgs 196/2003) e il tipo di consenso (affermativo o negativo) fornito;
▪ Accesso al Fascicolo Sanitario Elettronico: consentirà al cittadino di consultare gli atti sanitari presenti nel proprio Fascicolo Sanitario Elettronico. Devono essere previste diverse modalità di accesso agli atti (per tipologia di atto, per data o range di date ecc);
▪ Accesso alla Scheda Sanitaria Individuale: è la scheda gestita dal MMG/PLS contenente i dati anagrafici, l’anamnesi, i dati di base comprensivi dei dati di emergenza.
Nel seguito sono definite le specifiche tecniche dei servizi esposti dal SIST.
7.1 Elenco casi d’uso per componente
7.1.1 Componente AAGC (Anagrafe Assistiti e Gestione Consenso)
7.1.1.1 Regole di business
Dati_assistibile_fuori_anagrafe
Dati necessari per l'inserimento di un assistibile fuori anagrafe. I dati obbligatori sono :
codice identificativo dell'assistito (codice fiscale o codice sanitario) cognome
nome
comune di residenza
I dati opzionali sono :
data di nascita sesso
comune di nascita indirizzo di residenza
Dati_inserimento_consenso
comune di domicilio indirizzo di domicilio cittadinanza
usl di iscrizione
I dati da inserire sono :
Dati_revoca_consenso
codice identificativo dell'assistito data inizio consenso
data fine consenso (opzionale)
dati del tutore nel caso in cui il consenso avvenga per delega identificativo dell'operatore che ha registrato il consenso
il consenso o il rifiuto espresso dal cittadino per il trattamento dei suoi dati sensibili
Una volta registrato il consenso / rifiuto di un cittadino nel sistema, questo non è più cancellabile.
Verrà sempre memorizzata la data di registrazione della data di fine consenso e l'operatore che ha eseguito l'operazione.
La data di revoca del consenso sarà quella di sistema.
Dati_ricerca_assistito
La ricerca e la successiva identificazione dei cittadini può avvenire indicando in alternativa:
codice fiscale codice sanitario
cognome, nome o parte di esso, e facoltativamente sesso, data di nascita (completa o solo anno di nascita) e comune di nascita .
Dati_ricerca_elenco_assistiti_in_carico
Dati necessari per la ricerca dell' elenco degi assistiti in carico sono :
codice regionale del medico data di riferimento
Dati_ricerca_elenco_MMG_PLS
L'elenco dei medici di medicina generale e pediatri di libera scelta verrà prodotto in base ai possibili criteri di ricerca:
codice nazionale
tipo di incarico (generico o pediatra)
comune in cui ha sede lo studio professionale
flag che indica se la ricerca deve essere effettuata fra i medici massimalisti o meno ( per medico massimalista si intende un medico con un numero di assistiti incarico superiore o uguale al massimale)
nome e cognome del medico
Dati_ricerca_elenco_scelte_e_revoche
Dati necessari per la ricerca delle scelte e revoche . I parametri sono :
Dati_ricerca_medico
codice regionale del medico
periodo di riferimento (data inizio e data fine )
La ricerca e la successiva identificazione di un medico può avvenire indicando in alternativa:
Dati_richiesta_scelta_revoca
codice regionale
cognome per intero e in maniera opzionale il nome o parte di esso e in maniera opzionale
tipo incarico (generico/pediatra)
AUSL di convenzione
comune in cui ha sede lo studio del medico.
La richiesta di Xxxxxx/Revoca deve contenere i seguenti dati:
codice regionale del medico da scegliere /revocare codice fiscale dell'assistito che richiede l'operazione la data di decorrenza dell'operazione
il tipo di operazione (scelta o revoca)
Fonte_dati_ricerca
La fonte dati di ricerca dei cittadini è per default la smartcard se disponibile. In alternativa è possibile identificare i cittadini nell' Anagrafe Iscritti al Sistema Sanitario Regionale (SSR) oppure nell' Anagrafe Non Iscritti al SSR.
Mantenimento_della_sessione
Il sistema deve mantenere in memoria i dati ritrovati
Stampa_consenso
L'utente deve preoccuparsi di verificare che sia stato sottoscritto il modulo del consenso prima di procedere con l'inserimento dei dati nel sistema.
7.1.1.2 Gestire Consenso Informato
Scopo
Gestire la registrazione della volontà espressa dal cittadino per il trattamento dei suoi dati sensibili (cfr. Legge sulla Privacy dlgs 196/2003) e il tipo di consenso (affermativo o negativo ) fornito.
Pre-requisito
La postazione da cui si esegue la registrazione del consenso dispone di una stampante.
Precondizioni
Nessuna.
Postcondizioni
La stampa è stata eseguita correttamente ed il cittadino ha firmato l'informativa. L’informazione sul consenso è stata resa persistente. La storicizzazione dei periodi riferiti ai consensi precedentemente registrati viene garantita.
Requisiti accessori del caso d'uso
Nessuno.
Flusso principale
1. Il caso d'uso inizia quando l'attore decide di inserire o modificare i dati relativi al Consenso Informato forniti dal cittadino.
2. Il sistema esegue il caso d'uso "Identificare Cittadino" presentando una maschera per l'inserimento dei parametri di ricerca del cittadino.
3. Se l'assistibile non ha fornito alcun consenso o questo risulta non più valido viene eseguito il caso d'uso "Inserire Consenso Informato".
4. Altrimenti viene eseguito il caso d'uso "Revocare Consenso Informato".
5. Il caso d'uso termina.
Flusso alternativo
Nessuno
7.1.1.3 Identificare Cittadino da Smartcard
Scopo
Identificare il cittadino tramite la sua smartcard.
Pre-requisito
La smartcard del cittadino deve essere inserita.
Precondizioni
Nessuna.
Postcondizioni
Nessuna.
Requisiti accessori del caso d'uso Fonte_dati_ricerca Mantenimento_della_sessione Flusso principale
1. Il caso d'uso inizia quando l'attore inserisce la smart card del cittadino nel lettore ed accede al servizio di identificazione del cittadino.
2. Il sistema controlla che la smartcard risulti ancora inserita. In caso positivo ne legge i dati memorizzati (tra i quali il codice fiscale), ed avvia l'identificazione del cittadino; altrimenti dopo aver mostrato un messaggio d’errore il caso d’uso termina.
3. Il sistema recupera i dati del cittadino e li rende disponibili fino a quando resta inserita la Smartcard.
4. Il caso d'uso termina.
Flusso alternativo
Nessuno.
7.1.1.4 Inserire Consenso Informato
Scopo
Registrare nel sistema la volontà espressa dal cittadino per il trattamento dei suoi dati sensibili ( cfr. Legge sulla Privacy dlgs 196/2003) e il tipo di consenso (affermativo o negativo ) fornito.
Pre-requisiti
La postazione da cui si esegue la registrazione del consenso dispone di una stampante.
Precondizioni
L'assistibile è stato identificato e nel sistema, al momento, non risulta presente alcuna informazione sul consenso al trattamento dei dati espresso dallo stesso (o quella presente non risulta più valida, perchè scaduta).
Postcondizioni
I dati relativi al consenso al trattamento dei dati devono essere stati correttamente inseriti nel sistema.
Requisiti accessori del caso d'uso Dati_Inserimento_Consenso Stampa_Consenso
Flusso principale
1. Vengono mostrati i dati anagrafici dell'assistibile ( codice fiscale, cognome, nome, data di nascita, comune di nascita, indirizzo di residenza, comune di residenza) e la data di inizio validità del consenso ( che sarà quella della registrazione ).
2. L'attore specifica una eventuale data di fine validità e gli estremi di un documento di riconoscimento.
3. Se il consenso viene dato da chi esercita legalmente la potestà sull'assistibile l'attore dovrà specificare anche le generalità di chi sta fornendo il consenso e gli estremi di un documento di riconoscimento.
4. Nel caso in cui l'assistibile di cui stiamo registrando il consenso sia un minore verrà impostata per default la data di fine validità del consenso alla data di compimento del 18- mo anno di età.
L'attore potrà :
• Stampare il modulo del consenso e proseguendo il caso d'uso con il passo 5
• Richiedere la stampa dell'informativa (verrà fatto il download di un file PDF).
• Tornare alla pagina di inserimento dei dati dell'assistibile.
5. L'operatore fa firmare il modulo all'assistibile o al suo tutore e conferma i dati da inserire.
6. I dati vengono inseriti nel sistema.
Flusso alternativo
Nessuno.
7.1.1.5 Revocare Consenso Informato
Scopo
Revocare nel sistema il consenso/rifiuto espresso dal cittadino per il trattamento dei suoi dati sensibili ( cfr. Legge sulla Privacy dlgs 196/2003) .
Pre-requisiti
La postazione da cui si esegue la registrazione del consenso dispone di una stampante.
Precondizioni
L'assistibile è stato identificato e nel sistema risultano presenti e validi i dati relativi al consenso al trattamento dei dati espressi dal cittadino.
Postcondizioni
La modifica è stata registrata correttamente nel sistema.
Requisiti accessori del caso d'uso
Dati_revoca_consenso
Flusso principale
1. Il caso d'uso inizia quando l'attore decide di modificare i dati relativi al Consenso Informato forniti dal cittadino.
2. Vengono mostrati i dati identificativi del cittadino e le informazioni relative al consenso che risultano presenti nel sistema.
3. L'operatore può :
• Tornare alla pagina di inserimento dei parametri per la ricerca di un assistibile;.
• Confermare la revoca del consenso.
4. La revoca del consenso viene registrata nel sistema.
5. Il caso d'uso termina.
Flusso alternativo
Nessuno.
7.1.1.6 Verificare Consenso Informato
Scopo
Verificare che il cittadino abbia espresso la sua volontà per il trattamento dei suoi dati sensibili ( cfr. Legge sulla Privacy dlgs 196/2003) e il tipo di consenso (affermativo o negativo ) fornito.
Pre-requisiti
Nessuno.
Precondizioni
Il cittadino deve essere stato identificato.
Postcondizioni
Nessuna.
Requisiti accessori del caso d'uso Mantenimento_della_sessione Flusso principale
1. Il caso d'uso inizia quando il sistema deve verificare il consenso dell'assistibile al trattamento dei suoi dati sensibili.
2. Il sistema restituisce l'informazione relativa alla presenza nel sistema della volontà dell'assistibile in materia di trattamento dei suoi dati sensibili. La registrazione deve risultare valida al momento dell'invocazione del caso d'uso.
3. Nel caso in cui l'assistibile abbia espresso la sua volontà il flusso specifica se questa è di consenso al trattamento dei dati sensibili o di rifiuto.
4. Il caso d'uso termina.
Flusso alternativo
Nessuno.
7.1.2 Componente FSE (Fascicolo Sanitario Elettronico)
7.1.2.1 Regole di business
Assunzione di responsabilità
L'operatore si assume la responsabilità di consultare i dati sanitari sensibili, indicando il motivo.
Il sistema registra inoltre l'identificativo dell'operatore, l'assistibile e i riferimenti temporali (data e ora).
Ciclo erogativo
Le prestazioni specialistiche caratterizzate da un ciclo erogativo generano un solo evento sanitario specialistico caratterizzato da due date, inizio e fine del ciclo.
Anche i ricoveri di day-hospital che prevedono più accessi vengono considerati come un unico evento di ricovero.
Dati Evento Sanitario Di Certificato
I certificati di malattia emessi dal medico caratterizzano i relativi eventi. Questi includono le seguenti informazioni:
⮚ Medico che lo ha emesso;
⮚ Diagnosi (codice ICD-9-CM e descrizione);
⮚ Tipo di certificato (INPS, INAIL, ecc.);
⮚ Data di redazione;
⮚ Data di inizio della malattia;
⮚ Data di fine della prognosi;
⮚ Testo del certificato;
⮚ Altro tipo di certificato (Inizio, Continuazione, Ricaduta, Fine prognosi).
Dati Evento Sanitario Di Emergenza
Le prestazioni sanitarie erogate in regime di emergenza (DEA, DEU, Pronto Soccorso, 118, ecc) caratterizzano i relativi eventi. Questi includono le seguenti informazioni sanitarie rilevabili durante l'assistenza del cittadino al pronto soccorso:
⮚ Dati Generali:
Struttura erogatrice (servizio di pronto soccorso); Numero di emergenza (anno e progressivo); Triage;
Data e ora di accettazione; Descrizione diagnosi; Descrizione Infortunio/Incidente; Data e ora Infortunio/Incidente;
Descrizione Immunoprofilassi tetanica; Descrizione prescrizioni;
Descrizione terapie; Altre Terapie;
Data e ora di dimissione; Descrizione modalità di dimissione; Ore in osservazione;
Descrizione prognosi riservata. Stato evento;
⮚ Prestazioni:
Codice e descrizione prestazione specialistica; Numero di sedute;
Eventuale consulenza a cui si riferisce.
⮚ Consulenze
Reparto di consulenza;
Prestazioni specialistiche effettuate in consulenza; Quesito diagnostico;
Descrizione del referto.
Gli eventi di emergenza possono essere seguiti da ricovero dando vita a "Eventi di Ricovero" collegati.
Dati Evento Sanitario Di Ricovero
Gli eventi di ricovero sono classificabili in:
⮚ ricovero ordinario
⮚ day hospital
⮚ day surgery.
Gli eventi di ricovero includono non solo le informazioni sanitarie contenute nelle SDO (dati di accettazione, dimissione, diagnosi, interventi/procedure e trasferimenti interni di reparto) ma anche altre informazioni sanitarie rilevabili durante la permanenza dell'assistito nella struttura sanitaria (endoprotesi).
Dati Evento Sanitario Farmaceutico
I farmaci erogati caratterizzano i relativi eventi. Questi includono le seguenti informazioni:
⮚ Farmaco (codice e descrizione);
⮚ Numero di erogazioni effettuate;
⮚ Data e stato evento.
Dati Evento Sanitario Specialistico
Le prestazioni sanitarie specialistiche erogate caratterizzano i relativi eventi. Questi includono le seguenti informazioni:
Referto associato
⮚ Struttura erogatrice (Presidio specialistico esterno, ambulatorio specialistico e reparto/servizio di istituto di ricovero);
⮚ Prestazione specialistica (codice e descrizione);
⮚ Numero di erogazioni effettuate;
⮚ Branca specialistica;
⮚ Data e stato evento.
Un referto medico può essere associato ad un singolo evento (ricovero o emergenza) o a più eventi sanitari (specialistico).
Registrazione eventi
La registrazione degli eventi sanitari prescinde dal "consenso del cittadino" al trattamento dei propri dati.
La registrazione di un evento sanitario avviene al momento della:
Ricerca eventi
⮚ erogazione di una prestazione farmaceutica, specialistica o di emergenza;
⮚ accettazione e dimissione della prestazione di ricovero;
⮚ emissione di un certificato medico;
⮚ ricezione di una SDO validata e quindi già erogata .
Il sistema non effettua la storicizzazione degli eventi sanitari, nel senso che per ciascuno è mantenuta soltanto l'ultima registrazione. In altre parole, se al momento della registrazione l'evento esiste già in archivio, questo viene sostituito. Quindi si effettua la cancellazione dell'evento presente in archivio e la registrazione del nuovo evento.
La ricerca degli eventi sanitari può essere effettuata secondo le seguenti modalità:
⮚ Ricerca semplice
⮚ Ricerca avanzata
La ricerca semplice consente l'impostazione di pochi dati come filtro per la selezione degli eventi sanitari (identificativo cittadino, tipo evento, periodo temporale in cui ricade l'evento).
La ricerca avanzata aggiunge ulteriori dati di filtro in modo da rendere più precisa la selezione. In particolare si hanno i seguenti ulteriori filtri:
Stato evento
⮚ per l'evento farmaceutico codice ATC; farmaco.
⮚ per l'evento specialistico
prestazione specialistica; branca specialistica;
stato evento (erogato/refertato);
struttura erogatrice (Istituto di ricovero, ambulatorio, presidio esterno);
⮚ per l'evento di ricovero
diagnosi principale;
stato evento (accettato/erogato/refertato); specialità clinica di ammissione;
istituto di ricovero;
ricoveri scaturiti da eventi di emergenza;
⮚ per l'evento di emergenza prestazione specialistica;
stato evento (erogato/refertato); istituto di ricovero;
emergenze seguite da eventi di ricovero;
⮚ per l'evento di certificato diagnosi;
tipo di certificato (INPS, INAIL, ecc.).
Alcuni eventi sanitari hanno un proprio stato evento che dipende dallo stato della relativa prestazione sanitaria. Si prendono in considerazione i seguenti possibili stati:
⮚ Accettato
⮚ Erogato
⮚ Refertato
Ogni evento può assumere determinati stati, secondo la categoria d'appartenenza e lo stato pre-esistente (cfr. Tipo evento). I possibili stati di ciascuna categoria di evento sono: