PROGETTO AREUS-118 CAPITOLATO TECNICO PER LA … · 2019. 10. 18. · la Centrale Operativa di...

REPUBBLICA ITALIANA

Regione Siciliana

Assessorato della Salute Dipartimento della Pianificazione Strategica

SERVIZIO 6 “EMERGENZA URGENZA SANITARIA - ISOLE MINORI ED AREE DISAGIATE"

PROGETTO AREUS-118

CAPITOLATO TECNICO PER LA FORNITURA INTEGRATA DI UN SISTEMA DI GESTIONE

DEL 118 DELLA REGIONE SICILIANA

Redatto ai sensi del DDG 2182 del 19 novembre 2018

1

INDICE

INTRODUZIONE ......................................................................................................................................................................... 4

SITUAZIONE ATTUALE ............................................................................................................................................................. 4

OBIETTIVI DEL PROGETTO ..................................................................................................................................................... 8

OBIETTIVI DELLA FORNITURA DEL SISTEMA INFORMATIVO ........................................................................................... 9

ARCHITETTURA DI RIFERIMENTO .......................................................................................................................................11

INFRASTRUTTURE CENTRALIZZATE ..................................................................................................................................12

APPARATI DI RETE LOCALE .............................................................................................................................................14

RETE DI ACCESSO .............................................................................................................................................................15

SICUREZZA E AFFIDABILITÀ DELLA RETE DI ACCESSO AL SERVIZIO 118 .............................................................17

FUNZIONALITÀ DI “UTENTE PROTETTO” ...................................................................................................................17

RETE TELEFONICA NAZIONALE DELLE EMERGENZE ............................................................................................18

VPN DELLE EMERGENZE .............................................................................................................................................19

SISTEMA DI SICUREZZA DI PROTEZIONE VERSO LA VPN EMERGENZA ...........................................................19

ACCESSO A INTERNET E SICUREZZA .......................................................................................................................20

COMPONENTI IT CENTRALIZZATE DELLA SOLUZIONE ...................................................................................................20

INTRODUZIONE ...................................................................................................................................................................20

SOTTOSISTEMA SERVER CON CARATTERISTICHE FAULT TOLERANT ..................................................................20

SOTTOSISTEMA SERVER RACK STANDARD ................................................................................................................23

SOTTOSISTEMA STORAGE A BLOCCO E STORAGE AREA NETWORK ...................................................................24

SOTTOSISTEMA STORAGE NAS ......................................................................................................................................28

SOFTWARE DI BASE ...............................................................................................................................................................30

INTRODUZIONE ...................................................................................................................................................................30

SOFTWARE DI VIRTUALIZZAZIONE DELL’HARDWARE................................................................................................30

SOFTWARE DI BACKUP E REPLICA DELLE MACCHINE VIRTUALI E DEI DATI ........................................................31

SOFTWARE ANTIVIRUS .....................................................................................................................................................31

SISTEMI OPERATIVI “GUEST” DEI SERVER ...................................................................................................................31

SISTEMA TELEFONICO ..........................................................................................................................................................32

AFFIDABILITÀ E RIDONDANZA DELLA PIATTAFORMA DI COMUNICAZIONE ...........................................................38

SISTEMA DI REGISTRAZIONE ..........................................................................................................................................39

REQUISITI DELLA FORNITURA ....................................................................................................................................40

SISTEMA DI SUPERVISIONE E REPORTING ..................................................................................................................42

INFRASTRUTTURE SALE OPERATIVE ............................................................................................................................43

COMPONENTI IT PERIFERICHE DELLA SOLUZIONE ........................................................................................................46

INTRODUZIONE ...................................................................................................................................................................46

ALLESTIMENTO SALE OPERATIVE- REQUISITI TECNICI ............................................................................................46

WORKSTATION OPERATORE 118 (NR.48 WORKSTATION)....................................................................................46

2

MONITOR OPERATORE 118 (NR. 48 MONITOR) .......................................................................................................47

MONITOR DI GRANDI DIMENSIONI (NR.12 MONITOR) ............................................................................................48

STAMPANTI MULTIFUNZIONE ......................................................................................................................................48

CUFFIE .............................................................................................................................................................................48

INFRASTRUTTURE SEDI PERIFERICHE .........................................................................................................................49

RETE REGIONALE DELL’EMERGENZA ...........................................................................................................................49

PIATTAFORMA DI TEST .....................................................................................................................................................50

FUNZIONALITÀ APPLICATIVE RICHIESTE ..........................................................................................................................50

SISTEMA DI GESTIONE DELL’EMERGENZA-URGENZA 118 ........................................................................................51

APERTURA DELL’EVENTO ............................................................................................................................................51

GESTIONE DELL’INTERVENTO ....................................................................................................................................52

IDENTIFICAZIONE DEL CHIAMANTE E LOCALIZZAZIONE .......................................................................................52

MODIFICA DI INFORMAZIONI RELATIVE A CHIAMATA GIÀ APERTA .....................................................................52

SUPPORTO ALL’INTERVISTA .......................................................................................................................................52

GESTIONE DELLE CHIAMATE DUPLICATE ................................................................................................................52

GESTIONE DELLE CHIAMATE DA AUDIOLESI...........................................................................................................52

CONSULTAZIONE DEI PAZIENTI A RISCHIO .............................................................................................................52

SINOTTICO DEGLI INTERVENTI...................................................................................................................................53

ZONIZZAZIONE DEL TERRITORIO ...............................................................................................................................53

SCELTA DELLE RISORSE .............................................................................................................................................53

GESTIONE DEI RENDEZ-VOUS ....................................................................................................................................54

RILEVAZIONE DEI TEMPI ..............................................................................................................................................54

DEFINIZIONE DEL PRESIDIO OTTIMALE ....................................................................................................................54

ATTIVAZIONE DI ALTRI ENTI ........................................................................................................................................54

GESTIONE DEGLI ALLARMI DI SICUREZZA ...............................................................................................................54

CHIUSURA DELL’INTERVENTO ....................................................................................................................................54

ALLERTAMENTO PER ATTIVAZIONE DAE (DEFIBRILLATORE AUTOMATICO ESTERNO) ................................55

GESTIONE DEI MAXI-EVENTI .......................................................................................................................................55

GESTIONE DELLE MAXI-EMERGENZE .......................................................................................................................55

GESTIONE DELLE CONSEGNE TRA OPERATORI DELLE CO.................................................................................55

GESTIONE DELLA MESSAGGISTICA E DELLA CORRISPONDENZA .....................................................................55

GESTIONE DELLA CONFIGURAZIONE DI SISTEMA .................................................................................................55

GESTIONE DEGLI INTERVENTI DI ELISOCCORSO ..................................................................................................56

FUNZIONALITÀ TELEFONICHE INTEGRATE ..............................................................................................................56

FUNZIONALITÀ DI REGISTRAZIONE E RIASCOLTO INTEGRATE ..........................................................................56

SICUREZZA APPLICATIVA ............................................................................................................................................56

PRESENTAZIONE DELLA SITUAZIONE AGGIORNATA DELLA CO .........................................................................56

NUE112.............................................................................................................................................................................57

3

CONTINUITÀ ASSISTENZIALE ......................................................................................................................................57

SISTEMA CARTOGRAFICO (GIS) .................................................................................................................................58

GESTIONE VIARIO..........................................................................................................................................................59

INTEGRAZIONE CON IL SISTEMA DI INTERSCAMBIO DEI DATI TRA MEZZO DI SOCCORSO E SALE

OPERATIVE .....................................................................................................................................................................59

SISTEMA DI ALLERTAMENTO ......................................................................................................................................59

GESTIONE POSTI LETTO/RISORSE DISPONIBILI .....................................................................................................59

STATISTICHE EVOLUTE E REPORTISTICA ...............................................................................................................59

CRUSCOTTO DIREZIONALE .........................................................................................................................................60

FUNZIONALITÀ DI GESTIONE E PUBBLICAZIONE DELLE INFORMAZIONI ...........................................................60

FUNZIONALITÀ DI GESTIONE E PUBBLICAZIONE DEL FLUSSO EMUR ...............................................................61

ULTERIORI INTEGRAZIONI RICHIESTE: .........................................................................................................................61

SISTEMA RADIO .............................................................................................................................................................61

SISTEMA DI TELEFONIA................................................................................................................................................61

IL SISTEMA DI REGISTRAZIONE ..................................................................................................................................62

ANAGRAFICA UNICA REGIONALE ...............................................................................................................................63

GESTIONE DEI PRONTO SOCCORSO ........................................................................................................................63

INTEGRAZIONE CED INTERFORZE.............................................................................................................................63

ASSISTENZA E MANUTENZIONE ..........................................................................................................................................63

ASSISTENZA SOFTWARE ..................................................................................................................................................64

ASSISTENZA HARDWARE .................................................................................................................................................64

ASSISTENZA ASSET...........................................................................................................................................................65

SERVIZIO DI HELP DESK ...................................................................................................................................................65

PRESIDIO .............................................................................................................................................................................65

LIVELLI DI SERVIZIO RICHIESTI............................................................................................................................................66

SOPRALLUOGHI ......................................................................................................................................................................67

ATTIVAZIONE DEL SISTEMA .................................................................................................................................................67

SERVIZI DI CONSEGNA, POSA IN OPERA ED AVVIO IN ESERCIZIO ..............................................................................69

GESTIONE PRIVACY E SICUREZZA .....................................................................................................................................70

4

INTRODUZIONE La Regione Siciliana (di seguito “Ente”) ha la necessità di affidare l’attività di rinnovamento tecnologico degli impianti 118 della Regione e la relativa manutenzione ed assistenza interventi di aggiornamento evolutivo ad una impresa qualificata nel settore.

Di seguito vengono riportate le linee guida per lo sviluppo di un’offerta tecnica richiesta:

- Fornitura di licenze software relative al sistema informatico e applicativo di gestione del sistema di emergenza 118;

- Assistenza e manutenzione delle infrastrutture e delle attrezzature informatiche hardware e software in dotazione alle centrali operative regionali comprensive di sistemi telefonici e di registrazione in regime H24;

- Assistenza e manutenzione degli asset presenti nelle centrali operative (Sedute, scrivanie ecc); - Integrazione del Numero Unico Europeo 112 già attivo dal giugno 2017 a Catania ed in corso di

attivazione entro il 2019 a Palermo; - Predisposizione all’attivazione e disponibilità delle funzioni del numero di Continuità Assistenziale

116117; - Integrazione del sistema di tracciabilità per tutti i mezzi in servizio sul territorio per conto del sistema

SUES 118 - Integrazione della scheda medica informatizzata per tutti i mezzi in servizio sul territorio per conto

del sistema SUES 118 - n. 250 giornate “a consumo” all’anno per evoluzioni/personalizzazioni software del sistema

proposto; - modifica della funzione di gestione unica dell’evento di soccorso con possibilità di utilizzo della

scheda evento tra Centrali Operative; - integrazione anagrafica con anagrafe residenti e integrazione pronto soccorso con i sistemi

informativi degli ospedali siciliani;

La durata della fornitura e dei servizi è di 9 anni, che saranno calcolati dalla data di avvenuto collaudo di tutti i beni e servizi richiesti.

Obiettivo finale della presente gara è garantire, attraverso la selezione di un concorrente (di seguito “Ditta”) con elevate competenze e un progetto tecnologico adeguato, la realizzazione di un sistema integrato che implementi il servizio di emergenza della Regione Siciliana che soddisfi al meglio le esigenze dell’Ente e che abbia la flessibilità e la scalabilità necessaria per implementare i possibili scenari futuri delle Centrali Operative regionali e al contempo sia in grado di integrarsi con il Numero Unico Europeo 112 Sicilia.

SITUAZIONE ATTUALE Il sistema di emergenza STI SUES 118, è stato contrattualizzato nel 2013 e gestito dall’Assessorato della Salute con il supporto tecnico di Sicilia e Servizi (oggi Sicilia Digitale). Il progetto STI SUES 118 risponde ai requisiti espressi dal Progetto Esecutivo “Sistema Telematico Integrato per il Servizio di Emergenza Sanitaria

Regionale SUES 118 (STI-SUES118)” agli atti presso il Servizio 6 “Emergenza Urgenza Sanitaria - Isole Minori Ed Aree Disagiate" del Dipartimento di Pianificazione Strategica dell’Assessorato della Salute della Regione Siciliana. La struttura del Servizio S.U.E.S. 118 della Regione Siciliana è multi-provinciale, con la seguente distribuzione

di competenze territoriali:

5

Centrale Operativa Provincia

Caltanissetta

Caltanissetta

Agrigento

Enna

Catania

Catania

Ragusa

Siracusa

Messina Messina

Palermo

Palermo

Trapani

Il sistema è stato integrato nel sistema di emergenza NUE 112 della Sicilia Orientale, facente capo alla CUR di

Catania, per le province di Catania, Siracusa, Ragusa Messina, Enna e Caltanissetta.

Il nuovo servizio, implementato a partire dal giugno dello scorso anno prevede, per le chiamate dell’area della

Sicilia orientale (prefissi 095, 0931, 0932, 0933, 090, 0941, 0942, 0934 e 0935), la consegna delle

chiamate di emergenza del servizio 118 nel formato NUE (Numero Unico d’Emergenza) ovvero nel formato

atto alla localizzazione del chiamante alla CUR di Catania, che sulla base delle procedure già in essere le

smisterà (quando di competenza) alla CO 118 di Caltanissetta, Messina e Catania, comprensive di scheda

contatto.

È inoltre in fase di attivazione la CUR della Sicilia Occidentale presso l’A.O. ARNAS Civico, che avrà le

medesime funzioni della CUR della Sicilia Orientale di Catania per le chiamate dell’area della Sicilia

Occidentale (prefissi 0922, 0925, 0923, 0924, 0921, 091)

Nella seguente figura è illustrato lo schema tipo della Centrale Operativa, con indicate le componenti che la

compongono.

6

È inoltre riportato di seguito lo schema logico del sistema complessivo delle 4 Centrali Operative.

7

Il sistema 118 regionale, così come implementato dall’attivazione del 112 emergenza, è illustrato

schematicamente nella seguente figura:

La sua realizzazione ha previsto le seguenti componenti relativamente al sistema di Fonia: (ISDN BRA e PRA)

acquisita tramite listino Consip fonia, mediante delle personalizzazioni specifiche per il 118 a livello di

centrale pubblica, comprendenti:

l’instradamento delle chiamate di emergenza provenienti da qualsiasi operatore fisso e mobile verso

la Centrale Operativa di emergenza, con invio di CLI e prestazione di override (la CO 118 riceve anche

gli identificativi del chiamante anche in quei casi in cui quest’ultimo abbia disabilitato la trasmissione

del suo CLI, ossia numeri “riservati”);

l’adeguamento del sistema 118 per il servizio NUE 112 (laddove presente) mediante la

configurazione delle linee per far parte di una VPN di fonia nazionale (Gruppo Chiuso di Utente), con

tutte le linee telefoniche delle CUR e degli altri PSAP2 (112, 113, 115 e 118);

realizzazione di un servizio funzionale che prevede l’attestazione dei flussi primari ISDN afferenti a

ciascuna Centrale Operativa su centrali pubbliche urbane (Stadi di Gruppo Urbano - SGU) distinte, con

instradamento sui flussi a divisione di carico e protezione dall’eventuale caduta di uno dei due SGU.

(Il sopradescritto servizio di seguito verrà denominato “Utente Protetto”).

Sistema unico di accentramento guasti (SPOC) sia per le componenti infrastrutturali che applicative;

Accessi alla rete VPN nazionale delle emergenze del Ministero dell’Interno (rete di Telecom Italia non

SPC), con firewall per la protezione di tale rete e dell’accesso ad internet;

Rete dati per collegare le sedi periferiche alle centrali operative, che sono state fornite in

convenzione SPC, un accesso ad internet presso le centrali di Catania e Palermo;

Centrali telefoniche in SPC per le 4 sedi 118 e per la sede di prova, totalmente duplicate. La

realizzazione delle centrali è stata completata con delle personalizzazioni non previste in

Convenzione SPC: funzionalità di call center; interfacciamento ed integrazione con il sistema

applicativo gestionale; predisposizione di un ambiente in grado di lavorare anche senza la presenza

del sistema informativo in grado di gestire la chiamata telefonica in modalità degradata (senza CTI).

Aree critiche

8

Il sistema è stato progettato e realizzato senza singolo punto di fault, prevedendo la ridondanza di tutte le

componenti infrastrutturali ed in particolare dei sistemi telefonici, della infrastruttura di rete telefonica fonia

e dati per offrire la massima affidabilità, secondo le stringenti disposizioni del Ministero dell’Interno.

In definitiva, la situazione attuale, basata su 4 Centrali Operative Multiprovinciali, ha le seguenti limitazioni:

Assenza di logiche di BC/DR tra centrali;

Limitata interconnessione a livello applicativo e di servizio tra le centrali (rete dati di

interconnessione utilizzata solo per comunicazioni telefoniche fra CC.OO. e da/verso sedi

periferiche)

La registrazione dei terminali Telefonici, sui Flussi PSTN (PRI/BRI) e dei terminali radio è effettuata

localmente in ogni Centrale Operativa e non è mai stato attivato lo storage centralizzato di tutte le

registrazioni.

OBIETTIVI DEL PROGETTO Obiettivo principale del progetto è la modifica dell’architettura di gestione del sistema regionale delle

Emergenze Urgenze comprensivo delle componenti attualmente esistenti, individuando una soluzione

tecnologica per accentrare ed integrare le funzionalità delle attuali 4 Centrali Operative. Il nuovo sistema

integrato dovrà mantenere gli operatori fisicamente distribuiti nelle N°4 Sale Operative di Catania,

Caltanissetta, Messina, Palermo, mentre dovrà accentrare le applicazioni, le Risorse Telefoniche e la logica di

commutazione presso due Datacenter regionali.

L’architettura prevedrà quindi:

L’adozione di due Datacenter con servizi di hosting che operino in modalità Attivo/Attivo. Le infrastrutture dei Datacenter saranno l’una vicaria dell’altra con bilanciamento di carico dei due DC. I Datacenter saranno collegati fra di loro e verso le 4 Sale Operative per mezzo di collegamenti ad alta velocità e bassa latenza, con elementi di ridondanza atti a massimizzare la disponibilità del servizio.

Il consolidamento della Rete di accesso telefonico ai servizi di Emergenza in decade (Rete telefonica nazionale dell’Emergenza), secondo indicazioni del Ministero Interno.

Rete dati per lo scambio di informazioni fra CUR NUE 112 e PSAP2: VPN Emergenza (secondo indicazioni del Ministero Interno)

Il consolidamento della rete dati verso i siti periferici, per tenere conto delle crescenti esigenze prevedibili nel tempo di gestione del presente progetto

Sistema di Call Management con funzionalità di Call Center Integrato con il sistema informativo da e in grado di ricevere le chiamate e le schede contatto dalle CUR NUE 112.

La realizzazione di infrastrutture di cablaggio e rete locale adeguate e dotate di opportuni sistemi di

ridondanza, sia presso i Datacenter che nelle Sale Operative 118

La gestione totale della sicurezza perimetrale verso la VPN Emergenza e verso internet

Il consolidamento e aggiornamento dei Sistemi di Registrazione delle telefonate

Il mantenimento della Rete telefonica secondaria in CUG, comprensiva delle linee telefoniche delle

Centrali Operative e dei Presidi Ospedalieri

Il presente progetto rispetterà le seguenti specifiche fondamentali:

Assenza di singoli punti di fault in tutte le componenti interne ed esterne

Resilienza del sistema

Continuità di servizio

9

Protezione della rete di accesso telefonico dell’Emergenza

Rispetto delle direttive del Ministero dell’Interno su: livelli di ridonanza, disaster recovery

automatico, diversificazione chiamate.

Consegna chiamate di emergenza di tutti gli utenti del territorio (indipendentemente dagli operatori

di provenienza).

Accentramento e gestione unica dell’assurance.

Gli obiettivi si possono riassumere nei seguenti punti:

Consolidamento/Razionalizzazione architetturali, attraverso la Centralizzazione di risorse HW/SW in Data Center (Intelligenza di Commutazione, Risorse telefoniche, CTI, DB, Applicativi, Sistema di Archiviazione Registrazioni Telefoniche), mantenendo la fondamentale specifica di assenza di singoli punti di fault in tutte le componenti e massimizzando la continuità di servizio;

Consolidamento degli Operatori in 4 Centrali Operative con dotazioni IT e TLC snelle, lasciando in periferia un insieme minimale di elementi architetturali (Postazioni Telefoniche IP, Postazioni Informatiche, Sistema Radio, Sistemi minimali per la sopravvivenza e il Disaster Recovery);

Utilizzo di tecnologie di rete al massimo livello di prestazioni ed affidabilità per l’interconnessione dei DC e la remotizzazione degli Operatori;

Ottimizzazione della gestione;

Definizione di un Piano di Disaster Recovery / Business Continuity;

Supporto flessibile agli scenari evolutivi a medio/lungo termine;

Rispetto delle direttive Ministeriali su: livelli di ridonanza, disaster recovery, diversificazione

chiamate.

OBIETTIVI DELLA FORNITURA DEL SISTEMA INFORMATIVO L’intera fornitura dovrà consistere nella realizzazione “chiavi in mano” di un sistema informativo e tecnologico l’evoluzione del sistema 118 Sicilia al fine di posizionarlo ai maggiori standard di qualità europei. Con il nuovo sistema la Stazione Appaltante intende migliorare ulteriormente le capacità di resilienza delle applicazioni e dei servizi che esse sottendono realizzando un’infrastruttura a strati indipendenti in cui ogni strato è deputato ad una specifica funzione e ridondando gli elementi di ogni livello applicativo. Concettualmente, si vuole ottenere che un sistema ad un livello N parli con un servizio a livello N+1 senza essere legato ad un indirizzo specifico del server che lo fornisce.

In termini semplificati, si desidera realizzare una architettura a tre livelli (three-tier) basata su web services ove possibile. Il collegamento tra Client e Application Server (AS) passerà attraverso un Load Balancer. Anche il collegamento tra un generico AS e il DB server dovrà essere reso indipendente dalla macchina fisica su cui gira il DB.

La struttura dell'architettura della soluzione deve essere di tipo multi-tier (o multi-Iivello). In particolare viene richiesto che debba essere almeno three-tier basata cioè sui seguenti tre livelli:

1. LIVELLO DI PRESENTAZIONE (o GUI LAYER): è l'interfaccia utente dell'applicazione per acquisire dati e visualizzare risultati,

2. LIVELLO DI LOGICA FUNZIONALE (o BUSINESS LOGIC LAYER): è l'insieme delle regole che verificano i dati come significativi e le relazioni tra essi come consistenti; questo livello genera i risultati richiesti dall'utente,

3. LIVELLO DATI (o DATA BASE LAYER): è l'insieme dei servizi offerti da applicazioni indipendenti dal web (come ad es. i dati in un RDBMS; un sistema di posta elettronica; ecc.).

10

Livello di Presentazione: Le postazioni operatore su cui girerà il livello di presentazione saranno workstation

con le caratteristiche riportate nella descrizione delle postazioni di lavoro. Il sistema operativo sarà Windows

10 Professional o successivo. E’ obbligatorio che il livello di presentazione sia basato su interfaccia WEB (se

non diversamente specificato) e sia completamente compatibile con le ultime versioni di almeno 3 tipologie

di browser di uso comune (Internet Explorer/Microsoft Edge, Mozilla Firefox e Google Chrome, ect.)

Livello di Logica Funzionale: Il livello di logica funzionale comprende tutta la logica applicativa. Il client deve

essere usato solo per la visualizzazione dei risultati che vengono invece elaborati a livello di logica funzionale

su server speculari e ridondanti. I client accedono ai server applicativi puntando ad un “indirizzo logico” che

viene gestito da bilanciatori di carico i quali indirizzano la richiesta ad uno dei server applicativi in funzione

della disponibilità e del carico.

Livello Dati: Si tratta del terzo livello nel quale risiedono le informazioni utilizzate o elaborate dai vari processi

e/o applicativi.

Nell’ambito del sistema informativo l’architettura proposta deve lavorare per blocchi funzionali separati in modo tale che un eventuale guasto su una singola funzione non pregiudichi la funzionalità globale del sistema.

Di seguito si richiede la fornitura e il mantenimento per tutto il periodo contrattuale di:

- Sistema di Gestione eventi Sanitari Urgenti Il sistema di gestione delle emergenze deve consentire di gestire le attività inerenti le Sale Operative Regionale Emergenza Urgenza.

- Sistema di Gestione eventi Continuità assistenziale Il sistema di gestione del servizio regionale di Continuità Assistenziale secondo il modello 116117.

- Sistema di Gestione Trasporto programmato o secondario Il sistema deve consentire la gestione delle attività inerenti il trasporto sanitari, dalle Sale Operative dedicate.

- Interfaccia telefonica posto operatore telefonico informatizzato ed integrato con i moduli software sopra indicati.

- Interfaccia Radio;

- Sistema Cartografico deve integrarsi con i moduli software sopra indicati.

- Interfacciamento con le risorse esterne l’architettura deve permettere l’interfacciamento con le risorse software esterne alle centrali operative (integrazione PS e Anagrafe).

- Gestione dei “Flussi Informativi” deve essere fornito un sistema di invio e controllo dei flussi ministeriali del sistema SUES 118

- Sistema di Business intelligence e reportistica;

- Sistema di Gestione del “Disaster recovery” deve essere fornito un sistema per gestire le situazioni di funzionamento del sistema in modalità degradata.

- Integrazione con Applicazione mobile deve essere integrato il sistema già in nostro possesso per gestire le situazioni di emergenza urgenza sanitaria attraverso l’uso di dispositivi mobili.

- Formazione del personale è richiesto che gli operatori vengano formati ed addestrati all’utilizzo dell’Architettura SW proposta.

- Assistenza e Manutenzione è richiesto il supporto di manutenzione e assistenza dell’architettura Software fornita.

- Evoluzione si richiede di far evolvere le funzionalità e le caratteristiche della architettura SW proposta durante il periodo contrattuale previsto.

11

- Implementazione del sistema proposto (Transitorio) deve essere presentato un progetto completo, che introduca la nuova architettura e contemporaneamente riesca a garantire la continuità di servizio e i livelli minimi di assistenza presenti nell’architettura sw attualmente in uso.

ARCHITETTURA DI RIFERIMENTO Al fine di superare le limitazioni dell'attuale modello, sulla base di quanto indicato nei precedenti capitoli, è volontà dell’Amministrazione la realizzazione di un nuovo sistema regionale dell’emergenza sanitaria, con una profonda revisione architetturale per tutte le componenti previste. Uno schema logico di massima della nuova architettura è rappresentato in figura

Per quanto riguarda la componente telefonica, l'approccio si basa sui principi delle Open Communications. Le Open Communications rappresentano la terza "rivoluzione" del mondo delle comunicazioni e seguono l'avvento del PBX (fine del secolo scorso) focalizzato sulla "telefonia" e del VolP (a cavallo del 2000) focalizzato su un approccio "data-network" teso a sfruttare la convergenza voce dati sulla stessa rete rendendo possibili architetture distribuite a livello geografico. La nuova soluzione, così come quella attuale localizzata nelle 4 Centrali Operative, si basa su un sistema di comunicazione VolP (basato su SIP). Tale sistema è ideale per soluzioni geograficamente distribuite sul territorio e che richiedono architetture e infrastrutture sempre più flessibili e veloci ed è in grado di "seguire" e supportare i diversi cambiamenti organizzativi. La soluzione ipotizzata si compone di un'infrastruttura hardware e di componenti software studiati per offrire un vasto insieme di servizi e per permettere, in modo semplice e a costi contenuti, l'integrazione voce/dati con servizi multimediali e multimodali. In dettaglio, si ritiene funzionale l'installazione di una centrale telefonica costituito da due unità in modalità active/active nei due DC opportunamente dimensionati. Il telefono di una generica postazione di lavoro si registrerà quindi al PABX centrale primario, in caso di indisponibilità di quest'ultimo si registrerà al PABX secondario. Questa modalità sarà valida anche per tutte le postazioni presenti presso le sedi periferiche dove i singoli operatori avranno a disposizione un telefono VolP e una postazione di lavoro collegata agli applicativi di centrale via WEB con un primo vantaggio è la diminuzione degli apparati telefonici presenti nelle singole centrali.

Aree critiche

12

Oggi ogni centrale ha un'infrastruttura telefonica grandemente sovradimensionata in relazione alla numerosità degli operatori. Questo fatto è principalmente dovuto alla necessità di disporre di sistemi in alta affidabilità e forte resilienza. Nella nuova soluzione queste funzionalità sono mantenute e migliorate spostando i sistemi locali a livello centrale e in tale ipotesi bastano solo due PABX e relativi Server CTI per la gestione di tutte le postazioni operatore per la Regione Siciliana. Un secondo vantaggio riguarda l'indipendenza geografica. In questo nuovo scenario sarà possibile configurare in maniera dinamica il luogo dove far pervenire le chiamate indipendentemente dalla posizione geografica degli operatori. Ad esempio, in tutta la Regione Siciliana potrebbe essere possibile avere alcuni medici che coprono il turno di notte e qualunque operatore avesse bisogno di contattarli potrebbe digitare un interno definito a livello regionale senza conoscere la loro esatta ubicazione. Un ulteriore vantaggio riguarda la possibilità di avere un sistema di registrazione centralizzato per tutti gli utenti VolP sia interni, che presso le sedi periferiche coinvolte nel processo di emergenza. In questo modo sarà possibile risparmiare sulla dimensione del registratore, sulla sua ridondanza e sul numero di licenze contemporanee di registrazione. Anche la componente relativa ai sistemi informativi di centrale subirà una profonda rivisitazione architetturale. Come per la parte telefonica, tutte le componenti relative al sistema informativo di centrale risentono del vecchio modello in cui ogni centrale era vista come un elemento autonomo in grado di fronteggiare qualsiasi situazione di degrado (a parte situazioni di indisponibilità dell'intera centrale). In questo senso, ogni centrale è quindi equipaggiata con sistemi ridondati e sovradimensionati al fine di fornire una soluzione ad alta affidabilità unita ad una grande resilienza. È sicuramente possibile ottenere i seguenti vantaggi realizzando un Sistema Informativo centralizzato:

Riduzione del numero di sistemi

Consolidamento di tutti i dati operativi in sistemi di storage centralizzati e quindi raggiungibili da tutte le centrali (condivisione delle informazioni)

Possibilità di attuare soluzioni di Disaster Recovery (oggi non attuate)

Possibilità di rendere disponibili nuovi servizi applicativi immediatamente fruibili da tutte le centrali In ultimo ma forse più importante è la possibilità di sciogliere il legame fisico tra la Centrale Operativa e la propria sala dati. In quest’ottica, ad esempio, un operatore seduto a Caltanissetta potrebbe rispondere e lavorare su chiamate provenienti da Messina.

INFRASTRUTTURE CENTRALIZZATE Il modello descritto nel paragrafo precedente prevede la realizzazione di un sistema centralizzato in tutte le

sue componenti (di infrastrutture di rete locale, telefonica, di registrazione, applicativa, di sicurezza, etc), che

verrà ospitato presso due Data Center Regionali, interconnessi fra loro mediante collegamenti dati dedicati,

a totale ridondanza e diversificazione di percorsi, ad alta velocità e bassa latenza, idonei a realizzare un

collegamento di LAN estesa fra i due datacenter.

La proposta deve quindi prevedere l’implementazione di meccanismi di massima affidabilità trasversali a

tutte le componenti del Datacenter e rivolti alla risoluzione di eventi di fault localizzati all’interno del

Datacenter (alta affidabilità intra-Datacenter) e alla risoluzione di eventi di disastro.

Deve inoltre essere previsto un servizio di backup, con profondità di un mese e che consenta il recupero di

singoli file, presso un sito differente dai due Datacenter regionali,

Ogni sede di Data Center dovrà essere protetta da una recinzione perimetrale, pareti esterne realizzate in

cemento armato ed eventuali vetrate esterne protette da vetri antisfondamento. All’ingresso dovranno

essere presenti dei tornelli con badge magnetico e personale d’accoglienza. Il perimetro del data center

dovrà inoltre monitorato da un sistema di video controllo a circuito chiuso e tutte le telecamere sono

videoregistrate su sistema digitale.

13

La gestione degli accessi al Data Center oltre ad essere preventivamente autorizzata prevede

l’accompagnamento all’interno delle sale per la rintracciabilità del server oggetto di intervento.

La gestione dell’infrastruttura dovrà avvenire attraverso un modello organizzativo con erogazione dei servizi

H24, 7 giorni su 7, che prevedano:

Un NOC (Network Operation Center) – per il monitoraggio la gestione e la configurazione dell'infrastruttura di

rete del Data Center (supervisione proattiva/reattiva della rete, la ricezione di reclami e/o richieste di

supporto su tematiche di rete, diagnosi di primo livello e di secondo livello, etc). Il NOC permetterà di

verificare in modo continuativo le prestazioni dell’infrastruttura al fine di:

gestire la rete, con monitoraggio puntuale di ogni servizio;

valutare il grado di occupazione delle risorse trasmissive;

verificare il corretto dimensionamento complessivo del sistema;

consentire una verifica dei livelli di servizio contrattualmente stabiliti ed il calcolo di statistiche;

fornire reportistica almeno per tutti i livelli di servizio definiti, per tutti i servizi contrattualizzati.

Un SOC (Security Operation Center), per la gestione di tutte le attività volte ad assicurare la sicurezza dei

sistemi e delle operazioni che rientrano nel perimetro della fornitura, secondo una logica di interoperabilità

ed integrabilità. Le attività dei SOC sono riconducibili a:

Security Risk Management;

Security Intelligence & Incident Response;

Data Protection & Privacy;

Security Architecture;

Etc

Il SOC avrà inoltre funzione di supporto specialistico di secondo livello e assicurare le attività di prevenzione e

contrasto delle minacce informatiche allo scopo di mantenere il livello di sicurezza dei servizi in linea con gli obiettivi

prefissati.

Il SOC svolgerà a supporto del network management le seguenti attività:

coordinamento attività di delivery dell’infrastruttura di sicurezza

Gestione degli incidenti di sicurezza.

Una Control Room – per il monitoraggio e la gestione dell infrastrutture informatiche ospitate nei Data

Center (gestione sistemistica delle risorse IT: sistemi operativi, database, middleware, etc).

I DC dovranno essere attrezzati con idonei sistemi e procedure.

a) Impianto elettrico

L’impianto elettrico dovrà essere costituito da idonea cabina ENEL di consegna e trasformatori con

ridondanza N + 1. La continuità elettrica dovrà essere garantita da:

UPS di idonea capacità in parallelo

batterie di idonea capacità, per garantire l’alimentazione di emergenza per un tempo necessario all’avvio dei gruppi elettrogeni

14

almeno un gruppo elettrogeno di idonea capacità a partenza automatica più uno di backup con partenza manuale.

b) Condizionamento

Nell’area I/T devono essere mantenute, sia in estate sia in inverno, condizioni ambientali ottimali per il

funzionamento dei sistemi di elaborazione, per mezzo di gruppi frigoriferi in configurazione ridondante N+1

c) Rivelazione fumi e spegnimento incendi

Tutti gli ambienti della sede devono essere dotati di rilevatori antifumo e antincendio con attivazione dei

relativi impianti di spegnimento automatico degli incendi a saturazione di ambiente. Gli impianti devono

garantire la sola disattivazione della zona oggetto dell’intervento di manutenzione. In particolare l’impianto

di spegnimento deve essere stato progettato nel pieno rispetto della normativa UNI 9795 che garantisce la

segmentazione dell’impianto e di conseguenza la perdita delle sole zone oggetto di eventuale incidente o

calamità naturale ed il continuo funzionamento del resto dell’impianto.

d) Anti allagamento

Devono essere previste delle sonde di rivelazione presenza liquidi nel sottopavimento.

e) Anti intrusione

Il DC deve essere dotato di un sistema di anti intrusione integrato con l’impianto di rivelazione fumi e

spegnimento incendi, con il sistema di TVCC, con il sistema di controllo accessi e con gli allarmi tecnologici.

f) Controllo degli accessi fisici

I data Center devono prevedere sorveglianza armata, procedure di registrazione degli accessi e

identificazione del Personale, accesso alle sale sistemi controllato elettronicamente tramite badge e sistemi

di rilevamento di impronte digitali e controllo del perimetro con impianti a raggi infrarossi.

Presso i due Datacenter, dovranno essere ospitate tutte le apparecchiature e i sistemi indicati nel presente

documento, in apposite strutture protette che isolino i rack che ospiteranno i sistemi 118 da tutti gli altri

rack e server presenti nel Datacenter. L’accesso alle strutture protette, dovrà essere monitorato mediante

lettore di badge, al solo staff addetto alla manutenzione ed alla vigilanza dell’area.

APPARATI DI RETE LOCALE Presso i Datacenter, dovrà essere realizzata una rete locale dedicata ai sistemi del 118 ospitati. La rete locale

dovrà essere realizzata per mezzo di switch totalmente ridondati, sfruttati per la realizzazione di tutte le

VLAN necessarie per il corretto funzionamento dei sistemi.

Per garantire la ridondanza totale, si dovranno seguire le seguenti linee guida:

Server duplicati saranno collegati a moduli diversi degli apparati attivi diversificati

Server singoli dovranno essere dotati di doppia scheda di rete e le stesse dovranno essere collegate a moduli diversi degli apparati attivi diversificati

15

RETE DI ACCESSO Le Centrali Operative 118 devono essere connesse alla rete telefonica pubblica PSTN tramite collegamenti

ISDN PRA (Integrated Services Digital Network - Primary Rate Access) dedicati per l’instradamento delle

chiamate entranti. La numerosità dei canali fonici dovrà essere dimensionata in funzione dei picchi attesi di

intensità di traffico.

Il PABX delle Centrali Operative 118, installato in maniere ridondata presso i due Datacenter, termina i flussi

primari in arrivo dalla rete PSTN e gestisce la risposta automatica e l’accodamento delle chiamate in ingresso

in attesa di essere prese in carico dagli Operatori, provenienti dalle CUR NUE 1 1 2 di Catania e Palermo,

attraverso la Rete Telefonica Nazionale delle Emergenze, realizzata dal Ministero dell’Interno su rete

telefonica ISDN di Telecom Italia, con accessi telefonici dei singoli PSAP 1 e PSAP 2 in configurazione CUG

(Closed User Group).

Le attestazioni alla rete PSTN devono essere in alta affidabilità a fronte di disservizi sulla Centrale Telefonica

pubblica o su un flusso primario. Flussi ISDN di accesso dovranno essere realizzati per mezzo di due diversi

percorsi fisici allo scopo di garantire il funzionamento del call center anche in caso di interruzione totale di

uno dei due collegamenti.

Dovrà quindi essere usato il Servizio “utente protetto” che prevede la duplicazione dell’accesso primario

ISDN configurato in GNR, con attestazione del nuovo accesso a due Centrali differenti, in modo da garantire

che, in caso di guasto di rete o di Centrale, i servizi telefonici continuino a funzionare senza interruzione sia

in ingresso che uscita. Inoltre, per rispondere alle stringenti disposizioni del Ministero dell’Interno relative ai

PSAP 1 e PSAP 2 che accedono al servizio NUE 1 1 2, dovrà essere garantita la totale ridondanza delle

infrastrutture per l’instradamento delle linee di fonia verso il sistema telefonico centralizzato, con totale

ridondanza dei percorsi fisici e utilizzo di infrastrutture ad alta affidabilità (fibra ottica e ADM) per la

consegna dei flussi PRI ISDN

Per ciascuna centrale operativa dovranno essere individuate 2 diverse centrali di terminazione SGU,

attivando la configurazione di utente protetto. La caratteristica principale di tale funzionalità è quella di

avere un unico GNR configurato su due accessi, attestati su due differenti SGU. Per consentire il

funzionamento di tale meccanismo, è prevista l’esistenza di un fascio di collegamento diretto tra i due SGU ai

quali la Centrale Operativa è attestata. In caso di guasto di uno dei due SGU tutte le chiamate dirette verso

quel GNR vengono instradate automaticamente verso l’SGU in funzione.

La funzionalità consente di proteggere dalla indisponibilità di uno dei PABX, se ridondati, o di uno dei flussi

ISDN PRA di terminazione della sede di destinazione delle chiamate e da eventuali fuori servizio dello SGU cui

la sede è attestata.

Sulla scorta dell’architettura precedentemente descritta, il meccanismo di instradamento delle chiamate di

emergenza può essere descritto come segue:

1 L’utente effettua la chiamata di emergenza da rete fissa o rete mobile e la chiamata viene gestita

dalla CUR, che inoltra la chiamata alla centrale di emergenza sanitaria dopo l’intervista iniziale e

localizzazione dell’utente chiamante;

2 La centrale SGU di competenza interpreta l’area di provenienza, modifica la selezione utente sulla

base dell’origine della chiamata, ed instrada la chiamata verso Centrale di emergenza sanitaria. Il

tutto avviene mediante meccanismi di load sharing (lo SGU di origine instrada il 50% del traffico sul

1° SGU di attestazione ed il 50% sullo SGU di protezione);

3 In caso di indisponibilità di uno dei 2 SGU cui è attestata la centrale operativa, lo SGU di origine

provvedere a reinoltrare la chiamata verso l’altro SGU;

16

4 Lato Cliente, l’impegno dei circuiti verso la sede della centrale operativa viene effettuato sulla base

del primo canale disponibile, secondo il meccanismo della ricerca sequenziale;

5 In caso di indisponibilità degli accessi su uno dei due SGU, viene effettuato in automatico il

reinstradamento verso il secondo SGU disponibile, utilizzando i fasci diretti esistenti tra i due SGU;

Il progetto deve prevedere il mantenimento dei fabbisogni individuati di tutte le linee telefoniche afferenti le

ex Centrali Operative 118 e comprendenti le seguenti tipologie (e quantità) di linee:

N. 8 flussi PRI ISDN da 30 canali per ciascuno degli otto flussi, con configurazione di Utente Protetto e

ridondanza fisica, utilizzati per la ricezione delle chiamate di emergenza, dalla CUR NUE 1 1 2 (per

tutte le province servite dalla CO 118 già attive nel servizio NUE 1 1 2 regionale, come Catania,

Siracusa, Ragusa, Messina, Enna e Caltanissetta) o direttamente dai cittadini (per le province non

ancora attivate nel servizio NUE112 regionale, come Agrigento, Palermo, Trapani, in corso di

attivazione). Tali flussi PRI ISDN devono essere realizzati su percorsi trasmissivi interamente

diversificati, sia su strada pubblica che in area privata. I flussi per la ricezione delle chiamate di

emergenza devono essere attestati su Gateway telefonici differenti, per garantire la totale

diversificazione e la massima disponibilità del servizio.

N. 2 flussi PRI ISDN da 15 canali ciascuno, con configurazione di Utente Protetto, per la ricezione

delle chiamate su Numero Verde (come le chiamate da mezzi di soccorso). Gli accessi base per la

ricezione delle chiamate su Numero Verde sono attestati su Gateway telefonici differenti, per

garantire la diversificazione degli stessi.

N. 2 flussi PRI ISDN da 15 canali ciascuno, con configurazione di Utente Protetto, per la gestione delle

chiamate in uscita dalle Centrali Operative e per la gestione del backup delle chiamate verso i presidi

ospedalieri periferici in caso di cadute della rete dati secondaria. I flussi primari per la gestione delle

chiamate in uscita dalle Centrali Operative e per la gestione del backup delle chiamate verso i presidi

ospedalieri periferici sono attestati su Gateway telefonici differenti, per garantire la diversificazione

degli stessi.

17

N. 2 flussi PRI ISDN da 15 canali ciascuno, con configurazione di Utente Protetto e ridondanza fisica,

per la gestione delle chiamate in InterPSAP in uscita/ingresso dalle Centrali Operative e per la

gestione delle chiamate da/verso gli altri PSAP2. I flussi primari InterPSAP sono attestati su Gateway

telefonici differenti, per garantire la diversificazione degli stessi.

Le quantità saranno distribuite equamente sulle due CO che governeranno le sedi di CT-CL e PA-ME.

Le tipologie di linee telefoniche (ad esclusione di quelle per la gestione del Numero Verde) dovranno essere

in Gruppo Chiuso d’Utente (CUG) nella Rete Telefonica Nazionale delle Emergenze.

Infine, sia i flussi PRI ISDN per la ricezione delle chiamate di emergenza dalla CUR NUE 112 sia quelli

InterPSAP, dovranno essere configurati con abilitata la funzionalità UUI (type1), per consentire il processo di

scambio delle schede contatto dalle CUR e da/verso gli altri PSAP2.

Scopo di questo servizio è quello di:

in caso di chiamata ricevuta da altro PSAP, estrarre le informazioni necessarie alla correlazione di una chiamata voce con la scheda di emergenza associata (trasferita per via informatica) e/o alla possibilità di effettuare una ulteriore richiesta di localizzazione al CED interforze ricevuto da rete pubblica PSTN;

in caso di trasferimento di una chiamata ad altro PSAP, inviare, sempre via rete pubblica ISDN, le stesse informazioni al PSAP destinatario.

SICUREZZA E AFFIDABILITÀ DELLA RETE DI ACCESSO AL SERVIZIO 118 La Rete di accesso al servizio “118“ può essere vista come un sistema costituito da una serie di blocchi

fondamentali:

1. La rete d’instradamento e consegna delle chiamate d’emergenza alla singola Centrale

Operativa;

2. Il rilegamento d’accesso della singola centrale alla rete telefonica;

3. Il PABX della Centrale Operativa.

Garantire l’affidabilità della Rete d’accesso al servizio 118 significa garantirsi dall’indisponibilità di ciascuno

dei blocchi costituenti il sistema d’accesso.

La finalità risulta quindi garantire la continuità di funzionamento e la impossibilità di interruzione del servizio

in termini di rete e di apparati fonia.

Per tale ragione sono richieste le funzionalità sotto dettagliate per garantire la massima affidabilità che

compete ad un sistema quale quello dell’accesso al Servizio di Emergenza Sanitario 118.

FUNZIONALITÀ DI “UTENTE PROTETTO” La funzionalità di utente protetto consiste in una soluzione di Disaster Recovery automatica che consente alla

rete di fonia di consegnare le chiamate d’emergenza alle Centrali Operative anche in caso di indisponibilità

della Centrale Pubblica (SGU) a cui la singola Centrale Operativa è attestata e/o di un rilegamento d’accesso

PRI. E’ importante sottolineare che la prestazione di Utente Protetto NON è un semplice servizio di backup di

una linea telefonica. Sia il flusso principale sia quello di protezione sono entrambi attivi, e le chiamate

vengono normalmente instradate su entrambi i flussi.

Tale prestazione si realizza collegando la singola Centrale Operativa ad una coppia di SGU. Il collegamento

viene realizzato tramite una coppia di accessi primari ISDN configurati con lo stesso numero telefonico (GNR,

Gruppo di Numerazione Ridotta).

18

In condizioni normali la rete telefonica consegna le chiamate d’emergenza in load sharing (a divisione di

carico) al 50% sui due accessi primari; in caso di indisponibilità di uno dei due SGU, tutte le chiamate

vengono instradate automaticamente verso lo SGU ancora operativo.

Analogamente in caso di indisponibilità di un PRI tutte le chiamate vengono instradate automaticamente

verso lo SGU su cui è attestato l’altro accesso PRI di protezione.

Funzionalità Utente Protetto

Figura 3 - "Utente Protetto"

La funzionalità d’utente protetto prevede il collegamento della Centrale Operativa ad una coppia di SGU

tramite una coppia di accessi primari ISDN.

RETE TELEFONICA NAZIONALE DELLE EMERGENZE Come indicato nel precedente paragrafo, il sistema 118 regionale dovrà essere integrato con servizio NUE 1

1 2, mediante la configurazione delle linee telefoniche in ingresso ai Datacenter in modo da far parte di una

VPN di fonia nazionale (Gruppo Chiuso di Utente), Rete Telefonica Nazionale delle Emergenze, con tutte le

linee telefoniche delle CUR e degli altri PSAP2 (112, 113, 115 e 118), sia a livello regionale sia a livello

nazionale.

Devono essere configurate in CUG 1000:

1. i flussi PRI ISDN per la ricezione delle chiamate di emergenza 2. i flussi PRI ISDN InterPSAP

# 118

SGU

50% RTG/ISDN

50%

SGU SGU

50% 50%

Centrale

Operativa

19

VPN DELLE EMERGENZE Presso i Datacenter dovranno essere previsti accessi alla rete VPN nazionale delle emergenze del Ministero

dell’Interno (rete di Telecom Italia non SPC), con firewall per la protezione di tale rete e dell’accesso ad

internet;

La VPN delle Emergenze è necessaria per integrare le CO118 al sistema NUE 1 1 2 con le seguenti

funzionalità:

Localizzazione della chiamata 118 nativa (interconnessione con CED interforze, attività effettuata

esclusivamente dalla CUR)

Passaggio della Scheda Contatto (interconnessione IP con altri Enti, attività attualmente effettuata

dalla CUR verso i PSAP 2)

La VPN delle Emergenze è stata realizzata per il Ministero dell’Interno per l’accesso ai servizi su indicati.

Realizzata su rete Hyperway MPLS di Telecom Italia per la quale sono stati concordati costi e livelli di servizio

ad hoc per il progetto NUE 112, comunicati alla Conferenza Permanente per i rapporti tra lo Stato, le Regioni e

le Province Autonome di Trento e Bolzano.

Per ciascuna delle CC.OO., presso i Datacenter, dovranno essere previsti profili di accesso in fibra ottica

ridondati, con servizio di accesso GBE o DWDM, con bande adeguate per lo scambio dei dati dalle CUR NUE 1

1 2 e da/verso gli altri PSAP 2..

Di seguito si riporta lo schema di interconnessione, dove sono evidenziati i rilegamenti e le TdR

(Terminazione di Rete) che realizzano la completa duplicazione della catena.

N.B.: nello schema sono riportati indirizzi INDICATIVI per esempio.

SISTEMA DI SICUREZZA DI PROTEZIONE VERSO LA VPN EMERGENZA L’accesso alla VPN emergenza del Ministero dell’Interno, descritta nel precedente paragrafo, prevede la

protezione della rete da parte di tutti i soggetti che accedono ai servizi erogati dalla stessa (localizzazione del

chiamante, scambio scheda contatto, etc).

A tale scopo, si richiede la fornitura di 4 sistemi in HA, 2 per ciascun Datacenter, basati su Firewall di ultima

generazione, con servizi di Application Control, IPS, Antivirus, Web Filtering e Antispamming, per la durata di

9 anni. Tali firewall consentiranno inoltre la divisione e il routing di tutti i traffici dati delle Centrali Operative.

20

Oltre ai Firewall si richiede la fornitura di un sistema centralizzato, per l’analisi e protezione del traffico dati

delle Centrali Operative.

I firewall dovranno essere interamente gestiti dall’aggiudicatario, attraverso un apposito SOC.

ACCESSO A INTERNET E SICUREZZA Presso i 2 Datacenter, dovrà essere predisposto un doppio accesso verso internet, di banda adeguata alle

esigenze presenti e future del sistema 118 regionale. A protezione degli accessi Internet, verranno utilizzati i

firewall descritti nel paragrafo precedente, in modo da garantire in maniera centralizzata e ridondata la

gestione totale della sicurezza perimetrale del 118 verso il mondo esterno.

COMPONENTI IT CENTRALIZZATE DELLA SOLUZIONE INTRODUZIONE La presente sezione tecnica disciplina l’acquisizione dei server rack standard, del server rack in tecnologia fault tolerant e della SAN necessari affinchè i siti che ospitano i data center delle centrali operative di emergenza urgenza sanitaria 118 si dotino delle infrastrutture IT centralizzate correttamente dimensionate e caratterizzate dalla necessaria affidabilità. Scopo del progetto è infatti quello di realizzare in entrambe le sedi architetture in grado di erogare livelli di affidabilità pari al 99,999% su base annua senza ripercussioni apprezzabili sulle performance globali di sistema. I due siti data center dovranno essere fra loro speculari al fine di essere in grado di sopperire in qualsiasi momento ed in tempi minimi alla eventuale indisponibilità di uno di essi prendendo in carico tutto il traffico regionale.

Tutto quanto richiesto negli articoli di seguito riportati è da intendersi come requisito funzionale o tecnico minimo necessario a pena di esclusione, pertanto nel caso tali requisiti indispensabili non dovessero essere rispettati dal progetto tecnico presentato si procederà all'esclusione dello stesso.

Tutti gli apparati forniti dovranno essere nuovi di fabbrica ed essere costruiti utilizzando parti nuove. Non sono ammesse soluzioni classificabili come prototipi, versioni pre-serie o costruite ad-hoc per l’occasione, per i quali manca qualsiasi riscontro di mercato sulla validità in generale e sull’affidabilità in particolare.

Tutte le licenze HW e SW che accompagneranno la presente fornitura dovranno obbligatoriamente essere intestate al cliente finale. Nel caso tale requisito non dovesse essere rispettato, si procederà all'esclusione della proposta presentata.

SOTTOSISTEMA SERVER CON CARATTERISTICHE FAULT TOLERANT

Quanto segue intende rappresentare i requisiti che il server in tecnologia fault tolerant deve rispettare. Questo sottosistema sarà oggetto di virtualizzazione per tramite di un opportuno layer hypervisor.

Per ogni sito si richiede la fornitura in opera di nr.1 server per sito di tipo fault tolerant (totale in fornitura: nr.2 server). Si definisce fault tolerant la capacità di un apparato di rispondere ad eventi di guasto, di qualsiasi natura essi possano essere, preservando in maniera completa l’operatività degli applicativi da esso ospitati. La fault toleran differisce dalle architetture server caratterizzate da ridondanze interne a livello di alimentatore, processore, memoria, disco in quanto sottende un vero e proprio mirroring sincrono fra le due unità di elaborazione che, insieme, costituiscono l’apparato fault tolerant. Affinchè un apparato sia effettivamente definibile fault tolerant occorre che la disponibilità garantita nell’arco di un anno sia pari ad almeno il 99,999% e nel caso dei server questo valore deve essere sostenuto da

21

processi di mirroring sincroni fra le due unità di elaborazione, altrimenti note come Customer Replaceable Units (CRU), in termini di:

operazioni di calcolo a livello del processore; a fronte di guasto che renda indisponibile il processore, il server fault tolerant proposto dovrà preservare le operazioni di calcolo in corso in quell’istante ed in maniera trasparente ai sistemi operativi ed alle applicazioni ospitate

operazioni lettura e scrittura sulla memoria RAM: a fronte di guasto che renda indisponibili uno o più componenti di memoria, il server fault tolerant proposto dovrà preservare le operazioni di lettura e scrittura in corso in quell’istante ed in maniera trasparente ai sistemi operativi ed alle applicazioni ospitate

operazioni lettura e scrittura sui dischi interni: a fronte di guasto che renda indisponibile l’accesso al disco locale, il server fault tolerant proposto dovrà preservare le operazioni di lettura e scrittura in corso in quell’istante ed in maniera trasparente ai sistemi operativi ed alle applicazioni ospitate

operazioni di I/O sulle interfacce LAN: a fronte di guasto che renda indisponibile l’accesso alla rete LAN, il server fault tolerant proposto dovrà preservare le operazioni di I/O in corso in quell’istante ed in maniera trasparente ai sistemi operativi ed alle applicazioni ospitate

operazioni di I/O (scrittura e lettura) sulle interfacce di attestazione alla Storage Area Network: a fronte di guasto che renda indisponibile l’accesso alla rete di accesso allo storage, il server fault tolerant proposto dovrà preservare le operazioni di I/O in corso in quell’istante ed in maniera trasparente ai sistemi operativi ed alle applicazioni ospitate

Il server fault tolerant richiesto dovrà presentare le seguenti caratteristiche:

fault tolerance realizzata a livello hardware senza introdurre limitazioni di memoria o numero di CPU/core e limitazioni di performance dell’intero sistema; la fault tolerance deve consentire il raggiungimento di livelli di affidabilità certificati pari al 99,999% su base annua

dimensioni e peso che ne consentano l’alloggiamento in rack standard da 19” ed alimentazione compatibile con gli standard italiani

formato rack; non sono ammesse soluzioni di tipo tower

supporto dei seguenti sistemi operativi: Microsoft Windows Server 2016 con virtualizzazione Hyper-V, vmware vSphere 6.0 o superiori, RedHat Enterprise Linux 7.6. Non saranno prese in considerazione soluzioni server fault tolerant che non prevedono sistemi operativi come quelli sopra elencati

nello scenario di virtualizzazione dell’hardware il server non dovrà introdurre vincoli sui sistemi operativi guest assegnabili alle virtual machine

sia in grado di eseguire il boot da SAN (Fibre Channel)

sia dotato di strumenti software di heart-beat e di auto-diagnostica in grado di rilevare e segnalare in tempo reale anomalie di funzionamento e/o guasti al centro assistenza del Produttore operativo H24, 365 giorni all’anno

sia corredato di estensione di garanzia da parte del Produttore che includa la root cause analysis fino al sistema operativo guest

sia soggetto a politiche di “product life cycle” da parte del Produttore che ne garantiscano il supporto per un periodo superiore a 5 anni dall’acquisto

sia dotato di bus interno in tecnologia SAS con velocità superiori a 8Gbps Ciascun server fault tolerant in fornitura dovrà avere il seguente dimensionamento minimo:

22

nr.4 processori dotati di almeno 10 core con frequenza 2,2 Ghz e dotati di hyper-threading (due processori per ogni CRU)

512 GB di memoria RAM DDR4 (256 GB per ogni CRU)

nr.4 interfacce Ethernet 10/100/1000 RJ45 (due interfacce per ogni CRU)

nr.2 interfacce di management Ethernet 10/100 RJ45 (una interfaccia per ogni CRU)

nr.2 interfacce HBA Fibre Channel 8/16 Gbps (una interfaccia per ogni CRU)

nr.4 interfacce 10GE (GigabitEthernet) dotate di connettore per fibra ottica multimodo (due interfacce per ogni CRU)

nr.2 dischi 1.2TB 10 Krpm da 2.5” (un disco per ogni CRU)

Copertura di assistenza e supporto da parte del Produttore con le caratteristiche minime in termini di SLA descritte nel proseguo del documento

Nella risposta tecnica si richiede di indicare anche le seguenti informazioni di natura impiantistica:

numero di Rack Unit (RU) occupate dal singolo apparato

valore in BTU della quantità di calore emesso durante la normale operatività del singolo apparato

Server con caratteristiche fault tolerant (nr.1 server per sito) - Caratteristiche minimali della estensione di garanzia da includere nella fornitura Ciascun server fault tolerant dovrà essere fornito con una estensione di garanzia ufficiale del Produttore atta a garantire quanto segue:

- Estensione pari a 5 anni solari Allo scadere del quinto anno la proposta dovrà obbligatoriamente prevedere la completa sostituzione dei server con apparati aventi caratteristiche tecniche equivalenti o superiori e coperti dalla estensione di garanzia quinquennale.

- Monitoraggio proattivo H24, 365 giorni all’anno erogato in modalità sicura da parte del Produttore sui parametri di funzionamento dell’apparato e basato su strumenti di heart-beat, di diagnostica evoluta e remediation

- Disponibilità degli alerts, delle patch, degli update e di release software non appena disponibili

- La remediation deve anche includere gli automatismi di rilevazione di failure a livello hardware e l’invio automatico presso la sede indicata dalla Committente delle necessarie componenti di scorta

- Analisi di root-cause delle anomalie riscontrate che includa anche eventuali coinvolgimenti e collaborazioni con i Produttori del software di virtualizzazione e della componente storage

- L’analisi di root-cause dovrà estendersi anche ai sistemi operativi guest delle macchine virtuali ospitate sul server

- Livelli di servizio come segue: o Disponibilità del servizio: 24/7/365 o Supporto a livello software e hardware (qualsiasi guasto): presa in carico e prima

risposta entro 30 minuti o Disponibilità delle parti di scorta on site: NBD

23

SOTTOSISTEMA SERVER RACK STANDARD

Seguono i requisiti del sottosistema server standard destinato alla singola sede data center; si rammenta che la fornitura dovrà includere i sottosistemi server destinati ad entrambi i siti data center che saranno fra loro identici.

Il sottosistema server comprende le componenti di computing (di elaborazione dati) centralizzate ed installate su opportuni rack. Questo sottosistema sarà oggetto di virtualizzazione per tramite di un opportuno layer hypervisor.

Il sottosistema richiesto dovrà essere composto da nr. 2 sistemi di elaborazione (n. 2 server per sito) che dovranno essere gestibili integralmente da remoto; l'obiettivo primario a cui devono rispondere i server è indirizzato ad un'architettura che consenta la Business Continuity all'interno del CED e al disaster recovery verso il sito remoto. I server ospiteranno gli applicativi gestionali, cartografici e CTI a supporto delle sale operative ad essi asservite, nonché tutte le componenti software applicative al contorno che si renderanno necessarie alla gestione, all’enforcement delle politiche di sicurezza e di conservazione dei dati.

Per ogni sito si richiede la fornitura in opera di nr.2 apparati aventi le seguenti caratteristiche:

dimensioni e peso che ne consentano l’alloggiamento in rack standard da 19” ed alimentazione in corrente compatibile con gli standard italiani

deve occupare uno spazio rack non superiore a 2 rack unit (2 RU)

formato rack; non sono ammesse soluzioni di tipo tower

supporto di almeno i seguenti sistemi operativi: Microsoft Windows Server 2016 e 2012 R2 con virtualizzazione Hyper-V, vmware 6.0 o superiori, RedHat Enterprise Linux 7, CentOS

nello scenario di virtualizzazione dell’hardware il server non dovrà introdurre vincoli sui sistemi operativi guest assegnabili alle virtual machine

sia soggetto a politiche di “product life cycle” da parte del Produttore che ne garantiscano il supporto per un periodo pari ad almeno 5 anni dall’acquisto

Ciascun server in fornitura dovrà avere il seguente dimensionamento minimo:

nr.2 processori a diciotto core ciascuno con frequenza superiore a 2Ghz, dotati di hyper-threading e appartenenti alla famiglia Intel Xeon (requisito dettato dalla compatibilità a livello processore con altre macchine server che dovranno essere clusterizzate a livello hypervisor)

512 GB RAM DDR4

nr.4 interfacce Ethernet 10/100/1000 RJ45

nr.2 interfacce 10GE (GigabitEthernet) dotate di connettore per fibra ottica multimodo

nr.1 interfaccia di management Ethernet 10/100 RJ45

nr.2 interfacce Fibre Channel 8/16Gbps

nr.2 dischi SSD SATA 240GB

doppio alimentatore

Copertura di assistenza e supporto da parte del Produttore della durata di cinque anni e con le caratteristiche (SLA) sotto descritte

Allo scadere del quinto anno la proposta dovrà obbligatoriamente prevedere la completa sostituzione dei server con apparati aventi caratteristiche tecniche equivalenti o superiori e coperti dalla estensione di garanzia quinquennale H24 (24x7) con intervento on site in 4 ore dalla segnalazione.

24


Potenza assorbita durante la normale operatività del singolo apparato

valore in BTU della quantità di calore emesso durante la normale operatività del singolo apparato

SOTTOSISTEMA STORAGE A BLOCCO E STORAGE AREA NETWORK

Seguono i requisiti del sottosistema storage destinato alla singola sede; si rammenta che la fornitura dovrà includere i sottosistemi storage destinati ad entrambe le sedi Data Center. I sottosistemi storage delle due sedi sono fra loro identici.

Il sottosistema storage si declina nelle seguenti componenti:

componente storage a blocco in tecnologia Fibre Channel

componente SAN switch

componente storage NAS

25

Componente storage a blocco in tecnologia Fibre Channel (nr.1 apparato per sito) Per ogni sito si richiede la fornitura in opera di nr.1 storage a blocco deputato a fornire al sottosistema server i volumi disco necessari alla operatività delle applicazioni software ospitate. La componente storage Fibre Channel in fornitura deve possedere le seguenti caratteristiche minime:

Deve avere dimensioni e peso che ne consentano l’alloggiamento in rack standard da 19” ed alimentazione in corrente compatibile con gli standard italiani

Deve essere equipaggiabile con doppio RAID controller in alta affidabilità

Deve consistere di una soluzione modulare che ne consente la scalabilità mediante aggiunta “a caldo” degli ulteriori cassetti che dovessero rendersi necessari a fronte di un incremento dei dischi. Ogni cassetto deve essere in grado di ospitare almeno 24 dischi da 2,5”

Deve presentare livelli di affidabilità pari al 99,999% su base annua (fault tolerance)

Ciascun RAID controller deve essere dotato di almeno due interfacce verso la SAN di tipo Fibre Channel a 8/16 Gbps

Ciascun RAID controller deve poter essere equipaggiato con una cache di almeno 16GB ridondata ed in grado di completare, assicurando la consistenza dei dati, le scritture su disco in caso di improvvisa interruzione dell’alimentazione

Deve supportare le seguenti tecnologie di disco 2,5”: o Dischi SAS 15krpm o Dischi SAS 10krpm o Dischi NL-SAS 7.2 krpm o Dischi SSD

Nella risposta tecnica si prega di fornire l’elenco delle tipologie di disco supportate specificandone il volume in GB o TB che le contraddistingue

Deve supportare almeno i seguenti livelli RAID: 0, 1, 1+0, 5, 5+0, 6

Deve supportare la funzionalità di disco “hot spare” la cui presenza è richiesta nella configurazione dell’apparato riportata più avanti

Deve presentare bus interni ridondati di collegamento ai dischi con throughput di almeno 12Gbps in protocollo SAS

Deve supportare almeno i seguenti sistemi operativi: Microsoft Windows Server 2016 / 2012 R2 / 2012 /2008 R2, Red Hat Enterprise Linux 7 / 6 / 5, SUSE Linux Enterprise Server 15 / 12 / 11, Oracle Linux 7 / 6 / 5, vmware vsphere 6 / 5

Deve essere dotato di interfaccia Ethernet RJ45 dedicata al management

Deve essere dotato di software di management di tipo web based accessibile da almeno i seguenti browser: Internet Explorer, Chrome, Firefox, Safari

Deve essere soggetto a politiche di “product life cycle” da parte del Produttore che ne garantiscano il supporto per un periodo pari ad almeno 5 anni dall’acquisto

Deve essere dotato delle seguenti funzionalità software obbligatorie: o Thin provisioning o Connettori di integrazione con la suite di virtualizzazione vmware: vCenter Plug-in,

vStorage APIs for Storage Awareness (VASA), Storage Replication Adapter (SRA), VMware vSphere Storage APIs Array Integration (VAAI)

Deve essere dotabile, per eventuali esigenze future, con le seguenti funzionalità software opzionali (non richieste nella presente procedura):

o Funzionalità avanzata di snapshot

26

o Funzionalità di tiering automatico dei dati su dischi di tecnologia differente (SSD, SAS, NL-SAS)

o Replica remota su protocollo IP sincrona e asincrona o Funzionalità nativa NAS (protocolli CIFS, NFS)

Per venire incontro ad eventuali esigenze future: o deve presentare un livello di scalabilità tale da portare ad almeno 260 le unità disco

totali gestite o deve poter essere attestato a livello di Storage Area Network ad almeno 64 host

(numero massimo di host in SAN) Ciascun apparato storage in fornitura dovrà avere il seguente dimensionamento minimo:

Doppio controller Fibre Channel 8/16 Gbps, 16 GB cache

Doppio alimentatore

Spazio disco netto: o 12 TB di disco SSD (spazio calcolato dopo almeno il RAID 5 e la formattazione dei

dischi); è richiesta la presenza di almeno un disco “hot spare” di questo tipo o 10 TB di disco SAS 10krpm (spazio calcolato dopo almeno il RAID 5 e la formattazione

dei dischi); è richiesta la presenza di almeno un disco “hot spare” di questo tipo o 90 TB di disco NL-SAS 7,2krpm (spazio calcolato dopo almeno il RAID 5 e la

formattazione dei dischi); è richiesta la presenza di almeno un disco “hot spare” di questo tipo

Funzionalità software descritte in precedenza e definite come “obbligatorie”

Copertura di assistenza e supporto da parte del Produttore pari ad almeno 5 anni e con le caratteristiche minime in termini di SLA descritte nel proseguo del documento


Potenza assorbita durante la normale operatività del singolo apparato

Valore in BTU della quantità di calore emesso durante la normale operatività del singolo apparato

Rack unit totali necessarie per l’installazione dell’apparato Lo storage dovrà essere fornito con una estensione di garanzia ufficiale del Produttore atta a garantire quanto segue:

- Estensione pari a cinque anni solari - Disponibilità degli alerts, delle patch, degli update e di release software non appena

disponibili - È ritenuto un aspetto migliorativo la possibilità di assoggettare lo storage ad un sistema di

monitoraggio evoluto da parte del Produttore della tecnologia proposta al fine di intercettare in tempi estremamente brevi guasti ed anomalie hardware e software

- Livelli di servizio come segue: o Disponibilità del servizio: 24/7/365 o Risoluzione del problema mediante accesso da remoto o intervento on site: 4 ore

solari Allo scadere del quinto anno la proposta dovrà obbligatoriamente prevedere la completa sostituzione degli storage con apparati aventi caratteristiche tecniche equivalenti o superiori e

27

coperti dalla estensione di garanzia quinquennale H24 (24x7) con intervento on site in 4 ore dalla segnalazione Componente SAN switch Fibre Channel (nr.2 apparati per sito) Per ogni sito si richiede la fornitura in opera di nr.2 switch SAN. Questa componente consentirà la realizzazione della Storage Area Network disaccoppiando e mettendo in comunicazione i server e lo storage a blocco. La fabric realizzata attraverso i due SAN switch sarà a un livello e dovrà presentare caratteristiche di fault tolerance assicurando una affidabilità del 99,999% su base annua. Il singolo SAN switch in fornitura deve possedere le seguenti caratteristiche minime:


Deve avere dimensione massima d 1 RU

Deve supportare i protocolli standard che definiscono l’accesso al disco in modalità Fibre Channel

Deve essere dotato di almeno 24 interfacce Fibre Channel autosensing ed opzionalmente programmabili a velocità fisse; è richiesto il supporto dei seguenti throughput: 8Gbps e 16Gbps

Deve essere pienamente compatibile con i server e lo storage proposti

Deve essere pienamente compatibile con il software di virtualizzazione vmware vsphere e Microsoft Hyper-V

Dimensione massima di frame supportata (payload): 2.112 Byte

Deve essere dotato di interfaccia Ethernet RJ45 dedicata al management out-of-band


Ciascun apparato SAN switch in fornitura dovrà avere il seguente dimensionamento minimo:

Almeno 16 interfacce licenziate per operare in protocollo Fibre Channel 8 o 16 Gbps

Le interfacce licenziate dovranno essere equipaggiate con l’opportuno transceiver e l’opportuna patch in fibra ottica di lunghezza di almeno 3 metri (sono richiesti almeno nr.8 transceiver e nr.8 patch f.o. 3 mt per ciascun apparato)

Copertura di assistenza e supporto da parte del Produttore pari ad almeno 5 anni e con le caratteristiche minime in termini di SLA descritte nel proseguo del documento



Potenza assorbita durante la normale operatività del singolo apparato Sono richieste le stesse caratteristiche di estensione di garanzia a 5 anni solari descritte per la componente di storage a blocco. Anche per i SAN switch è valutato come aspetto migliorativo la possibilità di assoggettare gli apparati ad un sistema di monitoraggio evoluto da parte del Produttore della tecnologia proposta al fine di intercettare in tempi estremamente brevi guasti ed anomalie hardware e software.

28

Allo scadere del quinto anno la proposta dovrà obbligatoriamente prevedere la completa sostituzione degli switch con apparati aventi caratteristiche tecniche equivalenti o superiori e coperti dalla estensione di garanzia quinquennale H24 (24x7) con intervento on site in 4 ore dalla segnalazione

SOTTOSISTEMA STORAGE NAS

Per ogni sito si richiede la fornitura in opera di nr.1 storage NAS per sito. Questa componente assumerà il ruolo di repository dei file che necessitano di archiviazione su disco; a titolo di esempio e non esaustivo si citano i file delle registrazioni telefoniche, i backup del database ed i file prodotti dall’esecuzione dei backup delle macchine virtuali applicative. Il repository sarà attestato alla LAN del sito e dovrà esporre share di tipo CIFS e NFS. La componente NAS storage in fornitura deve possedere le seguenti caratteristiche funzionali e di dimensionamento minime:


Deve occupare uno spazio rack non superiore a 2 rack unit (RU)

Deve essere dotato di una interfaccia Ethernet RJ45 dedicata al management out-of-band


Deve esporre almeno i seguenti protocolli NAS: CIFS e NFS

Deve essere dotato di almeno nr.4 interfacce GigabitEthernet RJ45

Deve essere dotato di dischi in tecnologia SAS

Deve presentare uno spazio disco netto prima della deduplica non inferiore a 16 TB

Deve essere dotato di meccanismi automatici finalizzati ad assicurare la consistenza e la correttezza dei dati archiviati; fra questi meccanismi si richiedono almeno i seguenti:

o il rilevamento e correzione automatica di fenomeni di corruzione del dato nel momento della sua prima scrittura sui dischi locali dell’apparato

o l’utilizzo di buffer NVRAM o similari che consentano di terminare le scritture sui dischi locali al verificarsi di interruzioni improvvise di alimentazione elettrica

o la verifica periodica della consistenza dei dati ospitati sui dischi locali dell’apparato; a fronte del rilevamento di un errore il sistema deve essere in grado di mettere in atto processi automatici finalizzati alla sua correzione

o la protezione a livello disco attraverso meccanismi RAID 6 a doppio disco di parità o la presenza di un disco spare pronto ad essere utilizzato in maniera automatica dal

sistema in sostituzione a un disco andato incontro a guasto o meccanismi di ripristino a livello di file system

Deve essere dotato della funzionalità di deduplica dei dati secondo le seguenti caratteristiche mandatorie:

o La deduplica deve essere realizzata in collaborazione e a divisione di carico elaborativo con il software di backup grazie alla integrazione fra quest’ultimo e l’apparato NAS storage (si prega di indicare i software di backup disponibili sul mercato che presentano l’’integrazione richiesta con lo storage NAS proposto)

29

o La deduplica deve essere realizzata, dinamicamente e non su base configurazione, su segmenti di Byte a lunghezza variabile in modo da massimizzare l’efficacia della deduplica stessa

o La deduplica deve essere realizzata nel momento in cui i dati arrivano all’apparato e non dopo la loro scrittura sui dischi locali

Il sistema proposto deve essere dotato della funzionalità di replica asincrona su IP dei dati di backup; la replica dovrà avere come target l’apparato “gemello” ospitato sul sito remoto.

o La replica deve beneficiare della già descritta funzionalità di deduplica affinchè solo segmenti di dati prima non presenti vadano ad impegnare il canale di comunicazione ed i dischi del sistema remoto

Deve essere dotato della funzionalità di cifratura dei dati secondo le seguenti caratteristiche mandatorie:

o La cifratura deve attenersi agli standard a 128 bit e 256 bit AES ed essere realizzata prima della scrittura di un nuovo dato su disco

o I processi di cifratura e decifratura messi in atto sui dati at rest devono essere completamente trasparenti alle applicazioni/utenti che interagiscono con il sistema NAS e sui processi di replica in essere da e verso il sistema NAS remoto;

o Un file estratto/letto dal sistema NAS dovrà essere reso disponibile in chiaro e nel suo formato nativo al sistema/utente richiedente

o Nel processo di acquisizione di nuovi dati, la cifratura deve avvenire solo dopo la fase di deduplica in modo che i dati soggetti a crittazione siano i soli segmenti non ancora presenti nel sistema

o Le chiavi utilizzate per la cifratura dei dati devono essere a loro volta crittate

Deve essere coperto da un contratto di assistenza e supporto da parte del Produttore pari ad almeno 5 anni e con le caratteristiche minime in termini di SLA descritte nel proseguo del documento



Potenza assorbita durante la normale operatività del singolo apparato Ciascuno storage NAS dovrà essere fornito con una estensione di garanzia ufficiale del Produttore atta a garantire quanto segue:

- Estensione pari a cinque anni solari - Disponibilità degli alerts, delle patch, degli update e di release software non appena

disponibili - È ritenuto un aspetto migliorativo la possibilità di assoggettare lo storage ad un sistema di

monitoraggio evoluto da parte del Produttore della tecnologia proposta al fine di intercettare in tempi estremamente brevi guasti ed anomalie hardware e software

- Livelli di servizio come segue: o Disponibilità del servizio: 24/7/365 o Supporto da remoto: presa in carico e prima risposta entro 4 ore solari o Intervento hardware on site, inclusa la consegna in opera parti di scorta: NBD

30

Allo scadere del quinto anno la proposta dovrà obbligatoriamente prevedere la completa sostituzione degli storage con apparati aventi caratteristiche tecniche equivalenti o superiori e coperti da estensione di garanzia quinquennale con le medesime caratteristiche e SLA descritti in precedenza.

SOFTWARE DI BASE INTRODUZIONE Il presente capitolo disciplina l’acquisizione del software di base che si intende necessario per le infrastrutture IT centralizzate e periferiche al servizio dell’Emergenza Urgenza Sanitaria 118 della Regione Sicilia. Quanto segue intende rappresentare i requisiti a cui il software di base dei due siti dovrà rispondere.

Tutto quanto richiesto negli articoli di seguito riportati è da intendersi come requisito funzionale o tecnico minimo necessario a pena di esclusione, pertanto nel caso tali requisiti indispensabili non dovessero essere rispettati dal progetto tecnico presentato si procederà all'esclusione dello stesso.

Quanto fornito dovrà essere nuovo di fabbrica; non sono ammesse soluzioni classificabili come prototipi, versioni pre-serie o sviluppate ad-hoc per l’occasione, per i quali manca qualsiasi riscontro di mercato sulla validità in generale e sull’affidabilità in particolare.

SOFTWARE DI VIRTUALIZZAZIONE DELL’HARDWARE È richiesta la fornitura di un software di virtualizzazione a copertura dei tre host descritti nel capitolo precedente. Il software di virtualizzazione proposto deve rendere disponibili le seguenti caratteristiche minime:

Presentare un ambiente di gestione che, per ogni sito, renda possibile il governo del virtual data center in termini di configurazione e monitoraggio delle macchine virtuali (VM)

Dalla interfaccia di management dovrà essere possibile la definizione e memorizzazione di template delle macchine virtuali e delle virtual appliance; dalla interfaccia dovrà essere possibile eseguirne il deploy

Consentire l’utilizzo di almeno i seguenti sistemi operativi guest: Microsoft Windows Server e Linux (RedHat, CentOS, Ubuntu)

Consentire il clustering dei server che dovranno risultare come un unico pool di risorse a disposizione della piattaforma di virtualizzazione

Integrarsi con il sottostante storage a blocco al fine di utilizzare i volumi disco come datastore del sistema; l’integrazione con lo storage deve consentire anche operazioni di management quali il monitoraggio dei volumi, il thin-provisioning, il cloning e l’esecuzione di snapshot delle VM direttamente dalla console di management dell’ambiente virtualizzato senza richiedere allo storage operazioni ad alto impatto sulle risorse di CPU e memoria

Consentire lo spostamento a caldo delle macchine virtuali in maniera trasparente alle applicazioni e senza arrecare disservizi agli utenti

Consentire l’alta affidabilità delle macchine virtuali affinchè, a fronte di un guasto di un server, esse possano eseguire una ripartenza automatica sui rimanenti host del cluster. La ripartenza dovrà tenere conto delle affinità VM/server e delle priorità di reboot impostate dalla console di management dell’ambiente virtuale

31

Includere una soluzione nativa di protezione dei dati che ne consenta il backup agentless e che sia utilizzabile, in qualità di primitiva software, dall’applicativo di backup i cui requisiti sono esplicitati nel proseguo del documento

Includere una soluzione nativa di replica delle macchine virtuali che sia utilizzabile, in qualità di primitiva software, dall’applicativo di backup i cui requisiti sono esplicitati nel proseguo del documento

Le licenze del software di virtualizzazione dell’hardware dovranno essere coperte dai relativi servizi di support e maintenance del Produttore per tutto il periodo di validità del contratto.

SOFTWARE DI BACKUP E REPLICA DELLE MACCHINE VIRTUALI E DEI DATI Si richiede la fornitura di un software di backup e replica tale da coprire, in termini di licenze, le necessità di ciascun sito che, si ricorda, sarà composto da tre host per un totale di sei processori. Il software di backup deve presentare i seguenti requisiti:

Il software deve possedere una integrazione con il sottostante software di virtualizzazione dell’hardware allo scopo di sfruttarne le primitive per l’effettuazione di backup e repliche in locale e/o sul sito remoto

Il software deve mettere a disposizione una console di gestione attraverso la quale sia possibile gestire le schedulazioni dei job ed in generale accedere alle funzionalità messe a disposizione dal software stesso

Il software deve consentire il ripristino di un'intera macchina virtuale sull'host originale o su uno diverso e includere la funzionalità di rollback veloce per ripristinare solo i blocchi modificati

Il software deve consentire l’avvio di una VM direttamente dai file di backup salvati nel repository

Il software deve includere strumenti per l’esecuzione di test e verifica dei backup e delle repliche delle VM

Il software deve consentire il ripristino di singoli file e dischi virtuali di una VM; la funzionalità deve essere disponibile sui file system comunemente usati in ambienti Windows e Linux

Il software deve consentire la ricerca e il ripristino degli oggetti Active Directory (es. utenti, gruppi, account)

Il software deve integrarsi con lo storage NAS proposto affinchè la deduplica dei dati sia realizzata in collaborazione e a divisione di carico elaborativo con esso

Il software deve implementare la cifratura dei dati trasferiti verso il repository target utilizzando protocolli standard AES 256-bit

Il software deve consentire il roll-back delle repliche, il fail-back ed esporre strumenti per l’orchestrazione dei processi di fail-over

Le licenze del software di backup dovranno essere coperte dai relativi servizi di support e maintenance del Produttore per tutto il periodo di validità del contratto.

SOFTWARE ANTIVIRUS È richiesta la fornitura di almeno 120 subscription antivirus che dovranno essere rinnovate senza oneri per la

Committente per tutto il periodo di validità del contratto.

Il software antivirus proposto non dovrà in alcun modo ostacolare il corretto funzionamento delle

componenti applicative real time e non real time della piattaforma applicativa.

SISTEMI OPERATIVI “GUEST” DEI SERVER È richiesto che per ogni host di ciascun sito Data Center siano fornite le licenze abilitanti alla attivazione di un

numero illimitato di macchine virtuali con guest OS Microsoft Windows Server.

32

SISTEMA TELEFONICO Il sistema telefonico verrà installato in configurazione totalmente ridondata presso i due Datacenter, e

consentirà di gestire tutte le chiamate in ingresso e uscita dalle 4 Sale Operative, presso le quali risiederanno

solo, dal punto di vista telefonico, i telefoni degli operatori e gli elementi necessari a garantire la

sopravvivenza delle Sale Operative nei casi, per quanto improbabili, di indisponibilità dei servizi forniti dai

Datacenter.

È quindi importante la progettazione e realizzazione di un sistema in grado di garantire la massima

disponibilità del servizio in una configurazione distribuita.

Le architetture di comunicazione di nuova generazione sono in grado di offrire alte prestazioni in termini di

flessibilità applicativa, scalabilità, ridondanza e sicurezza e, al contempo, la piena aderenza agli standard di

comunicazione ed inoltre consentono la semplificazione dell’interoperabilità con piattaforme e sistemi

standard multivendor disponibili sul mercato oltre a mantenere il supporto di tecnologie consolidate come

ad esempio terminali digitali e/o analogici.

L’adozione di un’architettura basata su differenti strati funzionali abilita la flessibilità necessaria a supportare

i requisiti di integrazione delle funzionalità di comunicazione con i processi operativi e i relativi sistemi a

supporto in ambito servizi di Emergenza, garantendo l’affidabilità e la continuità delle operazioni che da

sempre costituiscono un elemento fondamentale nell’ambito di questa tipologia di servizi.

L’utilizzo di protocolli IP based standard come SIP, H323, H248, MGCP, ha consentito di centralizzare gli

elementi di controllo delle sessioni e di logica applicativa nei Data Center con il vantaggio di semplificare le

operazioni di gestione e supervisione fornendo servizi omogenei per tutte le utenze centrali e remote e

servizi di sopravvivenza e continuità del servizio in locale e in remoto. Il supporto nativo degli standard di

comunicazione IP basati su protocollo SIP e H323 e, analogamente, codec RTP standard, senza richiedere

interfacce o gateway dedicate che traducano gli stessi in modalità di comunicazione proprietarie facilita

l’interlavoro in contesti multivendor. La disponibilità di Media Gateway H.248 dotati di molteplici schede

(Media Modules) consente inoltre di supportare qualsiasi tipo di terminale (analogico, digitale, IP H323, IP

SIP).

Il modello architetturale a strati che si intende adottare come piattaforma di riferimento è un modello che

replica in ambito large Enterprise le caratteristiche del modello IMS (IP Multimedia Subsystem) proprio delle

reti dei Service Provider mobili. In tale modello architetturale è possibile identificare 3 livelli di riferimento

(come mostrato in figura):

33

Il livello di accesso dove risiedono gli elementi che abilitano l’accesso ai servizi da parte degli utenti

quali terminali hardware (come telefoni, desktop o terminali mobili) o software (applicazioni su

Desktop, smartphone o tablet), sistemi di comunicazione di tipo tradizionale come PABX o

KeySystem o terminali analogici a standard BCA o digitali proprietari oltre a terminali (e antenne)

DECT a standard GAP. Nello stesso layer si considerano le interfacce di accesso verso la rete pubblica

(PSTN TDM o SIP) rappresentati dai Media Gateway / Media Server e dal Session Border Controller. I

Media Gateway /Media Server assicurano le risorse DSP necessarie ad es. funzionalità quali gestione

della codifica/decodifica, erogazione annunci centralizzati, annunci di coda, musica su attesa, ecc.

Il livello di controllo (o gestione delle sessioni), il cui compito principale è quello di essere “motore

logico” della rete che svolge le funzioni di Proxy e Registar SIP dell’intera rete e orchestra le modalita

in cui il livello di accesso utilizza e invoca le applicazioni che risiedono al livello superiore.

Il livello applicativo in cui risiedono i server applicativi dove vengono erogate le prestazioni utente e

vengono implementati i processi applicativi. Essi sono di due tipologie:

o Application Server per prestazioni di telefoniche, nel seguito chiamato Telephony Server o

Call Server, che eroga servizi tipici dei PBX quali gestione delle chiamate, trasferta e

deviazione della chiamata, conferenza, gruppi di risposta e di pickup e molti altri servizi, e

che implementa le logiche di controllo dei Media Gateway avanzati, dei terminali non IP

(analogico, digitale) collegati ai media gateway e di utenti e linees IP H323.

o Application Server per servizi di comunicazione evoluta e di nuova generazione quali ad

esempio: Sistemi di messagistica vocale, di Instant Messaging & Presence, sistemi IVR

avanzati, Applicazioni di Contact Center e Unified Communicatio ecc.

o Ambiente di sviluppo (SDK) aperto e basato su standard per la realizzazione di applicazioni

personalizzate da affiancare alle applicazioni già disponibili all’interno della piattaforma di

comunicazione.

34

Il disaccoppiamento dello strato applicativo da quello di gestione delle sessioni nei sistemi di comunicazione

consente, in modo del tutto analogo alle architetture Web ed IMS sopra citate, di sviluppare applicazioni

sulla base delle specifiche necessità dell’utente in modo agile, flessibile e rapido, senza dover modificare

l’intero codice, a fronte di nuove specifiche o di modifiche dei servizi applicativi.

Nel dettaglio è richiesto che il sistema che gestisce le comunicazioni dell’infrastruttura di Emergenza sia

composto dai seguenti moduli funzionali:

Modulo Telephony Server incaricato di erogare i servizi tipici dei PBX (funzionalità telefoniche globali

e servizi utente). Il ruolo del Telephony Server, all’interno dell’architettura di riferimento, è quello

“Application Server” per le funzionalità telefoniche. A tale modulo è anche richiesto di mantenere

una certa “continuità con il passato” e quindi di assicurare il supporto e le logiche di controllo dei

Media Gateway, dei terminali non IP (analogici e/o digitali) collegati ai media gateway oltre che di

utenti e linee IP.

In particolare, il Telephony Server deve offrire un ricco set di servizi per l’utente, per l’operatore e di

sistema (ad esempio direttore\segretaria, indicazione di occupato, deviazione della chiamata,

conferenza, etc). Inoltre esso deve soddisfare i requisiti di connessione di reti eterogenee

supportando i protocolli standard di connessione (ISDN, Q.SIG, H323, SIP, etc) e trasportando tutte le

funzionalità, definite all’interno delle specifiche, anche su reti geografiche a pacchetto.

Tra le peculiarità richieste al modulo di Telephony Server vi è la capacità di realizzazione di alberi IVR

anche complessi con riconoscimento di toni tramite le funzionalità di “prompt e collect” e di

gestione di code ACD per mezzo di meccanismi di scripting con interfaccia visuale. Infine, per quanto

riguarda i principali dati di capacità ed espandibilità:

o Una singola istanza di Telephony Server deve poter gestire fino a 36.000 utenti in tecnologia

mista IP/TDM su singolo server.

o Deve essere possibile espandere le capacita’ dell’intero sistema aggiungendo altri Telephony

Server fino a raggiungere 350.000 utenti

Inoltre sono richieste al modulo di Telephony Server le seguenti funzionalità di distribuzione

automatica delle chiamate da utilizzarsi a fronte di eventuale indisponibilità della componente

applicativa a supporto degli operatori delle centrali operative distribuite sul territorio della Regione.

o Definizione di regole per la distribuzione delle chiamate ed il trattamento dell’attesa in coda.

Si richiede la disponibilità di un linguaggio di scripting per la definizione delle policy utilizzate

per la gestione delle chiamate che permetta di utilizzare costrutti logici e variabili. Deve

essere possibile la definizione di orari e calendari di servizio (per regolare automaticamente

il comportamento del sistema in base alla disponibilità del servizio).

o Selezione dell’Operatore più esperto (skill based routing) - L’ACD può instradare le chiamate

all’Operatore più preparato per gestire il particolare contatto in base a delle competenze

stabilite in fase di programmazione. All’interno di ogni skill potrà essere definito il livello di

competenza su una scala da 1 a 16. L’assegnazione delle funzionalità ad uno specifico

Operatore può essere legata alla Login-ID del singolo Operatore e non alla postazione

telefonica (es: free seating).

o Metodo di distribuzione delle chiamate - La distribuzione delle chiamate da parte dell’ACD

può essere realizzata implementando uno dei seguenti metodi:

Operatore libero da più tempo (la chiamata viene accodate all’Operatore con lo skill

richiesto e che risulta libero da più tempo)

Operatore percentualmente meno occupato (la chiamata viene accodata

all’Operatore con lo skill richiesto e con la minore percentuale di occupazione)

35

Quest’ultima metodologia di distribuzione consente di bilanciare il carico di lavoro tra gli

operatori del servizio in particolare in ambienti dove agli operatori stessi sono assegnati più

skills.

o Distribuzione per livelli di servizio - La soluzione ACD può assicurare la gestione della

distribuzione delle chiamate per livelli di servizio: quando un operatore diventa disponibile,

deve essere eseguita un’analisi sulle chiamate in testa alle diverse code relative agli skill che

l’operatore che si e’ appena liberato possiede. Per ognuna delle chiamate in testa alle varie

code da gestire, è valutato quanto segue:

Calcolo del Tempo Attuale d’Attesa

Previsione della quantità di tempo (Previsione d’Attesa) che la chiamata dovrà

attendere per un altro operatore opportunamente skillato se tale chiamata non

venisse assegnata all’Operatore che si è appena reso disponibile

Somma dei due tempi, Tempo Attuale d’Attesa + Previsione d’Attesa, per

determinare il Tempo d’Attesa Previsto di ogni chiamata (PWT)

Confronto del Tempo d’Attesa Previsto con l’Obiettivo di Servizio (SO) definito per la

coda

Confronto di questi rapporti per determinare quello più alto. La chiamata con il

rapporto maggiore è quella con la più alta necessità di servizio e dovrà essere inviata

all’operatore disponibile.

o Operatori di riserva – In ragione della casualità nell’arrivo delle chiamate e di circostanze

talvolta imprevedibili (es. picchi di traffico improvvisi), esiste il bisogno di pianificare gli

overflow in modo di aiutare gli skill che si trovano a gestire condizioni di sofferenza. Nel

definire nuovi processi di workflow uno degli obiettivi da perseguire e’ sicuramente quello di

automatizzare il più possibile le regole di overflow, definendo in base ai livelli di servizio

impostati delle soglie di overflow, calcolate sulla base del tempo di attesa previsto,

oltrepassate le quali interviene automaticamente un gruppo di Operatori di riserva. Si

possono definire sull’ACD alcuni Operatori come “Reserved” e utilizzare queste risorse nei

casi di necessità improvvise. L’aggregazione degli Operatori Reserved avviene in modo

automatico così come automaticamente ne avviene il rilascio. Tramite tale funzionalità il

supervisore del Call Center viene scaricato dalla responsabilità di dover reagire in maniera

manuale alle mutate condizioni di traffico del Call Center stesso. Inoltre l’automatismo

garantito da questa funzionalità consente di evitare errori umani nella allocazione /

deallocazione delle risorse.

o Routing sul miglior sito, bilanciamento del carico e distribuzione percentuale su i siti – Il

software ACD è in grado di instradare le chiamate a disversi siti sulla base di:

presenza dello skill adeguato

minore tempo di attesa previsto per la chiamata in coda

aderenza ad una percentuale configurata di chiamate per ciascun sito

Tale meccanismo può essere applicato in tempo reale ad ogni chiamata gestita e non può

essere basato su dati statistici. Questo garantirà al chiamante di venire servito

dall’Operatore più competente con il minore tempo di attesa, ridurrà le chiamate

abbandonate e permetterà il corretto bilanciamento del carico tra i siti.

o Distribuzione condizionata dalla digitazione di cifre da parte del chiamante - L’ACD è in grado

di distribuire le chiamate ad Operatori (o a gruppi di risposta) utilizzando le informazioni

digitate dal chiamante (via toni DTMF). Tale funzionalità è integrata all’interno del sistema

ACD e non richiede componenti esterne (es: piattaforma IVR dedicate). E’ richiesta

l’implementazione integrata di alberature vocali e, in base alle scelte effettuate dal

chiamante, è possibile accodare la chiamata all’operatore corretto. Le informazioni ricavate

36

dal chiamante possono essere comunicate ad applicazioni CTI esterne per mezzo del modulo

di interfaccia con applicazioni esterne.

o Comunicazione del tempo di attesa in coda - L’ACD può fornire ai chiamanti in coda,

utilizzando le risorse annunci integrate, il tempo di atteso previsto prima che la chiamata

venga inviata ad un Operatore. In tale modo viene lasciata al chiamante la scelta di rimanere

in attesa o, eventualmente, poter lasciare un messaggio in un sistema automatico.

Modulo Interfaccia Applicazioni CTI che fornisce servizi di integrazione applicativa con le funzionalita’

erogate dal Telephony Server tramite una suite di interfacce di programmazione applicative (API)

basate su protocolli e servizi Web standard, quali: Computer-Supported Telecommunications

Applications (CSTA), Java Telephony API (JTAPI), Telephony API Server (TSAPI), Web Services con

metodi Simple Object Access Protocol (SOAP)/XML, etc.

Modulo di Accesso alla rete telefonica (Gateway) che permette da un lato l’interfacciamento verso la

rete PSTN via interfacce ISDN Accesso Primario, ISDN Accesso Base e Linee Analogiche e dall’altro

l’attestazione di terminali utenti sia di tipo IP che di tipo tradizionale (Digitali e/o Analogici).

All’interno dei Gateway devono risiedere le necessarie risorse DSP (Digital Signalling Processor) per

le conversioni TDM/IP, per l’adattamento di codec e tutto quanto necessario all’interconnessione

con la rete e le utenze. Da ultimo all’interno dei Gateway e’ richiesta la disponibilita’ di risorse

annunci integrate per l’erogazione locale di messaggi di accoglienza, coda, menu vocali collezione di

cifre digitate dal chiamante.

Modulo di Accesso alla rete telefonica SIP (Session Border Controller) che permette di interfacciare il

fornitore delle linee di accesso/uscita tramite connettivita’ IP su protocollo SIP. Tale modulo

permette la definizione di una interfaccia sicura tra il Service Provider e l’infrastruttura a supporto

dei servizi di Emergenza. Garantisce funzionalita’ di firewall SIP e capacita’ di manipolazione dei

messaggi SIP. Inoltre permette l’accesso sicuro di eventuali operatori dei servizi di emergenza che si

trovassero ad operare da remoto o da terminali mobili (smartphones).

Modulo di gestione e configurazione della piattaforma che consente la configurazione, via interfaccia

Web, di utenze e sistemi. Questo elemento realizza un framework flessibile, efficiente e user

friendly, rispondente ai più moderni standard di Service Management per le attività di

amministrazione e configurazione dei sistemi. Il modulo deve offrire una console comune per le

esigenze di amministrazione, network routing policy (definizione delle regole di dial plan) e della

sicurezza.

Modulo di reporting ACD che permette la raccolta dei dati delle chiamate gestite dal software ACD e

fornisce le statistiche relative al funzionamento dei gruppi di risposta e degli Operatori. Il sistema

rende possibile ad uno o più supervisori il controllo e l'analisi della gestione delle chiamate in

funzione degli skill disponibili, delle risorse e delle richieste in modo da poter variare il trattamento

delle chiamate e migliorare costantemente la produttività del servizio. Il modulo di reporting riceve i

dati in tempo reale dal Telephony Server li aggrega e li rende disponibili ai supervisori con

un’interfaccia grafica in ambiente MS Windows o per mezzo di un browser Internet. Il modulo di

reporting deve possedere un set cospicuo di report preconfigurati e deve permettere la

personalizzazione dei report per mezzo di un’applicazione guidata (es: Wizard). L’accesso ai report

deve essere profilato e sicuro in modo da garantire la riservatezza dei dati e per poter separare le

stastistiche delle varie centrali operative. Inoltre l’interfaccia grafica in uso ai supervisori del servizio

deve consentire la gestione in tempo reale degli skills degli operatori in modo da condizionare la

distribuzione delle chiamate a fronte di picchi improvvisi di traffico

Terminali Telefonici IP per le postazioni operatore. Ogni postazione operatore deve essere

equipaggiata con un terminale telefonico IP che possa gestire i protocolli H323 oppure SIP. Il

terminale dovra’ essere registrato su due o più Gatekeeper/Registrar allo scopo di gestire eventuali

indisponibilità di uno di questi elementi. Allo scopo di ampliare la dotazione di pulsanti di ogni

37

singolo terminale IP è richiesta la disponibilità di moduli tasti addizionali (fino a 3) per ogni Terminale

IP. Le caratteristiche del terminale IP dovranno avere le seguenti caratteristiche tecniche minimali:

Hardware

o Display monocromatico o a colori – 3.2 inches x 2.2 inches (8.2 cm x 5.5 cm)

o 8 bottoni con doppio LED

o 4 tasti programmabili via software

o Tastiera con tasti per messaggi vocali, contatti, home page telefono, call history, cuffie,

vivavoce, regolazione volume, muto

o Tasto con led rosso per altoparlante, muto, cuffia, messaggi, call history

o 24 Softkey di amministrazione

o Wideband audio sia in cornetta che in cuffia

o Vivavoce full duplex

o Indicatori per il message waiting

o Suonerie

o Supporto di cuffie Bluetooth e DECT (mediante adattatore)

o Porta Ethernet 10/100/1000 Mbps

o Seconda Porta Ethernet 10/100/1000 Mbps

o PoE Class (IEEE 802.3af) class 1 device

o Supporto moduli espansione tasti (fino a 3)

Software

o protocollo SIP e H.323

o Standards-based codec: G.711, G.729A/B, G.722

o Supporto delle principali lingue oltre all’Italiano

Il terminale telefonico deve essere controllabile da applicazioni esterne mediante Link CTI. In caso di

indisponibilità dell’applicazione CTI in uso all’operatore, il terminale telefonico dovrà

automaticamente essere disponibile per la distribuzione delle chiamate ACD effettuate dal

Telephony Server. A tale proposito è richiesta la disponibilità di tasti funzione programmabili con

almeno le seguenti funzionalità:

o Login, Logout, Pausa, After Call Work.

Terminali Telefonici Evoluti. Questi terminali telefonici utilizzano la tecnologia “touch screen” e sono

basati su sistemi operativi aperti, quindi ampiamente personalizzabili. Tali terminali permettono di

utilizzare funzionalità integrate di voce, video e collaborazione e sono dotati di API/SDK che ne

permettono la personalizzazione in base alle esigenze operative dell’utilizzatore. Il dispositivo è

caratterizzato da un ampio display touchscreen e dalla possibilità di avere una video camera integrata

per fruire in maniera nativa dei servizi di collaborazione audio/video/web.

Le caratteristiche tecniche minimali di questi terminali sono definite di seguito:

o Display 8 "display a colori touch capacitivo

o Risoluzione: 1280 X 800 pixel

38

o 24 bit di profondità di colore.

o Audio a banda larga disponibile sulle cornette, cuffie e vivavoce

Codec supportati: G.722, G.711, G.729, Opus

o WiFi integrato

o Nessuna tastiera fisica

o MWI (Message Waiting Indicator)

o RJ9 porta analogica auricolare

o RJ45 Porta Ethernet 10/100/1000 Mbps Gigabit POE

o RJ45 Porta Ethernet secondaria 10/100/1000 Mbps

o Presa jack audio da 1X da 3,5 mm

o USB Tipo-C

o Connettore per alloggiamento cornetta

o Wi-Fi

Modalità access point wireless.

Wi-Fi 802.11a / b / g / n / ac.

o Bluetooth integrato per accessori opzionali (es. cuffie)

Terminale Telefonico Software (Softphone). Come alternativa al terminale fisico è richiesta la

disponibilità di un equivalente terminale telefonico software (Softphone). Funzionalmente simile al

terminale telefonico IP, il softphone deve poter essere installato su diversi sistemi operativi quali:

o MS Windows 7, 8.1 e 10

o Linux Suse e Debian

o Apple macOS 10.13 High Sierra e macOS 10.14 Mojave

Il softphone deve supportare i protocolli H323 e SIP e deve poter essere utilizzato in ambiente ACD,

quindi controllato da applicazioni CTI esterne e dotato delle funzionalità di Login, Logout, Pausa,

After Call Work

AFFIDABILITÀ E RIDONDANZA DELLA PIATTAFORMA DI COMUNICAZIONE L’architettura della piattaforma di comunicazione deve supportare i massimi livelli di affidabilità. In

particolare si richiede una duplicazione della piattaforma per entrambi i datacenter regionali nei quali

verranno implementate le funzionalità di Accesso, Telephony Server, SIP Proxy Registrar ed interfacciamento

dei sottosistemi di Call Recording e di Moduli applicativi in uso agli operatori.

I server fisici ove risiedono i moduli costituenti la piattaforma di comunicazione dovranno essere

equipaggiati con schede di rete multiple, alimentazione ridondata e dischi in RAID.

Allo scopo di garantire la massima affidabilità si richiede che il guasto di un componente dell’infrastruttura di

comunicazione non infici il funzionamento del servizio. È pertanto richiesta la duplicazione dei moduli

costituenti la piattaforma di comunicazione per entrambi i Data Center Regionali. In tali Data Center è

prevista la connettività verso le linee telefoniche di ingresso/uscita le quali saranno attestate su entrambi i

siti in modalità di bilanciamento del carico.

Nelle sedi ove sono previste le centrali operative è richiesta la disponibilità di linee locali, attestate a

Gateways di accesso in grado di garantire le funzionalità di accoglienza, annunci, distribuzione delle chiamate

secondo logiche ACD anche a fronte di eventuali guasti della connettività di rete o di indisponibilità di

entrambi i Data Center regionali. Le sedi operative pertanto saranno in grado di smistare il traffico in

ingresso/uscita anche in caso di completo isolamento.

È richiesto che i terminali IP in uso agli Operatori siano registrati su diverse destinazioni (es: Data Center 1,

Data Center 2, Telephony Server Locale) in modo da garantire l’operatività del terminale telefonico a fronte

39

di possibili guasti / interruzioni dei servizi offerti dai Data Center Regionali. Il meccanismo di registrazione dei

terminali IP deve rispettare la figura seguente:

Durante la normale operatività, quando tutti i sottosistemi funzionano regolarmente, le chiamate in

ingresso/uscita sono processate dal Telephony Server del Data Center 1 (attivo) il quale è costantemente

allineato con i Telephony Servers in standby (localizzati presso il Data Center 2 e in ogni sala Operativa). In

caso di guasto del Telephony Server attivo il Telephony Server in stand-by prende il controllo delle chiamate

e garantisce la continuità delle operazioni assicurando la gestione dell’intero pool di Operatori. In caso di

guasto del Telephony Server del Data Center 2, ogni sala Operativa dovrà essere gestita dal Telephony Server

locale.

Le funzionalità telefoniche (incluse quelle inerenti alla gestione dell’accoglienza tramite messaggi vocali,

all’erogazione di alberature IVR con navigazione DTMF, alla gestione degli annunci di coda e della

dsitribuzione ACD) erogate dai Telephony Servers locali devono essere le medesime disponibili su Telephony

Server implementati nei due Data Center.

Le linee di ingresso/uscita devono essere attestate a Gateway dotati di alloggiamenti multipli per schede sia

di interfaccia telefonica ISDN (Accesso Primario e Accesso Base) che per linee Analogiche. Inoltre i medesimi

Gateway dovranno poter ospitare interfacce telefoniche per la gestione di terminali tradizionali (Telefoni

Digitali e Analogici). Così come per i server della piattaforma di comunicazione, anche per i Gateway è

richiesto un doppio alimentatore per ogni Gateway oggetto dell’infrastruttura. E’ anche richiesta, all’interno

dei Data Center regionali la predisposizione di più Gateways con la relativa distribuzione delle interfacce di

accesso (Schede ISDN) allo scopo di minimizzare rischi di indisponibilità di accesso ai servizi.

SISTEMA DI REGISTRAZIONE È previsto il recupero e aggiornamento degli attuali sistemi di registrazione audio NICE INFORM che

l’Amministrazione, con Palermo, ha completamente attivato a fine 2018 nelle quattro CC.OO. 118. Ciò allo

40

scopo di continuare a garantire l’operatività e la compatibilità tecnica secondo gli stessi standard in essere,

siano essi i parametri di archiviazione dei file, la cifratura dati, le regole di accesso ed utilizzazione, i criteri di

controllo che altre collaudate funzionalità ed impostazioni fino ad oggi implementate. Per agevolarne

l’utilizzo, anche l’interfaccia GUI di gestione rimarrà la medesima.

Tutto ciò al fine di preservare il livello prestazionale raggiunto nonché salvaguardare l’investimento

economico già effettuato e di fornire delle nuove funzionalità evolutive atte ad incrementare il supporto

all’attività e all’efficienza operativa del servizio.

Attualmente in ogni CO è presente un’architettura Core/Satellite duplicata e indipendente, in altri termini si

registra in parallelo più volte la stessa conversazione così da garantire in caso di intervento di

riconfigurazione, manutenzione preventiva, guasto di una componente, di continuare a registrare tutte le

conversazioni e di memorizzarle su un doppio archivio.

Tali principi e criteri di alta affidabilità presenti attualmente nelle CO devono essere mantenuti trasferendo e

centralizzando la tecnologia suddetta nei due Datacenter, riconfigurandola per volume e tipologia di canali in

rapporto alle nuove linee e telefoni da registrare. In pratica si dovrà prevedere il riutilizzo centralizzato della

maggior parte delle licenze/canali TDM e di tutte quelle VoIP dei posti operatori di Regione sui datacenter. Si

dovrà prevedere una componente server satellite duplicata da interfacciare verso la rete telefonica in

modalità VoIP passivo ed integrare tali comunicazioni con l’applicativo di gestione emergenze.

Pur nell’evoluzione dell’architettura telefonica descritta, si dovranno mantenere presso le CO le componenti

server/schede di interfacciamento TDM minimali per le linee urbane che localmente continueranno ad

essere attestate come riserva.

Ove disponibile la proposta deve considerare l’aggiornamento HW e SW delle unità esistenti all’ultima

release raggiunta dal produttore. L’eventuale fornitura dovrà essere compatibile e conforme per

caratteristiche tecniche, modalità di configurazione e modalità di gestione, ai sistemi di registrazione già in

uso. Sempre nell’ottica di tutela dell’investimento già effettuato da questa Amministrazione,

l’aggiornamento dovrà in ogni caso prevedere il recupero delle schede di interfaccia canali e soprattutto

delle licenze attualmente in uso.

Preso i Datacenter, dovrà inoltre essere realizzato un sistema di storage, come repository di tutte le

registrazioni audio del sistema 118 regionale (flussi primari centralizzati, trunk SIP verso operatori e verso

sedi periferiche, linee di emergenza delle Sale Operative, registrazioni radio etc, per una durata non inferiore

a 10 anni. Tale repository dovrà contenere, oltre alle nuove registrazioni, anche le registrazioni pregresse

delle 3 Centrali Operative, sia degli attuali registratori che dei vecchi registratori analogici, in modo da

eliminare qualunque problema di manutenzione di apparati obsoleti e di difficile (per cui costosa)

manutenzione. La proposta dovrà pertanto prevedere anche l’attività di recupero delle registrazioni dagli

attuali supporti in atto esistenti.

Tale scelta progettuale, garantisce quindi un risparmio per l’Amministrazione in considerazione dell’alto

costo di licensing dei canali voce dei recorder, oltre al risparmio legato ai costi non più necessari di

manutenzione dei vecchi sistemi di registrazione.

REQUISITI DELLA FORNITURA Deve essere previsto l’aggiornamento all’ultima release sw disponibile di NICE Inform insieme a tutti i moduli

applicativi che formano la sua suite (Organizer, Reconstraction, Verify, ecc.) per:

recupero, riascolto, analisi e verifiche eventi;

accorpamento dati ricavati anche da altre fonti (video, foto, testi, GIS, ecc.);

analisi multi-mediale/dato per tutti i contributi associati all’evento;

supporto organizzativo, report e rappresentazione scenario maxi-emergenze;

41

statistiche evolute, avanzate in tempo reale;

estrazione massiva di file;

riascolto immediato ultime chiamate per supporto agli operatori;

screen recording e quality management per sostegno alla formazione.

Deve essere previsto l’aggiornamento delle componenti server e OS Windows 2016 nonché un’archiviazione

centralizzata su NAS in alta affidabilità. Deve essere rispettata continuità e compatibilità tra precedente e

futuro archivio.

La funzione Core Licensing deve garantire anche in futuro la possibilità di spostare e attribuire le licenze

canali tra più server e/o schede, tra più tipologie di segnale e modalità di registrazione (es. trasformare lic.

canali analogici che non vengono più utilizzati a nuovi canali VoIP).

Si provvederà alla fornitura di Modulo Pannello Allarmi su touch screen per avviso immediato di: caduta del

flusso primario 118 (dipendente anche da rete), interruzione dell’archiviazione audio, problema su HDD,

problema su alimentatore.

Il software di gestione dei registratori dovrà essere Web Based e dovrà prevedere le seguenti funzionalità

minime se non già presenti sugli attuali sistemi di registrazione:

Accesso contemporaneo tramite GUI (Graphical User Interface) Web per un numero illimitato di utenti senza necessità di acquistare licenze aggiuntive;

Accesso al sistema attraverso delle credenziali (user e password) con un periodo di validità delle stesse limitata nel tempo;

Creazione e gestione di privilegi (con un elevato grado di configurabilità) da assegnare al singolo utente o a gruppi di utente;

Personalizzazione dell’interfaccia grafica in funzione dei privilegi assegnati;

Tracciamento di tutte le operazioni eseguite dagli utenti e loro visualizzazione diretta;

Riproduzione ciclica di sezioni di chiamata a velocità variabile;

Esportazione dei files audio registrati nei formati commerciali più comuni (wav, mp3, ecc.);

Monitoraggio in tempo reale dei canali in registrazione, riascoltabili a conversazione non ancora ultimata;

Il sistema deve crittografare le registrazioni audio mediante sistema AES Rijndael 256 bit e Fingerprinting MD5 in modo da proteggere i files da riproduzioni, alterazioni o modifiche non autorizzate. In fase di replay, attraverso l’interfaccia web deve essere data evidenza all’utente che il file riprodotto corrisponde a quello originale registrato. Il sistema deve segnalare eventuali manomissioni dei file audio originali;

Possibilità di archiviazione delle registrazioni su storage esterno (almeno fino a 3 location indipendenti);

Possibilità di aggiungere, oltre a marker e tag automatici dell’applicativo di emergenza, note a commento ai file registrati, queste note potranno poi essere utilizzate come parametro di ricerca;

Possibilità di Integrazione CTI con i maggiori vendor di PBX e produttori nazionali di gestionali di emergenze e soccorso, funzionalità disponibili senza l’acquisto di eventuali licenze aggiuntive;

Il software di gestione dei registratori dovrà inoltre prevedere le seguenti funzionalità evolutive:

Dovrà essere possibile inibire in fase di riascolto una o più parti di una specifica conversazione, il relativo file audio potrà essere salvato introducendo del silenzio nelle parti “oscurate” o riproducendo un segnale audio;

Riproduzione di più registrazioni contemporaneamente (audio, screen, video, sms, ecc.) almeno fino a 16, con possibilità di modificare il volume di riproduzione per ogni singola registrazione;

Possibilità di importare audio, video, immagini di terze parti (TVCC, webcam, smarthphone,…) al fine di utilizzare anche questi dati esterni per l’analisi completa di uno specifico evento. Questi contributi

42

esterni dovranno essere riproducibili sulla base dei tempi attraverso la GUI del registratore al fine di ricomporre nella sua interezza, e con tutti i contributi correlati, lo scenario da analizzare;

Possibilità di importare documenti esterni quali immagini, .doc, .pdf,…, al fine di utilizzare anche questi dati esterni per l’analisi completa di uno specifico evento. Questi contributi esterni dovranno essere visualizzabili attraverso la GUI del registratore al fine di ricomporre nella sua interezza, e con tutti i contributi correlati, lo scenario da analizzare;

Possibilità di esportare in maniera sicura tutto il materiale associato ad uno specifico evento (audio, video, sms, screen,…). Lo stesso dovrà essere reso disponibile all’esterno e riproducibile da una terza parte attraverso una applicazione stand alone del tutto simile a quella della GUI del registratore, questo al fine di agevolare la condivisione delle informazioni sulla base delle funzionalità disponibili. Dovrà essere possibile visionare sia i singoli contributi che sincronizzare e riprodurre gli stessi sulla base dei tempi in maniera strutturata. L’accesso al materiale condiviso dovrà essere protetto da password al fine di garantirne la sicurezza e l’integrità;

Disponibilità opzionale di un modulo aggiuntivo, sempre integrato nella GUI del registratore, per il monitoraggio della qualità del servizio a partire dal riascolto delle registrazioni. Lo scopo è quello di analizzare le informazioni archiviate al fine di realizzare una formazione adeguata al personale, il tutto nel rispetto delle normative vigenti.

Disponibilità opzionale di un modulo aggiuntivo, sempre integrato nella GUI del registratore, per realizzare statistiche sulla base delle registrazioni effettuate, quali ad esempio:

o Utilizzo della risorsa o Chiamate registrate per risorsa

Possibilità opzionale di integrazione con cartografici GIS al fine di associare ad una registrazione, radio o telefonica, anche la localizzazione geografica.

SISTEMA DI SUPERVISIONE E REPORTING Le attività di supervisione, monitoraggio, controllo e reporting saranno svolte da una soluzione tecnologica

fortemente innovativa, capace di integrare una serie di funzionalità allo stato dell'arte negli ambiti di

pertinenza, permettendo in questo modo di gestire in modo efficiente e funzionale la complessa architettura

del servizio "118" che, schematicamente può riassumersi nelle seguenti macrocategorie:

reti LAN/WAN

centrali telefoniche

componenti hardware delle centrali operative

piattaforme software In questo modo, si potrà essere avvisati in tempo reale di eventuali anomalie e/o malfunzionamenti che

possano interessare le componenti monitorate, fare bench-marking, analizzare le prestazioni della

piattaforma.

L’implementazione della soluzione di gestione e controllo, in lingua italiana, consentirà di traguardare i

seguenti obiettivi:

Definire un modello schematico e rappresentativo del servizio "118", dove si mettano in evidenza le relazioni tra elementi tecnologici in esercizio, e si attui una corretta stratificazione ed identificazione dei servizi e dei sotto-servizi erogati.

Sviluppare Mappe e Sinottici all'interno della Piattaforma di Gestione Controllo che facciano riferimento al modello proposto e che evidenzino le interazioni tra gli elementi monitorati e il loro ambito d'intervento.

Integrare all'interno della Piattaforma, tutti i controlli hardware e software necessari per l'identificazione e la rilevazione di allarmi in tempo reale provenienti dagli elementi posti sotto monitoraggio.

43

Predisporre l'archiviazione dei dati e degli andamenti acquisiti dalla Piattaforma di Gestione al fine di analisi e successive valutazioni.

Realizzare degli strumenti che permettano l'inoltro degli allarmi verso gruppi ed entità adibite alla gestione del Sistema "118"

Effettuare misure di Performance e SLA per ogni elemento controllato e in relazione al modello schematico del Servizio "118" proposto dall’Amministrazione.

Le finalità operative saranno pertanto le seguenti:

Identificazione immediata da parte del Supervisore circa la natura del fault e dell'allarme riscontrato, circoscrivendo ed evidenziando le dirette relazioni interessate tra l'elemento in allarme e gli elementi tecnologici direttamente e/o indirettamente coinvolti.

Il sistema sarà in grado di individuare fisicamente l’ubicazione della porta di uno switch di rete a cui è connesso un apparato IP, rilevando e registrando in modo puntuale le modifiche alla configurazione degli apparati nella rete, con la possibilità di raggiungere in modo capillare, tramite l'indirizzo MAC la porta, l'interfaccia ed il nodo in cui ha avuto luogo la variazione di configurazione. Il sistema allo stesso modo è in grado di riconoscere un fault di rete, localizzando il sito in cui ha avuto luogo il guasto. Tali azioni sono armonizzate all'interno di una serie di criteri che permettono di associarne delle criticità e di stabilirne la gravità.

Definizione di alert, soglie, eventi e/o comunque delle azioni di notifica e/o correttive al fine di centralizzare e razionalizzare il controllo della piattaforma.

Costruzione di un archivio storico degli eventi in tempo reale e degli allarmi riscontrati.

Determinazione della qualità del servizio offerto, considerando i livelli di efficienza e di disponibilità nel tempo circa l'erogazione e la fruibilità del sistema "118" alle utenze finali.

INFRASTRUTTURE SALE OPERATIVE Presso le sale operative, saranno ospitate le apparecchiature necessarie per la gestione delle chiamate di

emergenza provenienti dalle CUR, limitate, oltre ai telefoni e ai PC dei Posti Operatore, alle infrastrutture di

rete locale, agli apparati radio e a tutti i dispositivi necessari per poter garantire la sopravvivenza delle Sale

Operative in casi, per quanto eccezionali, di indisponibilità delle infrastrutture centralizzate ospitate dai

Datacenter.

Dovranno quindi essere garantiti meccanismi di inoltro delle chiamate alle Sale Operative in maniera diretta

dalle CUR.

Le sale operative dovranno quindi essere equipaggiate con:

accessi dati ridondati e totalmente diversificati verso la Rete Regionale dell’Emergenza, per mettere in comunicazione le Sale Operative con i due Datacenter Regionali

Linee telefoniche di emergenza, in configurazione Utente Protetto con funzionalità mista, per la ricezione delle chiamate dalle CUR, per le chiamate InterPSAP, per le chiamate da/verso siti periferici, per il Numero Verde.

Gateway telefonici con funzionalità di sopravvivenza, ridondati, per l’attestazione delle linee telefoniche di emergenza

Sistemi radio

Sistemi di registrazione per tutte le chiamate radio e per le chiamate telefoniche afferenti le Sale Operative in caso di funzionamento in sopravvivenza

Dovrà essere previsto l’adeguamento e aggiornamento dell’infrastruttura LAN già attiva presso le sedi delle

sale operative.

44

Nelle seguenti figure sono illustrati i criteri di dimensionamento delle Sale Operative, in modo da garantire

una distribuzione di chiamate omogenea per sala operativa sulla base della popolazione servita.

45

Oltre alle su indicate postazioni si richiede la fornitura aggiuntiva di un numero di postazioni di riserva da

utilizzare in scaso di sovraccarico di emergenza e con funzione di ridondanza come di seguito indicato:

n. 2 postazioni aggiuntive per la sala operativa di Messina

n. 4 postazioni aggiuntive per la sala operativa di Caltanissetta

46

COMPONENTI IT PERIFERICHE DELLA SOLUZIONE INTRODUZIONE Segue il dettaglio delle dotazioni informatiche previste nelle sale operative per le quali è richiesta la fornitura in opera. Numero postazioni operatore:

• Palermo: 15 • Catania: 15 • Caltanissetta: 9 • Messina: 9

Ogni postazione si compone di una workstation e di un monitor. Numero monitor grandi dimensioni a parete previsti:


Per ogni monitor a parete è richiesta la fornitura di un mini PC di dimensioni tali da consentirne l’installazione sul retro del monitor. Numero stampanti di rete


ALLESTIMENTO SALE OPERATIVE- REQUISITI TECNICI Per far fronte alle esigenze di rinnovo tecnologico delle postazioni di sala di risposta, è richiesta la fornitura in opera delle workstation e dei monitor destinati alle sale di risposta 118. Seguono le caratteristiche hardware minime richieste per l’hardware destinato agli operatori:

WORKSTATION OPERATORE 118 (NR.48 WORKSTATION)

L’apparato deve avere caratteristiche di Workstation e non di semplice PC Desktop; deve essere in grado di operare ininterrottamente 24x7x365

L’apparato deve essere di Brand primario del quale è comprovabile il già avvenuto utilizzo, con esito ottimale, per la realizzazione di postazioni di lavoro di centrali operative NUE 112 e/o di emergenza urgenza sanitaria 118

L’apparato deve essere corredato da una soluzione di montaggio VESA in metallo che ne consenta il fissaggio su un elemento d’arredo (fondo scrivania, parete divisoria, ...)

Dimensioni massime consentite (escluse staffe e sistema di fissaggio): altezza 8 cm, larghezza 30 cm, lunghezza 30 cm

Peso: inferiore ai 2,5 Kg

Alimentatore a 220Volt e potenza max 250 W

CPU della famiglia Xeon (o equivalente) con almeno 4 core/8 threads e frequenza di clock pari ad almeno 3,0 Ghz

RAM: non meno di 8 GB

Disco interno: SSD 256 GB

Sistema Operativo: Windows 10 Professional Edition

Prese video: 4 Porte Video (HDMI e/o Display Port v. 1.2) con supporto monitor UHD/4K

Interfaccia Ethernet 1Gbps RJ45

47

Prese USB: 4 porte USB 3.0

Audio e Microfono integrati con prese jack o 1 cavo di collegamento video con lunghezza minima 150cm del tipo o DisplayPort/HDMI (Maschio/Maschio UHD/4K) o 1 cavo di collegamento video con lunghezza minima 150cm del tipo DisplayPort/DisplayPort

(Maschio/Maschio UHD/4K) o Tutto l’occorrente per agganciare la workstation ad un monitor o a un arredo (fondo

scrivania, parete divisoria, ecc. ….) tramite un fissaggio (Attacco VESA standard o soluzione alternativa)

o Mouse e tastiera wired

Estensione di garanzia di 5 anni del Produttore con intervento on site NBD (Next Business Day)

Allo scadere del quinto anno la proposta dovrà obbligatoriamente prevedere la completa sostituzione delle workstation con apparati aventi caratteristiche tecniche equivalenti o superiori e coperti da estensione di garanzia quinquennale con le medesime caratteristiche e SLA descritti in precedenza.

MONITOR OPERATORE 118 (NR. 48 MONITOR) Seguono le caratteristiche minime dei monitor destinati agli operatori 118:

L’apparato deve essere di Brand primario del quale è comprovabile il già avvenuto utilizzo, con esito ottimale, per la realizzazione di postazioni di lavoro di centrali operative NUE 112 e/o di emergenza urgenza sanitaria 118

Monitor LCD CURVO con retro-illuminazione a LED

Risoluzione 3840x1600 a 60Hz di frequenza

Diagonale Monitor tra 37” e 39” (area utile video)

Rapporto di scala 21:9

Alimentatore monitor integrato

Altoparlanti integrati

Base regolabile e attacchi per il montaggio a staffa

Peso inferiore a 17Kg (compresa la base)

Rapporto di contrasto superiore a 500:1

Tempo di risposta inferiore a 6ms

Angolo di visualizzazione maggiore di 165°

Estensione di garanzia di 5 anni del Produttore

È richiesto che il monitor sia fornito con il cavo video necessario alla sua corretta attestazione alla workstation in fornitura; la lunghezza del cavo non deve essere inferiore a 1,5 metri

I monitor devono essere forniti con garanzia di 5 anni di tipo “pick-up and return”. Allo scadere del quinto anno la proposta dovrà obbligatoriamente prevedere la completa sostituzione dei monitor con apparati aventi caratteristiche tecniche equivalenti o superiori e coperti da estensione di garanzia quinquennale.

48

MONITOR DI GRANDI DIMENSIONI (NR.12 MONITOR) Seguono le caratteristiche minime dei monitor di grandi dimensioni per l’allestimento delle sale operative:

Diagonale schermo: 55"

Tecnologia del pannello: AMVA3 con retroilluminazione a LED

Contrasto 4000:1

Ratio: 16:9

Angolo di visione: 178°/178°

Orientamenti supportati; landscape e portrait

Risoluzione nativa: 1920x1080

Comprensivo di: o Telecomando o Staffe per fissaggio a muro o Mini-PC “fanless” esterno con sistema operativo Windows 10, processore 1,8Ghz, 4 GB

RAM, 500GB HDD SATA 2, interfaccia LAN 10/100/1000 Rj45, interfaccia video compatibile con quelle disponibili sul monitor

o Decoder satellitare (S2) e terrestre (T2) esterno o Cavi video per il collegamento monitor/mini-PC e monitor/decoder o Estensione di garanzia per 5 anni (a copertura anche del mini-PC e del decoder)

I monitor ed i mini PC devono essere forniti con garanzia di 5 anni. Allo scadere del quinto anno la proposta dovrà obbligatoriamente prevedere la completa sostituzione dei monitor e dei mini PC con apparati aventi caratteristiche tecniche equivalenti o superiori e coperti da estensione di garanzia quinquennale

STAMPANTI MULTIFUNZIONE

Le stampanti destinate alle sale operative dovranno avere le seguenti caratteristiche:

multifunzione con possibilità di eseguire ed inviare scansioni via email

tecnologia laser B/N

formato carta A4/A3

fronte retro automatico

Interfaccia Ethernet 1Gbps RJ45

garanzia quinquennale con intervento on site NBD Allo scadere del quinto anno la proposta dovrà obbligatoriamente prevedere la completa sostituzione delle stampanti con apparati aventi caratteristiche tecniche equivalenti o superiori e coperti da estensione di garanzia quinquennale.

CUFFIE Sono da prevedere almeno 50 cuffie in sostituzione delle attuali. Dovrà essere prevista per il periodo

contrattuale adeguata scorta per cambi o sostituzioni.

49

INFRASTRUTTURE SEDI PERIFERICHE Presso le sedi periferiche, verranno sfruttate, laddove disponibili, le infrastrutture già realizzate col progetto

STI-SUES 118.

Ogni sede periferica dovrà essere equipaggiata con telefoni, configurati come derivati esterni del sistema

telefonico regionale, con un accesso alla rete regionale dell’emergenza, con una linea telefonica di backup e

con tutte le apparecchiature necessarie per gestire in modo trasparente le chiamate da/verso le Sale

Operative 118.

RETE REGIONALE DELL’EMERGENZA Il collegamento fra i due Datacenter dovrà essere caratterizzato da

Alta velocità

Bassa latenza

Bassa probabilità di errore

Elevata affidabilità, per continuare ad operare anche in presenza di guasti o malfunzionamenti

Espansibilità, per crescere nel tempo secondo le mutate esigenze senza significativi cambiamenti nella rete

Per garantire le caratteristiche su indicate, si richiede, fra i due Datacenter, un collegamento ridondato e

totalmente diversificato in tecnologia DWDM, con velocità pari a 10 Gbit/s. Fra i due Datacenter e le 4 Sale

Operative, si richiedono dei collegamenti DWDM con velocità pari a 1 Gbit/s, in modo da realizzare la

seguente infrastruttura di rete.

50

Si richiede anche l’aggiornamento della rete di interconnessione fra le Centrali Operative e le sedi

periferiche, mediante la realizzazione di accessi ridondati presso le Centrali Operative ospitate dai

Datacenter (con profili di accesso DWDM o GBE presso i Datacenter e xDSL presso le sedi periferiche). Ciò

consente una maggiore affidabilità e un risparmio rispetto alla situazione attuale) e l’integrazione di tutte le

sedi periferiche individuate dall’Amministrazione. La rete di interconnessione verso le sedi periferiche dovrà

essere configurata con opportune Classi di Servizio, per consentire di gestire correttamente flussi di fonia e

applicazioni presenti e future.

PIATTAFORMA DI TEST Dovrà essere realizzata una Piattaforma di Test, presso una sede concordata, con lo scopo di permettere la

realizzazione, test e certificazione dell’integrazione tra la suite applicativa la piattaforma di fonia.

In tale ambiente, dovrà essere possibile effettuare una verifica preliminare degli scenari di recovery da failure

introducendo singole o multiple malfunzioni in modalità controllata e verificando che il sistema nel suo complesso sia in

grado di erogare i servizi richiesti con un livello accettabile di degrado funzionale o prestazionale.

La piattaforma di test dovrà essere un’esatta replica della soluzione che verrà realizzata presso i Datacenter e sarà utile,

oltre che per le verifiche preliminari, anche per testare aggiornamenti e nuove soluzioni applicative, prima del loro

rilascio nei sistemi di produzione, per consentire un’analisi attenta degli impatti delle nuove implementazioni prima che

vengano rilasciate in produzione.

FUNZIONALITÀ APPLICATIVE RICHIESTE La piattaforma oggetto della presente fornitura deve prevedere i seguenti sistemi:

gestione dell’emergenza-urgenza 118;

integrazione con la CUR 112 di Catania e Palermo;

gestione 116117;

cartografico (GIS);

integrazione con Servizio di Elisoccorso;

sistema di interscambio dei dati tra mezzo di soccorso e CO;

sistema di statistiche evolute e reportistica.

Si richiede che nel complesso l’architettura proposta soddisfi i seguenti requisiti:

architettura fault tolerant, al fine di eliminare single point of failure almeno sulle componenti infrastrutturali abilitanti all’erogazione del servizio di gestione degli interventi di soccorso;

l’architettura dovrà consentire la possibilità di utilizzare le funzionalità applicative del sistema di gestione proposto da una postazione remota rispetto alla Centrale Operativa. Si richiede all’Offerente di specificare le caratteristiche minime in termini di prestazioni dei collegamenti dati richieste per il corretto funzionamento del sistema in modalità remota su rete geografica (ad esempio banda garantita del collegamento, presenza della qualità del servizio sulla rete geografica etc);

supporto dei sistemi windows based;

compatibilità con i principali RDBMS;

gestione delle chiamate telefoniche mediante uno strumento informatizzato (barra telefonica) completamente integrato con il sistema gestionale;

ergonomia, identificando le caratteristiche che consentono di rendere la soluzione confortevole all’uso.

Costituiscono caratteristiche migliorative della soluzione proposta le seguenti caratteristiche opzionali: architettura basata su una logica orientata ai servizi (SOA); comprovata scalabilità orizzontale della soluzione. Funzionalità amministrative aggiuntive

51

SISTEMA DI GESTIONE DELL’EMERGENZA-URGENZA 118 Il sistema di gestione dell’emergenza-urgenza dovrà supportare almeno le seguenti macro-funzioni come meglio descritto nei successivi paragrafi e come da Linee guida – protocolli e procedure, servizio S.U.E.S. 118 – Sicilia di cui alla GURS n.24 parte I del 21 Maggio 2010: ricezione della chiamata con automatismo dell’apertura scheda di evento di emergenza urgenza; gestione dell’intervento di emergenza/urgenza, con valorizzazione del livello di urgenza; identificazione del chiamante e localizzazione; modifica di informazioni relative a chiamata già aperta; supporto all’intervista del chiamante da parte dell’operatore; gestione delle chiamate duplicate, con segnalazione all’operatore che la chiamata in corso è

potenzialmente il duplicato di una già ricevuta; consultazione dei pazienti a rischio al fine di evidenziare all’operatore la richiesta di soccorso da parte di

pazienti "ricorrenti"; sinottico degli interventi; zonizzazione del Territorio della Provincia di ogni CO; scelta delle risorse proponendo all’operatore una lista di risorse ordinata dalla più adatta per vicinanza e

per tipologia di mezzo; gestione dei Rendez-Vous; rilevazione dei Tempi associando automaticamente ad ogni singola fase dell’intervento la corretta

marcatura temporale; definizione del Presidio ospedaliero ottimale; attivazione di altri Enti per portare a termine l’Intervento; gestione degli allarmi di sicurezza in modo da avvisare l’operatore, tramite segnalazione ottica e acustica,

di ritardi nella gestione delle fasi dell’intervento; chiusura dell’Intervento con possibilità di aggiungere e modificare i dati relativi all’anagrafica del paziente,

una volta chiuso l’intervento; gestione dei maxi eventi (concerti, eventi sportivi, etc.); gestione delle maxi-emergenze; Interfacciarsi con il sistema di gestione della turnistica dell’equipaggio e dei mezzi di soccorso già in

nostro possesso; gestione delle consegne tra operatori delle CO (bacheca elettronica) integrata nell’applicativo di

gestione); gestione della messaggistica e della corrispondenza per le comunicazioni di servizio tra operatori o per

avvisi generali; gestione della configurazione di sistema funzionale all’aggiornamento dei dati; gestione degli interventi di Elisoccorso; funzionalità telefoniche integrate; funzionalità di registrazione e riascolto integrate di tutte le chiamate vocali; sicurezza applicativa in termini di trasferimento dei dati, di tracciamento a sistema delle operazioni

effettuate, di profilatura degli accessi e di rispetto delle norme sul trattamento dei dati, anche sensibili; presentazione ai livelli decisionali ed operativi designati della situazione aggiornata, puntuale e chiara,

orientata alla gestione delle missioni di soccorso; funzionalità di allertamento verso la popolazione e verso la catena di commando; Rilevazione e gestione delle informazioni clinico-sanitarie del paziente rilevate on-site e trasmesse alle

Centrali Operative 118 di riferimento territoriale.

APERTURA DELL’EVENTO Il sistema dovrà consentire come requisiti: l’apertura di un evento in automatico partendo dalla ricezione di una chiamata telefonica, riportando

nella scheda di gestione il numero telefonico chiamante; che tutte le informazioni inserite e modificate da un operatore in relazione all’evento attivo dovranno

52

essere immediatamente rese disponibili agli altri operatori della centrale in modo da rendere possibile una gestione condivisa della scheda dell’evento.

GESTIONE DELL’INTERVENTO Il sistema dovrà consentire come requisito la gestione dell’intervento, ovvero tutte le attività svolte a valle dell’avvenuta ricezione della richiesta, che vanno dall’assegnazione delle risorse fino al rientro di queste alla propria postazione e dovrà essere caratterizzato da un’elevata automatizzazione per: ridurre al massimo le operazioni che l’operatore dovrà compiere per definire il tipo di intervento

richiesto; aumentare il livello di ottimizzazione delle risorse sanitarie disponibili; garantire un livello ottimale di assistenza tramite la scelta della risorsa sanitaria più adatta.

Inoltre, il sistema dovrà consentire come requisiti: la gestione dell’evento conformemente alle codifiche ministeriali previste; la produzione automatica dei flussi ministeriali previsti dall’attuale normativa.

IDENTIFICAZIONE DEL CHIAMANTE E LOCALIZZAZIONE Il Sistema dovrà come requisiti:

integrazione dei servizi di localizzazione e identificazione chiamante offerti dal CED interforze (per i servizi 112 e 118);

ricezione della localizzazione proveniente dal sistema NUE 112 (via scheda contatto); supportare, tramite le informazioni Toponomastiche e Cartografiche, l’operatore nella corretta

determinazione del Luogo dell’intervento.

MODIFICA DI INFORMAZIONI RELATIVE A CHIAMATA GIÀ APERTA Il sistema dovrà consentire come requisito la possibilità per l’operatore di demandare a personale di back office il completamento dei dati mancanti nella scheda di intervento al fine di rendere più veloci le azioni di gestione dell’emergenza a seguito della ricezione della chiamata. Il sistema deve inoltre associare ad ogni azione effettuata sulla scheda i differenti identificativi degli operatori compilanti.

SUPPORTO ALL’INTERVISTA Il sistema dovrà consentire come requisito la funzionalità di ausilio all’intervista del chiamante da parte dell’operatore (un protocollo assistito di tipo domanda/risposta che faciliti l’individuazione del livello di gravità della chiamata).

GESTIONE DELLE CHIAMATE DUPLICATE Il sistema dovrà consentire come requisito, in base a parametri configurabili, di segnalare all’operatore che una chiamata in corso è potenzialmente il duplicato di una già ricevuta. Per il rispetto del requisito, tale funzionalità dovrà quindi rendere possibile, su richiesta, un raffronto diretto della/e chiamata/e già censite, permettendo l’accorpamento dei nuovi dati in caso di reale duplicazione od il proseguimento del normale flusso di gestione in caso contrario.

GESTIONE DELLE CHIAMATE DA AUDIOLESI Il sistema dovrà consentire come caratteristica migliorativa di ricevere richieste di soccorso via sms dai pazienti sordomuti e di inviare loro sms di ritorno.

CONSULTAZIONE DEI PAZIENTI A RISCHIO Il sistema dovrà consentire come requisiti di: rilevare automaticamente ed evidenziare all’operatore la richiesta di soccorso da parte di pazienti

"ricorrenti" che chiamano con una certa frequenza, attraverso l’impostazione di filtri su informazioni chiave;

53

elencare la lista delle schede precedentemente elaborate e, qualora l’operatore lo richieda, le schede dovranno essere consultabili on line.

SINOTTICO DEGLI INTERVENTI Il sistema dovrà consentire come requisito la disponibilità di una finestra di visualizzazione nella quale mostrare in forma aggregata elementi significativi del carico di lavoro di ogni sala operativa. Dovranno come minimo essere mostrete informazioni relative a: flusso di chiamate per fascia oraria; chiamate per gravità/tipologia di emergenza; chiamate in corso/in coda/in gestione L’accesso al sinottico deve poter avvenire da qualsiasi postazione di lavoro o workastation, anche dall’esterno della centrale opeativa stessa. Il sistema dovrà inoltre consentire la possibilità di gestire quadri sinottici differenti, visualizzabili su uno o più monitor in contemporanea. Il numero di quadri sinottici attivabili non deve avere impatti significativi sui carichi di elaborazione del sistema, o sui tempi di risposta dello stesso. Qualora fosse richiesto da autorità esterna dovrà essere disponibile l’accesso al sinottico anche dall’esterno della centrale operativa.

ZONIZZAZIONE DEL TERRITORIO Il sistema dovrà consentire come requisito la suddivisione del Territorio della Provincia di ogni CO in zone omogenee per delimitare almeno: le aree di intervento dei Mezzi; il bacino di afferenza dei Presidi Ospedalieri; le aree di intervento di altri Enti. Visualizzare le risorse in eccedenza con integrazione della funzionalità con i dati prelevabili dal portale

“disponibilità eccedenze” in uso e gestito da SEUS s.c.p.a.

SCELTA DELLE RISORSE Il sistema dovrà consentire come requisito di proporre, all’interno del territorio delimitato dalle coordinate dell’evento, una lista di risorse ordinata dalla più adatta per vicinanza e tipologia di mezzo, almeno in base a: tipologia di risorsa; appartenenza del luogo dell’evento ad una particolare zona; tempo presunto di raggiungimento del luogo dell’evento da parte della risorsa. Tale lista dovrà essere composta in base ai turni operativi delle postazioni e dei mezzi e dovrà essere possibile l’assegnazione, se necessario, di un mezzo non di turno al momento della chiamata, per far fronte all’utilizzo di mezzi estemporanei o provenienti da altre Province. Il sistema dovrà consentire, inoltre, come requisito, di registrare, per ogni missione operata dai mezzi, sia i percorsi sia i cambi di stato con le relative tempistiche per eventuali successive verifiche della gestione della missione. Infine il sistema dovrà consentire, come requisito, la gestione di “condizioni al contorno” sul territorio di competenza della Centrale Operativa, intendendo la possibilità di impiego di risorse condivise tra la Centrale Operativa di pertinenza dell’evento da gestire e altre Centrali Operative confinanti. A titolo di esempio si pensi alla possibilità di utilizzo di mezzi particolari come l’elicottero o natanti che risultano per loro natura condivisi tra più centrali e alla loro gestione da parte della centrali che li identifica come mezzi di soccorso oppure all’invio di mezzi che, trovandosi sull’evento molto prima di altri mezzi della centrali 118 competenti per territorio, vengono utilizzati per la gestione dell’evento. Costituisce caratteristica migliorativa: La possibilità di implementare logiche autorizzative per le risorse condivise. A titolo di esempio si pensi

alla necessità, prima dell’uso, di autorizzare l’uso di un elicottero richiesto da una Centrale Operativa consentendo al referente di ciascuna base operativa di elisoccorso di gestire ed evadere le richieste di

54

attivazione del mezzo.

GESTIONE DEI RENDEZ-VOUS Data la conformazione orografica della Regione e la distribuzione degli insediamenti abitativi, le C.O. faranno uso, per i casi che lo richiedano, di Auto Mediche e/o di Elicottero per gli interventi più urgenti. Il sistema dovrà quindi consentire come requisito di coordinare il rendez-vous tra queste e le ambulanze necessarie per il trasporto dei pazienti verso i Presidi una volta stabilizzati. Tale funzione dovrà consentire di coordinare l’invio di più mezzi in caso della necessità di trasporto di più pazienti e di coordinare le attività di carico-scarico da mezzi aerei che spesso non sono in grado di atterrare nelle immediate vicinanze dei luogo di una chiamata e/o dell’Ospedale. É richiesto, come requisito, che eventuali dati relativi ai pazienti raccolti durante una qualsiasi fase di trasporto siano correttamente associati a ciascun mezzo che abbia effettuato il trasporto dello specifico paziente.

RILEVAZIONE DEI TEMPI Il sistema dovrà consentire come requisiti: la memorizzazione di tutte le fasi dell’intervento, compreso l’eventuale rendez-vous, associando ad ogni

singola fase la corretta marcatura temporale (time-stamp) che la marcatura temporale degli eventi caratterizzanti il soccorso avvenga in modalità automatica,

fruendo degli stati resi disponibili dal sistema di comunicazione verso i mezzi dovrà consentire la possibilità, da parte dell’operatore, di modificare in modalità manuale le registrazioni

orarie.

DEFINIZIONE DEL PRESIDIO OTTIMALE Il sistema dovrà consentire come requisito di predefinire quale sia il presidio ospedaliero ottimale per l'accettazione del paziente, in analogia con quanto richiesto in merito all’assegnazione della/e risorsa/e, in base alle informazioni raccolte durante l’intervento e alla tipologia del mezzo intervenuto (medicalizzato).

ATTIVAZIONE DI ALTRI ENTI Il sistema dovrà consentire come requisito di segnalare la necessità di intervento degli altri Enti per portare a termine l’Intervento. Tale segnalazione dovrà tener traccia della data e dell’ora in cui verrà fatta. Il sistema dovrà inoltre essere predisposto per l’invio informatizzato dei dati dell’evento ritenuti utili per la tipologia di ente selezionato, senza quindi oneri futuri di integrazione.

GESTIONE DEGLI ALLARMI DI SICUREZZA Il sistema dovrà consentire come requisito di avvisare l’operatore, tramite apposita segnalazione, di ritardi nella gestione delle fasi dell’intervento. In particolare, qualora si dovesse verificare un ritardo temporale di passaggio di stato del soccorso non giustificato, il sistema dovrà, secondo regole prefissate, avvisare l’operatore di centrale. Come requisito dovrà essere possibile impostare le tempistiche oltre le quali il sistema segnalerà il ritardo nella gestione tempistiche a seconda dello stato in cui l’intervento si trova, del suo livello di gravità e dell’area geografica su cui insiste.

CHIUSURA DELL’INTERVENTO Il sistema dovrà consentire come requisito di poter aggiungere e modificare i dati relativi all’anagrafica del paziente, una volta chiuso l’intervento. Tale operazione dovrà essere tracciata a sistema, riportando le modifiche effettuate e l’identificativo dell’operatore che le ha effettuate. Dovrà essere possibile accedere in modalità remota, da parte di eventuali enti che concorrono alla gestione dell’evento, ad un sottoinsieme di dati, garantendo la sicurezza dei dati trattati attraverso idonei strumenti informatici.

55

ALLERTAMENTO PER ATTIVAZIONE DAE (DEFIBRILLATORE AUTOMATICO ESTERNO) Il sistema dovrà essere predisposto, come requisite minimo, per attivare automaticamente una segnalazione verso l’operatore nel caso in cui venga ricevuto un allarme per l’attivazione di un DAE sul territorio, in armonia con le disposizioni adottate dai protocolli ministeriali vigenti nelle varie C.O. Il sistema dovrà, inoltre, visualizzare sulla cartografia i DAE più vicini al luogo dell’evento; il loro stato e i dati di ubicazione. Tali informazioni dovranno essere gestite sia da appositi strumenti di backoffice disponibili alla Centrale Operativa sia attraverso un portale web ad accesso riservato in cui tutti gli utenti interessati (private, enti, strutture sportive ecc.) possessori di un DAE possano denunciarlo e mantenerlo. Il portale web deve come requisito gestire l’ubicazione del DAE (comprensiva di coordinate GPS), lo stato, la proprietà, i dati di contatto, i dati di scadenza piastre. Il portale dovrà consentire l’accesso mendiante autenticazione, preferibilmente SPID.

GESTIONE DEI MAXI-EVENTI Il sistema dovrà consentire, come requisito, la gestione di maxi-eventi (concerti, event sportivi, etc) prevedendo funzionalità di pianificazione delle risorse e successivo collegamento degli interventi al maxi-evento per eventuali debriefing post evento. Dovrà essere possibile definire graficamente le aree interessate dall’evento e abilitare appositi algortmi di calcolo del livello di rischio (almeno MAURER). Dovrà inoltre essere offerto un portale web ad accesso riservato in cui gli enti organizzatori (privati, stakeholder, ecc.) possano dichiarare al Sistema di emergenza il maxi evento previsto. Tale evento potrà essere valutato dal personale preposto della Centrale Operativa e, se approvato, dovrà essere reso disponibile in sala operativa. In caso di mancata approvazione dovrà essere gestito il flusso di notifica all’ente organizzatore (via mail e via portale).

GESTIONE DELLE MAXI-EMERGENZE Il sistema dovrà consentire come requisito di fornire supporto nelle attività di gestione delle maxi emergenze. In particolare dovrà essere possibile definire un sottoinsieme di postazioni della CO ad uso esclusivo per la gestione della maxi emergenza. Il sistema dovrà inoltre consentire di gestire più eventi di maxi emergenza in contemporanea, e di definire risorse speciali riservati per queste casistiche. Dovrà anche essere possibile accedere al Sistema da una postazione esterna ed avanzata di soccorso prossima al luogo della maxi emergenza. Si richiede all’Offerente di specificare le caratteristiche minime in termini di prestazioni del collegamento dati su rete geografica necessario al corretto funzionamento del sistema in modalità remota (ad esempio banda garantita del collegamento, presenza della qualità del servizio sulla rete geografica etc).

GESTIONE DELLE CONSEGNE TRA OPERATORI DELLE CO Il sistema dovrà consentire come requisito il passaggio delle consegne tra operatori alla fine di ogni turno lavorativo.

GESTIONE DELLA MESSAGGISTICA E DELLA CORRISPONDENZA Il sistema dovrà prevedere come requisito la funzionalità di messaggistica istantanea (real time) tra operatori per la gestione di comunicazioni di servizio utili nel passaggio di consegne tra operatori o per avvisi generali.

GESTIONE DELLA CONFIGURAZIONE DI SISTEMA Il sistema dovrà consentire come requisito almeno l’aggiornamento del seguente insieme di dati: archivi toponomastici; dati relativi alla struttura Sanitaria della Regione (Presidi, Reparti, Unità Operative, Servizi); elementi cartografici (località, luoghi di interesse, parcheggi, ospedali); zone di competenza delle Postazioni, Presidi, altri Enti; diritti di accesso al Sistema.

56

GESTIONE DEGLI INTERVENTI DI ELISOCCORSO Il sistema dovrà prevedere come requisito la funzionalità di gestione e tracciamento, anche ai fini della consuntivazione, degli interventi di elisoccorso, per i quali sono richiesti tipologie di dati differenti rispetto a quanto previsto per una missione eseguita da un mezzo di terra.

FUNZIONALITÀ TELEFONICHE INTEGRATE Il sistema dovrà consentire come requisito la fruizione di almeno i seguenti servizi telefonici integrati sulla postazione operatore e dovrà essere certificato con la maggior parte dei sistemi telefonici esistenti: chiamate in Ingresso; risposta alle Chiamate; chiamata in Uscita; chiusura della Chiamata in Corso; attesa e recupero da attesa; chiamata di Consultazione; riconnessione da Consultazione; trasferimento di Chiamata; conferenza; monitoraggio Stato del Telefono; recupero Automatico di Informazioni per Chiamate di Emergenz; selezione da Rubrica; composizione Rapida.

FUNZIONALITÀ DI REGISTRAZIONE E RIASCOLTO INTEGRATE Il sistema dovrà consentire come requisito la registrazione di tutte le chiamate vocali: una rapida ricerca delle registrazione telefoniche relative ad un determinato evento direttamente dalla

postazione operatore; la storicizzazione delle registrazioni, che dovranno essere rese disponibili se richieste.

SICUREZZA APPLICATIVA Il sistema dovrà consentire come requisiti almeno: il trasferimento in sicurezza dei dati che fluiscono su rete geografica o attraverso il web; il tracciamento di tutte le operazioni a livello di sistema, che devono essere riportate su log con dettaglio

di data, ora ed utente che ha effettuato l’operazione; l’accesso profilato, almeno tramite digitazione di username e password, ai dati e alle funzionalità

applicative in funzione dei ruoli e privilegi associati, almeno 3, assegnati agli utenti; il salvataggio real time dei dati gestiti su ogni singola workstation, anche in caso di dati parziali e non

validati, consentendo così in caso di crash di una postazione di lavoro di continuare l’operativa su una delle rimanenti senza perdita di informazioni;

il rispetto dei requisiti previsti sulla privacy dalla normativa vigente. Costituiranno caratteristiche migliorative:

la possibilità di definire un numero di ruoli superiore al minimo richiesto l’identificazione dell'utente tramite controllo biometrico o smart card o riconoscimento facciale

PRESENTAZIONE DELLA SITUAZIONE AGGIORNATA DELLA CO Il sistema dovrà consentire come requisito, la presentazione chiara e puntuale, ai livelli decisionali ed operativi designati, della situazione aggiornata delle missioni di soccorso, secondo le specifiche che saranno definite dall’Amministrazione.

57

NUE112 Il sistema dovrà garantire, come requisito, la disponibilità di un apposito modulo software specializzato per l’integrazione con la CUR 112, così come previsto dalla normative vigente.

CONTINUITÀ ASSISTENZIALE È noto che la Commissione Europea unitamente al numero unico dell’emergenza 112 ha istituito il numero unico per servizi di assistenza medica non urgenti (116117) che indirizzerà i chiamanti ad un servizio di assistenza medica in situazioni critiche, ma non di emergenza, in particolare al di fuori delle ore di lavoro, nei fine settimana e nei giorni festivi, attività attualmente coperta dal servizio di Continuità Asssistenziale. L'obiettivo è quindi quello di mettere in contatto il chiamante con un operatore competente e/oppure direttamente con un medico qualificato che possa fornire assistenza o consulenza medica, soprattutto se la persona cui si rivolge normalmente il chiamante non è disponibile (es. Medico di Medicina Generale, Pediatra di Libera scelta). In realtà tale tipo di attività, vista la tipologia di utenti sul nostro territorio, deve essere inteso come un servizio unificato ed allargato anche a funzionalità di tipo informativo/procedurale sanitario. Ad esempio già oggi molte centrali operative del 118 forniscono altri tipi di informazioni e sono strutturate per la gestione di servizi non propriamente di emergenza, quali le chiamate per le guardie mediche, l'igiene ambientale e le guardie veterinarie, così come i Vigili del Fuoco ricevono attraverso il 115 numerose chiamate per interventi che non rivestono carattere di emergenza o per informativa. A tale scopo è prevista l’istituzione di una Centrale (logica) di gestione del numero unificato 116117 per singola ASP in grado di erogare tale tipologia di servizi in modo professionale ed organizzato supportando altresì le attività connesse alle attività di Guardia Medica. Tale centrale logica dovrà sfruttare la medesima infrastruttura tecnologica del servizio 118. Tali Centrali dovranno essere essere autonome ed indipendenti nelle proprie attività primarie e nei propri strumenti tecnologici, ma deve altresì essere in grado di scambiare dati ed informazioni con la Centrale 118 per ottimizzare la gestione degli utenti e delle risorse, anche di natura tecnologico. Come si intuisce da questi accenni le problematiche dovranno essere affrontate con flessibilità e propositività di modello funzionale dalle Ditte concorrenti e saranno premiate soluzioni nativamente orientate all’integrazione dei sistemi ed allo scambio automatico dei dati. Il sistema 116117 dovrà rispondere almeno ai seguenti requisiti: integrazione con il sistema telefonico, secondo quanto già dettagliato per i servizi 118; localizzazione del chiamante e del paziente; gestione dell’intervista telefonica, che dovrà essere strutturata sulla base di un protocollo (integrato alla

soluzione) di valenza internazionale e focalizzato sull’identificazione di eventuali casi gravi occulti, da passare immediatamente al servizio di emergenza 118. Il protocollo proposto dovrà dare evidenza precisa della sua efficacia nel contribuire a ridurre l’inappropriatezza della risposta del sistema sanitario (es. escalation verso il 118 e relativo invio del mezzo di soccorso quando non necessario);

gestione dell’assegnazione delle missioni ai medici sul territorio, potendo gestire assegnazioni multiple e code di assegnazione;

gestione della mobilità sul territorio da parte dei medici, attraverso l’uso di un apposito dispositivo tablet (similmente a quanto previsto per i mezzi di soccorso) in grado di ricevere, gestire e chiudere il caso passato dalla centrale 116117. Tale strumento dovrà consentire, attraverso apposita configurazione, la gestione di differenti schede di raccolta dati, specializzate per la singola tipologia di missione. Dovrà esser possibile modificare o aggiungere schede di rilevazione dati senza modifiche strutturali all’applicazione mobile. Tale applicazione dovrà poter funzionare anche in assenza di connettività, la quale sarà a carico del fornitore;

gestione di una banca dati della conoscenza per consentire agli operatori di rispondere alle richieste dei cittadini: tale banca dati dovrà consentire l’organizzazione di informazioni destrutturate (link, documenti, testo ecc.), organizzate secondo opportune categorie. Dovrà inoltre essere garantita un’apposita funzionalità di raccolta automatica delle informazioni provenienti da fonti attendibili (es. siti web

58

istituzionali), che verranno indicizzate e rese disponibili per l’interrogazione in linguaggio naturale; strumenti per i data manager, che dovranno occuparsi di visionare e mantenere aggiornate le

informazioni gestite dal sistema 116117; statistiche e report, secondo quanto definito nel paragrafo specifico.

SISTEMA CARTOGRAFICO (GIS) La soluzione software deve prevedere supporto cartografico che disponga delle seguenti funzionalità e deve essere comprensivo delle mappe (le relative licenze ed installazione di aggiornamenti si intendono ricompresi nell’offerta economica proposta per tutta la durata del contratto (Gli aggiornamenti dovranno essere con frequenza non superiore all’anno):

Visualizzare mappe con la completezza delle basi cartografiche inclusa la visualizzazione di Google Street View;

Permettere una precisa identificazione della posizione del chiamante e delle risorse più adeguate per gestire la richiesta, aggiornando la posizione dei mezzi nel corso della missione e identificandone lo stato;

Presentare una interfaccia utente semplice ed ergonomica;

Avere le caratteristiche cartografiche proprie di un GIS quindi essere geo-referenziato e in grado di gestire layer cartografici differenti (raster, vettoriale, ortofoto);

Aderire agli standard di mercato (Google Maps, Bing Maps ecc.) per le funzionalità di navigazione della mappa, del tutto simili a quelle riscontrabili e utilizzate nei servizi citati;

Permettere di effettuare le operazioni di zoom, di misura ecc. con un semplice click del mouse;

Disegnare aree di interesse (geofencing) per definire ambiti operativi speciali, calcolandone la superficie e registrandone attributi, consentendone la visualizzazione attivabile anche in considerazione della programmazione temporale, che possano consentire di visualizzare ulteriori informazioni specifiche. Al verificarsi di eventi all’interno di queste aree deve essere generato un allarme.

Aumentare o diminuire il livello di ingrandimento in maniera conforme a quello che è ormai divenuto uno standard universale (es. Google Maps);

Permettere lo spostamento della cartografia visualizzata tramite il trascinamento della mappa con il puntatore del mouse o altra icona dedicata (Pan);

Permettere la visualizzazione di cartografia vettoriale, raster, mista;

Stampare la porzione di mappa visualizzata;

Consentire ricerca su base toponomastica (es: comune, indirizzo, numero civico e incrocio);

Calcolare la distanza fra due o più punti della mappa con evidenza del tratto interessato.

Visualizzare i POI di due tipi: icone dinamiche (es: risorse per soccorso) e icone statiche di diverso genere e interesse:

Entità normalmente dislocate sul territorio in posizione fissa (farmacie, cinema, supermercati, …)

Enti (ospedali, stazionamenti ambulanze, aeroporti, …)

Ostacoli di vario genere che possono influenzare la viabilità (mercati rionali, interruzioni stradali, …)

Calcolare il percorso tra due o più punti e del tempo di percorrenza stimato;

Permettere di importare le coordinate di un punto individuato sul cartografico in una scheda informativa.

Il sistema cartografico deve riportare le condizioni di traffico in tempo reale acquisite tramite pacchetti commerciali integrati e utilizzandoli per integrare le stime dei tempi di intervento.

59

GESTIONE VIARIO Deve essere preservata la struttura esistente del viario regionale in uso integrandola e ampliandola con altre basi dati open source o rese disponibili da altri enti (es: Comune di Catania, Uffici Regione Siciliana). Particolare rilevanza dovrà essere data alla strutturazione delle tratte stradali a scorrimento veloce quali autostrade, superstrade e Strade Statali che hanno accessi vincolati che devono essere opportunamente gestiti al fine di consentire l’individuazione della risorsa più competitiva.

INTEGRAZIONE CON IL SISTEMA DI INTERSCAMBIO DEI DATI TRA MEZZO DI SOCCORSO E SALE

OPERATIVE Il sistema dovrà integrarsi con tutte le informazioni provenienti dai dispositivi mobili attuali e futuri provenienti dalle risorse sul territorio; con App mobile progetto “118 volte digitale”; con App degli Enti privati che forniscono servizi in eccedenza; con App per la rilevazione presenza e gestione del personale.

SISTEMA DI ALLERTAMENTO Il sistema dovrà garantire, come requisito, la possibilità di invare allerte e segnalazione ai soccoritori che operano sul territorio in caso di gravi calamità o criticità, secondo quanto di competenza dei singoli servizi (112, 118). L’allerta potrà avvenire attraverso molteplici canali di comunicazione, quali ad esempio: SMS; eMail; notifiche push; social network; chiamate telefoniche automatiche con tecnologia text-to-

speech. Dovranno essere previste funzionalità di escalation tali da garantire, in caso impossibilità di allerta su un canale (es. Mail), di passarea automaticamente ad un altro (es. SMS). Dovranno inoltre essere previste specifiche funzionalità di allerta verso la catena di commando, con relative logiche di escalation di persona/ruolo. Il sistema di allerta dovrà poter essere utilizzato da tutti i servizi oggetto della presente fornitura, ovvero 112, 118 e 116117. Eventuali oneri relativi al traffico SMS o ad altri canoni afferenti ai servizi di allerta si intendono inclusi nella fornitura. L’anagrafe dei soccoritori dovrà essere sincronizzata al portale dei volontari di Regione Siciliana.

GESTIONE POSTI LETTO/RISORSE DISPONIBILI Il sistema dovrà integrarsi con tutte le informazioni provenienti dal sistema in fase di realizzione con progetto “118 volte digitale” della Regione Siciliana.

STATISTICHE EVOLUTE E REPORTISTICA Il sottosistema di statistiche evolute e reportistica dovrà offrire un vero e proprio ambiente di data warehousing multi-dominio (112, 118 e 116117) che consenta di accedere ai dati, analizzarli tramite una struttura che rispecchi quella del database relazionale, senza doverne conoscere i dettagli. Questa componente dovrà consentire di produrre documenti efficaci, senza dover richiedere una particolare esperienza sui database da parte degli utilizzatori. I dati operativi raccolti alimenteranno il data warehouse sul quale dopo un opportuno periodo di popolamento, potranno essere svolte analisi (data mining) sui tempi di risposta della Centrale nel suo complesso, sul carico degli operatori, sul tipo di attività che questi sono più frequentemente chiamati a svolgere. Tale analisi può evidenziare con facilità aree di miglioramento. Sulla base dei dati ottenuti l’organizzazione può adottare i correttivi che ritiene opportuni per migliorare l’efficacia e l’efficienza della struttura.

60

Il sistema dovrà soddisfare almeno i seguenti requisiti:

mettere a disposizione le informazioni derivanti da tutte le attività svolte dalle Centrali Operative nel suo complesso, nonché la raccolta dei parametri configurati per i sistemi e funzionalità attivate, tra cui almeno: ricezione della chiamata di soccorso; comunicazione con i mezzi sul territorio; comunicazione con ospedali e con altri enti di soccorso; comunicazione con l’utente; inoltro verso PSAP di 2° livello; tempi di attesa e di risposta;

consentire la gestione dei dati sia a livello di singola CO sia a livello di più CO; tenere traccia di tutte le attività degli operatori, dei processi e delle procedure implementate. I dati

raccolti saranno oggetto di analisi, attraverso un cruscotto di controllo direzionale, come meglio descritto nel paragrafo seguente;

rendere disponibili dei report in grado di visualizzare i dati statistici distribuendoli su una mappa cartografica, in particolare i report disponibili daranno evidenza del numero di eventi/mezzi/pazienti raggruppati per differenti entità geografiche (ad es: Regione, Provincia, Comune);

fornire un insieme di report predefiniti con diversi livelli di aggregazione e dettaglio; permettere la generazione di report personalizzati con diversi livelli di aggregazione e dettaglio; consentire l’accesso in base a differenti profili configurabili a sistema; consentire l’accesso al sistema via web attraverso l’utilizzo dei browser principali (Microsoft Internet

Explorer, Mozilla Firefox); gestire l’export dei dati con diversi formati (ad.es: xls, pdf, csv, etc…); consentire l’invio pianificato dei risultati dei report via mail; realizzare un cruscotto direzionale come meglio specificato nel paragrafo relativo; realizzare la funzionalità di gestione e pubblicazione delle informazioni, come meglio specificato nel

paragrafo relativo. Inoltre il Fornitore dovrà fornire all’Amministrazione, come requisiti: trimestralmente, l’estrazione dei dati “raw” di reportistica, in un formato che sarà concordato con

l’Amministrazione; semestralmente, il datamodel che realizza gli schemi del database relativi alla reportistica.

CRUSCOTTO DIREZIONALE Il cruscotto direzionale, derivante dalla messa a punto di un data warehouse per l’interrogazione facilitata dei dati a fini statistici e o di valutazione delle attività, costituisce un valido supporto per il miglioramento continuo dell’efficienza e dell’efficacia delle prestazioni erogate. Il cruscotto di controllo direzionale dovrà permettere non solo l’uso di interrogazioni predisposte e memorizzate, ma anche dare la possibilità all’utente di creare report “on demand” in maniera semplice sulla base di esigenze contingenti, consentendo anche il confronto tra serie di dati afferenti ad archi temporali differenziati o a classi non omogenee. Dovrà essere disponibile per gli amministratori del sistema un ambiente di statistiche e di supporto alle decisioni, in grado di visualizzare in modo veloce ed intuitivo i dati relativi all’andamento della centrale e agli indicatori NSIS del Ministero della Salute. In particolare dovranno essere disponibili degli “indicatori” che esprimano situazioni di criticità da gestire e che verranno monitorati costantemente dal cruscotto.

FUNZIONALITÀ DI GESTIONE E PUBBLICAZIONE DELLE INFORMAZIONI Al Fornitore è richiesto di garantire la funzionalità di accesso ad informazioni statiche e dinamiche inerenti l’attività di emergenza fornita dal 118. Le informazioni dovranno essere ottenute in tempo reale e la loro composizione deve essere gestita dai processi della piattaforma. Attraverso tale funzionalità si vuole realizzare una finestra verso i cittadini e gli stakeholder per fornire

61

informazioni su servizi e strutture messe a disposizione dal servizio sanitario e dal 118. Attraverso un’interfaccia intuitiva, i cittadini dovranno essere in grado di navigare nelle varie sezioni messe a disposizione, eventualmente supportati dal sistema cartografico per la visualizzazione delle informazioni geografiche. Tra le informazioni trattate dovranno essere almeno presenti: numeri, indirizzi e link utili; informazioni sullo stato del parco mezzi e sui codici serviti procedure da eseguire per rivolgersi al servizio 118; informazioni sulle strutture ospedaliere e pronto soccorsi; statistiche di servizio su telefonate e soccorsi gestiti. Su tali informazioni dovrà essere possibile effettuare ricerche ed aggregazioni di dati. Inoltre dovrà essere prevista la possibilità di accedere ai dati previsti in maniera autenticata, attraverso una procedura di registrazione da parte degli utenti. Tutte le funzionalità offerte dal sistema dovranno rispettare gli standard di usabilità ed accessibilità previsti da organismi internazionali (WAI, W3-Consortium, ecc.) e nazionali (e-Government). Nel garantire tale funzionalità al Fornitore è anche richiesto di prevedere funzionalità di editing e strutturazione del portale e delle sezioni per supportare il gestore e gli editori nello sviluppo di sezioni e servizi. Tutto il sistema, infine, dovrà garantire il rispetto delle norme dettate dal Garante per la Privacy in materia di dati riservati e sensibili.

FUNZIONALITÀ DI GESTIONE E PUBBLICAZIONE DEL FLUSSO EMUR La funzionalità fornita dovrà consentire la piena rispondenza alle indicazioni ministeriali per la predisposizione la verifica e l’elaborazione del Flusso EMUR 118. In particolare è richiesta una componente gestionale in grado di assiscurare senza elaborazioni aggiuntive l’estrazione dei dati in coerenza con la semantica del flusso richiamato e, in particolare, il si dovranno monitorare e collegare i contenuti informativi dei capi afferenti al tracciato in maniera tale da fissare la coerenza tra di essi e le regole di compilazione ministeriale. La fornitura dovrà prevedere personale dedicato al supporto e all’affiancamento delle attività inerenti la gestione dei flussi informativi e in grado di adottare e implementare soluzioni di modifica evolutiva in corso d’opera.

ULTERIORI INTEGRAZIONI RICHIESTE:

SISTEMA RADIO La centrale operativa 118 sarà dotata di un sistema radio operante secondo le prescrizioni del D.M. e l’intero sistema radio è integralmente gestito da un dispositivo informatico di centrale (radioserver) attualmente in fase di realizzazione. Al Fornitore è richiesto come requisito l’integrazione della propria soluzione con il sistema radio futuro. I servizi di manutenzione ed adeguamento del sistema radio non rientrano nelle prestazioni richieste.

SISTEMA DI TELEFONIA Nel caso di inoperatività di una SO, le chiamate sono instradate verso un’altra SO attraverso un sistema automatico di redirezione dei flussi telefonici nel caso in cui uno o più flussi di centrali operative non dovessero essere disponibili. L’architettura SW deve interagire con il sistema telefonico attraverso un’interfaccia software che sostituisca l’uso del telefono per la gestione delle chiamate, permettendo al contempo di avere tutte le funzionalità proprie di un centralino evoluto (es: chiamare, riagganciare, parcheggiare, riprendere, trasferire, effettuare conferenza).

Visualizzare le chiamate entranti ordinate per priorità di coda in base alla funzione assegnata alla postazione;

Scegliere la chiamata a cui rispondere anche se non è la prima in coda;

62

Presentare per ogni chiamata: secondi di attesa, coda, numero del chiamante e identificazione se censito;

Gestire le chiamate personali effettuate dagli altri operatori;

Associare file sonoro specifico per ogni coda configurata;

Associare allarme per chiamate con attesa superiore a tempo configurabile per postazione;

Segnalare eventuale malfunzionamento sia dell’ambiente telefonico sia della rete LAN (Verifica di funzionamento sistema in continuo);

Permettere di effettuare chiamate uscenti mediante numerazione breve;

Consentire l’attuazione della modalità conferenza con il servizio di interpretariato telefonico contestualmente alla chiamata ricevuta;

Consentire di richiamare gli ultimi numeri telefonici gestiti (almeno 10 entranti e/o uscenti);

Disporre di una rubrica telefonica dedicata con backup locale automatizzato e sincronizzato (minimo settimanalmente); La rubrica deve poter essere gestita in modo centralizzato

Scambiare messaggi testuali tra le postazioni operatore in modalità chat (per singolo utente o gruppo di utenti in tempo reale (max 5 secondi di latenza));

Avere informazioni sullo stato delle postazioni operatore (es: non presidiata, libera, in conversazione);

Utilizzare toni DTMF. E Stringhe di toni salvate;

Gestione ed amministrazione della rubrica telefonica;

Configurazione della gestione delle code sulle postazioni utente in base al tipo di chiamata ricevuta (amministrazione delle code).

IL SISTEMA DI REGISTRAZIONE Ogni Centrale Operativa deve essere dotata di apparati per la registrazione del traffico complessivo fonia e radio (Modello NICE), svolto in entrata ed in uscita, così come previsto dalla vigente normativa. Al Fornitore è richiesto come requisito di assicurare la funzionalità di registrazione completa delle comunicazioni effettuate per il singolo evento, garantendo:

l’integrazione con il sistema applicativo; la conformità alla normativa vigente che regolamenta le fasi di controllo e verifica delle chiamate da

parte degli operatori delle diverse centrali; la compressione digitale audio attraverso specifico algoritmo; la registrazione sia dei canali telefonici, sia sulla comunicazione da rete pubblica sia sulla

comunicazione inoltrata all’utente interno del centralino, sia dei canali radio; il riascolto della registrazione direttamente dal sistema di gestione ed attraverso un’interfaccia

grafica semplificata utilizzando gli strumenti multimediali tipici e utilizzando la rete dati IP. Le registrazioni delle chiamate devono poter essere ascoltate in tempo reale nei successivi 3 mesi dalla data di registrazione, mentre nei successivi mesi, fino ad un minimo di 24, dovrà essere possibile recuperare le registrazioni accedendo al sistema di storicizzazione previsto. Oltre sarà cura del Fornitore evidenziare il tipo di archiviazione che dovrà comunque essere permanente (a vita);

la possibilità di contrassegnare la registrazione delle chiamate almeno con le seguenti proprietà:

canale;

identificativo della scheda evento;

identificativo dell’operatore che ha gestito la chiamata;

l’utilizzo di tecniche di acquisizione, compressione e cifratura dei dati audio che garantiscono alte performance di “record and replay” simultaneo;

alta capacità del database di buffer on-line ed una elevata sicurezza dei dati archiviati;

la ricerca delle chiamate registrate, almeno mediante:

durata della chiamata;

data e ora;

63

CLI/numero chiamato su linee ISDN (se disponibile da PSTN);

contrassegno della chiamata, anche mediante eventuale testo di commento inserito post-registrazione;

nome e cognome;

combinazione dei criteri indicati. Il Fornitore potrà garantire come caratteristiche migliorative:

possibilità di riascolto della conversazione telefonica direttamente dal sistema di gestione per un tempo superiore al minimo richiesto;

possibilità di recuperare le registrazioni dal sistema di storicizzazione previsto per tempo superiore al minimo richiesto.

ANAGRAFICA UNICA REGIONALE Il Sistema proposto dovrà, come requisito, gestire un’Anagrafe degli Assistiti attraverso l'integrazione con il

Database di Anagrafica Unica Regionale, in grado di fornire sia le informazioni anagrafiche dei soggetti gestiti

(cittadini, medici generici e medici pediatri) sia informazioni di altra natura (es. la scelta e la revoca del

medico di base, ecc.) fatto salvo ogni utile meccanismo di gestione in differita quale ad esempio anagrafe

locale aggiornata con apposito collegamento standard (MPI) all’Anagrafe Assistiti Regionale.

Il presente paragrafo elenca gli applicativi degli altri Enti sanitari per i quali, allo stato attuale di conoscenza,

si sta valutando l’integrazione con il sistema di emergenza- urgenza delle Centrali Operative:

Sistema informativo di Gestione dei Pronto Soccorso;

Sistema Informativo di Gestione dei Posti Letto.

Integrazione portale DAE di regione; Allo stato attuale si prevede che le integrazioni dovranno essere realizzate attraverso l'implementazione di

servizi applicativi di tipo Web Service.

Il Fornitore dovrà, su eventuale richiesta dell’Amministrazione, assistere e supportare quest’ultima, nei modi

e nei tempi che gli Enti Regionali richiederanno, nella realizzazione dell’integrazione con gli applicativi

suddetti e con altri eventuali applicativi al momento non previsti. I costi derivanti da tale attività si intendono

esclusi dalla fornitura.

GESTIONE DEI PRONTO SOCCORSO Il sistema di gestione 118 dovrà essere progettato in modo tale da potersi integrare (attraverso l’utilizzo di protocolli

standard di comunicazione in ambito sanitario) con il sistema di gestione del Pronto Soccorso, in relazione al

trasferimento dei dati relativi al paziente soccorso dal 118 e trasferito alla struttura di pronto soccorso di competenza,

o più idonea, con trasmissione delle informazioni di ritorno al 118 in tempo reale.

INTEGRAZIONE CED INTERFORZE Come già indicato, i sistemi 118 e 112 dovranno essere integrati con i servizi CED interforze per le funzioni di scambio scheda contatto e localizzazione del chiamante, secondo quanto previsto dalla normativa ministeriale in vigore.

ASSISTENZA E MANUTENZIONE Il presente capitolo dettaglia i requisiti richiesti per i servizi di assistenza e manutenzione del sistema 118 regionale, lasciando piena libertà alle Ditte concorrenti di proporre miglioramenti e/o estensioni di tali servizi secondo quanto da loro ritenuto più opportuno.

64

Si precisa che le modalità e i termini cui la Ditta aggiudicataria deve sottostare nell'erogazione dei servizi di gestione e manutenzione indicati in questo paragrafo comprendendo tutti gli oneri del caso, i.e. la fornitura di parti di ricambio, la manodopera e le spese di trasferta. Si precisa inoltre che I servizi di gestione e manutenzione non ricomprendono i danni causati da eventi dolosi, catastrofici e, con l'esclusione del solo secondo sito Data Center, gli eventi di guasto riconducibili a cattivo funzionamento dell'impianto elettrico e/o di condizionamento salvo i casi di diretta responsabilità del fornitore cagionati da negligenza, colpa o dolo da parte di quest’ultimo. L’obiettivo primario dell’assistenza e della manutenzione dovrà essere quello di assicurare la completa operatività e la migliore efficienza dell’infrastruttura tecnologica al servizio del 118 della Regione Siciliana. Il servizio di assistenza e manutenzione dovrà essere assicurato per l’intera durata contrattuale e dovrà essere prestato presso tutte le sedi centrali e periferiche del 118. I servizi di assistenza e manutenzione dei sistemi informatici e telematici a supporto del servizio 118 della Regione Siciliana riguarderanno i seguenti ambiti: • connettività dati locale e geografica fra le Centrali Operative e i siti Data Center, inclusa la connettività Internet

• centrali telefoniche locali alle Centrali Operative

• applicativo di gestione del sistema di emergenza urgenza sanitaria ed in particolare le due piattaforme la piattaforma 118 ed il sistema per il triage telefonico sanitario

• infrastrutture informatiche hardware centralizzate e periferiche

• software di base centralizzato e periferico

ASSISTENZA SOFTWARE Per tutta la durata del contratto la Ditta aggiudicataria avrà in carico l’assistenza e la manutenzione del software applicativo e dell’applicazione per il triage telefonico sanitario. Tali servizi si declinano nelle seguenti attività manutentive: • Manutenzione correttiva. La manutenzione correttiva avrà come oggetto l’eliminazione di eventuali bugs o malfunzionamenti che dovessero emergere nell’utilizzo delle piattaforme applicative. La Ditta aggiudicataria assumerà dunque l’obbligo di eliminare le cause dei malfunzionamenti riscontrati secondo l’urgenza e la criticità dettate dai livelli di servizio (SLA) contrattualizzati • Manutenzione adattativa. La manutenzione adattativa dovrà includere tutte le attività di configurazione e fine tuning della piattaforma applicativa al fine di beneficiare di eventuali evoluzioni che dovessero interessare l'ambiente tecnologico al servizio del 118 regionale

• Manutenzione evolutiva. Con particolare riferimento alla piattaforma gestionale, dovrà esserne garantita, per tutta la durata del contratto, l’aderenza alle Normative e Leggi che dovessero essere promulgate relativamente alle modalità di gestione ed erogazione del servizio di emergenza urgenza sanitaria

• Servizi professionali per la personalizzazione del sistema informativo. Con particolare riferimento alla piattaforma gestionale dovrà essere garantita la possibilità di eseguire evoluzioni specifiche per la Regione Siciliana, in particolare: o la condivisione telematica dei dati di eventi e missioni con centrali Operative limitrofe

o la sincronizzazione dell’anagrafica pazienti del Sw 118 con l’Anagrafe Residenti Siciliani

o le attività di personalizzazione per un ammontare non inferiore a 500/anno giorni uomo di una risorsa di tipo senior

ASSISTENZA HARDWARE Il servizio di assistenza e manutenzione di tutti gli apparati hardware dovrà essere fornito da personale esperto con competenze specifiche sugli ambienti, architetture e prodotti forniti e dovrà comprendere le seguenti attività: • Manutenzione preventiva e programmata. Questa manutenzione dovrà essere effettuata on site allo scopo di verificare il regolare funzionamento degli apparati hardware per prevenire anomalie di funzionamento o guasti. In particolare si possono identificare a titolo di esempio le seguenti attività: mantenere i sistemi in

65

condizioni di perfetto funzionamento verificando ad esempio lo stato di pulizia degli inlet/outlet dei sistemi di raffreddamento o lo stato dei connettori elettrici e di rete. Le Ditte concorrenti sono invitate a indicare la frequenza con cui tale tipologia di manutenzione sarà effettuata • Monitoraggio proattivo da remoto. Tale tipologia di manutenzione dovrà essere effettuata da una postazione o da un centro di assistenza remoti e dotati degli opportuni strumenti per garantire la sicurezza a livello informatico e nello scambio delle informazioni. Lo scopo del monitoraggio sarà di prevenire eventi di guasto grazie al tracciamento dei parametri interni di funzionamento delle apparecchiature e dei processi core del sistema 118. Le Ditte concorrenti sono invitate a indicare la frequenza con cui tale tipologia di manutenzione sarà effettuata • Manutenzione correttiva. Questa manutenzione sarà mirata alla riparazione di guasti e malfunzionamenti al fine di ripristinare, nel rispetto degli SLA, l’originale funzionalità delle apparecchiature malfunzionanti. Quando richiesto il servizio dovrà essere fornito on-site dove risultano essere installate le apparecchiature guaste o malfunzionanti. Le attività sulle apparecchiature hardware dovranno essere svolte da personale qualificato e dotato di tutti gli strumenti necessari allo scopo. Quando richiesto la Ditta aggiudicataria dovrà garantire l’accesso al servizio manutentivo del Costruttore per l’esecuzione delle opportune escalation.

ASSISTENZA ASSET Per la durata contrattuale deve essere prevista la manutenzione di quanto concerne le Centrali operative

(Sedute, Arredi, piccole attività di cablaggio dati ecc).

SERVIZIO DI HELP DESK Il servizio di Help Desk dovrà configurarsi come punto unico di contatto (SPOC) per tutte le segnalazioni relative a quanto oggetto di fornitura nel presente procedimento. Il servizio dovrà essere focalizzato alla risoluzione,nel rispetto degli SLA sopra indicati, degli incident mettendo in atto ove necessario processi di escalation per il coinvolgimento di figure specialistiche; il servizio dovrà essere erogato h 24 per 7 giorni su 7 per 365 giorni/anno e dovrà essere raggiungibile mediante numerazione telefonica e ticket inserito sul sistema di trouble ticketing. Il servizio di Help Desk dovrà prevedere un processo di gestione dell’incident che consenta la registrazione e storicizzazione delle informazioni riguardanti tutte le fasi di gestione del ticket con il duplice scopo di consentirne il tracking e rendere possibile la produzione di report che dovranno contenere le informazioni necessarie a misurare la qualità dei servizi erogati ed il rispetto dei livelli di servizio (SLA). Nel caso di più segnalazioni relative alla stessa problematica dovrà essere aperto un unico Trouble Ticket di manutenzione con dati relativi alla prima. Ulteriori segnalazioni per lo stesso problema, successive alla chiusura dell'intervento, porteranno alla apertura di un nuovo intervento di manutenzione. Il servizio di Help Desk dovrà prevedere un processo di gestione dell’incident che consenta la registrazione e storicizzazione delle informazioni riguardanti tutte le fasi di gestione del ticket con il duplice scopo di consentirne il tracking e rendere possibile la produzione di report che dovranno contenere le informazioni necessarie a misurare la qualità dei servizi erogati ed il rispetto dei livelli di servizio (SLA). Nel caso di più segnalazioni relative alla stessa problematica dovrà essere aperto un unico Trouble Ticket di manutenzione con dati relativi alla prima. Ulteriori segnalazioni per lo stesso problema, successive alla chiusura dell'intervento, porteranno alla apertura di un nuovo intervento di manutenzione.

PRESIDIO È richiesto un servizio di assistenza che includa un presidio di due risorse a tempo pieno per tutta la durata contrattuale. Il presidio deve avere la possibilità di operare su tutte le Centrali/Sale Operative.

66

Per quanto concerne il presidio, si dovrà dare evidenza del Curriculum Vitae del soggetto che il Fornitore intende proporre. Nell’ambito della valutazione costituiranno titolo di merito le seguenti competenze:

Esperienze nella gestione della LAN (punti rete, apparati passivi, apparati attivi in tecnologia Cisco,…)

Esperienze nella gestione dei servizi telefonici

Esperienze nella gestione dei servizi di registrazione

Esperienze nella gestione dei server CTI

Esperienza nella gestione dei collegamenti WAN e internet

Esperienze significative ed anni di esperienza in ruoli analoghi nella gestione di un servizio di emergenza 118

LIVELLI DI SERVIZIO RICHIESTI Per quanto riguarda la definizione di Guasto Bloccante e Guasto non bloccante si specifica che: GUASTO BLOCCANTE: è il caso in cui l’intero sistema emergenza/urgenza sanitaria della singola Centrale Operativa o un’area funzionale risulta non funzionante ed impedisce l’operatività di almeno il 50% delle postazioni di Centrale Operativa;

GUASTO NON BLOCCANTE: tutti gli altri casi diversi dal guasto bloccante; I livelli di servizio (o Service Level Agreement SLA) rappresentano sostanzialmente i tempi di ripristino e sono i valori di riferimento rispetto ai quali valutare la qualità del servizio erogato. I livelli di servizio (SLA) necessari per avere un adeguato servizio di emergenza-urgenza sono identificati come segue: Infrastruttura di rete dati: collegamenti WAN e WWW

La finestra di copertura prevista è h24 – 7/7 giorni

Disponibilità per sede: 99,9 %

Tempo di ripristino per guasto bloccante per sede: 2 ore nel 90% dei casi e 4 ore nel 100 % dei casi

Tempo di ripristino per guasto non bloccante per sede: 6 ore nel 85% dei casi e 9h nel 100%

Centralini e telefoni analogici/digitali ad essi attestati Sistemi telefonici: GUASTO BLOCCANTE

La finestra di erogazione prevista è h24 – 7/7 giorni

tempo di ripristino per guasto bloccante: 4 ore nel 85 % dei casi e 8 ore nel 100%dei casi GUASTO NON BLOCCANTE

La finestra di erogazione prevista è 8:00-18:00 - 5/7 giorni

tempo di ripristino Next Business Day nel 100% dei casi Telefono digitale:


tempo di ripristino: Next Business Day nel 100 % dei casi Telefono analogico


tempo di ripristino: Next Business Day nel 100 % dei casi Cuffie


tempo di ripristino: Next Business Day nel 100 % dei casi

Risponditori automatici, stazioni di energia dei centralini e server documentazione addebiti Stazione Energia dei centralini:

67

GUASTI BLOCCANTI

La finestra di erogazione prevista è h24 7/7 giorni

tempo di ripristino: 4 ore nel 85 % dei casi e 8 ore nel 100% dei casi GUASTINON BLOCCANTI


tempo di ripristino per Next Business Day nel 100% dei casi Sistema informatico. In questa voce rientrano l’applicativo Software, i server, le workstation complete di mouse e tastiera, i monitor, i maxi-monitor, le stampanti, i firewall, gli switch, gli UPS: GUASTI BLOCCANTI

La finestra di erogazione prevista è h24 7/7

Tempo di risoluzione entro 8 ore nel 90 % dei casi e entro 16 ore nel 100 % dei casi GUASTI NON BLOCCANTI


Tempo di risoluzione Next Business Day nel 100% dei casi Storage e switch Fiber Channel:


Tempo di risoluzione GUASTI BLOCCANTI entro 4 ore nel 100% dei casi

Tempo di risoluzione GUASTI NON BLOCCANTI Next Business Day nel 100% dei casi Sistema di registrazione: GUASTI BLOCCANTI


Tempo di ripristino entro 8 ore nel 100 % dei casi GUASTI NON BLOCCANTI


Tempo di ripristino Next Business Day nel 100 % dei casi Apparati del sistema di navigazione. GUASTI BLOCCANTI


Tempo di ripristino entro 8 ore nel 100 % dei casi GUASTI NON BLOCCANTI


Tempo di ripristino GUASTI NON BLOCCANTI Next Business Day nel 100 % dei casi

SOPRALLUOGHI L’Impresa dovrà farsi carico, nella fase antecedente alla definizione dell’offerta, di eseguire gli opportuni

sopralluoghi presso tutte le Centrali Operative del servizio 118 per le verifiche necessarie a soddisfare i

requisiti richiesti e gli obiettivi del presente Capitolato pena esclusione.

ATTIVAZIONE DEL SISTEMA L’appaltatore, entro 120 giorni naturali consecutivi dalla data di stipula del Contratto, dovrà attivare il

servizio nella fase TRANSITORIA e entro 18 mesi dalla attivazione della fase Transitoria dovrà passare alla

fase a REGIME.

L’appaltatore dovrà fornire un piano delle attività contenente un diagramma di Gantt nel quale dovranno

essere presenti le seguenti milestones:

69

Consegna del software applicativo

- Installazione Operazioni di collaudo - Avvio pre-esercizio - Avvio dei corsi di formazione - Fine dei corsi di formazione - Fine pre-esercizio - Servizi aggiuntivi - migliorie offerte: - Le Ditte sono invitate a presentare servizi aggiuntivi e/o integrativi rispetto a quanto richiesto nel

presente appalto.

Oltre al Gantt è richiesta un’approfondita documentazione relativa all’organizzazione delle attività/modalità

di implementazione della architettura software richiesta.

È imprescindibile che l’implementazione della nuova architettura software non vada ad interrompere o a

limitare le attività svolte dall’architettura software oggi in uso.

SERVIZI DI CONSEGNA, POSA IN OPERA ED AVVIO IN ESERCIZIO

Le componenti hardware in fornitura andranno consegnate al piano, installate e configurate presso le sedi indicate dalla Committente entro 40 giorni solari dalla data di stipula del contratto. L’Impresa dovrà provvedere, a proprio esclusivo onere, a consegnare contestualmente alla data di stipula del contratto un piano lavori che rappresenti la schedulazione delle attività di consegna, installazione e configurazione di quanto in fornitura. Per tali attività, l’Impresa si impegnerà a:

impiegare personale adeguatamente preparato e in numero sufficiente allo svolgimento delle attività descritte nel presente capitolato

nominare entro 5 giorni lavorativi dal perfezionamento del contratto, il nominativo del responsabile tecnico che dovrà curare il coordinamento delle prestazioni contrattuali

Al termine delle attività di installazione e configurazione l’Impresa Aggiudicataria dovrà provvedere alle seguenti attività:

lo sgombero e l’asporto delle attrezzature e dei materiali residui, ivi compresi quelli di imballaggio, in conformità alle norme vigenti in materia di smaltimento dei rifiuti

la consegna del verbale di installazione recante le seguenti indicazioni: marca, modello e numero seriale di ciascun apparato hardware installato e configurato, identificativi del software fornito, nonché la dichiarazione di rispondenza dei prodotti alle specifiche tecniche di cui al Capitolato Tecnico

L’Impresa Aggiudicataria si impegnerà ad erogare, a proprio esclusivo onere, l’assistenza tecnica specialistica e il training on the job propedeutico all’avvio in esercizio dei sistemi installati. Tale assistenza dovrà essere svolta presso la sede indicata dalla Committente durante il normale orario di lavoro con la presenza di un sistemista di provata esperienza. Nel giorno di avvio in esercizio delle infrastrutture e nel giorno successivo, l’Impresa Aggiudicatrice dovrà provvedere, a proprio esclusivo onere ed in ogni sito, a quanto segue:

garantire la presenza in loco di personale di provata esperienza durante il normale orario di lavoro

70

garantire un accesso telefonico diretto al medesimo personale fuori orario base al fine di garantire una rapida risposta in caso si dovessero verificare fenomeni di grave interruzione del servizio

GESTIONE PRIVACY E SICUREZZA Le ditte concorrenti dovranno produrre un apposito documento, denominato “GESTIONE DELLA PRIVACY E

DELLA SICUREZZA” nel quale vengano evidenziate le procedure adottate per garantire un elevato livello di

privacy e sicurezza dei dati, in accordo con le normative vigenti (GDPR, CNIPA).

In termini più operativi è bene intendere la Sicurezza del Sistema Informativo non solo come “protezione del

patrimonio informativo da rilevazioni, modifiche o cancellazioni non autorizzate, per cause accidentali o

intenzionali”, ma anche come “limitazione degli effetti causati dall’eventuale occorrenza di tali cause”.

Delle misure di sicurezza adottate dovranno far parte i seguenti aspetti:

Il controllo degli accessi alle informazioni;

Il mantenimento della loro integrità e riservatezza;

La sicurezza nella trasmissione e nelle comunicazioni all’interno e all’esterno del sistema di gestione dell’Emergenza Sanitaria;

La sicurezza delle stazioni di lavoro e dei Personal Computer;

La sicurezza nella gestione operativa delle installazioni informatiche;

La tempestiva rilevazione e segnalazione di eventuali problemi di sicurezza.

Per quanto riguarda la tutela dei dati personali dovranno essere predisposte misure di protezione idonee:

A prevenire il rischio di una perdita o distruzione dei dati, anche solo accidentale;

Ad eliminare o ridurre al minimo i rischi di un accesso non autorizzato;

Ad impedire un trattamento non consentito o “non conforme alla finalità della raccolta”.

Per quanto riguarda la sicurezza degli archivi informatici sarà necessario implementare misure aggiuntive di

sicurezza e ridondanza dei dati, facendo anche ricorso a sistemi Fault Tolerant con uso di adeguati sistema di

dischi in mirroring.

In aggiunta dovrà essere previsto un adeguato piano di backup così da permettere che i dati siano sempre

disponibili al ripristino. Occorre altresì assicurarsi che la pianificazione di ripristino di emergenza sia adeguata

alle necessità della Regione definendo:

Analisi dei rischi per ciascuna area;

Livelli di priorità sulla base dell’analisi dei rischi;

Livelli di interruzione, inclusa l’interruzione generale;

Assegnazione di priorità a software applicativi e dati;

Conservazione di eventuali documenti originali e reimmissione dei dati;

Requisiti di sicurezza per ambienti di elaborazione di riserva.

--------------------------------------------- FINE DOCUMENTO----------------------------------------------------------------------

PROGETTO AREUS-118 CAPITOLATO TECNICO PER LA … · 2019. 10. 18. · la Centrale Operativa di...

Documents

Transcript of PROGETTO AREUS-118 CAPITOLATO TECNICO PER LA … · 2019. 10. 18. · la Centrale Operativa di...