LINEE GUIDA PER I SERVIZI DI ASSISTENZA E MANUTENZIONE PER I SOFTWARE

(1)

Allegato A1

LINEE GUIDA PER I SERVIZI DI

ASSISTENZA E MANUTENZIONE PER I SOFTWARE

Vers. 22 Luglio 2021

(2)

Pag. 2 di 23

INDICE

Il contesto 3

Identificazione della fornitura 3

Obiettivi del servizio 4

Utilizzatori 5

Oggetto del servizio 5

Copertura oraria oggetto del servizio 5

Attività previste dal servizio 5

Modalità di gestione del servizio 5

Modello di erogazione del servizio di assistenza e manutenzione 6

Richieste utente che necessitano di manutenzione evolutiva 7

Modalità di intervento 7

Gestione della sicurezza 7

Gestione della Privacy 7

Gestione della Profilazione utenti 8

Livelli di Servizio 8

Livelli di servizio per l'assistenza, per la manutenzione correttiva e per la gestione di RDBMS/server (se

inclusi) 8

Misurazione dei livelli di servizio 10

Servizi aggiuntivi 10

Manutenzione Evolutiva 10

Acquisto del servizio 10

Formazione e Addestramento 11

Impegno previsto 11

Penali 11

Penali mancata copertura servizio 11

Penali manutenzione ordinaria e correttiva 11

Penali manutenzione evolutiva standard 12

Penali manutenzione normativa standard 12

Penali manutenzione evolutiva o normativa urgente 13

Importi trattenuti a titolo di Penale 13

Rischio Clinico 14

(3)

Pag. 3 di 23

Appendice A 15

Premessa 15

Servizi del Fornitore per servizio di manutenzione 15

Modalità di intervento del Fornitore per servizio di manutenzione 15

Metodi oggettivi di misurazione delle performances 16

Risorse dedicate al supporto sistemistico 16

Definizione degli elementi Hw / SW oggetto di manutenzione 16

Definizione delle interfacce di amministrazione applicativi 17

Definizione delle tipologie di manutenzione sulla componente architetturale del Database 17

A)

Il contesto

Nel presente documento vengono normate le modalità di erogazione dei servizi di assistenza e manutenzione per i software che devono essere erogati ad ESTAR e alle Aziende Sanitarie della Regione Toscana.

Il presente documento si applica a ciascuno dei seguenti casi:

• ESTAR e/o le Aziende Sanitarie della Regione Toscana utilizzano applicazioni software per le quali un fornitore è proprietario/licenziatario del software in seguito ad aggiudicazioni di gare o ad acquisizione di aziende precedentemente proprietarie/licenziatarie dei software;

in tal caso si evidenzia che le Aziende Sanitarie hanno sempre acquistato la manutenzione dal fornitore proprietario/distributore delle licenze software e le attività richieste si inquadrano pertanto in una continuità di servizio

• ESTAR e/o le Aziende Sanitarie della Regione Toscana intendono acquisire nuove applicazioni software contestualmente all’acquisizione di servizi di assistenza e manutenzione

• ESTAR e/o le Aziende Sanitarie della Regione Toscana sono proprietarie di file sorgenti di un software e intendono acquisire i servizi di assistenza e manutenzione

B)

Identificazione della fornitura

Il servizio di assistenza e manutenzione di un software prevede sempre le seguenti voci:

● Assistenza telefonica e on line agli utilizzatori e diffusione dei manuali utente. Ha ad oggetto un servizio di helpdesk telefonico e/o telematico (via email o web form) dedicati da erogarsi nei tempi indicati nel paragrafo 5.1 del presente documento, al fine di offrire supporto al per il corretto ed efficiente utilizzo del programma e delle estrazioni dati e la soluzione dei problemi operativi che possono emergere nel suo utilizzo. Rientrano in Assistenza tutte le richieste informative di carattere tecnico (funzionamento di script, estrazione flussi, estrazioni dati, viste, etc.) fatte esclusivamente da personale di ICT Estar, salvo che, quanto richiesto, non sia già presente nei manuali tecnici consegnati a ICT.

● Manutenzione ordinaria: comprende tutti gli interventi sul software volti a consentire il corretto funzionamento con altri software presenti sulla postazione e con i sistemi operativi aggiornati rispetto a quelli previsti dal contratto di licenze, anche sulla base di segnalazioni ricevute.

È realizzata ciclicamente su base temporale, ovvero a scadenze regolari. Le linee guida distinguono due tipi di manutenzione ordinaria:

a) programmata, ovvero basata sul tempo, che prevede interventi con cadenza regolare e verifiche determinate da elenchi prefissati;

(4)

Pag. 4 di 23 b) di revisione, ovvero finalizzata ad assicurare aderenza delle procedure all’evoluzione

dell’ambiente tecnologico, ad es: aggiornamento di versioni del software di base;

Rientra nella manutenzione ordinaria tutta l’attività di profilazione utenti e comunque di generica configurazione (parametri, dizionari) laddove il software non sia dotato di funzionalità applicativa o nel caso in cui i moduli da utilizzare risultino oggettivamente difficili da utilizzare in termini di rapporto tra il dato da immettere il numero di passaggi da fare nell’applicativo.

● Manutenzione correttiva: Attività di manutenzione realizzata in risposta a malfunzionamenti e/o non rispondenza a specifiche applicative o di flussi, sulla base dei test o delle segnalazioni fatte, da realizzarsi entro i tempi previsti dagli SLA contrattualizzati. Rientrano nella manutenzione correttiva tutti gli interventi necessari alla sistemazione dei dati sul database laddove la causa sia direttamente imputabile ad un malfunzionamento dell’applicativo o ad una integrazione con altri software.

● Manutenzione normativa: Attività di manutenzione realizzata per garantire il rispetto della normativa nazionale e/o regionale, prevista da delibere emesse dall’organismo legislativo competente ed effettuata su segnalazione/richiesta del Cliente. Rientrano nella manutenzione normativa anche gli aggiornamenti di tabelle di dizionari salvo che non siano già previsti tool per il caricamento massivo delle informazioni con i quali Estar può procedere in autonomia. Sono da quotare separatamente le attività relative a manutenzione normativa regionale laddove l’intervento richiesto dia luogo alla modifica delle strutture della base dati, o, nel caso di flussi, al cambio di tecnologia usata (es. da flussi a eventi) o quando la variazione richieda l’integrazione con software di altre ditte. La manutenzione normativa è soggetta a specifico collaudo.

● Erogazione dei seguenti servizi aggiuntivi:

- Manutenzione evolutiva e forniture supplementari - Assicurazione qualità e risoluzione dei problemi - Fornitura documentazione esaustiva e aggiornata - Reportistica periodica sugli SLA

- Reportistica periodica sulla gestione flussi ad eventi

C)

Obiettivi del servizio

Gli obiettivi della Assistenza sono così definiti:

● facilitare le diverse categorie di Utenti nell’utilizzo operativo e funzionale dei mezzi informativi e dei sistemi e servizi previsti;

● fornire in modo esaustivo tutte le informazioni e gli strumenti di supporto richiesti dagli Utenti per risolvere i problemi in modo tempestivo ed efficace;

● offrire agli Utenti tutte le informazioni che l’Amministrazione ritiene opportuno far conoscere in merito alla disponibilità di nuovi servizi o alla modifica di servizi esistenti;

● fornire manuali d'uso periodicamente aggiornati;

● garantire, alle strutture di controllo preposte, la verifica costante della qualità del servizio erogato e la conoscenza sia delle necessità e dello stato di soddisfazione degli Utenti sia dell’utilizzo dei servizi;

● identificare e segnalare all’Amministrazione la necessità di formazione sulla base delle informazioni monitorate dal Contact Center, al fine di adeguare o mantenere la competenza degli utenti e degli operatori sui servizi supportati.

Gli obiettivi della Manutenzione sono così definiti:

● mantenere operative le soluzioni software attraverso attività che assicurino in via continuativa la rimozione dei malfunzionamenti;

● risolvere, anche con eventuali workaround temporanei, le criticità del software o dei flussi estratti da correggersi in via definitiva con il rilascio di patch/release correttive;

● assicurare il miglioramento tempestivo delle funzionalità e delle prestazioni;

● garantire l’evoluzione tecnico funzionale della soluzione software;

● assicurare l’aggiornamento periodico della soluzione, attraverso il miglioramento della funzionalità, dell’affidabilità e dell’efficienza dei prodotti.

(5)

Pag. 5 di 23

● assicurare l’aggiornamento della documentazione sull’architettura del prodotto e sulla struttura database utilizzata, nonché delle integrazioni con altri prodotti;

● assicurare gli aggiornamenti del software di base (sistema operativo, agent di gestione e monitoring, application server, etc etc) con particolare riferimento alle patch di sicurezza;

● predisporre e mantenere aggiornato il piano di backup/restore, ovvero indicare e mantenere aggiornato nel tempo l’elenco degli elementi, le modalità, la frequenza con cui programmare il backup per assicurare un restore consistente all’ultimo backup effettuato;

predisporre altresì gli elementi da sottoporre a backup, in accordo al piano;

● predisporre ed implementare il piano periodico di storicizzazione dei dati obsoleti, ritenuti tali secondo le normative vigenti o le indicazioni del servizio cui il software afferisce, con la sola gestione “in linea” dei dati del periodo di riferimento. L’intento è quello di mantenere efficiente la gestione quotidiana dei dati, ottimizzando le dimensioni dei db “in linea” e i tempi di backup/restore che saranno pertanto effettuati sulla sola componente “in linea”, ovvero non storicizzata. Se per coerenza con la normativa vigente occorresse mantenere storia dei dati obsoleti, dovrà essere predisposto specifico piano di backup.

D)

Utilizzatori

Gli utenti destinatari del servizio di assistenza si distinguono in:

● utenti identificati da ESTAR e/o dalle Aziende Sanitarie che utilizzano i software

● incaricati dall’Amministrazione delle Aziende Sanitarie per la Gestione Applicativi e Basi Dati, Gestione Sistemi e Gestione Reti, Postazioni di Lavoro

● personale del Dipartimento Tecnologie Informatiche di ESTAR

Si evidenzia che il principale utente per il Controllo dei Livelli di Servizio è il Dipartimento Tecnologie informatiche di ESTAR che deve monitorare, attraverso i Direttori dell’Esecuzione del Contratto, lo stato del servizio e informare l’Amministrazione di ESTAR e di ogni Azienda Sanitaria di eventuali criticità.

E)

Oggetto del servizio

Il Fornitore di un servizio di assistenza e manutenzione dovrà svolgere le attività previste dal presente documento per tutto il software che rientra nel relativo contratto.

I moduli software oggetto del servizio possono essere installati presso le sale server delle Aziende Sanitarie, di ESTAR o presso Centri Servizi esterni (ad esempio TIX di Regione Toscana). In quest’ultimo caso le modalità di aggiornamento software per attività di manutenzione sono regolate in maniera specifica.

Per una più puntuale identificazione della fornitura si chiede che il Fornitore fornisca in sede di offerta tutti i dettagli necessari per identificare in dettaglio i singoli moduli in ambito alla fornitura in modo non vago o ambiguo. In particolare il Fornitore deve esplicitare/fornire tutti i dettagli per identificare in modo chiaro i moduli e le funzionalità a disposizione delle Aziende, evidenziando le eventuali differenze per le diverse installazioni.

1.

Copertura oraria oggetto del servizio

Il servizio di assistenza può essere erogato con fasce orarie di copertura più o meno ampie; nella tabella seguente vengono indicate le fasce orarie di copertura più comuni adottate per gli

applicativi gestiti da Estar:

Copertura oraria del servizio

STANDARD 5 gg – 10 h Da lunedì a venerdì, dalle 8:00 alle 18:00, festivi esclusi

ESTESO 6 gg Da lunedì a sabato, dalle 7:30 alle 19:30, festivi esclusi

(6)

Pag. 6 di 23 H24 365 gg H 24 Tutti i giorni della settimana dalle 00:00 alle

23:59 festivi compresi

Il Fornitore dovrà fare riferimento alla tipologia di fascia oraria richiesta nel capitolato per definire nell’offerta per ogni Azienda/Software le fasce orarie di copertura ed i relativi costi.

Nel caso in cui non sia indicata la fascia oraria nel capitolato, il Fornitore è tenuto a produrre un elenco chiaro ed esaustivo delle fasce orarie di copertura proposte per ogni modulo software.

F)

Attività previste dal servizio

1.

Modalità di gestione del servizio

Per tutti i servizi oggetto del capitolato, il Fornitore dovrà produrre documentazione su:

● organizzazione e responsabilità delle risorse (risorse hardware, software ed umane) previste dal fornitore per la gestione e l’erogazione del servizio, comprensivo dei limiti di competenza per i diversi livelli previsti nell’erogazione del servizio;

● attività, processi, metodologie affinché l’erogazione del servizio possa avvenire secondo i livelli di qualità definiti (Operational Level Agreement - OLA);

● i controlli da svolgere internamente per assicurare la qualità della fornitura e relativi piani di verifica, incluse le specifiche responsabilità riguardo alla gestione delle non conformità, alla gestione delle configurazioni ed al controllo delle sub-forniture;

● le modalità di aggiornamento e condivisione della documentazione tecnica e funzionale;

● il piano di gestione delle comunicazioni (comprensivo delle procedure di escalation), in particolare nel caso in cui il rilascio assuma caratteristiche di criticità, quando siano previste significative modifiche o impatti sui processi o sull’organizzazione dell’utente o del gestore dei sistemi;

● le modalità per la condivisione/pubblicazione del Reporting sul Servizio ove si illustrano le performance del servizio nel periodo di riferimento

Si richiede che i manuali d’uso del software vengano mantenuti aggiornati in base alle evoluzioni del software e della base dati nel tempo.

● Fornitura dei seguenti manuali:

Manuale Descrizione Documento

Manuale Tecnico

● Architettura del prodotto

● Amministratore Sistema

● Struttura del Database – schema relazioni

● Estrazione Flussi (criteri e tabelle coinvolte)

● Integrazioni con altri sistemi

● Check List di primo intervento Manuale

Applicativo (Funzionale)

● Amministratore

● Operatore

L’ “Architettura del prodotto”, da completare in fase di deployment e da aggiornare ad ogni variazione, deve descrivere in maniera esaustiva

le componenti e i ruoli (es. server e risorse, componenti sw quali application server e database, proxy, etc etc), compresa la loro identificazione nell’ambiente di deployment (hostname, ip, etc) le interazioni tra le diverse componenti, in termini di servizi forniti/usati, anche avvalendosi di schemi riassuntivi e di immediata consultazione (es. Deployment diagram – UML).

(7)

Pag. 7 di 23 Il manuale “Amministratore di sistema” deve riportare, tra l’altro, in maniera esaustiva (per ogni componente dell’architettura) le risorse utilizzate (hw/sw, compatibilità, locazione nelle directory, log e eventi prodotti, etc.), le operazioni e agli strumenti necessari per la loro manutenzione.

La “Check List di primo intervento”, da completare in fase di deployment e da aggiornare ad ogni variazione, è una procedura, automatica o manuale, che comprende una serie di test elementari sullo stato operativo delle risorse di sistema, di rete e database (es. check raggiungibilità del server con IP =…, check dello stato del processo XYZ, stato di occupazione del disco, verifica spazio libero sui tablespace, etc.).

L’esecuzione della “Check List” serve, in caso di malfunzionamento dell’applicativo, per individuare o escludere le principali cause di errore a livello sistemistico e di rete.

2.

Modello di erogazione del servizio di assistenza e manutenzione

Per poter svolgere il servizio di manutenzione richiesto il fornitore deve ricevere una segnalazione da un utente abilitato.

Le segnalazioni potranno essere effettuate da:

● Service desk aziendale dopo aver escluso o risolto problematiche legate alle postazioni di lavoro

● Personale ICT Estar addetto al presidio dei software

● Dall’utente aziendale (soprattutto in fasce orarie non coperte dai servizi interni)

● Dal Personale del fornitore del Middleware aziendale solo per i ticket oggetto di integrazione con l’applicativo.

Si precisa che in caso di chiusura impropria di un ticket, senza aver riscontrato l’effettiva e definitiva risoluzione dell’anomalia e che comporta una successiva apertura di nuovo ticket riconducibile al precedente, gli SLA decorrono dalla data di apertura del primo ticket e le penali saranno calcolate sulla data di risoluzione definitiva del problema segnalato.

Il Fornitore deve indicare in sede di offerta il punto di accesso unificato per ESTAR e per ogni Azienda Sanitaria, rendendo disponibili numeri di telefono, relativi indirizzi email e piattaforme di trouble ticketing per le quali si richiede la visibilità per il monitoraggio dei ticket aperti.

È richiesta la disponibilità MINIMA di un numero telefonico dotato di tecnologia di gestione delle code e di un punto di accesso all'apertura di ticket via E-Mail.

Si precisa che, a prescindere dal modello organizzativo di assistenza ai software in essere presso le Aziende Sanitarie, il fornitore è tenuto a prendere in carico, gestire ed evadere qualsiasi richiesta di assistenza notificata attraverso i canali ufficiali.

3.

Richieste utente che necessitano di manutenzione evolutiva

Ogni richiesta utente non compresa nel servizio di manutenzione ordinaria, correttiva o normativa deve essere gestita secondo le modalità indicate nella “Procedura Software Change Request”.

4.

Modalità di intervento

In relazione alla natura dell’intervento necessario questo potrà essere svolto dal Fornitore con:

● Intervento telefonico

● Intervento da remoto

● Intervento on site

Ogni intervento potrà comprendere anche più modalità.

L’impossibilità di intervento da remoto, qualsiasi sia la causa, non può costituire in alcun caso motivo di non intervento. In tali situazioni, il fornitore deve garantire l’intervento on-site in tempi compatibili con quanto previsto negli SLA.

(8)

Pag. 8 di 23 Tutte le attività eseguite presso le sedi degli utenti dovranno essere documentate da un Rapporto di Intervento redatto a cura del tecnico del Fornitore che esegue l’intervento e dovrà essere controfirmato dal committente e/o da ESTAR. Una copia del Rapporto di Intervento firmato dovrà essere inviato al Direttore dell'Esecuzione del Contratto.

5.

Gestione della sicurezza

L’applicazione dovrà mantenere il livello di sicurezza necessario atto a mantenere la riservatezza e integrità dei dati, dei flussi ed il controllo del livello di accesso alle funzioni del sistema. A tal fine il fornitore dovrà:

● evidenziare al committente eventuali carenze sulla protezione del software di base ai virus informatici che possono danneggiare gli applicativi e/o la base dati;

● gestire le emergenze attraverso l’uso efficace degli strumenti adottati per l’erogazione del servizio;

● mettere tempestivamente in atto gli aggiornamenti sul software in esercizio necessari per l’efficace funzionamento delle componenti fornite;

● su richiesta di ESTAR, verificare la compatibilità dei componenti applicativi con gli aggiornamenti di sicurezza del software di base (antivirus, antimalware, patch di sicurezza s.o, etc); nel caso di incompatibilità che impediscono l’aggiornamento, il fornitore deve produrre un report delle attività necessarie per l’adeguamento (manutenzione evolutiva dell’applicazione) e attuarle.

● monitorare gli eventi significativi per la sicurezza, evidenziati durante l’erogazione del servizio;

● in caso di segnalazione o rilevazione di minaccia proveniente dal sistema antivirus locale o centralizzato o da altre fonti concordate, attivarsi immediatamente per ripristinare il sistema per quanto di competenza, ad esempio rimuovendo/sostituendo/ripristinando eventuali componenti applicative infette;

● controllare ed analizzare, in modalità centralizzata, i dati (ad esempio i log dei sistemi) e gli allarmi di tipo automatico.

● progettare e monitorare un’architettura di backup per il recupero delle informazioni cliniche di un paziente in assenza di accesso all’applicativo (offline)

6.

Gestione della Privacy

La particolare delicatezza dei dati trattati per mezzo dei programmi impone un alto livello di attenzione per garantire il pieno rispetto degli obblighi imposti dalla normativa in vigore in tema di privacy.

In particolare le procedure informatiche dovranno risultare adeguate alle norme vigenti e alle direttive del garante in materia di sicurezza e privacy, alle linee guida in tema di fascicolo sanitario elettronico (FSE) e dossier sanitario (Del. n. 8 del 5 marzo 2009 e.s.m.) nonché, per l’attività in ambito, al documento sulle misure minime di sicurezza ict per le pubbliche amministrazioni (AGID).

Qualora le procedure non fossero adeguate, si chiede l’evidenza delle parti/funzionalità ove le procedure non sono adeguate e un piano per la realizzazione di tutti gli interventi necessari per il loro adeguamento (si evidenzia che tali interventi rientrano nella manutenzione normativa). In attesa degli eventuali adeguamenti normativi, a fronte di eventuali sanzioni, Estar si rivarrà direttamente sulla ditta appaltatrice.

Nel caso in cui l'Azienda Sanitaria o ESTAR individuino malfunzionamenti o configurazioni del software a loro avviso particolarmente rischiose per la protezione dei dati (es. password in chiaro sui file locali ai pc, backup pdf di parti di cartelle cliniche su pc locali senza adeguati meccanismi di protezione, ecc.), si riservano di aprire ticket a gravità 2 e/o gravità 3 per la messa in sicurezza dei sistemi, e di applicare le conseguenti penali nel caso in cui il tempo di risoluzione non rientrasse negli SLA contrattualizzati.

7.

Gestione della Profilazione utenti

(9)

Pag. 9 di 23 Gli applicativi in ambito ai contratti di assistenza e manutenzione devono garantire che il processo di profilazione ed autorizzazione degli utenti sia effettuato preservando i livelli di riservatezza legati ai profili configurati. Si richiede che gli applicativi informatici siano dotati di un’interfaccia utente amministrativa che consenta di configurare gli utenti associando gli opportuni profili di accesso alle funzionalità ed ai dati.

Tale interfaccia utente, per gli applicativi che ne sono sprovvisti o che non corrisponda ai requisiti descritti, dovrà essere realizzata e installata dal fornitore senza oneri aggiuntivi per Estar entro 3 mesi dalla sottoscrizione del contratto, includendo la formazione degli amministratori di sistema ed il manuale utente aggiornato per tale funzionalità. La realizzazione dell’interfaccia dovrà tener conto dei principi di semplicità e linearità garantendo il minor numero di passaggi possibili.

G)

Livelli di Servizio

Il calcolo dei livelli di servizio deve avvenire in modo indipendente per ogni Ente.

I criteri di valutazione della Gravità sono identificati in base all’impatto che hanno sul funzionamento del sistema, sulle prestazioni, sulla sicurezza e sui vincoli di scadenza previsti dalle norme Nazionali o Regionali.

Si precisa che, in linea con le indicazioni AGID nonché con le strategie regionali di evoluzione dei data center, ogni procedura ad evidenza pubblica per l’acquisizione di nuovo software per il SSR Toscano dovrà essere fruibile sia nella modalità IAAS che nella modalità PAAS. In particolare vengono richiesti all’Aggiudicatario:

1. La manutenzione e assistenza sul solo livello software oggetto della fornitura, che è ritenuta economicamente inclusa nella voce ‘Progetto impianto….’ della scheda dettaglio economico.

In tal caso la gestione del livello PAAS è garantita da RT o ESTAR anche avvalendosi di contratti di servizio con fornitori terzi.

2. La possibile estensione all’Aggiudicatario della manutenzione e assistenza di livello sistemistico a tutto lo stack software (es. sistemi operativi, RDBMS, etc), avvalendosi dei costi dichiarati alla voce ‘Estensione del servizio di assistenza e manutenzione a sistemi operativi, RDBMS, etc.. (infrastruttura erogata come IAAS)’ della scheda dettaglio economico. In tal caso la gestione del livello IAAS è garantita da RT o ESTAR anche avvalendosi di contratti di servizio con fornitori terzi.

Maggiori dettagli in merito sono riportati nel documento ”Specifiche tecniche per progettazione, acquisizione ed implementazione di automazioni informatiche”.

3.

Livelli di servizio per l'assistenza, per la manutenzione correttiva e per la gestione di RDBMS/server

Per definire i livelli di servizio si associa il livello di criticità ai relativi tempi di intervento richiesti come valori normali e valori limite.

I criteri di valutazione della complessità sono catalogati in base all’impatto che hanno per gli utenti, sul funzionamento del sistema, sulle prestazioni e sulla sicurezza; a tale proposito si individuano 3 livelli di criticità:

● GRAVITA' 1: una o più linee di prodotto presso una Azienda sono completamente bloccati oppure nessuna linea di prodotto è bloccata, ma le funzionalità critiche di uno o più moduli non sono disponibili o sono malfunzionanti. Si evidenzia che un guasto non bloccante può diventare bloccante in particolari momenti lavorativi (es. necessità di produrre report amministrativi il cui normale tempo di produzione non consente la presentazione entro la data di scadenza, impossibilità di fare ricoveri o dimissioni per un software ADT o per un Sistema Informativo Ospedaliero Integrato, impossibilità di inserire richieste in un Order Entry, etc...), rientrano in questa casistica anche i blocchi delle integrazioni che coinvolgono altri software collegati la cui funzionalità è strettamente connessa a processi clinici. Vengono classificati a massima gravità anche i malfunzionamenti che causano la presentazione o generazione di dati/contenuti informativi errati conseguenti a difetti interni del software o delle integrazioni (ad es. la visualizzazione di una lista di pazienti

(10)

Pag. 10 di 23 errata, la modifica impropria di un dato anagrafico come una data di nascita, CF o indirizzo, la modifica impropria dell'esito di un referto, modifica impropria / perdita di dati critici come prenotazioni, appuntamenti, consensi); in tali casi rientra nelle attività a carico del fornitore, negli stessi SLA, anche la correzione dei dati e il ripristino di un archivio dati corretto e integro. Rientrano infine in questo livello di gravità anche i blocchi delle integrazioni che coinvolgono altri software la cui regolare funzionalità è strategica nel supporto ai processi clinici (es. integrazioni di richieste di esami e ritorno referti, accesso alla visualizzazione di immagini, ).

● GRAVITA' 2: Nessuna linea di prodotto è bloccata, ma importanti funzionalità di una o più linee di prodotto non sono disponibili o sono malfunzionanti. Si evidenzia che un guasto può diventare di Gravità 2 in particolari momenti lavorativi (es. impossibilità di invio un evento RFC o di un flusso entro le scadenze, estrazione di una lista di pazienti non completa per errori nelle query di retrieve, mancato funzionamento di una integrazione non critica, etc...);

● GRAVITA' 3: le funzionalità non critiche e non importanti del sistema non sono disponibili o malfunzionanti, senza impatto sulla operatività degli utenti (es. maggiore inefficienza); in questa categoria sono comprese anche le normali chiamate di assistenza funzionale da parte degli operatori;

Livello di Criticità

Descrizione della Criticità Tempi di Risoluzione

Standard *

Tempi di Risoluzione

Limite **

GRAVITA' 1 Alta criticità

Fermo operativo di aree critiche dell'Azienda o integrazioni critiche (legate a processi clinici)

Soluzione garantita entro 2 ore lavorative dalla

segnalazione

segnalazione GRAVITA'

2 Media criticità

Fermo operativo di aree circoscritte dell’Azienda

segnalazione

segnalazione GRAVITA'

3 Bassa criticità

Assistenza all'utenza o malfunzionamento di funzionalità non critiche o non essenziali per l’Azienda

segnalazione

* il tempo di risoluzione deve rispettare i Tempi indicati almeno nel 90% dei casi

** il tempo di risoluzione deve rispettare i Tempi indicati nel 100% dei casi

Si evidenzia che rientrano negli SLA anche le chiamate di assistenza e manutenzione successive all'installazione di una nuova release o di un aggiornamento di ambienti tecnologici, server, etc....

Per il calcolo dei livelli di servizio si considera il tempo che intercorre dalla data di segnalazione da parte dell’utente alla data di risoluzione della criticità all'interno del tempo di disponibilità del servizio contrattualizzato (solo per un servizio H24x365GG il calcolo del tempo di risoluzione non deve prevedere interruzioni).

Nel caso in cui il fornitore della manutenzione riscontri che la risoluzione della problematica sia completamente di competenza di fornitori terzi tali chiamate possono essere escluse dal Calcolo degli SLA, ma devono comunque essere riportate – in elenco a parte - nella rendicontazione trimestrale (Allegato B “Esempio calcolo SLA”) che deve sempre contenere TUTTE le chiamate aperte dal Cliente.

Si evidenzia che nel caso in cui il fornitore della manutenzione riscontri che la risoluzione della problematica sia completamente di competenza di terzi sono definiti dei livelli di servizio diversi che devono comunque essere rispettati. Si prevedono infatti i seguenti livelli di servizio per la sola presa in carico del problema (si intende per Tempo di presa in carico il tempo che intercorre tra la ricezione della segnalazione di un problema e il re-inoltro della segnalazione a terzi). Nel caso di

(11)

Pag. 11 di 23 integrazioni con terze parti, dove la ricerca del problema viene di norma fatta in modo congiunto tra le parti, la chiusura del ticket per escalation a terzi non esonera il fornitore dall’effettuare tutte le attività necessarie a supporto [informazioni, dati, test ecc..] raccordandosi direttamente con le software house interessate.

Livello di Criticità Valori Normali (*) Valori Limite (**)

GRAVITA' 1 30 min 1 ora

GRAVITA' 2 2 ore 4 ore

GRAVITA' 3 8 ore 12 ore

* da rispettare almeno nel 90% dei casi

** da rispettare nel 100% dei casi 4.

Misurazione dei livelli di servizio

Questa attività si rende necessaria per il controllo sulla conduzione del contratto e il monitoraggio del servizio offerto all’utente.

A questo proposito:

● il personale di ESTAR e delle Aziende deve avere la possibilità monitorare i ticket, compresi gli avanzamenti di stato, presenti nella piattaforma di trouble ticketing del fornitore;

● il DEC per le diverse Aziende effettuerà la verifica del rispetto dei livelli di servizio e il calcolo delle eventuali penali;

● la verifica dei livelli di servizio avverrà trimestralmente a partire dalla reportistica inviata dal fornitore;

● Il Fornitore deve fornire il Rapporto sui Livelli di Servizio e il Rapporto sull’Attività erogata trimestralmente, entro i primi 5gg lavorativi del mese successivo;

Il DEC analizzerà i dati forniti verificando la completezza e la correttezza dei dati forniti a suo insindacabile giudizio. Il DEC si riserva di effettuare verifiche a campione sulle chiamate effettuate e sui tempi di chiusura indicati nei report.

Il mancato rispetto dei livelli di servizio concordati potrà dare luogo all’addebito di penali come esplicitato nel successivo capitolo.

H)

Servizi aggiuntivi

1.

Servizi Aggiuntivi in Ambito

Ogni richiesta utente non compresa nel servizio di manutenzione ordinaria, correttiva o normativa deve essere gestita secondo le modalità indicate nella “Procedura Software Change Request”.

1.1 Manutenzione Evolutiva

Gli interventi di manutenzione evolutiva per i software in esercizio riguardano prevalentemente:

● modifiche anche urgenti alle funzioni, realizzate con tempi e risorse contenuti (ad esempio la modifica di una transazione o di un tabulato per una diversa prospettazione dei dati);

tali modifiche non comportano alcun impatto significativo sull’architettura generale delle applicazioni, sui processi o sull’organizzazione del lavoro degli utenti finali; possono comportare talvolta una variazione, di norma molto limitata, della consistenza dei prodotti;

● interventi volti ad arricchire il prodotto o comunque a modificare o integrare le funzionalità del prodotto. Tale manutenzione implica la scrittura di funzioni aggiuntive d’integrazione a sistemi applicativi esistenti o parti di funzioni (anche in sostituzione di altre già esistenti) di dimensione significativa e di cui è possibile preventivamente definire i requisiti o quantomeno identificare le esigenze;

● attività mirate a migliorare l'asset tecnologico su cui si basano i sistemi oggetto della fornitura: aggiornamenti di release, migrazione di DB, upgrade di server, etc…;

(12)

Pag. 12 di 23

2.1 Forniture Supplementari Opzionali

Le forniture supplementari comprendono quelle forniture (moduli software aggiuntivi, licenze, etc.) destinate ad ampliare l'applicativo esistente e di riferimento per le quali il cambiamento del fornitore aggiudicatario del servizio creerebbe, per la Stazione appaltante, gli effetti indicati dall’art. 106 comma 1. lett. b). La modifica non può alterare la natura complessiva del contratto/convenzione.

Le forniture complementari per i software in esercizio riguardano:

● Modifica o integrazione di un prodotto software con moduli applicativi aggiuntivi che ne arricchiscono / estendono le funzionalità;

● Acquisizione di Licenze di prodotti software al fine di estendere l’utilizzo di applicativi esistenti e di riferimento;

● modifiche che possono comportare un impatto significativo sull’architettura generale delle applicazioni, sui processi o sull’organizzazione del lavoro degli utenti finali; possono comportare talvolta una variazione, di norma molto limitata, della consistenza dei prodotti;

Gli acquisti di forniture supplementari sono gestiti seguendo percorso e procedure amministrativi delle manutenzioni evolutive (descritte al capitolo H) con le relative penali (descritte al capitolo I).

2.

Acquisto del servizio

Le Aziende Sanitarie non assumono alcun impegno per l’acquisto di attività di Manutenzione Evolutiva o di altro servizio aggiuntivo.

L’indicazione dell’impegno per tipologia di figura professionale deve intendersi unicamente allo scopo di determinare una quantità di giorni uomo che sarà considerata dal committente disponibile e utilizzabile fino ad esaurimento. I giorni uomo disponibili si ridurranno con l’addebito a consuntivo, da parte del fornitore, dei servizi formalmente richiesti con un ordine specifico. Qualora sia necessario impiegare un numero di giorni uomo superiore rispetto a quanto previsto, dovranno essere definiti specifici accordi per la quota eccedente.

Gli interventi di Manutenzione Evolutiva sono regolati dalla Procedura “Software Change Request” che costituisce parte integrante del contratto.

La manutenzione evolutiva può essere fatturata dal Fornitore solo ad avvenuto collaudo positivo per le modifiche al software o a fronte di rendicontazione firmata delle attività svolte On Site.

Su richiesta della stazione appaltante e/o del RES del contratto, il Fornitore è tenuto a dare disponibilità alla pubblicazione del software, quando auto-consistente ed acquisito come Manutenzione Evolutiva o come Fornitura Supplementare, sul catalogo del riuso (Developers Italia).

3.

Formazione e Addestramento

Il fornitore deve esplicitare nell’offerta tecnica la modalità di erogazione della formazione e:

● la tecnologia prevista e/o utilizzabile;

● le variabili di dimensionamento;

● i vincoli e i requisiti organizzativi;

● gli standard e le norme di riferimento.

La modalità di acquisto del servizio, di erogazione e di fatturazione sono analoghe a quanto illustrato per la Manutenzione evolutiva.

4.

Impegno previsto

Per gli interventi presso sedi ESTAR o delle Aziende Sanitarie si ritiene che:

● la tariffa giornaliera sia comprensiva di spese e oneri di trasferta

(13)

Pag. 13 di 23

● sia svolto un numero minimo di 8h lavorative presso la sede del Cliente e siano stati raggiunti gli obiettivi prefissati

In caso di acquisizione di servizi di Manutenzione Evolutiva o di Forniture Supplementari, il RES e il Fornitore possono concordare un incremento del canone di manutenzione e assistenza alle seguenti condizioni:

che sia previsto l'anno di garanzia a partire dalla data di collaudo

che il costo del canone aggiuntivo sia inferiore al 25% rispetto al costo dello sviluppo del software o al costo della fornitura supplementare

I)

Penali

Se l’Azienda o l’ESTAR riscontrano inosservanze delle obbligazioni contrattuali e/o inadempimenti non puntuali delle stesse, il Responsabile dell'Esecuzione contesta formalmente al fornitore le inadempienze riscontrate e assegna un termine per la presentazione di contro-deduzioni scritte.

Qualora le giustificazioni non pervengano o non siano ritenute idonee, saranno applicate penali dandone preventiva comunicazione al Fornitore.

1.

Penali mancata copertura servizio

Le Aziende Sanitarie e/o il Dir. dell’Esecuzione procederanno a verifiche a campione sul rispetto dell’orario di copertura del servizio.

Nel caso in cui si verifichi per due volte nell’arco di un trimestre la mancanza di copertura oraria per il servizio, il Responsabile dell'Esecuzione ha la facoltà di decurtare dal canone di manutenzione l’importo come di seguito calcolato:

A = numero di ore intercorse dall’inizio del servizio giornaliero fino alla verifica di ESTAR (si considera l’orario maggiore, con arrotondamento all’ora successiva)

B = costo orario del canone di manutenzione

C = numero di giorni di manutenzione intercorsi dall’inizio del trimestre di fatturazione fino al giorno del secondo rilevamento

Importo da decurtare = A x B x C x 2

2.

Penali manutenzione ordinaria e correttiva

Nel caso di disservizi ovvero non osservanza dei livelli di servizio, ritardi negli interventi di manutenzione o nel ripristino delle funzionalità imputabili al Fornitore, il Responsabile dell'Esecuzione ha facoltà di applicare nei confronti del Fornitore le penali calcolate come di seguito illustrato:

Le penali previste per il mancato rispetto degli SLA (da applicarsi ad OGNI ticket che non rientra negli SLA) sono:

1. Gravità 1 – € 400,00 per avvenuto ripristino delle funzionalità entro la prima ora di ritardo rispetto al tempo limite di risoluzione indicato nel presente Capitolato; ulteriori € 800,00 per avvenuto ripristino delle funzionalità entro la seconda ora di ritardo rispetto al tempo limite di risoluzione indicato nel presente Capitolato; ulteriori € 1600,00 per avvenuto ripristino delle funzionalità entro la terza ora di ritardo rispetto al tempo limite di risoluzione indicato nel presente Capitolato; ulteriori € 3200,00 per ogni successiva ora (dalla quarta ora compresa in poi) di ritardo rispetto al tempo limite di risoluzione indicato nel presente Capitolato;

2. Gravità 2 – il ritardo rispetto al valore limite verrà considerato giornata intera e verrà applicata una penale pari ad € 200,00 per ogni giorno di ritardo rispetto al tempo limite di risoluzione indicato nel presente Capitolato;

(14)

Pag. 14 di 23 3. Gravità 3 – il ritardo rispetto al valore limite verrà considerato giornata intera e verrà applicata una penale pari ad € 100,00 per ogni giorno di ritardo rispetto al tempo limite di risoluzione indicato nel presente Capitolato.

3.

Penali manutenzione evolutiva standard

e Forniture Supplementari

Le penali previste per i ritardi nella gestione della manutenzione evolutiva e forniture supplementari possono essere applicate fino ad un massimo di:

● €. 50,00 per ogni giorno successivo al 10° giorno lavorativo nella emissione di un preventivo da parte del Fornitore da calcolarsi da quando le specifiche tecnico-funzionali complete ed esaustive sono state formalmente inviate al fornitore;

● €. 100,00 per ogni giorno lavorativo di ritardo nella consegna di modifiche autorizzate, da calcolarsi dalla data in cui viene inviata al fornitore formale autorizzazione a procedere; si precisa che la data limite per la consegna non può ovviamente essere definita unilateralmente dal fornitore per non incorrere nell’applicazione delle penali e che essa deve essere concordata tra Cliente e Fornitore ; si ritiene a tal proposito congruo un tempo di consegna pari a N° 5 volte l'effort della modifica richiesta (ad es. per una modifica quotata in 4gg/uomo di sviluppo si ritiene congruo un tempo di realizzazione/consegna massimo pari a N° 20gg lavorativi oltre i quali il Cliente si riserva di applicare la penale), salvo diversi accordi tra le parti.

4.

Penali manutenzione normativa standard

Le penali previste per i ritardi nella gestione della manutenzione normativa che prevede la quotazione della modifica (MEV o fornitura supplementare) possono essere applicate fino ad un massimo di:

● €. 100,00 per ogni giorno lavorativo di ritardo nella consegna di modifiche autorizzate, da calcolarsi dalla data in cui viene inviata al fornitore formale autorizzazione a procedere; si precisa che la data limite per la consegna non può ovviamente essere definita unilateralmente dal fornitore per non incorrere nell’applicazione delle penali e che essa deve essere concordata tra Cliente e Fornitore; si ritiene a tal proposito congruo un tempo di consegna pari a N° 5 volte l'effort della modifica richiesta (ad es. per una modifica quotata in 4gg/uomo di sviluppo si ritiene congruo un tempo di realizzazione/consegna massimo pari a N° 20gg lavorativi oltre i quali il Cliente si riserva di applicare la penale), salvo diversi accordi tra le parti.

Le penali previste per i ritardi nella gestione della manutenzione normativa che non prevede la quotazione della modifica (MEV) possono essere applicate fino ad un massimo di:

● €. 500,00 per ogni giorno lavorativo successivo alla data di attuazione prevista dalla normativa o (nel caso di diverso accordo tra le parti) dalla data formalmente concordata per l’avvio

5. Penali manutenzione evolutiva o normativa urgente

Il Responsabile dell’Esecuzione o il DEC hanno facoltà di formalizzare al Fornitore eventuali richieste di manutenzione evolutiva e/o normativa da soddisfare in regime di urgenza, garantendo che l’ammontare delle giornate destinate a questo fabbisogno non sia superiore al 20% del totale delle giornate contrattualizzate.

In tal caso, sul modulo ‘Software Change Request’, sarà riportata la dicitura ‘Richiesta URGENTE – Riferimento paragrafo J.5 delle Linee Guida Manutenzione e Assistenza Software’.

(15)

Pag. 15 di 23 In tal caso, le penali previste per i ritardi nella gestione della manutenzione evolutiva e/o normativa possono essere applicate fino ad un massimo di:

● €. 200,00 per ogni giorno lavorativo di ritardo nella consegna di modifiche autorizzate, da calcolarsi dalla data in cui viene inviata al fornitore formale autorizzazione a procedere (intendendosi per essa anche il solo invio del modulo MEV autorizzato); si precisa che la data limite per la consegna non può ovviamente essere definita unilateralmente dal fornitore per non incorrere nell’applicazione delle penali e che essa deve essere concordata tra Cliente e Fornitore; si ritiene a tal proposito congruo un tempo di consegna pari a N°

2,5 volte l'effort della modifica richiesta (ad es. per una modifica quotata in 4gg/uomo di sviluppo si ritiene congruo un tempo di realizzazione/consegna massimo pari a N° 10gg lavorativi oltre i quali il Cliente si riserva di applicare la penale), salvo diversi accordi tra le parti.

6.

Importi trattenuti a titolo di Penale

L’Azienda è autorizzata a trattenere l’importo di dette penali dalle fatture presentate dall’Impresa fornitrice o a richiedere diversa modalità di pagamento. L’Azienda ha facoltà di rifiutare la prestazione eseguita in ritardo.

Qualora il fornitore della manutenzione del software:

● non utilizzi un sistema di trouble ticketing, oppure il sistema di ticketing non sia adeguato alle richieste

● non vengano fornite le informazioni richieste nel presente capitolato per il controllo degli SLA

il Direttore dell'Esecuzione ha la facoltà di non autorizzare il pagamento delle fatture del fornitore fino alla completa messa in regola del sistema di ticketing e alla regolare produzione della reportistica richiesta.

Si evidenzia che ESTAR e/o le Aziende hanno facoltà di addebitare al fornitore eventuali costi indotti che le Aziende devono sostenere per il ripristino della funzionalità; es.:

● a causa dell’interruzione del servizio per consentire l’aggiornamento del software, l’Azienda addebiterà al fornitore il costo del lavoro mancato eventualmente aumentato dello straordinario che e’ risultato necessario;

Se per consentire l’aggiornamento del software il fornitore deve lavorare al di fuori delle ore lavorative per il rispetto degli SLA contrattuali, gli eventuali extracosto che il fornitore deve sostenere non sono a carico delle Aziende Clienti.

Nel caso in cui a danno delle Aziende Sanitarie e di ESTAR si determinano:

● sanzioni civili, perdite economiche, gravi ripercussioni sull’immagine

● interruzione del servizio con conseguenti danni economici e di immagine

da imputare alla mancata ottemperanza del servizio, totale o parziale, con le modalità e i Livelli di Servizio definiti nel presente documento, il Fornitore dovrà pagare il risarcimento completo del danno.

In caso di inadempienze gravi o nel caso in cui le penali superino il 10% complessivo dell’importo contrattuale da fatturare nel periodo di riferimento, l’Ente ha facoltà di risolvere il contratto senza obbligo di messa in mora.

J)

Rischio Clinico

Il rischio è il risultato di una combinazione di probabilità e di danni, aventi valenza economica e di immagine. Il rischio in sanità riguarda un insieme di eventi assai diversificato; essi possono derivare, infatti, da fonti molto diverse, ma il manifestarsi di eventi avversi, ha, nella maggior parte dei casi, una rilevanza economica e, quindi, l’impegno nella prevenzione del rischio clinico rappresenta un investimento per il sistema sanitario.

(16)

Pag. 16 di 23 Per tutto il periodo contrattuale qualora si verifichino degli eventi categorizzati con qualsiasi livello di rischio clinico, citiamo, senza pretesa di esaustività:

● Disallineamenti paziente / dati tra sistemi informatici

● Scambio di referti/pazienti su un software diagnostico o in una integrazione tra software

● Errori nella prescrizione/somministrazione di una terapia e/o errori sugli allarmi / alert

● Errori/ritardi nella trasmissione di una richiesta di esami

● Errori nella integrazione di molteplici tecnologie medicali (per es. Errori nell’integrazione tra software diagnostici e sanitari sia in input che in output)

● Errate indicazione nelle politiche di backup e recovery dei dati sanitari

Il Responsabile dell'Esecuzione ha facoltà di applicare al fornitore una penalità nella misura che va dal 1% al 10% del valore del contratto di manutenzione e assistenza annuale, da valutarsi in base alla gravità dell'evento e al danno subito dall'Ente, ivi compreso il danno di immagine.

K)

Appendice A

1.

Premessa

Obiettivo della Appendice A è definire le linee guida entro le quali l’Area Infrastrutture, Processi e Flussi governa le attività di assistenza e manutenzione dei sistemi delle Aziende Sanitarie Toscane. Tali linee guida devono ritenersi vincolo e possibilità per tutti gli attori coinvolti nei processi di gestione delle attività di manutenzione dei sistemi informatici a supporto delle Aziende stesse. Per una corretta definizione di piani di manutenzione e degli SLA in essi contenuti, si individuano alcune linee guida generali che sono da ritenersi vincoli minimi per l'erogazione dei servizi di manutenzione.

2.

Servizi del Fornitore per servizio di manutenzione

Lo SLA deve riportare i metodi utilizzati per la comunicazione fra il committente e l'esecutore della manutenzione.

Servizio Descrizione Servizio SLA del Servizio Figura

Professionale

Personale del fornitore che esegue materialmente la manutenzione

Lista delle figure professionali coinvolte

Stati

Avanzamento

Riunione di

verifica/pianificazione con la figura di riferimento di fornitore

Almeno 1 volta al mese

Ingaggio servizio manutenzione

Il fornitore deve predisporre a suo carico almeno un un indirizzo e-mail e

un

numero verde attivo nelle fasce orarie del servizio come richiesto dal capitolato

Risposta telefonica garantita entro un minuto dalla chiamata

Risposta mail garantita entro 10 minuti dalla comunicazione

Accesso a servizi di reporting

Il fornitore deve predisporre a suo carico un cruscotto di monitoraggio in formato elettronico, che Estar possa rielaborare, sull'andamento del servizio di manutenzione

Almeno 1 volta al mese

Tabella 1 - Servizi Fornitori

(17)

Pag. 17 di 23 3.

Modalità di intervento del Fornitore per servizio di manutenzione

Lo SLA deve riportare quali siano i metodi adottati dal fornitore per garantire gli interventi ed i tempi proposti.

Devono essere garantite almeno quattro modalità di intervento:

● Intervento da remoto in totale autonomia

● Intervento da remoto con supporto di altre risorse

● Intervento on-site in totale autonomia

● Intervento on-site con supporto di altre risorse

Lo SLA deve riportare i casi nei quali l'intervento da remoto può risultare limitato, ad esempio perché sono consentiti solamente accessi a porte/protocolli specifici in base alle politiche sulla sicurezza, oppure perché l'infrastruttura di rete che permette accesso remoto non è sotto controllo da parte di ESTAR e non è garantibile quindi la raggiungibilità.

L’impossibilità di intervento da remoto, qualsiasi sia la causa, non può costituire in alcun caso motivo di modifica dei tempi di intervento garantiti. In tali situazioni, il fornitore deve garantire l'immediato intervento on-site.

Il fornitore, nell’utilizzo delle reti e dei sistemi SSR, garantisce il rispetto della PA 90/2020 ESTAR e delle Linee Guide T.I. ESTAR aggiornate e vigenti al momento del deployment del prodotto, garantendo di adeguarsi alle variazioni che dovessero intervenire in corso di validità del contratto.

4.

Metodi oggettivi di misurazione delle performances

Per ognuno dei macro-oggetti identificati nello SLA, devono essere declinati i metodi di misurazione delle performances dell'oggetto stesso. Il fornitore deve presentare dei report con cadenze fissate nello SLA (minimo mensilmente), fra i quali quello sulle performances dei sistemi in manutenzione.

5.

Risorse dedicate al supporto sistemistico

Il fornitore deve riportare quali siano le figure professionali che saranno coinvolte nel supporto sistemistico delle applicazioni ESTAR. Senza pretesa di esaustività le figure professionali possono essere: DBA, Sistemista di Rete, Sistemista Windows/Unix/Linux.

6.

Definizione degli elementi HW / SW oggetto di manutenzione

Il fornitore nella proposta deve dettagliare le caratteristiche delle componenti hw e sw che sono necessarie per l’erogazione del servizio del sistema. A titolo esemplificativo, senza pretesa di esaustività, si riportano i dettagli HW / SW richiesti.

Component

e HW Specifiche Componenti HW Dettaglio Richiesta Web Server

● Configurazioni parametri di OS non standard

● Dettaglio Risorse aggiuntive rispetto a configurazione Standard

Lista parametri di configurazione con valore richiesto

Lista risorse aggiuntive richieste (scheda di rete aggiuntiva, RAM aggiuntiva, etc)

Application Server

● Apertura porte di rete

Integration Server

● Apertura porte di rete

Database Server

Lista risorse aggiuntive richieste (scheda di rete aggiuntiva, RAM

(18)

Pag. 18 di 23

● Apertura porte di rete aggiuntiva, etc) Apparati

controller

● Politiche di Configurazione Accesso (i.e.

WiFi)

● Politiche di Configurazione Accesso (i.e.

Domini)

Documento Specifiche politiche di accesso

Firewall ● Regole firewall

● Regole di Natting

Lista delle regole su firewall Lista regole di Natting

Client PDL

● Caratteristiche di Lettori di carte

● Caratteristiche delle carte di firma

● Caratteristiche codici a barre, sw di firma

Caratteristiche Hw delle periferiche richieste

Client Medicale

● Caratteristiche apparato

● Caratteristiche del montaggio/

disinfezione apparato

Descrizione delle caratteristiche apparato

Tabella 2- Specifiche Componenti HW

Componente

SW Caratteristiche del Componente Dettaglio Richiesta Web

Server

● Configurazioni parametri del sw di base non standard

● Log del sw di base

● Log applicativi

Applicatio n Server

● Configurazioni parametri del sw di base non standard (Java, Tomcat, etc)

● Log applicativi

Integration Server

● Configurazioni parametri del sw di base non standard

● Log applicativi

Database Server

● Configurazioni parametri di DB non standard

● Storage richiesto per dati con proiezione a 1 / 3 anni

● Tuning DB (in fase di test)

Client PDL ● Caratteristiche sw di firma

● Caratteristiche / Configurazione Java

Caratteristiche Hw delle periferiche richieste

Tabella 3 - Specifiche Componenti SW (*)

(*) In ogni caso il fornitore deve fornire la garanzia di funzionalità con sistemi operativi client e Server presenti sul parco macchine aziendale, compresi i nuovi sistemi operativi rilasciati durante il periodo di validità del contratto.

7.

Definizione delle interfacce di amministrazione applicativi

Gli applicativi in ambito al contratto di manutenzione devono includere le necessarie funzionalità, erogate mediante interfaccia client (o User Interface), a supporto degli amministratori di

applicativo per l’esecuzione delle attività di amministrazione sul sistema (ad esempio Creazione e Profilazione utenti, definizioni profili, etc).

8.

Definizione delle tipologie di manutenzione sulle componenti architetturali

Quanto indicato nel presente paragrafo si applica nel caso in cui l’Azienda Sanitaria o ESTAR acquisisca dal fornitore del software anche l’ ”Estensione del servizio di assistenza e manutenzione a sistemi operativi, RDBMS, etc. (infrastruttura erogata in modalità IAAS)”.

(19)

Pag. 19 di 23 La particolarità più rilevante di questo servizio è che il fornitore assume piena e totale responsabilità del mantenimento dei Livelli di Servizio contrattualizzati, operando però non solo a livello applicativo ma sostanzialmente su tutti i componenti e i livelli dello stack sistemistico, a esclusione di quelli strettamente infrastrutturali (es.: rete, componenti di data center quali ambiente di virtualizzazione, storage, etc.), gestiti da ESTAR o da uno dei fornitori.

In ogni caso il fornitore opera in autonomia sulle risorse assegnate, con l’obiettivo sia di assicurare gli SLA, sia di mantenere una adeguata efficienza e operatività dei sistemi in gestione, al fine di preservarne le funzionalità evitando sprechi e aderire alle normative di legge previste (GDPR), in coerenza con le linee guida condivise con ESTAR (nomenclatura, gestione utenti, raccolta log di accesso, gestione condivisioni, metodologie di backup, etc.).

In caso di problemi oltre l'ambito di operatività assegnato, il fornitore attiva una procedura di escalation definita con ESTAR, a fronte di una reportistica con la quale dimostra di aver provveduto ad effettuare tutte le azioni di manutenzione correttiva che hanno portato a individuare la necessità di una precisa azione a livello infrastrutturale (es. aggiunta di un disco, riavvio del sistema, apertura porta firewall, etc.)

Di seguito vengono riportate, a titolo esemplificativo ma non esaustivo, alcune delle azioni che devono comunque far parte delle attività di manutenzione dei sistemi e dei database.

Componenti di ambito Sistemi

Lo scopo della manutenzione del sistema operativo è quello di garantire un adeguato livello di performance e di funzionamento del Sistema Operativo. Per questo è necessario che il fornitore definisca e attui un “piano di manutenzione”, cioè definisca e attui metodicamente l’esecuzione di una serie di azioni, con lo scopo di ripristinare all’occorrenza situazioni di degrado o di prevenire il verificarsi di situazioni di sofferenza o scarsità di risorse.

ESTAR predispone i sistemi secondo quanto concordato in un “landscape” che definisce le risorse (CPU, memoria, storage, network) e assicura il primo aggiornamento del sistema operativo e l’istallazione delle componenti necessarie a garantire un adeguato livello di protezione di sicurezza (Antivirus, Firewall) secondo le politiche aziendali. Vengono quindi predisposte le procedure di autenticazione che permettono al fornitore l’accesso ai sistemi con un profilo di amministratore, tramite la definizione puntuale degli utenti nominativi indicati dal fornitore stesso. E’ sua responsabilità l’uso corretto delle utenze e delle risorse assegnate, in adempienza della normativa vigente (GDPR).

Una volta effettuato il collaudo applicativo, la gestione del sistema passa completamente sotto la responsabilità del fornitore. La manutenzione riguarda sia gli ambienti che compongono il landscape applicativo, quindi sia le macchine di produzione, sia le macchine di test e collaudo.

In generale gli interventi di manutenzione dovrebbero essere effettuati nei periodi di bassa operatività dell’applicazione o del servizio erogati, in modo da limitare l’impatto. Nel caso in cui invece un impatto è inevitabile (riavvio, fermo macchina, attività di durata significativa, etc.) è necessario procedere ad una programmazione dell’intervento, coinvolgendo le strutture di riferimento (ESTAR e aziendali).

Infine, è da prevedere nella gestione sistemistica ordinaria anche una eventuale attività di analisi e trouble shooting di problematiche che coinvolgono lo stesso sistema non direttamente ma, ad esempio, in funzioni di integrazione del prodotto con altri prodotti/applicazioni anche di terzi.

Di seguito il dettaglio delle tipologie di manutenzione e le caratteristiche.

Tipologia di Caratteristiche della manutenzione

(20)

Pag. 20 di 23 Manutenzione

Ordinaria

● Aggiornamenti di sistema obbligatori o raccomandati o su mandato di ESTAR

● Istallazione delle patch di sicurezza.

● In generale l’istallazione o l’aggiornamento di un componente, individuato come necessario, deve essere preceduto da una analisi di compatibilità con il servizio o l’applicazione forniti dal server, eventualmente (e auspicabilmente) anche con una fase di test e verifica preventiva. In caso di situazioni di incompatibilità, il fornitore deve comunque scalare il problema al livello della manutenzione applicativa, promuovendo e proponendo a seconda del caso una azione di manutenzione evolutiva o correttiva dell’applicazione stessa, con lo scopo finale dell’aggiornamento dell’intero sistema.

● Controllo dello stato di aggiornamento della componente Antivirus e esecuzione delle azioni richieste in caso di necessità di riavvio del sistema o di esecuzioni di azioni manuali di scansione dei dati

● Monitoraggio proattivo sullo stato, sulla saturazione e sugli errori delle risorse Memoria, Processore e Storage e Network

● Controllo degli eventi e log di sistema

● Gestione dei log con politiche log rotation quando ritenuto opportuno oppure ridimensionamento periodico dei file di log

● Definizione, aggiornamento e esecuzione delle procedure di backup / recovery dei dati. Fa parte dell’attività la verifica della corretta

esecuzione delle procedure e la revisione dei log delle procedure al fine di assicurarne l’esecuzione con successo o rilevare casi di anomalie e quindi attivare azioni di recupero.

●

Correttiva

● Analisi, tuning e dispiegamento delle azioni necessarie in caso di malfunzionamenti applicativi imputabili a problemi del sistema, sia nel caso di degrado delle performance o più in generale per situazioni di compatibilità con altre componenti (driver, agenti, antivirus, patch, etc). Nel caso in cui il problema fosse imputabile alla infrastruttura che ospita il sistema, il fornitore deve produrre un report con tutte le informazioni contestuali e le attività svolte a riprova che il problema non è risolubile operando solo sull’ambito del prodotto specifico

● Manutenzione dello storage con attività di deframmentazione, partizionamento, estensione delle partizioni fisiche e logiche, sharing nfs, etc.) se consentito da ESTAR come gestore dell’Infrastruttura

● Analisi delle segnalazioni Antivirus (provenienti da sistema centralizzato o locale) e adozione immediata delle misure correttive/preventive suggerite (aggiornamento, patch di sicurezza, disinstallazione di componenti o eliminazione di file, etc).

● Esecuzione della procedura di recovery a fronte di necessità di recupero di parte del sistema operativo o di dati

●

Evolutiva

● Tutte le azioni, configurazioni e interventi necessari ma che non possono essere eseguite e completate all’interno di attività di manutenzione ordinaria o preventiva

●

Normativa

● Rientrano in questa categoria tutte le azioni e configurazioni necessarie per adeguare la configurazione del sistema alle disposizioni di legge nazionali, regionali o locali.

●

A puro titolo esemplificativo, si riassumono di seguito le principali attività in carico al fornitore, contrassegnate con "X"; per quanto non rappresentato in tabella sottostante, vale quanto meglio dettagliato sopra:

(21)

Pag. 21 di 23

Componenti di ambito Database

La componente database riveste particolare criticità in quanto il corretto funzionamento

garantisce tempi di risposta applicativi secondo gli SLA concordati e la conservazione dei dati. Il presente paragrafo include la classificazione delle operazioni di manutenzione sui database, nei due casi di

●

gestione centralizzata ovvero gestione, configurazione, amministrazione e manutenzione della istanza di un database in carico ad Estar (es. unico cluster Oracle che gestisce più

applicazioni di più fornitori)

●

gestione demandata ovvero gestione, configurazione, amministrazione e manutenzione della istanza di un database in carico al fornitore

In particolare, tutte le operazioni indicate si intendono a carico del fornitore nel caso di gestione demandata; quelle indicate con (C) sono da intendersi a carico del fornitore come le sole

applicabili in caso di gestione centralizzata del database:

Tipologia di

Manutenzione Caratteristiche della manutenzione

Ordinaria

● ( C ) Applicazione delle patch raccomandate da produttore su software di base

● ( C ) Aggiornamento software di base del database

● ( C ) Creazione e manutenzione delle procedure di backup / recovery dei dati

● ( C ) Gestione degli ambienti di sviluppo e collaudo (incluso anche ambienti di test, duplicazioni, etc)

● ( C ) Seguito operativo a richieste utente di verifica dati in produzione, per sospetta anomalia di funzionalità

● Estrazioni dati occasionali al fine di ottenere informazioni non ottenibili tramite il software applicativo

● Piena gestione delle utenze database (creazione/cancellazione oggetti, grant, etc)

● ( C ) Tuning proattivo del database per garantire le prestazioni ottimali al variare / evolversi delle funzionalità applicative

● Modifica delle strutture dello schema utente del database nel caso di utilizzo di strutture diventate obsolete e non supportate

● ( C ) Monitoraggio proattivo delle necessità di storage

● Monitoraggio e implementazione di procedure di archiviazione / storicizzazione dei dati su nuove funzionalità

● ( C ) Aggiornamento / manutenzione delle procedure di backup / recovery dei dati

● Realizzazione di ulteriori funzionalità volte a soddisfare le esigenze dell’utente (inserimento di nuove funzionalità non presenti nell’attuale sistema e/o la modifica delle funzioni previste dall’attuale architettura)

● Garanzia di funzionalità con SO client e Server presenti sul parco macchine aziendale, compresi i nuovi sistemi operativi rilasciati